Hi, These changes are complete:
https://www.iana.org/assignments/gnap thanks, Amanda Baber IANA Operations Manager On Fri Apr 18 22:45:37 2025, kmo...@staff.rfc-editor.org wrote: > Dear IANA, > > Please make the following updates under the "Grant Negotiation and > Authorization Protocol (GNAP)” registry group > (https://www.iana.org/assignments/gnap) to match the edited document > (https://www.rfc-editor.org/authors/rfc9767-diff.html). > > 1) In the "GNAP Resource Set Registration Request Parameters” > registry: > > OLD: > token_formats_supported > string > [RFC-ietf-gnap-resource-servers-09, Section 3.4] > > NEW: > token_formats_supported > array of strings > [RFC-ietf-gnap-resource-servers-09, Section 3.4] > > 2) In the "GNAP Resource Set Registration Request Parameters” > registry: > > OLD: > resource_server > string or object > [RFC-ietf-gnap-resource-servers-09, Section 3.4] > > NEW: > resource_server > object/string > [RFC-ietf-gnap-resource-servers-09, Section 3.4] > > Thank you in advance! > RFC Editor/kc > > > > On Apr 18, 2025, at 3:42 PM, Karen Moore <kmo...@staff.rfc- > > editor.org> wrote: > >> > >> Hi Fabien, > >> > >> Thank you for providing your approval. We have updated the AUTH48 > >> status page accordingly. > >> > >> We now have all necessary approvals and will ask IANA to update > >> their registries to match the edited document. When the updates are > >> complete, we will inform you. > >> > >> Note that we made the following update to Section 5.6.2: > >> > >> OLD: > >> resource_server > >> string or object > >> > >> NEW: > >> resource_server > >> object/string > >> > >> —FILES (please refresh)— > >> > >> The updated XML file is here: > >> https://www.rfc-editor.org/authors/rfc9767.xml > >> > >> The updated output files are here: > >> https://www.rfc-editor.org/authors/rfc9767.txt > >> https://www.rfc-editor.org/authors/rfc9767.pdf > >> https://www.rfc-editor.org/authors/rfc9767.html > >> > >> These diff files show all changes made during AUTH48: > >> https://www.rfc-editor.org/authors/rfc9767-auth48diff.html > >> https://www.rfc-editor.org/authors/rfc9767-auth48rfcdiff.html (side > >> by side) > >> > >> These diff files show all changes made to date: > >> https://www.rfc-editor.org/authors/rfc9767-diff.html > >> https://www.rfc-editor.org/authors/rfc9767-rfcdiff.html (side by > >> side) > >> > >> For the AUTH48 status of this document, please see: > >> https://www.rfc-editor.org/auth48/rfc9767 > >> > >> Best regards, > >> RFC Editor/kc > >> > >> > >>> On Apr 18, 2025, at 11:47 AM, Fabien Imbault > >>> <fabien.imba...@gmail.com> wrote: > >>> > >>> Hi Karen, > >>> > >>> I have indeed reviewed the document and it looks good. Hopefully > >>> I'll implement it soon (btw Justin, now gnap is in testing at > >>> ssi.gouv.fr ;-)) > >>> > >>> Cheers > >>> Fabien > >>> > >>> > >>> On Thu, 17 Apr 2025, 21:55 Karen Moore, <kmo...@staff.rfc- > >>> editor.org> wrote: > >>> Hi Fabien, > >>> > >>> Per your response, we believe you are currently reviewing the > >>> document; however, if your review is complete and you approve the > >>> document in its current form, please let us know. > >>> > >>> Thanks! > >>> RFC Editor/kc > >>> > >>>> On Apr 16, 2025, at 5:33 PM, Fabien Imbault > >>>> <fabien.imba...@gmail.com> wrote: > >>>> > >>>> Hi Karen, hi Justin, > >>>> > >>>> That's good, thanks a lot. > >>>> > >>>> Best regards > >>>> Fabien > >>>> > >>>> > >>>> On Wed, 16 Apr 2025, 22:01 Karen Moore, <kmo...@staff.rfc- > >>>> editor.org> wrote: > >>>> Hi Justin, > >>>> > >>>> We have noted your approval on the AUTH48 status page for this > >>>> document (https://www.rfc-editor.org/auth48/rfc9767). We now > >>>> await Fabien’s approval prior to moving forward with the > >>>> publication process. > >>>> > >>>> Additionally, please let us know if you would like to add any > >>>> keywords (beyond those that appear in the title) for use on > >>>> https://www.rfc-editor.org/search. > >>>> > >>>> Best regards, > >>>> RFC Editor/kc > >>>> > >>>>> On Apr 16, 2025, at 9:40 AM, Justin Richer <jric...@mit.edu> > >>>>> wrote: > >>>>> > >>>>> All, > >>>>> > >>>>> I’ve read through the changes and I approve this version of the > >>>>> document for final publication. > >>>>> > >>>>> Fabien, please review (especially the final diff at > >>>>> https://www.rfc-editor.org/authors/rfc9767-rfcdiff.html) and let > >>>>> us know where you stand on the changes and content. > >>>>> > >>>>> Thank you, everyone. > >>>>> > >>>>> — Justin > >>>>> > >>>>>> On Apr 14, 2025, at 1:55 PM, Karen Moore <kmo...@staff.rfc- > >>>>>> editor.org> wrote: > >>>>>> > >>>>>> Hi Justin, > >>>>>> > >>>>>> Thank you for your reply. We have updated our files > >>>>>> accordingly. Please review and let us know if any further > >>>>>> changes are needed or if you approve the document in its current > >>>>>> form. We will await approvals from each author prior to moving > >>>>>> forward in the publication process. > >>>>>> > >>>>>> --FILES-- > >>>>>> > >>>>>> The updated XML file is here: > >>>>>> https://www.rfc-editor.org/authors/rfc9767.xml > >>>>>> > >>>>>> The updated output files are here: > >>>>>> https://www.rfc-editor.org/authors/rfc9767.txt > >>>>>> https://www.rfc-editor.org/authors/rfc9767.pdf > >>>>>> https://www.rfc-editor.org/authors/rfc9767.html > >>>>>> > >>>>>> These diff files show all changes made during AUTH48: > >>>>>> https://www.rfc-editor.org/authors/rfc9767-auth48diff.html > >>>>>> https://www.rfc-editor.org/authors/rfc9767-auth48rfcdiff.html > >>>>>> (side by side) > >>>>>> > >>>>>> These diff files show all changes made to date: > >>>>>> https://www.rfc-editor.org/authors/rfcXXXX-diff.html > >>>>>> https://www.rfc-editor.org/authors/rfc9767-rfcdiff.html (side by > >>>>>> side) > >>>>>> > >>>>>> Note that it may be necessary for you to refresh your browser to > >>>>>> view the most recent version. Please review the document > >>>>>> carefully to ensure satisfaction as we do not make changes once > >>>>>> it has been published as an RFC. > >>>>>> > >>>>>> For the AUTH48 status of this document, please see: > >>>>>> https://www.rfc-editor.org/auth48/rfc9767 > >>>>>> > >>>>>> Thank you, > >>>>>> RFC Editor/kc > >>>>>> > >>>>>> > >>>>>>> On Apr 11, 2025, at 2:14 PM, Justin Richer via auth48archive > >>>>>>> <auth48archive@rfc-editor.org> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Apr 10, 2025, at 2:58 PM, rfc-edi...@rfc-editor.org wrote: > >>>>>>>> > >>>>>>>> Authors, > >>>>>>>> > >>>>>>>> While reviewing this document during AUTH48, please resolve > >>>>>>>> (as necessary) the following questions, which are also in the > >>>>>>>> XML file. > >>>>>>>> > >>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that > >>>>>>>> appear in > >>>>>>>> the title) for use on https://www.rfc-editor.org/search. --> > >>>>>>>> > >>>>>>>> > >>>>>>>> 2) <!--[rfced] We changed this paragraph into smaller > >>>>>>>> sentences > >>>>>>>> for easier reading and arranged the list of items in > >>>>>>>> alphabetical > >>>>>>>> order. Please let us know of any objections. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Terminology specific to GNAP is defined in the terminology > >>>>>>>> section of > >>>>>>>> the core specification [GNAP], and provides definitions for > >>>>>>>> the > >>>>>>>> protocol roles: authorization server (AS), client, resource > >>>>>>>> server > >>>>>>>> (RS), resource owner (RO), end user; as well as the protocol > >>>>>>>> elements: > >>>>>>>> attribute, access token, grant, privilege, protected resource, > >>>>>>>> right, > >>>>>>>> subject, subject information. The same definitions are used in > >>>>>>>> this > >>>>>>>> document. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> Terminology specific to GNAP is defined in the terminology > >>>>>>>> section of > >>>>>>>> the core specification [GNAP]. The following protocol roles > >>>>>>>> are > >>>>>>>> defined: authorization server (AS), client, end user, > >>>>>>>> resource owner (RO), > >>>>>>>> and resource server (RS). The following protocol elements are > >>>>>>>> defined: > >>>>>>>> access token, attribute, grant, privilege, protected > >>>>>>>> resource, right, > >>>>>>>> subject, and subject information. The same definitions are > >>>>>>>> used in this > >>>>>>>> document. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> This change is fine. > >>>>>>> > >>>>>>>> > >>>>>>>> 3) <!--[rfced] To avoid the "[JWT]" citation being used as an > >>>>>>>> adjective, > >>>>>>>> may we update "[JWT] formatted token" to "JSON-formatted token > >>>>>>>> [JWT]" or "JSON Web Token [JWT]" or otherwise? Note that > >>>>>>>> there are > >>>>>>>> 9 instances in the document. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> In a [JWT] formatted token or a token introspection response, > >>>>>>>> this > >>>>>>>> corresponds to the iss claim. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> In a JSON-formatted token [JWT] or a token introspection > >>>>>>>> response, > >>>>>>>> this corresponds to the iss claim. > >>>>>>>> > >>>>>>>> Or: > >>>>>>>> In a JSON Web Token [JWT] or a token introspection response, > >>>>>>>> this corresponds to the iss claim. > >>>>>>>> --> > >>>>>>> > >>>>>>> Let’s go with: > >>>>>>> > >>>>>>> In the payload of a JSON Web Token [JWT] or a token > >>>>>>> introspection response, > >>>>>>> this corresponds to the iss claim. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 4) <!--[rfced] FYI, we updated the following text for clarity > >>>>>>>> and to make > >>>>>>>> the second sentence a complete sentence. Please review whether > >>>>>>>> the > >>>>>>>> updates are accurate. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> GNAP access tokens can have multiple data flags associated > >>>>>>>> with them > >>>>>>>> that indicate special processing or considerations for the > >>>>>>>> token. > >>>>>>>> For example, whether the token is a bearer token, or should be > >>>>>>>> expected to be durable across grant updates. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> GNAP access tokens can have multiple associated data flags > >>>>>>>> that > >>>>>>>> indicate special processing or considerations for a token. > >>>>>>>> For > >>>>>>>> example, the data flags can indicate whether a token is a > >>>>>>>> bearer > >>>>>>>> token or should be expected to be durable across grant > >>>>>>>> updates. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> The change is fine. > >>>>>>> > >>>>>>>> > >>>>>>>> 5) <!--[rfced] We updated "RS's" to "one or more RSs" in the > >>>>>>>> following > >>>>>>>> text. We also updated "from others usable at" to "from other > >>>>>>>> access tokens used at" in the first paragraph for consistency > >>>>>>>> with the second paragraph. Please let us know if any of these > >>>>>>>> changes are not correct. > >>>>>>>> > >>>>>>>> In addition, please review the remaining instances of "RS's" > >>>>>>>> and "AS's" > >>>>>>>> (singular possessive) throughout the document and let us know > >>>>>>>> if any > >>>>>>>> occurrences are intended to be plural. We have updated a few > >>>>>>>> instances, > >>>>>>>> e.g., "targeted to different RS's" -> "targeted to different > >>>>>>>> RSs". > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> When an access token is used for the grant continuation API > >>>>>>>> defined > >>>>>>>> in Section 5 of [GNAP] (the continuation access token) the > >>>>>>>> token > >>>>>>>> management API defined in Section 6 of [GNAP] (the token > >>>>>>>> management > >>>>>>>> access token), or the RS-facing API defined in Section 3 (the > >>>>>>>> resource server management access token), the AS MUST separate > >>>>>>>> these > >>>>>>>> access tokens from others usable at RS's. > >>>>>>>> [...] > >>>>>>>> > >>>>>>>> For continuation access tokens and token management access > >>>>>>>> tokens, a > >>>>>>>> client instance MUST take steps to differentiate these > >>>>>>>> special- > >>>>>>>> purpose access tokens from access tokens used at RS's. > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> When an access token is used for the grant continuation API > >>>>>>>> defined > >>>>>>>> in Section 5 of [GNAP] (the continuation access token), the > >>>>>>>> token > >>>>>>>> management API defined in Section 6 of [GNAP] (the token > >>>>>>>> management > >>>>>>>> access token), or the RS-facing API defined in Section 3 (the > >>>>>>>> resource server management access token), the AS MUST separate > >>>>>>>> these > >>>>>>>> access tokens from other access tokens used at one or more > >>>>>>>> RSs. > >>>>>>>> [...] > >>>>>>>> > >>>>>>>> For continuation access tokens and token management access > >>>>>>>> tokens, a > >>>>>>>> client instance MUST take steps to differentiate these > >>>>>>>> special- > >>>>>>>> purpose access tokens from access tokens used at one or more > >>>>>>>> RSs. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> These changes are fine. > >>>>>>> > >>>>>>>> > >>>>>>>> 6) <!-- [rfced] [GNAP] does not contain Section 3.1.2. Please > >>>>>>>> let us know > >>>>>>>> which section was intended (perhaps Section 3.2.1 ("Single > >>>>>>>> Access > >>>>>>>> Token"). > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> The client instance is given token management access tokens > >>>>>>>> only > >>>>>>>> as part of the manage field of the grant response in Section > >>>>>>>> 3.1.2 > >>>>>>>> of [GNAP]. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> Yes, the reference was intended to be section 3.2.1 as this > >>>>>>> defines the “manage” field that is referenced here. > >>>>>>> > >>>>>>>> > >>>>>>>> 7) <!--[rfced] In the lists in Sections 3.1 and 3.5, we note > >>>>>>>> that the key > >>>>>>>> words (REQUIRED, OPTIONAL, etc.) are included at the end of > >>>>>>>> the > >>>>>>>> descriptions whereas the key words are included at the > >>>>>>>> beginning > >>>>>>>> of the descriptions in all other relevant sections. Would you > >>>>>>>> like to make these consistent by updating Sections 3.1 and 3.5 > >>>>>>>> as > >>>>>>>> shown in the example below? > >>>>>>>> > >>>>>>>> One example > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> token_formats_supported (array of strings): A list of token > >>>>>>>> formats > >>>>>>>> supported by this AS. The values in this list MUST be > >>>>>>>> registered > >>>>>>>> in the "GNAP Token Format Registry Formats" registry in > >>>>>>>> Section 5.3. > >>>>>>>> OPTIONAL. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> token_formats_supported (array of strings): OPTIONAL. A list > >>>>>>>> of token > >>>>>>>> formats supported by this AS. The values in this list MUST > >>>>>>>> be > >>>>>>>> registered in the "GNAP Token Format Registry Formats" > >>>>>>>> registry per > >>>>>>>> Section 5.3. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> In the companion specification, RFC9646, we seem to have > >>>>>>> usually put the keywords at the end on the lists, so I think we > >>>>>>> should instead update the lists in sections 3.3 (two lists) and > >>>>>>> 3.4 (two lists) to make them all consistent with the normative > >>>>>>> requirements at the end. > >>>>>>> > >>>>>>>> > >>>>>>>> 8) <!--[rfced] Please note the mismatch here between > >>>>>>>> "array of strings" vs. "string". > >>>>>>>> > >>>>>>>> As both of these seem to be regarding the "GNAP Resource Set > >>>>>>>> Registration > >>>>>>>> Request Parameters" registry (as opposed to the "GNAP RS- > >>>>>>>> Facing Discovery > >>>>>>>> Document Fields" registry), should Section 3.4 be updated to > >>>>>>>> "string" to match > >>>>>>>> the registry? > >>>>>>>> > >>>>>>>> Section 3.4 > >>>>>>>> token_formats_supported (array of strings): > >>>>>>>> > >>>>>>>> vs. > >>>>>>>> > >>>>>>>> Section 5.6.2: > >>>>>>>> token_formats_supported | string | Section 3.4 > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> Section 5.6.2 should be updated to be “array of strings” and > >>>>>>> the corresponding entry in the IANA registry will need to be > >>>>>>> updated as well (it currently is registered as “string” at > >>>>>>> https://www.iana.org/assignments/gnap/gnap.xhtml#gnap-resource- > >>>>>>> set-registration-request-parameters > >>>>>>> > >>>>>>>> > >>>>>>>> 9) <!--[rfced] We are having trouble parsing the following > >>>>>>>> text (are some > >>>>>>>> words missing?). Please let us know how we may update this > >>>>>>>> sentence for clarity. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> token_formats_supported (array of strings): OPTIONAL. The > >>>>>>>> token > >>>>>>>> formats the RS is able to process for accessing the > >>>>>>>> resource. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> token_formats_supported (array of strings): OPTIONAL. The > >>>>>>>> list of > >>>>>>>> token formats the RS is able to process in order to access > >>>>>>>> the > >>>>>>>> resources. > >>>>>>>> --> > >>>>>>> > >>>>>>> > >>>>>>> We can simplify to: > >>>>>>> > >>>>>>> token_formats_supported (array of strings): OPTIONAL. The list > >>>>>>> of > >>>>>>> token formats that the RS is able to process. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 10) <!--[rfced] We note "HTTP 400 Bad Request error" vs. "HTTP > >>>>>>>> (Bad > >>>>>>>> Request) status code". Should this perhaps be updated as "HTTP > >>>>>>>> 400 (Bad Request) error code" for consistency as shown below? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> If the registration fails, the AS returns an HTTP 400 Bad > >>>>>>>> Request > >>>>>>>> error to the RS indicating that the registration was not > >>>>>>>> successful. > >>>>>>>> > >>>>>>>> In the case of an error from the RS-facing API, the AS > >>>>>>>> responds to > >>>>>>>> the RS with an HTTP 400 (Bad Request) status code and a JSON > >>>>>>>> object > >>>>>>>> consisting of a single error field, which is either an object > >>>>>>>> or a > >>>>>>>> string. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> If the registration fails, the AS returns an HTTP 400 (Bad > >>>>>>>> Request) > >>>>>>>> error code to the RS indicating that the registration was not > >>>>>>>> successful. > >>>>>>>> > >>>>>>>> In the case of an error from the RS-facing API, the AS > >>>>>>>> responds to > >>>>>>>> the RS with an HTTP 400 (Bad Request) error code and a JSON > >>>>>>>> object > >>>>>>>> consisting of a single error field, which is either an object > >>>>>>>> or a > >>>>>>>> string. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> From my understanding of the HTTP style guidelines, these > >>>>>>> instances should be: > >>>>>>> > >>>>>>> … returns HTTP status code 400 (Bad Request) to the RS ... > >>>>>>> > >>>>>>> … the RS with HTTP status code 400 (Bad Request) and a … > >>>>>>> > >>>>>>>> > >>>>>>>> 11) <!--[rfced] FYI, for the sourcecode element in Section 4, > >>>>>>>> two spaces were removed from the left side of the access_token > >>>>>>>> so that it fits the line-length restriction. Please let us > >>>>>>>> know > >>>>>>>> if you prefer otherwise. > >>>>>>>> > >>>>>>>> This line was previously too long: > >>>>>>>> "existing_access_token": > >>>>>>>> "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0" > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> I don’t actually see this change in the source or in the > >>>>>>> rendered text, but as long as it does not change the relative > >>>>>>> indentation/formatting of the JSON element in the HTTP request, > >>>>>>> that should be fine. We can also shave a few characters off of > >>>>>>> the access token value without affecting the utility of the > >>>>>>> example. If we do this, we should also change the value in > >>>>>>> section 3.3 — even though the examples are not directly > >>>>>>> connected to each other, it was intentional that they use a > >>>>>>> consistent value. > >>>>>>> > >>>>>>>> > >>>>>>>> 12) <!--[rfced] Regarding variations of "string/object" > >>>>>>>> in the "GNAP Token Introspection Request" registry. > >>>>>>>> > >>>>>>>> a) In Table 2 (which corresponds to > >>>>>>>> https://www.iana.org/assignments/gnap/gnap.xhtml#gnap-token- > >>>>>>>> introspection-request) > >>>>>>>> would you like to change this type from > >>>>>>>> "object/string" to "string/object" to match the form of the > >>>>>>>> subsequent item? > >>>>>>>> If so, we will ask IANA to update the registry accordingly. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> resource_server object/string Section 3.3 of > >>>>>>>> RFC xxxx > >>>>>>>> > >>>>>>>> access array of strings/objects Section 3.3 of > >>>>>>>> RFC xxxx > >>>>>>>> > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> resource_server string/object Section 3.3 of > >>>>>>>> RFC 9767 > >>>>>>>> > >>>>>>>> access array of strings/objects Section 3.3 of > >>>>>>>> RFC 9767 > >>>>>>> > >>>>>>> No, this should remain as written, “object/string” and “array > >>>>>>> of strings/objects”. > >>>>>>> > >>>>>>>> > >>>>>>>> b) Similarly, in Section 3.3, would you like to change > >>>>>>>> "string or object" to "string/object"? > >>>>>>>> (Note: If you decide not to change the original > >>>>>>>> "object/string" above, > >>>>>>>> then we will update "string or object" to "object/string" to > >>>>>>>> match.) > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> resource_server (string or object): REQUIRED. ... > >>>>>>>> > >>>>>>>> access (array of strings/objects): OPTIONAL. ... > >>>>>>>> > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> resource_server (string/object): REQUIRED. ... > >>>>>>>> > >>>>>>>> access (array of strings/objects): OPTIONAL. ... > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> This should be: > >>>>>>> > >>>>>>> resource_server (object/string): ... > >>>>>>> > >>>>>>> And the IANA registry should be updated. > >>>>>>> > >>>>>>>> > >>>>>>>> 13) <!--[rfced] Regarding variations of "string/object" > >>>>>>>> in the "GNAP Token Introspection Response" > >>>>>>>> and "GNAP Resource Set Registration Request Parameters" > >>>>>>>> registries. > >>>>>>>> > >>>>>>>> a) In Table 3, would you like to change "object/string" > >>>>>>>> to "string/object" to match usage in the preceding item? > >>>>>>>> If so, we will ask IANA to update the registry > >>>>>>>> (https://www.iana.org/assignments/gnap/gnap.xhtml#gnap-token- > >>>>>>>> introspection-response) accordingly. > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> | access | array of strings/objects | Section 3.3 of RFC > >>>>>>>> xxxx | > >>>>>>>> | key | object/string | Section 3.3 of RFC > >>>>>>>> xxxx | > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> | access | array of strings/objects | Section 3.3 of RFC > >>>>>>>> 9767 | > >>>>>>>> | key | string/object | Section 3.3 of RFC > >>>>>>>> 9767 | > >>>>>>>> > >>>>>>>> > >>>>>>>> b) Similarly, in Section 3.3, would you like to change > >>>>>>>> "object/string" > >>>>>>>> to "string/object" to match usage in the preceding item? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> key (object/string): REQUIRED if ... > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> key (string/object): REQUIRED if ... > >>>>>>>> > >>>>>>> > >>>>>>> No, these should remain “object/string” and “array of > >>>>>>> strings/objects” as written. > >>>>>>> > >>>>>>>> > >>>>>>>> c) With the same rationale, in Section 3.4 (and Table 4), > >>>>>>>> would you like > >>>>>>>> to change this as follows? If so, we will ask IANA to update > >>>>>>>> the registry > >>>>>>>> (https://www.iana.org/assignments/gnap/gnap.xhtml#gnap- > >>>>>>>> resource-set-registration-request-parameters) accordingly. > >>>>>>>> > >>>>>>>> Original: resource_server (string or object) > >>>>>>>> > >>>>>>>> Perhaps: resource_server (string/object) > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> This should be: > >>>>>>> > >>>>>>> resource_server (object/string) > >>>>>>> > >>>>>>> > >>>>>>> as above. The IANA registry should be updated accordingly. > >>>>>>> > >>>>>>>> > >>>>>>>> 14) <!--[rfced] May we update this sentence for clarity? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> The contents of the access token model divulge to the RS > >>>>>>>> information > >>>>>>>> about the access token's context and rights. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> The contents of the access token model, which contains > >>>>>>>> information > >>>>>>>> about the access token's context and rights, are divulged to > >>>>>>>> the RS. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> Perhaps instead: > >>>>>>> > >>>>>>> The contents of the access token model divulge information > >>>>>>> about the access token’s context and rights to the RS. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> 15) <!--[rfced] Would using "certain circumstances" in place > >>>>>>>> of "limited > >>>>>>>> circumstances" be better to avoid the redundancy of "limiting" > >>>>>>>> and > >>>>>>>> "limited" as shown below? > >>>>>>>> > >>>>>>>> Original: > >>>>>>>> Furthermore, limiting the use of bearer tokens and AS-provided > >>>>>>>> keys > >>>>>>>> to only highly trusted AS's ASs and limited circumstances > >>>>>>>> prevents the > >>>>>>>> attacker from being able to willingly exfiltrate their token > >>>>>>>> to an > >>>>>>>> unsuspecting client instance. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> Furthermore, limiting the use of bearer tokens and AS-provided > >>>>>>>> keys > >>>>>>>> to only highly trusted ASs and certain circumstances prevents > >>>>>>>> the > >>>>>>>> attacker from being able to willingly exfiltrate their token > >>>>>>>> to an > >>>>>>>> unsuspecting client instance. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> I think instead we can say: > >>>>>>> > >>>>>>> Furthermore, limiting the use of bearer tokens and AS-provided > >>>>>>> keys > >>>>>>> to only highly trusted ASs in certain circumstances prevents > >>>>>>> the > >>>>>>> attacker from being able to willingly exfiltrate their token to > >>>>>>> an > >>>>>>> unsuspecting client instance. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> 16) <!-- [rfced] The URL <https://www.ndss- > >>>>>>>> symposium.org/ndss2014/ > >>>>>>>> ndss-2014-programme/macaroons-cookies-contextual-caveats- > >>>>>>>> decentralized-authorization-cloud/> provides an open-access > >>>>>>>> link > >>>>>>>> to this symposium paper and is where the DOI for this paper > >>>>>>>> directs. May we replace the original URL with this URL as > >>>>>>>> shown below? > >>>>>>>> > >>>>>>>> Current: > >>>>>>>> [MACAROON] Birgisson, A., Politz, J. G., Erlingsson, U., Taly, > >>>>>>>> A., > >>>>>>>> Vrable, M., and M. Lentczner, "Macaroons: Cookies > >>>>>>>> with > >>>>>>>> Contextual Caveats for Decentralized Authorization > >>>>>>>> in the > >>>>>>>> Cloud", NDSS Symposium 2014, DOI > >>>>>>>> 10.14722/ndss.2014.23212, > >>>>>>>> February 2014, > >>>>>>>> <https://research.google/pubs/pub41892/>. > >>>>>>>> > >>>>>>>> Perhaps: > >>>>>>>> [MACAROON] Birgisson, A., Politz, J. G., Erlingsson, U., Taly, > >>>>>>>> A., > >>>>>>>> Vrable, M., and M. Lentczner, "Macaroons: Cookies > >>>>>>>> with > >>>>>>>> Contextual Caveats for Decentralized Authorization > >>>>>>>> in the > >>>>>>>> Cloud", NDSS Symposium 2014, DOI > >>>>>>>> 10.14722/ndss.2014.23212, > >>>>>>>> February 2014, <https://www.ndss- > >>>>>>>> symposium.org/ndss2014/ > >>>>>>>> ndss-2014-programme/macaroons-cookies-contextual- > >>>>>>>> caveats- > >>>>>>>> decentralized-authorization-cloud/>. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> This change is fine - whatever the best URL is for the > >>>>>>> reference. I am not able to find another RFC that references > >>>>>>> the Macaroon format. > >>>>>>> > >>>>>>>> > >>>>>>>> 17) <!-- [rfced] FYI: To match other usage in the document, we > >>>>>>>> updated the first > >>>>>>>> artwork element in Section 3.2 to sourcecode and set the type > >>>>>>>> to > >>>>>>>> "http-message". Please let us know if we need to update > >>>>>>>> otherwise. > >>>>>>>> > >>>>>>>> Additionally, please review the "type" attribute of each > >>>>>>>> sourcecode element > >>>>>>>> in the XML file to ensure correctness. If the current list of > >>>>>>>> preferred > >>>>>>>> values for "type" > >>>>>>>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode- > >>>>>>>> types) > >>>>>>>> does not contain an applicable type, then feel free to let us > >>>>>>>> know. > >>>>>>>> Also, it is acceptable to leave the "type" attribute not > >>>>>>>> set. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> Yes, these look good. > >>>>>>> > >>>>>>>> > >>>>>>>> 18) <!-- [rfced] Please review usage of <tt> and <em> in this > >>>>>>>> document > >>>>>>>> and let us know if any updates are needed. > >>>>>>>> > >>>>>>>> In the HTML and PDF outputs, the text enclosed in <tt> is > >>>>>>>> output > >>>>>>>> in fixed-width font. In the TXT output, there are no changes > >>>>>>>> to the font, > >>>>>>>> and quotation marks are not generated. > >>>>>>>> > >>>>>>>> In the HTML and PDF outputs, the text enclosed in <em> is > >>>>>>>> output in > >>>>>>>> italics. In the TXT output, the text enclosed in <em> appears > >>>>>>>> with an > >>>>>>>> underscore before and after. This is used only in Section > >>>>>>>> 2.1.1. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> Yes, these look good. > >>>>>>> > >>>>>>>> > >>>>>>>> 19) <!-- [rfced] Please review the "Inclusive Language" > >>>>>>>> portion of the online > >>>>>>>> Style Guide <https://www.rfc- > >>>>>>>> editor.org/styleguide/part2/#inclusive_language> > >>>>>>>> and let us know if any changes are needed. Updates of this > >>>>>>>> nature typically > >>>>>>>> result in more precise language, which is helpful for readers. > >>>>>>>> > >>>>>>>> Note that our script did not flag any words in particular, but > >>>>>>>> this should > >>>>>>>> still be reviewed as a best practice. > >>>>>>>> --> > >>>>>>>> > >>>>>>> > >>>>>>> I believe we have followed best practice for this language. > >>>>>>> > >>>>>>>> > >>>>>>>> Thank you. > >>>>>>>> > >>>>>>>> RFC Editor/kc/ar > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I believe with these changes implemented we should be ready to > >>>>>>> publish. > >>>>>>> > >>>>>>> — Justin > >>>>>>> > >>>>>>>> > >>>>>>>> On Apr 10, 2025, rfc-edi...@rfc-editor.org wrote: > >>>>>>>> > >>>>>>>> *****IMPORTANT***** > >>>>>>>> > >>>>>>>> Updated 2025/04/10 > >>>>>>>> > >>>>>>>> RFC Author(s): > >>>>>>>> -------------- > >>>>>>>> > >>>>>>>> Instructions for Completing AUTH48 > >>>>>>>> > >>>>>>>> Your document has now entered AUTH48. Once it has been > >>>>>>>> reviewed and > >>>>>>>> approved by you and all coauthors, it will be published as an > >>>>>>>> RFC. > >>>>>>>> If an author is no longer available, there are several > >>>>>>>> remedies > >>>>>>>> available as listed in the FAQ (https://www.rfc- > >>>>>>>> editor.org/faq/). > >>>>>>>> > >>>>>>>> You and you coauthors are responsible for engaging other > >>>>>>>> parties > >>>>>>>> (e.g., Contributors or Working Group) as necessary before > >>>>>>>> providing > >>>>>>>> your approval. > >>>>>>>> > >>>>>>>> Planning your review > >>>>>>>> --------------------- > >>>>>>>> > >>>>>>>> Please review the following aspects of your document: > >>>>>>>> > >>>>>>>> * RFC Editor questions > >>>>>>>> > >>>>>>>> Please review and resolve any questions raised by the RFC > >>>>>>>> Editor > >>>>>>>> that have been included in the XML file as comments marked as > >>>>>>>> follows: > >>>>>>>> > >>>>>>>> <!-- [rfced] ... --> > >>>>>>>> > >>>>>>>> These questions will also be sent in a subsequent email. > >>>>>>>> > >>>>>>>> * Changes submitted by coauthors > >>>>>>>> > >>>>>>>> Please ensure that you review any changes submitted by your > >>>>>>>> coauthors. We assume that if you do not speak up that you > >>>>>>>> agree to changes submitted by your coauthors. > >>>>>>>> > >>>>>>>> * Content > >>>>>>>> > >>>>>>>> Please review the full content of the document, as this cannot > >>>>>>>> change once the RFC is published. Please pay particular > >>>>>>>> attention to: > >>>>>>>> - IANA considerations updates (if applicable) > >>>>>>>> - contact information > >>>>>>>> - references > >>>>>>>> > >>>>>>>> * Copyright notices and legends > >>>>>>>> > >>>>>>>> Please review the copyright notice and legends as defined in > >>>>>>>> RFC 5378 and the Trust Legal Provisions > >>>>>>>> (TLP – https://trustee.ietf.org/license-info). > >>>>>>>> > >>>>>>>> * Semantic markup > >>>>>>>> > >>>>>>>> Please review the markup in the XML file to ensure that > >>>>>>>> elements of > >>>>>>>> content are correctly tagged. For example, ensure that > >>>>>>>> <sourcecode> > >>>>>>>> and <artwork> are set correctly. See details at > >>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>>>>>> > >>>>>>>> * Formatted output > >>>>>>>> > >>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>>>>> formatted output, as generated from the markup in the XML > >>>>>>>> file, is > >>>>>>>> reasonable. Please note that the TXT will have formatting > >>>>>>>> limitations compared to the PDF and HTML. > >>>>>>>> > >>>>>>>> > >>>>>>>> Submitting changes > >>>>>>>> ------------------ > >>>>>>>> > >>>>>>>> To submit changes, please reply to this email using ‘REPLY > >>>>>>>> ALL’ as all > >>>>>>>> the parties CCed on this message need to see your changes. The > >>>>>>>> parties > >>>>>>>> include: > >>>>>>>> > >>>>>>>> * your coauthors > >>>>>>>> > >>>>>>>> * rfc-edi...@rfc-editor.org (the RPC team) > >>>>>>>> > >>>>>>>> * other document participants, depending on the stream (e.g., > >>>>>>>> IETF Stream participants are your working group chairs, the > >>>>>>>> responsible ADs, and the document shepherd). > >>>>>>>> > >>>>>>>> * auth48archive@rfc-editor.org, which is a new archival > >>>>>>>> mailing list > >>>>>>>> to preserve AUTH48 conversations; it is not an active > >>>>>>>> discussion > >>>>>>>> list: > >>>>>>>> > >>>>>>>> * More info: > >>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf- > >>>>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >>>>>>>> > >>>>>>>> * The archive itself: > >>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>>>>>> > >>>>>>>> * Note: If only absolutely necessary, you may temporarily opt > >>>>>>>> out > >>>>>>>> of the archiving of messages (e.g., to discuss a sensitive > >>>>>>>> matter). > >>>>>>>> If needed, please add a note at the top of the message that > >>>>>>>> you > >>>>>>>> have dropped the address. When the discussion is concluded, > >>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC > >>>>>>>> list and > >>>>>>>> its addition will be noted at the top of the message. > >>>>>>>> > >>>>>>>> You may submit your changes in one of two ways: > >>>>>>>> > >>>>>>>> An update to the provided XML file > >>>>>>>> — OR — > >>>>>>>> An explicit list of changes in this format > >>>>>>>> > >>>>>>>> Section # (or indicate Global) > >>>>>>>> > >>>>>>>> OLD: > >>>>>>>> old text > >>>>>>>> > >>>>>>>> NEW: > >>>>>>>> new text > >>>>>>>> > >>>>>>>> You do not need to reply with both an updated XML file and an > >>>>>>>> explicit > >>>>>>>> list of changes, as either form is sufficient. > >>>>>>>> > >>>>>>>> We will ask a stream manager to review and approve any changes > >>>>>>>> that seem > >>>>>>>> beyond editorial in nature, e.g., addition of new text, > >>>>>>>> deletion of text, > >>>>>>>> and technical changes. Information about stream managers can > >>>>>>>> be found in > >>>>>>>> the FAQ. Editorial changes do not require approval from a > >>>>>>>> stream manager. > >>>>>>>> > >>>>>>>> > >>>>>>>> Approving for publication > >>>>>>>> -------------------------- > >>>>>>>> > >>>>>>>> To approve your RFC for publication, please reply to this > >>>>>>>> email stating > >>>>>>>> that you approve this RFC for publication. Please use ‘REPLY > >>>>>>>> ALL’, > >>>>>>>> as all the parties CCed on this message need to see your > >>>>>>>> approval. > >>>>>>>> > >>>>>>>> > >>>>>>>> Files > >>>>>>>> ----- > >>>>>>>> > >>>>>>>> The files are available here: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9767.xml > >>>>>>>> https://www.rfc-editor.org/authors/rfc9767.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9767.pdf > >>>>>>>> https://www.rfc-editor.org/authors/rfc9767.txt > >>>>>>>> > >>>>>>>> Diff file of the text: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9767-diff.html > >>>>>>>> https://www.rfc-editor.org/authors/rfc9767-rfcdiff.html (side > >>>>>>>> by side) > >>>>>>>> > >>>>>>>> Diff of the XML: > >>>>>>>> https://www.rfc-editor.org/authors/rfc9767-xmldiff1.html > >>>>>>>> > >>>>>>>> > >>>>>>>> Tracking progress > >>>>>>>> ----------------- > >>>>>>>> > >>>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9767 > >>>>>>>> > >>>>>>>> Please let us know if you have any questions. > >>>>>>>> > >>>>>>>> Thank you for your cooperation, > >>>>>>>> > >>>>>>>> RFC Editor > >>>>>>>> > >>>>>>>> -------------------------------------- > >>>>>>>> RFC9767 (draft-ietf-gnap-resource-servers-09) > >>>>>>>> > >>>>>>>> Title : Grant Negotiation and Authorization > >>>>>>>> Protocol Resource Server Connections > >>>>>>>> Author(s) : J. Richer, Ed., F. Imbault > >>>>>>>> WG Chair(s) : Yaron Sheffer, Leif Johansson > >>>>>>>> Area Director(s) : Deb Cooley, Paul Wouters > >>>>>>> > >>>>>>> -- > >>>>>>> auth48archive mailing list -- auth48archive@rfc-editor.org > >>>>>>> To unsubscribe send an email to auth48archive-leave@rfc- > >>>>>>> editor.org > >>>>>> > >>>>> > >>>> > >>> > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
