From d7e80d4c929c1686500dcf5fa3c2c3c66db6969d Mon Sep 17 00:00:00 2001 From: Michiel de Jong Date: Fri, 5 Apr 2024 13:08:56 +0200 Subject: [PATCH] Spec is in Google Docs for the time being --- phase-2/spec/build.js | 50 ------------- phase-2/spec/out.txt | 153 ---------------------------------------- phase-2/spec/source.txt | 100 +------------------------- 3 files changed, 2 insertions(+), 301 deletions(-) delete mode 100644 phase-2/spec/build.js delete mode 100644 phase-2/spec/out.txt diff --git a/phase-2/spec/build.js b/phase-2/spec/build.js deleted file mode 100644 index 7cf0df0..0000000 --- a/phase-2/spec/build.js +++ /dev/null @@ -1,50 +0,0 @@ -const version = 1; -const day = 19; -const expiresDay = 1; -const fileName = `./out.txt`; - -if (version % 2 === 0) { - month = 'October'; - expiresMonth = 'April'; -} else { - month = 'April'; - expiresMonth = 'October'; -} -const year = Math.floor(2024 + (version - 1) / 2); -const expiresYear = Math.floor(2013 + version / 2); -const date = `${day} ${month} ${year}`; -const expires = `${expiresDay} ${expiresMonth} ${expiresYear}`; -const monthYear = (month === 'June' ? ' ' : '') + month + ' ' + year; - -var fs = require('fs'), - lines = fs.readFileSync('source.txt').toString().split('\n'), - breaker1a = '\n\n [Page ', - breaker1b = '\n\n [Page ', - breaker2 = ']', - breaker3 = '\n \nInternet-Draft OAuth Scope Info '+ monthYear + '\n\n', - page = 1, line = 0; - -let outStream = fs.createWriteStream(fileName); - -while (line < lines.length) { - lines[line] = lines[line].split('${EXPIRES}').join(expires); - lines[line] = lines[line].split('${DATE}').join(date); - lines[line] = lines[line].split('${YEAR}').join(year); - lines[line] = lines[line].split('${VERSION}').join(version); - outStream.write(lines[line] + '\n'); - if (lines[line].length > 72) { - outStream.write('123456789012345678901234567890123456789012345678901234567890123456789012*****\n'); - break; - } - line++; - if (line > 7 && line%43 === 7) { - outStream.write((page < 10 ? breaker1a : breaker1b) + page + breaker2 + (line < lines.length ? breaker3 : '') + '\n'); - page++; - } -} -while (line%43 !== 7) { - outStream.write('\n'); - line++; -} -outStream.write((page < 10 ? breaker1a : breaker1b) + page + breaker2 + (line < lines.length ? breaker3 : '') + '\n'); -outStream.close(); diff --git a/phase-2/spec/out.txt b/phase-2/spec/out.txt deleted file mode 100644 index b2cbe88..0000000 --- a/phase-2/spec/out.txt +++ /dev/null @@ -1,153 +0,0 @@ - OAuth Scope Info - -Abstract - - We define the Resource Helper as a subsystem of an OAuth - authorization server. It can be included in an OAuth flow as a - - (hosted) implementations of OAuth authorization servers can make - this subsystem pluggable. - We further define the scope info data structure, which can convey - more detailed information than the unstructured strings in - an OAuth scopes parameter. The authorization server can retrieve - this data - structure from the Resource Helper, and use the information for it - to - display a scope label to the user, provide a scope info endpoint - to clients, - and include detailed scope information in introspection responses - to the - resource server. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 1 October 2013. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - - - [Page 1] - -Internet-Draft OAuth Scope Info April 2024 - - - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction...................................................2 - -1. Introduction - - The part of an OAuth authorization server that deals with scope - selection - is necessarily tied to the specifics of the resource server. In - some deployment - scenarios, where one authorization server deals with many diverse - resource servers, - it is therefore desirable to make this part of the authorization - server pluggable. - - To achieve this, we propose a plugin standard, as follows: - - * the Resource Helper provides an authorization endpoint and a - token info endpoint. - * in the administration interface where the authorization server - allows the registration of resource - servers, the authorization endpoint and token info endpoint of the - resource helper can also be defined - * as part of the main authorization dialog, the user is redirected - to the resource helper for scope selection - * the user is redirected back to the main authorization dialog with - a code - * this code gives access to the token info endpoint in the same way - it would give access to a token endpoint - - The data returned from this scope info endpoint is a JSON document - representing an object containing the following fields: - * type [REQUIRED]: 'informational' - * id [OPTIONAL]: string to be added into the scopes parameter - * label [REQUIRED]: string to be displayed to the resource owner in - the rest of the authorization dialog - * protocols [OPTIONAL]: similar to the protocols entry in an Open - Cloud Mesh share definition - * introspect [OPTIONAL]: additional info to pass to the Resource - server - - - [Page 2] - -Internet-Draft OAuth Scope Info April 2024 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Page 3] diff --git a/phase-2/spec/source.txt b/phase-2/spec/source.txt index 5300539..d3f1888 100644 --- a/phase-2/spec/source.txt +++ b/phase-2/spec/source.txt @@ -1,98 +1,2 @@ - OAuth Scope Info - -Abstract - - We define the Resource Helper as a subsystem of an OAuth - authorization server. It can be included in an OAuth flow as a - - (hosted) implementations of OAuth authorization servers can make - this subsystem pluggable. - We further define the scope info data structure, which can convey - more detailed information than the unstructured strings in - an OAuth scopes parameter. The authorization server can retrieve - this data - structure from the Resource Helper, and use the information for it - to - display a scope label to the user, provide a scope info endpoint - to clients, - and include detailed scope information in introspection responses - to the - resource server. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on ${EXPIRES}. - -Copyright Notice - - Copyright (c) ${YEAR} IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction...................................................2 - -1. Introduction - - The part of an OAuth authorization server that deals with scope - selection - is necessarily tied to the specifics of the resource server. In - some deployment - scenarios, where one authorization server deals with many diverse - resource servers, - it is therefore desirable to make this part of the authorization - server pluggable. - - To achieve this, we propose a plugin standard, as follows: - - * the Resource Helper provides an authorization endpoint and a - token info endpoint. - * in the administration interface where the authorization server - allows the registration of resource - servers, the authorization endpoint and token info endpoint of the - resource helper can also be defined - * as part of the main authorization dialog, the user is redirected - to the resource helper for scope selection - * the user is redirected back to the main authorization dialog with - a code - * this code gives access to the token info endpoint in the same way - it would give access to a token endpoint - - The data returned from this scope info endpoint is a JSON document - representing an object containing the following fields: - * type [REQUIRED]: 'description' - * id [OPTIONAL]: string to be added into the scopes parameter - * label [REQUIRED]: string to be displayed to the resource owner in - the rest of the authorization dialog - * protocols [OPTIONAL]: similar to the protocols entry in an Open - Cloud Mesh share definition - * introspect [OPTIONAL]: additional info to pass to the Resource - server - - The authorization server can also provide a scope info endpoint to - clients, but then the type field should be set to 'grant'. This - indicates that the resource helper only describes the scope, whereas - the authorization server gives out scoped access grants. \ No newline at end of file +(moved to Google Docs) +https://docs.google.com/document/d/12vt-TC1ivaweqJVfnhi3ayxYYnEYsfGYx7gNjIwVu6w/edit?usp=sharing \ No newline at end of file