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
