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-...@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 (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-middle with >>>> adversary-in-the-middle, which apparently NIST 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" >>>> 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
