Hi all, This change is complete:
https://www.iana.org/assignments/oauth-parameters thanks, Amanda On Thu Apr 17 16:45:37 2025, lbartholo...@amsl.com wrote: > Dear IANA, > > Per author feedback, please make the following update in the "OAuth > Protected Resource Metadata" registry on > <https://www.iana.org/assignments/oauth-parameters/>: > > OLD: > JSON array containing a list of the OAuth 2.0 Bearer Token > presentation methods that this protected resource supports > > NEW (please change "Bearer Token" to "bearer token"): > JSON array containing a list of the OAuth 2.0 bearer token > presentation methods that this protected resource supports > > Thank you! > > RFC Editor/lb > > > On Apr 17, 2025, at 9:39 AM, Lynne Bartholomew > > <lbartholo...@staff.rfc-editor.org> wrote: > > > > Hi, Mike, Phil, and Aaron. > > > > Mike, yes, we have seen all of the emails (approvals and latest > > proposed changes). We also added a comma in the "relationships with" > > sentence. > > > > The latest files are posted here. Please refresh your browser: > > > > https://www.rfc-editor.org/authors/rfc9728.txt > > https://www.rfc-editor.org/authors/rfc9728.pdf > > https://www.rfc-editor.org/authors/rfc9728.html > > https://www.rfc-editor.org/authors/rfc9728.xml > > https://www.rfc-editor.org/authors/rfc9728-diff.html > > https://www.rfc-editor.org/authors/rfc9728-rfcdiff.html (side by > > side) > > https://www.rfc-editor.org/authors/rfc9728-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9728-auth48rfcdiff.html (side > > by side) > > https://www.rfc-editor.org/authors/rfc9728-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9728-lastrfcdiff.html (side by > > side) > > > > https://www.rfc-editor.org/authors/rfc9728-xmldiff1.html > > https://www.rfc-editor.org/authors/rfc9728-xmldiff2.html > > > > We have noted your approvals on the AUTH48 status page: > > > > https://www.rfc-editor.org/auth48/rfc9728 > > > > We will ask IANA to change "Bearer Token" to "bearer token" in the > > "OAuth Protected Resource Metadata" registry on > > <https://www.iana.org/assignments/oauth-parameters/>, per AUTH48 > > feedback on usage. After IANA makes the update, we will move this > > document forward for publication. > > > > Thank you! > > > > RFC Editor/lb > > > >> On Apr 17, 2025, at 7:31 AM, Michael Jones > >> <michael_b_jo...@hotmail.com> wrote: > >> > >> Hi Lynne. I wanted to confirm that you saw the additional two > >> proposed changes below, as well as that all the authors have > >> approved. > >> Best > >> wishes, > >> -- > >> Mike > >> From: Michael Jones > >> Sent: Wednesday, April 16, 2025 9:09 AM > >> To: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org>; Aaron > >> Parecki <aa...@parecki.com>; Phil Hunt <phil.h...@yahoo.com> > >> Cc: rfc-edi...@rfc-editor.org; oauth-...@ietf.org; oauth- > >> cha...@ietf.org; rifaat.s.i...@gmail.com; Deb Cooley > >> <debcool...@gmail.com>; auth48archive@rfc-editor.org > >> Subject: RE: AUTH48: RFC-to-be 9728 <draft-ietf-oauth-resource- > >> metadata-13> for your review > >> As I final check, I ran the draft through Word’s spelling and > >> grammar checker. It made these suggestions, which I agree with: > >> 1. Change “its relationships to other services” to “its > >> relationships with other services”. > >> 2. Change “can by dynamically changed” to “can be dynamically > >> changed”. > >> Can you please apply those changes and send us updated drafts, > >> Lynne? > >> Thanks > >> again, > >> -- > >> Mike > >> From: Aaron Parecki <aa...@parecki.com> > >> Sent: Wednesday, April 16, 2025 7:58 AM > >> To: Phil Hunt <phil.h...@yahoo.com> > >> Cc: Michael Jones <michael_b_jo...@hotmail.com>; Lynne Bartholomew > >> <lbartholo...@staff.rfc-editor.org>; rfc-edi...@rfc-editor.org; > >> oauth-...@ietf.org; oauth-cha...@ietf.org;rifaat.s.i...@gmail.com; > >> Deb Cooley <debcool...@gmail.com>; auth48archive@rfc-editor.org > >> Subject: Re: AUTH48: RFC-to-be 9728 <draft-ietf-oauth-resource- > >> metadata-13> for your review > >> Thanks, I concur. > >> Aaron > >> On Tue, Apr 15, 2025 at 10:19 PM Phil Hunt <phil.h...@yahoo.com> > >> wrote: > >> I concur > >> > >> Phil > >> > >>> On Apr 15, 2025, at 10:09 PM, Michael Jones > >>> <michael_b_jo...@hotmail.com> wrote: > >>> > >>> Thank you, Lynne. Please record in https://www.rfc- > >>> editor.org/auth48/rfc9728 that I approve of the publication of the > >>> current draft as RFC 9728. > >>> > >>> Phil, Aaron, do you concur? > >>> > >>> Thanks all, > >>> -- Mike > >>> > >>> -----Original Message----- > >>> From: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org> > >>> Sent: Tuesday, April 15, 2025 10:33 AM > >>> To: Michael Jones <michael_b_jo...@hotmail.com> > >>> Cc: Aaron Parecki <aa...@parecki.com>; rfc-edi...@rfc-editor.org; > >>> phil.h...@yahoo.com; oauth-...@ietf.org; oauth-cha...@ietf.org; > >>> rifaat.s.i...@gmail.com; Deb Cooley <debcool...@gmail.com>; > >>> auth48archive@rfc-editor.org > >>> Subject: Re: AUTH48: RFC-to-be 9728 <draft-ietf-oauth-resource- > >>> metadata-13> for your review > >>> > >>> Hi, Mike. Thanks for your replies! We have updated this document > >>> per your notes below. > >>> > >>> Apologies for the missing space before the email address; thank you > >>> for catching that! > >>> > >>> We also removed the "<!-- [rfced] " comment. (We'd left it in > >>> until the remaining part of the question was addressed, so that it > >>> wouldn't fall through the cracks.) > >>> > >>> The latest files are posted here. Please refresh your browser: > >>> > >>> https://www.rfc-editor.org/authors/rfc9728.txt > >>> https://www.rfc-editor.org/authors/rfc9728.pdf > >>> https://www.rfc-editor.org/authors/rfc9728.html > >>> https://www.rfc-editor.org/authors/rfc9728.xml > >>> https://www.rfc-editor.org/authors/rfc9728-diff.html > >>> https://www.rfc-editor.org/authors/rfc9728-rfcdiff.html (side by > >>> side) > >>> https://www.rfc-editor.org/authors/rfc9728-auth48diff.html > >>> https://www.rfc-editor.org/authors/rfc9728-auth48rfcdiff.html (side > >>> by side) > >>> https://www.rfc-editor.org/authors/rfc9728-lastdiff.html > >>> https://www.rfc-editor.org/authors/rfc9728-lastrfcdiff.html (side > >>> by side) > >>> > >>> https://www.rfc-editor.org/authors/rfc9728-xmldiff1.html > >>> https://www.rfc-editor.org/authors/rfc9728-xmldiff2.html > >>> > >>> Thanks again! > >>> > >>> RFC Editor/lb > >>> > >>> > >>>> On Apr 14, 2025, at 5:45 PM, Michael Jones > >>>> <michael_b_jo...@hotmail.com> wrote: > >>>> > >>>> Aaron and talked about my WWW-Authenticate response suggestion, > >>>> based on that conversation, we'd like to change what I wrote below > >>>> on that topic. > >>>> > >>>> Rather, let's leave the example as it currently is: > >>>> HTTP/1.1 401 Unauthorized > >>>> WWW-Authenticate: Bearer resource_metadata= > >>>> "https://resource.example.com/.well-known/oauth-protected- > >>>> resource" > >>>> > >>>> Also, we agree with this this suggestion that you made. Please > >>>> apply it. > >>>> > >>>> Change: > >>>> The HTTP status code and error string in the example > >>>> response above > >>>> are defined by <xref target="RFC6750"/>. > >>>> to: > >>>> The HTTP status code in the example response above > >>>> are defined by <xref target="RFC6750"/>. > >>>> > >>>> Aaron agrees with the rest of my suggestions. We look forward > >>>> reviewing the next iteration. > >>>> > >>>> Thanks again! > >>>> -- Mike > >>>> > >>>> -----Original Message----- > >>>> From: Michael Jones > >>>> Sent: Monday, April 14, 2025 5:29 PM > >>>> To: 'Lynne Bartholomew' <lbartholo...@staff.rfc-editor.org>; Aaron > >>>> Parecki <aa...@parecki.com> > >>>> Cc: 'rfc-edi...@rfc-editor.org' <rfc-edi...@rfc-editor.org>; > >>>> 'phil.h...@yahoo.com' <phil.h...@yahoo.com>; 'oauth-...@ietf.org' > >>>> <oauth-...@ietf.org>; 'oauth-cha...@ietf.org' <oauth- > >>>> cha...@ietf.org>; 'rifaat.s.i...@gmail.com' > >>>> <rifaat.s.i...@gmail.com>; 'Deb Cooley' <debcool...@gmail.com>; > >>>> 'auth48archive@rfc-editor.org' <auth48archive@rfc-editor.org> > >>>> Subject: RE: AUTH48: RFC-to-be 9728 <draft-ietf-oauth-resource- > >>>> metadata-13> for your review > >>>> > >>>> Resending including Aaron Parecki <aa...@parecki.com>, since > >>>> apparently <aaron=40parecki....@dmarc.ietf.org> didn't reach him. > >>>> > >>>> -----Original Message----- > >>>> From: Michael Jones > >>>> Sent: Monday, April 14, 2025 2:55 PM > >>>> To: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org>; Aaron > >>>> Parecki <aaron=40parecki....@dmarc.ietf.org> > >>>> Cc: rfc-edi...@rfc-editor.org; phil.h...@yahoo.com; oauth- > >>>> a...@ietf.org; oauth-cha...@ietf.org; rifaat.s.i...@gmail.com; Deb > >>>> Cooley <debcool...@gmail.com>;auth48archive@rfc-editor.org > >>>> Subject: RE: AUTH48: RFC-to-be 9728 <draft-ietf-oauth-resource- > >>>> metadata-13> for your review > >>>> > >>>> Thanks, Lynne. My responses to your questions are inline below, > >>>> prefixed by "Mike>". > >>>> > >>>> Reading the auth48diff, I also noticed a missing space before the > >>>> e-mail address in the text "Registration requests should be sent > >>>> to<oauth-ext-rev...@ietf.org>". > >>>> > >>>> Thanks again! > >>>> -- Mike > >>>> > >>>> -----Original Message----- > >>>> From: Lynne Bartholomew <lbartholo...@staff.rfc-editor.org> > >>>> Sent: Monday, April 14, 2025 1:35 PM > >>>> To: Aaron Parecki <aaron=40parecki....@dmarc.ietf.org> > >>>> Cc: rfc-edi...@rfc-editor.org; michael_b_jo...@hotmail.com; > >>>> phil.h...@yahoo.com; oauth-...@ietf.org; oauth-cha...@ietf.org; > >>>> rifaat.s.i...@gmail.com; Deb Cooley <debcool...@gmail.com>; > >>>> auth48archive@rfc-editor.org > >>>> Subject: Re: AUTH48: RFC-to-be 9728 <draft-ietf-oauth-resource- > >>>> metadata-13> for your review > >>>> > >>>> Hi, Aaron. > >>>> > >>>> Thank you for your replies to our questions! > >>>> > >>>> We have three follow-up items for you: > >>>> > >>>> * Regarding this question and your reply: > >>>> > >>>>>> 5) <!-- [rfced] Sections 1 and 2: We had trouble determining > >>>>>> what > >>>>>> "for instance" refers to in these sentences. For example, in > >>>>>> the > >>>>>> first sentence listed below, we do not see any mention of > >>>>>> "jwks_uri" > >>>>>> in [FAPI.MessageSigning] (although we see "jwks_uri" > >>>>>> in Section 2 of this document as well as RFCs 7591, 7592, 8414, > >>>>>> 8705, > >>>>>> 8725, 9068, 9700, and 9701, but [FAPI.MessageSigning] does not > >>>>>> mention any of these published RFCs, except for one mention of > >>>>>> RFC > >>>>>> 8705 ("This is outside of the scope of both [RFC8705] and the > >>>>>> FAPI > >>>>>> standards")). Could these sentences be reworded to make them > >>>>>> clearer? > >>>>>> > >>>>>> Original: > >>>>>> These values may be > >>>>>> used by other specifications, such as the jwks_uri used to > >>>>>> publish > >>>>>> public keys the resource server uses to sign resource responses, > >>>>>> for > >>>>>> instance, as described in [FAPI.MessageSigning]. > >>>>>> ... > >>>>>> JSON array containing a list of the JWS [JWS] signing > >>>>>> algorithms (alg values) [JWA] supported by the protected > >>>>>> resource > >>>>>> for signing resource responses, for instance, as described in > >>>>>> [FAPI.MessageSigning]. > >>>>>> > >>>>>> Possibly: > >>>>>> These values may be > >>>>>> used by other specifications, such as the jwks_uri (see Section > >>>>>> 2) > >>>>>> used to publish public keys the resource server uses to sign > >>>>>> resource responses, as described in [FAPI.MessageSigning]. > >>>>>> ... > >>>>>> JSON array containing a list of the JWS [JWS] signing > >>>>>> algorithms (alg values) [JWA] supported by the protected > >>>>>> resource > >>>>>> for signing resource responses - for instance, as described in > >>>>>> [FAPI.MessageSigning]. --> > >>>>>> > >>>>> Please use this wording, as we identified another ambiguity in > >>>>> the previous wording: > >>>>> > >>>>> These values, such as the <tt>jwks_uri</tt> (see Section 2), may > >>>>> be > >>>>> used with other specifications; for example, the public keys > >>>>> published > >>>>> in the <tt>jwks_uri</tt> can be used to verify the signed > >>>>> resource responses, as described in [FAPI.MessageSigning]. > >>>> > >>>> We updated the "These values ..." sentence per your note. How may > >>>> we update the following? > >>>> > >>>>> JSON array containing a list of the JWS [JWS] signing > >>>>> algorithms (alg values) [JWA] supported by the protected > >>>>> resource > >>>>> for signing resource responses, for instance, as described in > >>>>> [FAPI.MessageSigning]. > >>>> > >>>> Mike> I noticed that you already applied <tt> to the alg here > >>>> Mike> (good). I think the text above is already fine. Aaron? > >>>> > >>>> = = = = = > >>>> > >>>> * Regarding this question and your reply: > >>>> > >>>>>> 26) <!-- [rfced] Please review the "Inclusive Language" portion > >>>>>> of > >>>>>> the online Style Guide at > >>>>>> <https://www/ > >>>>>> .rfc- > >>>>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05% > >>>>>> 7C02%7C%7C03dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaa > >>>>>> aaaaaaaa%7C1%7C0%7C638802597201581579%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > >>>>>> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > >>>>>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RknoutA0DIyLk5oQFgLqFA7Faoi4nx%2B > >>>>>> yISVZxRP0Xm8%3D&reserved=0>, and let us know if any changes are > >>>>>> needed. Updates of this nature typically result in more precise > >>>>>> language, which is helpful for readers. > >>>>>> > >>>>>> For example, please consider whether the following should be > >>>>>> updated: > >>>>>> > >>>>>> man-in-the-middle --> > >>>>> > >>>>> We believe “man-in-the-middle” can be removed from the sentence > >>>>> without affecting its meaning. Please do so. > >>>> > >>>> > >>>> "man-in-the-middle" was used in both Section 7.3 and Section 7.6. > >>>> We removed both instances. Please review, and let us know if > >>>> either sentence should be clarified. For example, in Section 7.3, > >>>> is it correct to now refer to one form of attack instead of two? > >>>> > >>>> Not sure if it helps, but some authors have replaced "man-in-the- > >>>> middle" with "on-path". > >>>> > >>>> Mike> Actually, let's replace both former uses of man-in-the- > >>>> Mike> middle with adversary-in-the-middle, which apparently NIST > >>>> Mike> is using. > >>>> > >>>> = = = = = > >>>> > >>>> * Regarding this update: > >>>> > >>>>> In this review, we also identified a mistake in an example. > >>>>> Please > >>>>> update the example in Section 5.1 as described in this pull > >>>>> request: > >>>>> https://githu/ > >>>>> b.com%2Foauth-wg%2Fdraft-ietf-oauth-resource- > >>>>> metadata%2Fpull%2F65%2Ffi > >>>>> les&data=05%7C02%7C%7C03dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f64 > >>>>> 0afb435aaaaaaaaaaaa%7C1%7C0%7C638802597201602007%7CUnknown%7CTWFpbGZsb > >>>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xCCE8Lb9ZtREL2DAZccrDG5NG > >>>>> N7Ph0HQQinP0rCgV90%3D&reserved=0 > >>>>> > >>>>> (Lines 892-895 replaced with the below) > >>>>> > >>>>> HTTP/1.1 401 Unauthorized > >>>>> WWW-Authenticate: Bearer resource_metadata= > >>>> > >>>> Because the new "401" entry doesn't appear to include an error > >>>> string, should the paragraph that follows it be removed? > >>>> > >>>> Mike> Actually, let's restore the "error" and "error_description" > >>>> Mike> parameters, so that the entry becomes: > >>>> HTTP/1.1 401 Unauthorized > >>>> WWW-Authenticate: Bearer error="invalid_request", > >>>> error_description="No access token was provided in this request", > >>>> resource_metadata= > >>>> "https://resource.example.com/.well-known/oauth-protected- > >>>> resource" > >>>> > >>>> Currently: > >>>> > >>>> HTTP/1.1 401 Unauthorized > >>>> WWW-Authenticate: Bearer resource_metadata= > >>>> "https://resource.example.com/.well-known/oauth-protected- > >>>> resource" > >>>> > >>>> The HTTP status code and error string in the example response > >>>> above are defined by [RFC6750]. > >>>> > >>>> = = = = = > >>>> > >>>> The latest files are posted here. Please refresh your browser: > >>>> > >>>> https://www.rfc-editor.org/authors/rfc9728.txt > >>>> https://www.rfc-editor.org/authors/rfc9728.pdf > >>>> https://www.rfc-editor.org/authors/rfc9728.html > >>>> https://www.rfc-editor.org/authors/rfc9728.xml > >>>> https://www.rfc-editor.org/authors/rfc9728-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9728-rfcdiff.html (side by > >>>> side) > >>>> https://www.rfc-editor.org/authors/rfc9728-auth48diff.html > >>>> https://www.rfc-editor.org/authors/rfc9728-auth48rfcdiff.html > >>>> (side by side) > >>>> > >>>> https://www.rfc-editor.org/authors/rfc9728-xmldiff1.html > >>>> https://www.rfc-editor.org/authors/rfc9728-xmldiff2.html > >>>> > >>>> Thanks again! > >>>> > >>>> RFC Editor/lb > >>>> > >>>> > >>>>>> On Apr 11, 2025, at 2:18 PM, Aaron Parecki > >>>>>> <aaron=40parecki....@dmarc.ietf.org> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On Wed, Apr 9, 2025 at 4:00 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] Section 1: This sentence does not parse. As it > >>>>> appears that "then fetch" means "then the client fetches", may we > >>>>> update as suggested below? > >>>>> > >>>>> Original: > >>>>> In other cases, it may be > >>>>> dynamically discovered; for example, a user could enter their > >>>>> email > >>>>> address into an email client, the client could perform WebFinger > >>>>> [RFC7033] discovery (in a manner related to the description in > >>>>> Section 2 of "OpenID Connect Discovery 1.0" [OpenID.Discovery]) > >>>>> to > >>>>> find the resource server, then fetch the resource server metadata > >>>>> to > >>>>> find the authorization server to use to obtain authorization to > >>>>> access the user's email. > >>>>> > >>>>> Suggested: > >>>>> In > >>>>> other cases, it may be dynamically discovered; for example, a > >>>>> user > >>>>> could enter their email address into an email client, the client > >>>>> could perform WebFinger discovery [RFC7033] (in a manner related > >>>>> to > >>>>> the description in Section 2 of [OpenID.Discovery]) to find the > >>>>> resource server, and the client could then fetch the resource > >>>>> server > >>>>> metadata to find the authorization server to use to obtain > >>>>> authorization to access the user's email. --> > >>>>> > >>>>> Agreed, thanks for the suggested text. > >>>>> > >>>>> > >>>>> 2) <!-- [rfced] Section 1: We changed "Software Statement" to > >>>>> "software statement" per the text of RFC 7591 and changed > >>>>> "Dynamic > >>>>> Client Registration" to "dynamic client registration" per RFCs > >>>>> 7591, > >>>>> 9700, and 9701. Please let us know any objections. > >>>>> > >>>>> Original: > >>>>> This is > >>>>> analogous to the role that the Software Statement plays in OAuth > >>>>> Dynamic Client Registration [RFC7591]. > >>>>> > >>>>> Currently: > >>>>> This is > >>>>> analogous to the role that the software statement plays in OAuth > >>>>> dynamic client registration [RFC7591]. --> > >>>>> > >>>>> We agree with lowercase "software statement", but "Dynamic Client > >>>>> Registration" should be capitalized, as it's the name of RFC > >>>>> 7591. > >>>>> > >>>>> > >>>>> > >>>>> 3) <!-- [rfced] Section 1: We had trouble parsing this sentence. > >>>>> We > >>>>> removed the comma before "but that" to clarify that "that" refers > >>>>> to > >>>>> attacker-generated metadata and is not used as a noun. If this > >>>>> update > >>>>> is incorrect, please clarify what "but that" refers to. > >>>>> > >>>>> Original: > >>>>> This prevents attackers from publishing metadata supposedly > >>>>> describing the protected resource, but that is not actually > >>>>> authoritative for the protected resource, as described in > >>>>> Section > >>>>> 7.3. > >>>>> > >>>>> Currently: > >>>>> This prevents attackers from publishing metadata that supposedly > >>>>> describes the protected resource but that is not actually > >>>>> authoritative for the protected resource, as described in > >>>>> Section > >>>>> 7.3. --> > >>>>> > >>>>> > >>>>> Agreed. > >>>>> > >>>>> 4) <!-- [rfced] Sections 1 and subsequent: Please review and > >>>>> advise > >>>>> regarding the usage of "<tt>" for certain values and parameters > >>>>> as > >>>>> listed in the XML file for this document. For example, we see > >>>>> 2 instances of (OAuth 2.0) "<tt>scope</tt> values" and 1 instance > >>>>> of > >>>>> "scope values". Should usage be consistent? Also, please review > >>>>> the > >>>>> parameters listed in Sections 2 and 8.1.2; no <tt>s for > >>>>> parameters > >>>>> listed in Section 2, but parameters listed in Section 8.1.2 > >>>>> (except > >>>>> for "signed_metadata"; see below) are enclosed in <tt>s. > >>>>> > >>>>> A few more examples: > >>>>> "alg values": 2 instances with <tt>, 2 without GET > >>>>> ("<tt>GET</tt> > >>>>> request" vs. "the GET") <dt>Metadata > >>>>> Name:</dt><dd>signed_metadata</dd> (Section 8.1.2) > >>>>> (All other parameter names in Section 8.1.2 that follow > >>>>> "Metadata Name: " are enclosed in <tt>s.) --> > >>>>> > >>>>> > >>>>> We intend to call out parameter names with <tt>, but not use that > >>>>> markup when referring to the concept. So in the case of all 3 > >>>>> occurrences of "scope values", these are not referring to the > >>>>> parameter names so the <tt> should be removed. > >>>>> > >>>>> For "alg values", "alg" is a parameter name in JWT, so that > >>>>> should always be wrapped in <tt>. > >>>>> > >>>>> The instance of "the GET" should be corrected to "the > >>>>> <tt>GET</tt> request". > >>>>> > >>>>> "signed_metadata" is missing the <tt> wrapper as well. > >>>>> > >>>>> > >>>>> 5) <!-- [rfced] Sections 1 and 2: We had trouble determining > >>>>> what > >>>>> "for instance" refers to in these sentences. For example, in the > >>>>> first sentence listed below, we do not see any mention of > >>>>> "jwks_uri" > >>>>> in [FAPI.MessageSigning] (although we see "jwks_uri" > >>>>> in Section 2 of this document as well as RFCs 7591, 7592, 8414, > >>>>> 8705, > >>>>> 8725, 9068, 9700, and 9701, but [FAPI.MessageSigning] does not > >>>>> mention > >>>>> any of these published RFCs, except for one mention of RFC 8705 > >>>>> ("This > >>>>> is outside of the scope of both [RFC8705] and the FAPI > >>>>> standards")). > >>>>> Could these sentences be reworded to make them clearer? > >>>>> > >>>>> Original: > >>>>> These values may be > >>>>> used by other specifications, such as the jwks_uri used to > >>>>> publish > >>>>> public keys the resource server uses to sign resource responses, > >>>>> for > >>>>> instance, as described in [FAPI.MessageSigning]. > >>>>> ... > >>>>> JSON array containing a list of the JWS [JWS] signing > >>>>> algorithms (alg values) [JWA] supported by the protected > >>>>> resource > >>>>> for signing resource responses, for instance, as described in > >>>>> [FAPI.MessageSigning]. > >>>>> > >>>>> Possibly: > >>>>> These values may be > >>>>> used by other specifications, such as the jwks_uri (see Section > >>>>> 2) > >>>>> used to publish public keys the resource server uses to sign > >>>>> resource > >>>>> responses, as described in [FAPI.MessageSigning]. > >>>>> ... > >>>>> JSON array containing a list of the JWS [JWS] signing > >>>>> algorithms (alg values) [JWA] supported by the protected > >>>>> resource > >>>>> for signing resource responses - for instance, as described in > >>>>> [FAPI.MessageSigning]. --> > >>>>> > >>>>> Please use this wording, as we identified another ambiguity in > >>>>> the previous wording: > >>>>> > >>>>> These values, such as the <tt>jwks_uri</tt> (see Section 2), may > >>>>> be > >>>>> used with other specifications; for example, the public keys > >>>>> published > >>>>> in the <tt>jwks_uri</tt> can be used to verify the signed > >>>>> resource responses, as described in [FAPI.MessageSigning]. > >>>>> > >>>>> > >>>>> > >>>>> 6) <!-- [rfced] Section 1.1: "uses of ... utilize", which also > >>>>> means > >>>>> "uses of ... uses", read oddly. We changed "uses of" to > >>>>> "applications > >>>>> of". Please let us know any objections. > >>>>> > >>>>> Original: > >>>>> All uses of JSON Web Signature (JWS) [JWS] and JSON Web > >>>>> Encryption > >>>>> (JWE) [JWE] data structures in this specification utilize the JWS > >>>>> Compact Serialization or the JWE Compact Serialization; the JWS > >>>>> JSON > >>>>> Serialization and the JWE JSON Serialization are not used. > >>>>> > >>>>> Currently: > >>>>> All applications of JSON Web Signature (JWS) data structures > >>>>> [JWS] > >>>>> and JSON Web Encryption (JWE) data structures [JWE] as discussed > >>>>> in > >>>>> this specification utilize the JWS Compact Serialization or the > >>>>> JWE > >>>>> Compact Serialization; the JWS JSON Serialization and the JWE > >>>>> JSON > >>>>> Serialization are not used. --> > >>>>> > >>>>> > >>>>> Agreed. > >>>>> > >>>>> 7) <!-- [rfced] Section 1.2: This text says "This specification > >>>>> uses > >>>>> the terms ...", but except for a few terms (e.g., "Client > >>>>> Authentication" (only used in the title of Section 5.3), "Claim > >>>>> Name", > >>>>> "Authorization Code"), we could not find any instances of the > >>>>> following terms anywhere in the text: > >>>>> Authorization Endpoint, Authorization Grant, Client Secret, Grant > >>>>> Type, Redirection URI, Refresh Token, Resource Owner, Response > >>>>> Type, > >>>>> Token Endpoint, and Claim Value. > >>>>> > >>>>> We see that this paragraph was taken from Section 1.2 of RFC > >>>>> 8414. > >>>>> We also see similar paragraphs in several other post-6000 RFCs. > >>>>> > >>>>> The following terms are lowercased in text everywhere else in > >>>>> this > >>>>> document. Should we lowercase them in this list as well? > >>>>> > >>>>> Access Token, Authorization Server, Client, Client Identifier, > >>>>> Protected Resource, and Resource Server > >>>>> > >>>>> We see that the terms listed as being from RFC 6749 are > >>>>> lowercased in > >>>>> RFC 6749. Lowercase versus uppercase for the terms listed as > >>>>> being in > >>>>> [JWT] (RFC 7519) is mixed. > >>>>> > >>>>> If all of these terms are relevant to this document, should the > >>>>> text > >>>>> be reworded to suggest that readers be familiar with them? If > >>>>> not, > >>>>> could this paragraph be (1) updated to tailor it to this > >>>>> document, as > >>>>> was done in RFCs 9470 and 9700 or (2) removed? > >>>>> > >>>>> Original: > >>>>> This specification uses the terms "Access Token", "Authorization > >>>>> Code", "Authorization Endpoint", "Authorization Grant", > >>>>> "Authorization Server", "Client", "Client Authentication", > >>>>> "Client > >>>>> Identifier", "Client Secret", "Grant Type", "Protected Resource", > >>>>> "Redirection URI", "Refresh Token", "Resource Owner", "Resource > >>>>> Server", "Response Type", and "Token Endpoint" defined by OAuth > >>>>> 2.0 > >>>>> [RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web > >>>>> Token > >>>>> (JWT)" defined by JSON Web Token (JWT) [JWT]. --> > >>>>> > >>>>> > >>>>> Yes, let's delete the terms we're not using, and use quoted > >>>>> lowercase terms so that it matches RFC 9449, RFC 9470, and RFC > >>>>> 9700. > >>>>> > >>>>> 8) <!-- [rfced] Sections 2 and 8.1.2: We changed "Bearer Token" > >>>>> to > >>>>> "bearer token" per RFC 6750. Please let us know any objections. > >>>>> > >>>>> If no objections, we will ask IANA to change "Bearer Token" to > >>>>> "bearer > >>>>> token" in the "OAuth Protected Resource Metadata" registry on > >>>>> <https://www/. > >>>>> iana.org%2Fassignments%2Foauth- > >>>>> parameters%2F&data=05%7C02%7C%7C03dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638802597201751463%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TxUFf0ihhrrSSESPn1bY8RDg1hcRmB84Tur%2BvMqXgEg%3D&reserved=0> > >>>>> just prior to publication. > >>>>> > >>>>> Original: > >>>>> JSON array containing a list of the supported methods > >>>>> of sending an OAuth 2.0 Bearer Token [RFC6750] to the protected > >>>>> resource. > >>>>> ... > >>>>> * Metadata Description: JSON array containing a list of the > >>>>> OAuth > >>>>> 2.0 Bearer Token presentation methods that this protected > >>>>> resource > >>>>> supports > >>>>> > >>>>> Currently: > >>>>> JSON array containing a list of the supported methods > >>>>> of sending an OAuth 2.0 bearer token [RFC6750] to the protected > >>>>> resource. > >>>>> ... > >>>>> Metadata Description: JSON array containing a list of the OAuth > >>>>> 2.0 > >>>>> bearer token presentation methods that this protected resource > >>>>> supports --> > >>>>> > >>>>> > >>>>> Agreed, when "bearer token" is referring to the type of token > >>>>> (rather than referring to RFC 6750) it should be lowercase. > >>>>> > >>>>> 9) <!-- [rfced] Section 2.2: For ease of the reader, we provided > >>>>> a > >>>>> brief explanation of the term "MACed" per RFC 7591. Please let > >>>>> us > >>>>> know any objections. > >>>>> > >>>>> Original: > >>>>> The signed metadata MUST be > >>>>> digitally signed or MACed using JSON Web Signature (JWS) [JWS] > >>>>> and > >>>>> MUST contain an iss (issuer) claim denoting the party attesting > >>>>> to > >>>>> the claims in the signed metadata. > >>>>> > >>>>> Currently: > >>>>> The signed metadata MUST be > >>>>> digitally signed or MACed (protected with a Message > >>>>> Authentication > >>>>> Code) using a JSON Web Signature (JWS) [JWS] and MUST contain an > >>>>> iss > >>>>> (issuer) claim denoting the party attesting to the claims in the > >>>>> signed metadata. --> > >>>>> > >>>>> > >>>>> Agreed. > >>>>> > >>>>> 10) <!-- [rfced] Please review the four sourcecode entries in > >>>>> this > >>>>> document, and let us know if you would like to specify a type. > >>>>> For example, should the first and second sourcecode items have > >>>>> the > >>>>> type set to "http-message", and should the third and fourth > >>>>> sourcecode > >>>>> items have the type set to "json"? Please review and advise. > >>>>> > >>>>> If the current list of preferred values for "type" > >>>>> (https://www/. > >>>>> rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode- > >>>>> types&data=05 > >>>>> %7C02%7C%7C03dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaa > >>>>> aaaaaaaa%7C1%7C0%7C638802597201765076%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > >>>>> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > >>>>> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S9rCSReF7kSe9klNsDq5cv8DrSHcch5VmNii > >>>>> ZXlX7Lo%3D&reserved=0) does not contain an applicable type, > >>>>> please let > >>>>> us know. Also, it is acceptable to leave the "type" attribute > >>>>> unset. > >>>>> --> > >>>>> > >>>>> > >>>>> All should be set to type "http-message". > >>>>> > >>>>> 11) <!-- [rfced] Section 4: Please confirm that "OAuth protected > >>>>> resources for protected resources" is as intended. > >>>>> > >>>>> Original: > >>>>> protected_resources > >>>>> OPTIONAL. JSON array containing a list of resource identifiers > >>>>> for OAuth protected resources for protected resources that can > >>>>> be > >>>>> used with this authorization server. --> > >>>>> > >>>>> > >>>>> That looks like a duplicate "for protected resources", please > >>>>> delete, so that it reads: > >>>>> > >>>>> protected_resources > >>>>> OPTIONAL. JSON array containing a list of resource identifiers > >>>>> for OAuth protected resources that can be > >>>>> used with this authorization server. > >>>>> > >>>>> 12) <!-- [rfced] Figure 1: We see that the bottom set of boxes > >>>>> for > >>>>> "Client", "Resource Server", and "Authorization Server" appear in > >>>>> the > >>>>> SVG but not the ASCII art. Please update so that the ASCII art > >>>>> and > >>>>> the SVG match. > >>>>> --> > >>>>> > >>>>> > >>>>> Thanks for flagging the inconsistency. Please add this to the > >>>>> bottom of the diagram: > >>>>> > >>>>> +----+-----+ +----+-----+ +-------+-------+ > >>>>> | Client | | Resource | | Authorization | > >>>>> | | | Server | | Server | > >>>>> +----------+ +----------+ +---------------+ > >>>>> > >>>>> 13) <!-- [rfced] Section 5: The descriptive text regarding the > >>>>> steps > >>>>> shown in Figure 1 doesn't seem to align with the steps shown in > >>>>> Figure > >>>>> 1: > >>>>> > >>>>> In Figure 1: > >>>>> Step 5 is "Validate ..." and "... Build ..." > >>>>> Step 6 is "Fetch ..." > >>>>> > >>>>> In the text: > >>>>> Step 5 is "... validates ..." > >>>>> Step 6 is "... builds ..." and "... makes a request to fetch ..." > >>>>> > >>>>> May we update the descriptive text as suggested below? > >>>>> > >>>>> Original: > >>>>> | 5. Validate RS Metadata | | | > >>>>> | Build AS Metadata URL | | | > >>>>> ... > >>>>> | 6. Fetch AS Metadata | | > >>>>> ... > >>>>> 5. The client validates the protected resource metadata, as > >>>>> described in Section 3.3. > >>>>> > >>>>> 6. The client builds the authorization server metadata URL from > >>>>> an > >>>>> issuer identifier in the resource metadata according to > >>>>> [RFC8414] and makes a request to fetch the authorization > >>>>> server > >>>>> metadata. > >>>>> > >>>>> Suggested (easier to change the text than the figure): > >>>>> 5. The client validates the protected resource metadata, as > >>>>> described in Section 3.3, and builds the authorization server > >>>>> metadata URL from an issuer identifier in the resource > >>>>> metadata > >>>>> according to [RFC8414]. > >>>>> > >>>>> 6. The client makes a request to fetch the authorization server > >>>>> metadata. --> > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> 14) <!-- [rfced] Section 5.3: Does "scenarios where" also apply > >>>>> to > >>>>> the text after "and", or is the text after "and" a separate > >>>>> thought? > >>>>> If the former, may we update as suggested? > >>>>> > >>>>> Original: > >>>>> This specification is intended to be deployed in scenarios where > >>>>> the > >>>>> client has no prior knowledge about the resource server, and the > >>>>> resource server might or might not have prior knowledge about the > >>>>> client. > >>>>> > >>>>> Suggested: > >>>>> This specification is intended to be deployed in scenarios where > >>>>> the > >>>>> client has no prior knowledge about the resource server and where > >>>>> the > >>>>> resource server might or might not have prior knowledge about > >>>>> the > >>>>> client. --> > >>>>> > >>>>> Looks good. > >>>>> > >>>>> 15) <!-- [rfced] Section 6: "such as resource" looked odd in the > >>>>> text > >>>>> output, so we placed "resource" in quotes per 'The name requested > >>>>> (e.g., "resource")' in Section 8.1.1. Please let us know any > >>>>> objections. > >>>>> > >>>>> Original: > >>>>> For example, the member names in the > >>>>> metadata response might be compared to specific member names such > >>>>> as > >>>>> resource. > >>>>> > >>>>> Currently: > >>>>> For example, the member names in the > >>>>> metadata response might be compared to specific member names such > >>>>> as > >>>>> "resource". --> > >>>>> > >>>>> > >>>>> We should use <tt>resource</tt> for consistency, since this is > >>>>> actually a parameter name. > >>>>> > >>>>> 16) <!-- [rfced] Section 7.6: We had trouble determining what > >>>>> "or > >>>>> which could be published" refers to. If the suggested text is > >>>>> not > >>>>> correct, please clarify. > >>>>> > >>>>> Original: > >>>>> For > >>>>> instance, some protected resources are used with a fixed > >>>>> authorization server or set of authorization servers, the > >>>>> locations > >>>>> of which may be well known, or which could be published as > >>>>> metadata > >>>>> values by the protected resource. > >>>>> > >>>>> Suggested (guessing that the location information could be > >>>>> published): > >>>>> For > >>>>> instance, some protected resources are used with a fixed > >>>>> authorization server or set of authorization servers, the > >>>>> locations > >>>>> of which may be well known or could be published by the protected > >>>>> resource as metadata values. --> > >>>>> > >>>>> > >>>>> Maybe we can make this even more explicit by separating it into > >>>>> multiple sentences: > >>>>> > >>>>> For instance, some protected resources are used with a fixed > >>>>> authorization server or a set of authorization servers, the > >>>>> locations of which may be known via out-of-band mechanisms. > >>>>> Alternatively, as described in this specification, the locations > >>>>> of the authorization servers could be published by the protected > >>>>> resource as metadata values. > >>>>> > >>>>> 17) <!-- [rfced] Section 7.9: We see "PKIX" mentioned in RFC > >>>>> 9525 but > >>>>> not standalone "PKI". Would you prefer to mention "PKIX" instead > >>>>> of > >>>>> "PKI" here? > >>>>> > >>>>> Original: > >>>>> This means that its security is dependent upon the Internet > >>>>> Public > >>>>> Key Infrastructure (PKI) [RFC9525]. > >>>>> > >>>>> Possibly: > >>>>> This means that its security is dependent upon the Internet > >>>>> Public > >>>>> Key Infrastructure using X.509 (PKIX) [RFC9525]. --> > >>>>> > >>>>> > >>>>> Please use: > >>>>> > >>>>> This means that its security is dependent upon the Internet > >>>>> Public Key > >>>>> Infrastructure using X.509 (PKIX), as described in [RFC9525]. > >>>>> > >>>>> 18) <!-- [rfced] Section 7.10: RFC 7234 has been obsoleted by > >>>>> RFC 9111. > >>>>> Because we see "Cache-Control" and "max-age" discussed in RFC > >>>>> 9111 as > >>>>> well, we updated the RFC number accordingly. Please let us know > >>>>> any > >>>>> objections. > >>>>> > >>>>> Original ("utlize" has been fixed): > >>>>> Implementations should utlize HTTP > >>>>> caching directives such as Cache-Control with max-age, as defined > >>>>> in > >>>>> [RFC7234], to enable caching of retrieved metadata for > >>>>> appropriate > >>>>> time periods. > >>>>> ... > >>>>> [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. > >>>>> Reschke, > >>>>> Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", > >>>>> RFC 7234, DOI 10.17487/RFC7234, June 2014, > >>>>> <https://www.rfc-editor.org/info/rfc7234>. > >>>>> > >>>>> Currently: > >>>>> Implementations should utilize HTTP > >>>>> caching directives such as Cache-Control with max-age, as defined > >>>>> in > >>>>> [RFC9111], to enable caching of retrieved metadata for > >>>>> appropriate > >>>>> time periods. > >>>>> ... > >>>>> [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. > >>>>> Reschke, > >>>>> Ed., "HTTP Caching", STD 98, RFC 9111, > >>>>> DOI 10.17487/RFC9111, June 2022, > >>>>> > >>>>> <https://www/. > >>>>> rfc- > >>>>> editor.org%2Finfo%2Frfc9111&data=05%7C02%7C%7C03dd1f9970bf4841b6bd > >>>>> 08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638802597201 > >>>>> 789879%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > >>>>> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > >>>>> ta=jbOe9nWAwJvXV8bxH1ONAMS9qvNk%2BLvMrFz0%2FHYST%2B4%3D&reserved=0>. > >>>>> --> > >>>>> > >>>>> > >>>>> Agreed. > >>>>> > >>>>> 19) <!-- [rfced] We have removed this first paragraph, as it > >>>>> seems unnecessary. Please review. > >>>>> > >>>>> Original: > >>>>> The following registration procedure is used for the registry > >>>>> established by this specification. > >>>>> --> > >>>>> > >>>>> > >>>>> Ok. > >>>>> > >>>>> 20) <!-- [rfced] To clarify the text, please consider the > >>>>> following > >>>>> update. Currently, it is unclear whether mail sent to the list > >>>>> initiates review or if it is where the expert sends the comments. > >>>>> In addition, does the text need to mention Designated Experts, > >>>>> because > >>>>> Expert Review is already part of Specification Required? > >>>>> > >>>>> Original: > >>>>> Values are registered on a Specification Required [RFC8126] basis > >>>>> after a two-week review period on the oauth-ext-rev...@ietf.org > >>>>> mailing list, on the advice of one or more Designated Experts. > >>>>> > >>>>> Perhaps: > >>>>> Values are registered per Specification Required [RFC8126]. > >>>>> Registration requests should be sent to <oauth-ext- > >>>>> rev...@ietf.org> > >>>>> to initiate a two-week review period. > >>>>> --> > >>>>> > >>>>> We don’t intend there to be anything unique to this spec with > >>>>> regards to the review process. Any corrections here are > >>>>> acceptable. > >>>>> > >>>>> 21) <!-- [rfced] Note that we have updated the text as follows > >>>>> based > >>>>> on discussion with IANA. Please let us know if you have > >>>>> concerns. > >>>>> > >>>>> Original: > >>>>> The IANA escalation process is followed when the designated > >>>>> experts > >>>>> are not responsive within 14 days. > >>>>> > >>>>> Current: > >>>>> If the designated experts are not responsive, the registration > >>>>> requesters > >>>>> should contact IANA to escalate the process. > >>>>> --> > >>>>> > >>>>> Looks good. > >>>>> > >>>>> 22) <!-- [rfced] For clarity, please consider whether "makes > >>>>> sense" > >>>>> should be "is clear and fits the purpose of the registry"? In > >>>>> addition, we suggest stating the criteria clearly (i.e., is the > >>>>> designated expert supposed to approve or not approve proposals > >>>>> that duplicate functionality). > >>>>> > >>>>> Original: > >>>>> Criteria that should be applied by the Designated Experts > >>>>> includes > >>>>> determining whether the proposed registration duplicates existing > >>>>> functionality, whether it is likely to be of general > >>>>> applicability or is useful only for a single application, > >>>>> and whether the registration makes sense. > >>>>> > >>>>> Perhaps: > >>>>> Designated experts should apply the following criteria when > >>>>> reviewing > >>>>> proposed registrations: they must be unique, that is, they should > >>>>> not > >>>>> duplicate existing functionality; they are likely generally > >>>>> applicable, > >>>>> as opposed to being used for a single application; and they are > >>>>> clear > >>>>> and fit the purpose of the registry. > >>>>> --> > >>>>> > >>>>> Agreed. > >>>>> > >>>>> 23) <!-- [rfced] This sentence is tough to parse. Please > >>>>> consider the > >>>>> following update for clarity. > >>>>> > >>>>> Original: > >>>>> The reason to allow the Designated Experts to allocate values > >>>>> prior > >>>>> to publication as a final specification is to enable giving > >>>>> authors > >>>>> of specifications proposing registrations the benefit of review > >>>>> by > >>>>> the Designated Experts before the specification is completely > >>>>> done, > >>>>> so that if problems are identified, the authors can iterate and > >>>>> fix > >>>>> them before publication of the final specification. > >>>>> > >>>>> Perhaps: > >>>>> Designated experts may allocate values prior to publication of > >>>>> the > >>>>> final specification. This allows authors to receive guidance > >>>>> from > >>>>> the designated experts early, so any identified issues can be > >>>>> fixed > >>>>> before the final specification is published. > >>>>> --> > >>>>> > >>>>> Looks good. > >>>>> > >>>>> 24) <!-- [rfced] [USA15] Do you want to specifically refer to the > >>>>> 2015 version of the standard, or do you want to refer to the most > >>>>> current version? Currently, we have updated this reference > >>>>> listing to primarily refer to the 2015 version, and we have > >>>>> included a second link to the curent version. Please review. > >>>>> > >>>>> Original: > >>>>> [USA15] Davis, M. and K. Whistler, "Unicode Normalization > >>>>> Forms", > >>>>> Unicode Standard Annex 15, 1 June 2015, > >>>>> <https://www.unicode.org/reports/tr15/>. > >>>>> > >>>>> Currently: > >>>>> [USA15] Davis, M., Ed. and K. Whistler, Ed., "Unicode > >>>>> Normalization Forms", Unicode Standard Annex #15, 1 June > >>>>> 2015, <https://www.unicode.org/reports/tr15/tr15- > >>>>> 43.html>. > >>>>> Latest version available at > >>>>> > >>>>> <https://www/. > >>>>> unicode.org%2Freports%2Ftr15%2F&data=05%7C02%7C%7C03dd1f9970bf4841b6bd > >>>>> 08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638802597201 > >>>>> 825678%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > >>>>> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > >>>>> ta=xcb4024eQ2zzXVIndtE2I77t6c%2F8IkfM%2FWVwdy4VOq4%3D&reserved=0>. > >>>>> --> > >>>>> > >>>>> The most current version would be best. > >>>>> > >>>>> 25) <!-- [rfced] Acknowledgements: We found that all names were > >>>>> listed in alphabetical order by last name, except for Gabriel > >>>>> Corona. > >>>>> We moved Gabriel's name so that it appears after Deb Cooley's > >>>>> name > >>>>> instead of Roman Danyliw's name. Please let us know any > >>>>> objections. > >>>>> > >>>>> Original: > >>>>> We would would also like to thank Amanda Baber, Mike Bishop, > >>>>> Ralph > >>>>> Bragg, Brian Campbell, Deb Cooley, Roman Danyliw, Gabriel > >>>>> Corona, > >>>>> Vladimir Dzhuvinov, George Fletcher, Arnt Gulbrandsen, Pieter > >>>>> Kasselman, Murray Kucherawy, David Mandelberg, Tony Nadalin, > >>>>> Francesca Palombini, John Scudder, Rifaat Shekh-Yusef, Filip > >>>>> Skokan, > >>>>> Orie Steele, Atul Tulshibagwale, Éric Vyncke, Paul Wouters, and > >>>>> Bo Wu > >>>>> for their contributions to the specification. > >>>>> > >>>>> Currently ("would would" has been fixed): > >>>>> We would also like to thank Amanda Baber, Mike Bishop, Ralph > >>>>> Bragg, > >>>>> Brian Campbell, Deb Cooley, Gabriel Corona, Roman Danyliw, > >>>>> Vladimir > >>>>> Dzhuvinov, George Fletcher, Arnt Gulbrandsen, Pieter Kasselman, > >>>>> Murray Kucherawy, David Mandelberg, Tony Nadalin, Francesca > >>>>> Palombini, John Scudder, Rifaat Shekh-Yusef, Filip Skokan, Orie > >>>>> Steele, Atul Tulshibagwale, Éric Vyncke, Paul Wouters, and Bo Wu > >>>>> for > >>>>> their contributions to the specification. --> > >>>>> > >>>>> Looks good, thanks. > >>>>> > >>>>> 26) <!-- [rfced] Please review the "Inclusive Language" portion > >>>>> of the > >>>>> online Style Guide at > >>>>> <https://www/. > >>>>> rfc- > >>>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > >>>>> 02%7C%7C03dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaa > >>>>> aaaaa%7C1%7C0%7C638802597201839021%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 > >>>>> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > >>>>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=KsZYR8dDQ8LdpDmxMVzjY%2FluS3GqJk%2B8wLD > >>>>> h1Lx7C3c%3D&reserved=0>, and let us know if any changes are > >>>>> needed. > >>>>> Updates of this nature typically result in more precise language, > >>>>> which is helpful for readers. > >>>>> > >>>>> For example, please consider whether the following should be > >>>>> updated: > >>>>> > >>>>> man-in-the-middle --> > >>>>> > >>>>> We believe “man-in-the-middle” can be removed from the sentence > >>>>> without affecting its meaning. Please do so. > >>>>> > >>>>> 27) <!-- [rfced] The following terms were used inconsistently in > >>>>> this > >>>>> document. We chose to use the latter forms. Please let us know > >>>>> any > >>>>> objections. > >>>>> > >>>>> Protected resource (1 instance) ("The Protected resource's") / > >>>>> protected resource (108 instances) > >>>>> > >>>>> Resource Identifier (1 instance in text) ("The protected > >>>>> resource's > >>>>> Resource Identifier") / resource identifier (19 instances in > >>>>> text) > >>>>> ("The protected resource's resource identifier") --> > >>>>> > >>>>> Agreed. > >>>>> > >>>>> Thank you. > >>>>> > >>>>> RFC Editor > >>>>> > >>>>> > >>>>> In this review, we also identified a mistake in an example. > >>>>> Please > >>>>> update the example in Section 5.1 as described in this pull > >>>>> request: > >>>>> https://githu/ > >>>>> b.com%2Foauth-wg%2Fdraft-ietf-oauth-resource- > >>>>> metadata%2Fpull%2F65%2Ffi > >>>>> les&data=05%7C02%7C%7C03dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f64 > >>>>> 0afb435aaaaaaaaaaaa%7C1%7C0%7C638802597201853214%7CUnknown%7CTWFpbGZsb > >>>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > >>>>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=h2wdn1pfYeI05m%2FpTa%2Fdd > >>>>> KkYl4UmkGUal9%2FGSqmf5t8%3D&reserved=0 > >>>>> > >>>>> (Lines 892-895 replaced with the below) > >>>>> > >>>>> HTTP/1.1 401 Unauthorized > >>>>> WWW-Authenticate: Bearer resource_metadata= > >>>>> > >>>>> Thanks for the thorough review. > >>>>> > >>>>> > >>>>>> On Apr 9, 2025, at 3:52 PM, rfc-edi...@rfc-editor.org wrote: > >>>>> > >>>>> *****IMPORTANT***** > >>>>> > >>>>> Updated 2025/04/09 > >>>>> > >>>>> 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://maila/ > >>>>> rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > >>>>> 4Q9l2USxIAe6P8 > >>>>> O4Zc&data=05%7C02%7C%7C03dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f6 > >>>>> 40afb435aaaaaaaaaaaa%7C1%7C0%7C638802597201902963%7CUnknown%7CTWFpbGZs > >>>>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > >>>>> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lQRqElj9UJPcPJtqZWyrg8%2 > >>>>> B18k1zyFYb5ozmWaYbZsI%3D&reserved=0 > >>>>> > >>>>> * The archive itself: > >>>>> > >>>>> https://maila/ > >>>>> rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7C%7C0 > >>>>> 3dd1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1 > >>>>> %7C0%7C638802597201915095%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy > >>>>> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > >>>>> 3D%7C0%7C%7C%7C&sdata=KRO4R3sNId6bw1CzSK1bifBXgLRoiV3Ga6j2e9E44wU%3D&r > >>>>> eserved=0 > >>>>> > >>>>> * 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/rfc9728.xml > >>>>> https://www.rfc-editor.org/authors/rfc9728.html > >>>>> https://www.rfc-editor.org/authors/rfc9728.pdf > >>>>> > >>>>> https://www.r/ > >>>>> fc- > >>>>> editor.org%2Fauthors%2Frfc9728.txt&data=05%7C02%7C%7C03dd1f9970bf48 > >>>>> 41b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638802 > >>>>> 597201962079%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL > >>>>> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > >>>>> 7C&sdata=9WtF%2BkNgKaleZydYZrgA4OGQBeI7lQcR0SYHqUeEadI%3D&reserved=0 > >>>>> > >>>>> Diff file of the text: > >>>>> https://www.rfc-editor.org/authors/rfc9728-diff.html > >>>>> > >>>>> https://www.r/ > >>>>> fc-editor.org%2Fauthors%2Frfc9728- > >>>>> rfcdiff.html&data=05%7C02%7C%7C03dd1 > >>>>> f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0 > >>>>> %7C638802597201984827%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > >>>>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > >>>>> C0%7C%7C%7C&sdata=Vx0krnpprmj8G98K8gkAVVIrCwfgUGuNwoGcQfiO3KY%3D&reser > >>>>> ved=0 (side by side) > >>>>> > >>>>> Diff of the XML: > >>>>> > >>>>> https://www.r/ > >>>>> fc-editor.org%2Fauthors%2Frfc9728- > >>>>> xmldiff1.html&data=05%7C02%7C%7C03dd > >>>>> 1f9970bf4841b6bd08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C > >>>>> 0%7C638802597201998456%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > >>>>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > >>>>> 7C0%7C%7C%7C&sdata=4oGXGo%2FBy1DegNnuw20yVy%2BTeGHs2Y3ntOZej%2FXqfO4%3 > >>>>> D&reserved=0 > >>>>> > >>>>> > >>>>> Tracking progress > >>>>> ----------------- > >>>>> > >>>>> The details of the AUTH48 status of your document are here: > >>>>> > >>>>> https://www.r/ > >>>>> fc- > >>>>> editor.org%2Fauth48%2Frfc9728&data=05%7C02%7C%7C03dd1f9970bf4841b6b > >>>>> d08dd7b93de50%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63880259720 > >>>>> 2010697%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > >>>>> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > >>>>> ata=EncU0stsHS%2Bra2SNhCMyi7I%2FzMqt328rQmQ%2BymJRLkM%3D&reserved=0 > >>>>> > >>>>> Please let us know if you have any questions. > >>>>> > >>>>> Thank you for your cooperation, > >>>>> > >>>>> RFC Editor > >>>>> > >>>>> -------------------------------------- > >>>>> RFC 9728 (draft-ietf-oauth-resource-metadata-13) > >>>>> > >>>>> Title : OAuth 2.0 Protected Resource Metadata > >>>>> Author(s) : M.B. Jones, P. Hunt, A. Parecki > >>>>> WG Chair(s) : Hannes Tschofenig, Rifaat Shekh-Yusef > >>>>> 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
