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-le...@rfc-editor.org >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
