jiebi/CodeConvo huggingface dataset:
Code change:
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.

Related discussion:
text: presenting an access token. The resource server responds with a "WWW-Authenticate" header <del> including the resource identifier of the protected resource. </del> <ins> including the URL of the protected resource metadata. </ins> <del> The client fetches resource metadata from the ".well-known/oauth- protected-resource" location derived from the resource identifier according to PRConfig. </del> <ins> The client fetches the protected resource metadata from this URL. </ins> The protected resource responds with the protected resource metadata according to PRConfigurationResponse. <ins> The client validates the protected resource metadata. </ins> 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.
Code change:
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.

Related discussion:
text: 5.1. This specification introduces a new parameter in the "WWW- <del> Authenticate" response to indicate the resource identifier of the protected resource: </del> <ins> Authenticate" response to indicate the protected resource metadata URL: </ins> <del> The resource identifier of the protected resource. </del> <ins> The URL of the protected resource metadata. </ins> The HTTP status code and error string in the response are defined by RFC6750. <del> The issuer parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </del> <ins> The "resource_metadata" parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </ins> 5.2. At any point, for any reason determined by the protected resource, the protected resource MAY respond with a new "WWW-Authenticate" <del> challenge that includes a value for the resource identifier to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </del> <ins> challenge that includes a value for the protected resource metadata URL to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </ins> 5.3.
Code change:
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.

Related discussion:
text: There are some existing methods by which an unrecognized client can make use of an authorization server, such as using Dynamic Client <del> Registration RFC7591, to register the client prior to initiating the </del> <ins> Registration RFC7591 to register the client prior to initiating the </ins> authorization flow.  Future extensions might define alternatives, such as using URLs to identify clients.
Code change:
Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.

Related discussion:
text: Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison. <ins> Note that this is the same equality comparison procedure described in Section 8.3 of RFC8259. </ins> 7. 7.1.
Code change:
This fixes the definition, it incorrectly used "fragment" when it meant "body" as later shown in section-3.2

Related discussion:
text: OPTIONAL.  JSON array containing a list of the OAuth 2.0 Bearer Token RFC6750 presentation methods that this protected resource <del> supports.  Defined values are "["header", "fragment", "query"]", </del> <ins> supports.  Defined values are "["header", "body", "query"]", </ins> corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.
Code change:
cc NAME
From Pieter's review: Since "presentation methods" has come to have a new meaning. The language above is consistent with the language used in 6750.
The text is clear and brings better alignment with the name of the parameter.

Related discussion:
text: used. <del> OPTIONAL.  JSON array containing a list of the OAuth 2.0 Bearer Token RFC6750 presentation methods that this protected resource supports.  Defined values are "["header", "body", "query"]", </del> <ins> OPTIONAL.  JSON array containing a list of the supported methods of sending an OAuth 2.0 Bearer Token RFC6750 to the protected resource.  Defined values are "["header", "body", "query"]", </ins> corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.
Code change:
cc NAME
From Pieter's review: "between the host and path components of the protected resource's resource identifier, as shown in Section 3.1 below"
Looks good to me.

Related discussion:
text: is "/.well-known/oauth-protected-resource".  The syntax and semantics of ".well-known" are defined in RFC5785.  The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry <del> IANA.well-known. </del> <ins> IANA.well-known.  Examples of this construction can be found in PRConfigurationRequest. </ins> Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well-
Code change:
Cc NAME
Section 3.3 should reference the attack described in section 7.3 URL And evaluate whether it makes sense to add a back reference from 7.3 to 3.3.
Looks good to me.

Related discussion:
text: to the resource server.  If these values are not identical, the data contained in the response MUST NOT be used. <ins> These validation actions can thwart impersonation attacks, as described in Impersonation. </ins> 4. To support use cases in which the set of legitimate protected
Code change:
Cc NAME
Section 3.3 should reference the attack described in section 7.3 URL And evaluate whether it makes sense to add a back reference from 7.3 to 3.3.
Looks good to me.

Related discussion:
text: the resource identifier URL it is using as the prefix for the metadata request exactly matches the value of the "resource" metadata value in the protected resource metadata document received by the <del> client. </del> <ins> client, as described in PRConfigurationValidation. </ins> 7.4.
Code change:
cc NAME
[ ] Step 5, add reference to how to validate: "...according to the validation steps described in Section 2.1 (validation of signed resource metadata if it applies) and Section 3.3" [ ] Step 5.2: rephrase to "If the client receives such a WWW-Authenticate response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained."
Looks good to me.

Related discussion:
text: The resource server responds with the protected resource metadata according to PRConfigurationResponse. <del> The client validates the protected resource metadata. </del> <ins> The client validates the protected resource metadata, as described in PRConfigurationValidation. </ins> The client builds the authorization server metadata URL from an issuer identifier in the resource metadata according to RFC8414
Code change:
cc NAME
[ ] Step 5, add reference to how to validate: "...according to the validation steps described in Section 2.1 (validation of signed resource metadata if it applies) and Section 3.3" [ ] Step 5.2: rephrase to "If the client receives such a WWW-Authenticate response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained."
Looks good to me.

Related discussion:
text: the protected resource MAY respond with a new "WWW-Authenticate" challenge that includes a value for the protected resource metadata URL to indicate that its metadata MAY have changed.  If the client <del> receives such a "WWW-Authenticate" response, the client SHOULD retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </del> <ins> receives such a "WWW-Authenticate" response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </ins> 5.3.
Code change:
cc NAME
URL Move paragraph 3 to the top so that we first talk about what use cases are supported.
Looks good to me.

Related discussion:
text: 7.6. <ins> To support use cases in which the set of legitimate authorization servers to use with the protected resource is fixed and enumerable, this specification defines the "authorization_servers" metadata value, which enables explicitly listing them.  Note that if the set of legitimate protected resources to use with an authorization server is also fixed and enumerable, lists in the protected resource metadata and authorization server metadata should be cross-checked against one another for consistency when these lists are used by the application profile. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this specification.  This specification assumes that the client has a
Code change:
cc NAME
URL Move paragraph 3 to the top so that we first talk about what use cases are supported.
Looks good to me.

Related discussion:
text: other means of determining appropriate associations between protected resources and authorization servers are also possible. <del> To support use cases in which the set of legitimate authorization servers to use with the protected resource is fixed and enumerable, this specification defines the "authorization_servers" metadata value, which enables explicitly listing them.  Note that if the set of legitimate protected resources to use with an authorization server is also fixed and enumerable, lists in the protected resource metadata and authorization server metadata should be cross-checked against one another for consistency when these lists are used by the application profile. </del> 7.7. The OAuth client is expected to fetch the authorization server
Code change:
Removed extraneous paragraph about downgrade attacks discussing an issue that's already addressed elsewhere in the specification.

Related discussion:
text: specification, and allows clients to choose their preferred authentication scheme. <del> A fair question is whether allowing clients to choose from among supported authentication methods represents an opportunity for a downgrade attack.  Since resource servers will only enumerate authentication methods acceptable to them, by definition, any choice made by the client from among them is one that the resource server is OK with.  Thus, the resource server allowing the use of different supported authentication methods does not represent an opportunity for a downgrade attack. </del> 6. Processing some OAuth 2.0 messages requires comparing values in the
Code change:
for
Per my reply to Bo Wu's OpsDir review: NAME can you add your motivating example to the introduction? Thanks!
I didn't mean to merge that PR without your review, so let me know if it looks good before I close this issue!
Looks good! The only change I made was to make the WebFinger reference informative. Please close.
Good catch, not sure why that wasn't informative before.
It was previously incorrectly normative. I just happened to notice when reviewing your addition. Thanks again!

Related discussion:
text: RFC8414, which enables a client to obtain metadata about an OAuth 2.0 authorization server. <ins> The means by which the client obtains the location of the protected resource is out of scope of this document.  In some cases, the location may be manually configured into the client; for example, an email client could provide an interface for a user to enter the URL of their RFC8620 server.  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 RFC7033 discovery (in a manner related to the description in Section 2 of 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. </ins> The metadata for a protected resource is retrieved from a well-known location as a JSON RFC8259 document, which declares information about its capabilities and optionally, its relationships to other services.
Code change:
for
Per my reply to Bo Wu's OpsDir review: NAME can you add your motivating example to the introduction? Thanks!
I didn't mean to merge that PR without your review, so let me know if it looks good before I close this issue!
Looks good! The only change I made was to make the WebFinger reference informative. Please close.
Good catch, not sure why that wasn't informative before.
It was previously incorrectly normative. I just happened to notice when reviewing your addition. Thanks again!

Related discussion:
text: authoritative for the protected resource, as described in Impersonation. <del> The means by which the client obtains the location of the protected resource is out of scope.  In some cases, the location may be manually configured into the client.  In other cases, it may be dynamically discovered, for instance, through the use of RFC7033, in a manner related to the description in Section 2 of OpenID.Discovery. </del> PRMetadata defines metadata values that a protected resource can publish, which includes things like which scopes are supported, how a client can present an access token, and more.  These values may be
Code change:
from review comments from John Scudder
Please also add John Scudder to the acknowledgements.

Related discussion:
text: WWW-Authenticate describes the use of "WWW-Authenticate" by protected resources to dynamically inform clients of the URL of their protected resource metadata.  This use of "WWW-Authenticate" can indicate that <del> the protected resource metadata MAY have changed. </del> <ins> the protected resource metadata may have changed. </ins> 1.1.
Code change:
from review comments from John Scudder
Please also add John Scudder to the acknowledgements.

Related discussion:
text: At any point, for any reason determined by the resource server, the protected resource MAY respond with a new "WWW-Authenticate" challenge that includes a value for the protected resource metadata <del> URL to indicate that its metadata MAY have changed.  If the client </del> <ins> URL to indicate that its metadata may have changed.  If the client </ins> receives such a "WWW-Authenticate" response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained, after validating them as described in
Code change:
... per additional feedback by NAME Cc: NAME
I'm checking with IANA.... will reply once they respond. Thanks for the work!

Related discussion:
text: Values are registered on a Specification Required RFC8126 basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to <del> allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. </del> <ins> allow for the allocation of values prior to publication of the final version of a specification, the Designated Experts may approve registration once they are satisfied that the specification will be completed and published.  However, if the specification is not completed and published in a timely manner, as determined by the Designated Experts, the Designated Experts may request that IANA withdraw the registration. </ins> Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Protected
Code change:
... per additional feedback by NAME Cc: NAME
I'm checking with IANA.... will reply once they respond. Thanks for the work!

Related discussion:
text: Expert, that Expert should defer to the judgment of the other Experts. <ins> The reason for the use of the mailing list is to enable public review of registration requests, enabling both Designated Experts and other interested parties to provide feedback on proposed registrations. 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. </ins> 8.1. This specification establishes the IANA "OAuth Protected Resource
Code change:
maybe adjust the language around DEFLATE and ZLIB per Originally posted by NAME in URL
Copied over, to have everything in the issue here: This is the current text: This is the proposal: >The complete byte array is compressed using DEFLATE {{RFC1951}} inside the ZLIB {{RFC1950}} data format. Implementations are RECOMMENDED to use the highest compression level available. I agree that the current text is a bit weird and I wasn't really sure how to formulate it better when writing it.
More context copied over via Screenshot: !

Related discussion:
text: ("7").  All bits of the byte array at a particular index are set to a status value. <del> The complete byte array is compressed using the "DEFLATE" RFC1951 compression method and stored using the "ZLIB" RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </del> <ins> The byte array is compressed using DEFLATE RFC1951 with the ZLIB RFC1950 data format.  Implementations are RECOMMENDED to use the highest compression level available. </ins> The following example illustrates a Status List that represents the statuses of 16 Referenced Tokens, requiring 16 bits (2 bytes) for the
Code change:
Fixes most of Relaxes requirements on referenced token in terminology issuer in status list token is only required when also present in referenced token (and matching checked) reorder references

Related discussion:
text: The following content applies to the JWT Claims Set: <del> "iss": REQUIRED.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the Referenced Token. </del> <ins> "iss": REQUIRED when also present in the Referenced Token.  The "iss" (issuer) claim MUST specify a unique string identifier for the entity that issued the Status List Token.  In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC3986.  The value MUST be equal to that of the "iss" claim contained within the Referenced Token. </ins> "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for that Status List Token.  The value MUST be