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
