jiebi/TextFlow huggingface dataset:
Original text:
presenting an access token. The resource server responds with a "WWW-Authenticate" header <del> including the resource identifier of the protected resource. </del>  <del> The client fetches resource metadata from the ".well-known/oauth- protected-resource" location derived from the resource identifier according to PRConfig. </del>  The protected resource responds with the protected resource metadata according to PRConfigurationResponse.  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.

Reviewer comments:
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.

Revised text:
presenting an access token. The resource server responds with a "WWW-Authenticate" header  <ins> including the URL of the protected resource metadata. </ins>  <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.
Original 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>  authorization flow.  Future extensions might define alternatives, such as using URLs to identify clients.

Reviewer comments:
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.

Revised text:
There are some existing methods by which an unrecognized client can make use of an authorization server, such as using Dynamic Client  <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.
Original text:
Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison.  7. 7.1.

Reviewer comments:
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.

Revised 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.
Original 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>  corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.

Reviewer comments:
This fixes the definition, it incorrectly used "fragment" when it meant "body" as later shown in section-3.2

Revised text:
OPTIONAL.  JSON array containing a list of the OAuth 2.0 Bearer Token RFC6750 presentation methods that this protected resource  <ins> supports.  Defined values are "["header", "body", "query"]", </ins> corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.
Original 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>  corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.

Reviewer comments:
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.

Revised text:
used.  <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.
Original 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>  Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well-

Reviewer comments:
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.

Revised 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  <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-
Original text:
to the resource server.  If these values are not identical, the data contained in the response MUST NOT be used.  4. To support use cases in which the set of legitimate protected

Reviewer comments:
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.

Revised 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
Original 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>  7.4.

Reviewer comments:
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.

Revised 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  <ins> client, as described in PRConfigurationValidation. </ins> 7.4.
Original text:
The resource server responds with the protected resource metadata according to PRConfigurationResponse. <del> The client validates the protected resource metadata. </del>  The client builds the authorization server metadata URL from an issuer identifier in the resource metadata according to RFC8414

Reviewer comments:
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.

Revised text:
The resource server responds with the protected resource metadata according to PRConfigurationResponse.  <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
Original 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>  5.3.

Reviewer comments:
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.

Revised 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  <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.
Original text:
7.6.  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

Reviewer comments:
cc NAME
URL Move paragraph 3 to the top so that we first talk about what use cases are supported.
Looks good to me.

Revised 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
Original 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

Reviewer comments:
cc NAME
URL Move paragraph 3 to the top so that we first talk about what use cases are supported.
Looks good to me.

Revised text:
other means of determining appropriate associations between protected resources and authorization servers are also possible.  7.7. The OAuth client is expected to fetch the authorization server
Original 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

Reviewer comments:
Removed extraneous paragraph about downgrade attacks discussing an issue that's already addressed elsewhere in the specification.

Revised text:
specification, and allows clients to choose their preferred authentication scheme.  6. Processing some OAuth 2.0 messages requires comparing values in the
Original text:
RFC8414, which enables a client to obtain metadata about an OAuth 2.0 authorization server.  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.

Reviewer comments:
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!

Revised 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.
Original 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

Reviewer comments:
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!

Revised text:
authoritative for the protected resource, as described in Impersonation.  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
Original 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>  1.1.

Reviewer comments:
from review comments from John Scudder
Please also add John Scudder to the acknowledgements.

Revised 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  <ins> the protected resource metadata may have changed. </ins> 1.1.
Original 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>  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

Reviewer comments:
from review comments from John Scudder
Please also add John Scudder to the acknowledgements.

Revised 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  <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
Original 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>  Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Protected

Reviewer comments:
... per additional feedback by NAME Cc: NAME
I'm checking with IANA.... will reply once they respond. Thanks for the work!

Revised 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  <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
Original text:
Expert, that Expert should defer to the judgment of the other Experts.  8.1. This specification establishes the IANA "OAuth Protected Resource

Reviewer comments:
... per additional feedback by NAME Cc: NAME
I'm checking with IANA.... will reply once they respond. Thanks for the work!

Revised 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