jiebi/TextFlow huggingface dataset:
Original text:
2.3.1. Authorization servers MUST require clients to register their complete <del> redirect URI (including the path component) and reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered; the exception is loopback redirects, where an exact match is required except for the port URI component. </del>  The authorization server MAY allow the client to register multiple redirect URIs.  For private-use URI scheme-based redirect URIs, authorization servers SHOULD enforce the requirement in private-use-uri-scheme that clients use schemes that are reverse domain name based.  At a minimum, any

Reviewer comments:
for issue
URL Redirect URIs are not required to be registered if the client is using PAR and is a confidential client.
Discussed in the side meeting: Mike suggested that if 2.1 talks about this exception at all, it include a note that PAR defines an exception to the pre-registration requirement, which cites the PAR section. The text should be a heads-up to implementers - not appear to be defining something new.

Revised text:
2.3.1. Authorization servers MUST require clients to register their complete  <ins> redirect URI (including the path component).  Authorization servers MUST reject authorization requests that specify a redirect URI that doesn't exactly match one that was registered, with an exception for loopback redirects, where an exact match is required except for the port URI component. </ins> The authorization server MAY allow the client to register multiple redirect URIs. <ins> Registration may happen out of band, such as a manual step of configuring the client information at the authorization server, or may happen at runtime, such as in the initial POST in Pushed Authorization Requests RFC9126. </ins> For private-use URI scheme-based redirect URIs, authorization servers SHOULD enforce the requirement in private-use-uri-scheme that clients use schemes that are reverse domain name based.  At a minimum, any
Original text:
token and client identity whenever the client identity can be authenticated.  When client authentication is not possible, the authorization server SHOULD issue sender-constrained refresh tokens <del> or use refresh token rotation as described in (#refresh-token- endpoint-extension). </del>  The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by

Reviewer comments:
Fixed URL
Thank you!
The following link appears to be broken. URL I have confirmed that the link works correctly by fixing `.

Revised text:
token and client identity whenever the client identity can be authenticated.  When client authentication is not possible, the authorization server SHOULD issue sender-constrained refresh tokens  <ins> or use refresh token rotation as described in refresh-token-endpoint- extension. </ins> The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by
Original text:
2.3.4. <del> In order to prevent mix-up attacks, clients MUST only process redirect responses of the authorization server they sent the respective request to and from the same user agent this authorization request was initiated with.  Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization response was received from the correct authorization server.  Clients MUST ensure that the subsequent access token request, if applicable, is sent to the same authorization server.  Clients SHOULD use distinct redirect URIs for each authorization server as a means to identify the authorization server a particular response came from. </del>  2.3.5.

Reviewer comments:
Most of the text is copied from the security BCP and only slightly adjusted. I am not sure if 2.1 needs to contain the detailed description of mix-up attacks and variants (56b6b6cdcfccf30baa124d37597d18a7cecf032e) or if it would be sufficient to add mix-up mitigations (2d07d10b9787d3798fab0913ff67ea1cd2e29d89).
Thank you, in general we have been erring on the side of leaving the detailed discussion of the security considerations in the Security BCP, and only moving the mitigation recommendations in 2.1. Would you be able to remove the detailed description from this PR?
Finally had the time for this quick revert of my latest commit. Do you think the description of mix-up is fine now? Should we add a reference to the detailed description of mix-up attacks in the security BCP?
Thanks, I added a reference to the security BCP in that section

Revised text:
2.3.4.  <ins> When an OAuth client can only interact with one authorization server, a mix-up defense is not required.  In scenarios where an OAuth client interacts with two or more authorization servers, however, clients MUST prevent mix-up attacks.  In order to prevent mix-up attacks, clients MUST only process redirect responses of the issuer they sent the respective request to and from the same user agent this authorization request was initiated with. See mixupcountermeasures for a detailed description of two different defenses against mix-up attacks. </ins> 2.3.5.
Original text:
authorization request.  The exact value received from the client. OPTIONAL.  The identifier of the authorization server which the <del> client can use to prevent mixup attacks, if the client interacts with more than one authorization server.  See RFC9207 for additional details on when this parameter is necessary, and how the client can use it to prevent mixup attacks. </del>  For example, the authorization server redirects the user agent by sending the following HTTP response:

Reviewer comments:
Most of the text is copied from the security BCP and only slightly adjusted. I am not sure if 2.1 needs to contain the detailed description of mix-up attacks and variants (56b6b6cdcfccf30baa124d37597d18a7cecf032e) or if it would be sufficient to add mix-up mitigations (2d07d10b9787d3798fab0913ff67ea1cd2e29d89).
Thank you, in general we have been erring on the side of leaving the detailed discussion of the security considerations in the Security BCP, and only moving the mitigation recommendations in 2.1. Would you be able to remove the detailed description from this PR?
Finally had the time for this quick revert of my latest commit. Do you think the description of mix-up is fine now? Should we add a reference to the detailed description of mix-up attacks in the security BCP?
Thanks, I added a reference to the security BCP in that section

Revised text:
authorization request.  The exact value received from the client. OPTIONAL.  The identifier of the authorization server which the  <ins> client can use to prevent mix-up attacks, if the client interacts with more than one authorization server.  See mix-up and RFC9207 for additional details on when this parameter is necessary, and how the client can use it to prevent mix-up attacks. </ins> For example, the authorization server redirects the user agent by sending the following HTTP response:
Original text:
REQUIRED.  The type of the access token issued as described in access-tokens.  Value is case insensitive. <del> RECOMMENDED.  The lifetime in seconds of the access token.  For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated.  If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value. </del>  RECOMMENDED, if identical to the scope requested by the client; otherwise, REQUIRED.  The scope of the access token as described

Reviewer comments:
This small PR attempts to clarify an unfortunately not that rare mistake of server implementations where they respond with a JSON string and not the expected JSON number. In between the client implementations I maintain I get a PRs/issues at least twice a year which ask that the clients attempt to normalize the Token Endpoint response expires_in value instead of expecting it to be a number.
Just curious, won't this necessities adding the type for all other parameters? Because a few sentences after the proposed edit, the specification states:
It might. In the past this awkward definition in a follow up paragraph might've been seen as necessary because the same response parameters and their descriptions were used for the implicit grant response which does not have any data types associated given it's part of the url fragment. With that portion of the spec gone we might as well put the JSON data type in the descriptions for all token response parameters.

Revised text:
REQUIRED.  The type of the access token issued as described in access-tokens.  Value is case insensitive.  <ins> RECOMMENDED.  A JSON number that represents the lifetime in seconds of the access token.  For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated.  If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value. </ins> RECOMMENDED, if identical to the scope requested by the client; otherwise, REQUIRED.  The scope of the access token as described
Original text:
1.3.3. <del> The client credentials or other forms of client authentication (e.g. </del>  a private key used to sign a JWT, as described in RFC7523) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client,

Reviewer comments:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Revised text:
1.3.3.  <ins> The client credentials or other forms of client authentication (e.g., </ins> a private key used to sign a JWT, as described in RFC7523) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client,
Original text:
authentication, integrity and confidentiality such as Transport-Layer Security RFC8446, to protect the exchange of clear-text credentials and tokens either in the content or in header fields from <del> eavesdropping, tampering, and message forgery (eg. see client-secret, authorization_codes, token-endpoint, and bearer-tokens). </del>  OAuth URLs MUST use the "https" scheme except for loopback interface redirect URIs, which MAY use the "http" scheme.  When using "https",

Reviewer comments:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Revised text:
authentication, integrity and confidentiality such as Transport-Layer Security RFC8446, to protect the exchange of clear-text credentials and tokens either in the content or in header fields from  <ins> eavesdropping, tampering, and message forgery (e.g., see client- secret, authorization_codes, token-endpoint, and bearer-tokens). </ins> OAuth URLs MUST use the "https" scheme except for loopback interface redirect URIs, which MAY use the "http" scheme.  When using "https",
Original text:
an HTML document response, processed by the user agent.  If the HTML response is served directly as the result of the redirection request, any script included in the HTML document will execute with full <del> access to the redirect URI and the artifacts (e.g. authorization </del>  code) it contains.  Additionally, the request URL containing the authorization code may be sent in the HTTP Referer header to any embedded images, stylesheets and other elements loaded in the page.

Reviewer comments:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Revised text:
an HTML document response, processed by the user agent.  If the HTML response is served directly as the result of the redirection request, any script included in the HTML document will execute with full  <ins> access to the redirect URI and the artifacts (e.g., authorization </ins> code) it contains.  Additionally, the request URL containing the authorization code may be sent in the HTTP Referer header to any embedded images, stylesheets and other elements loaded in the page.
Original text:
_Sender-constrained refresh tokens:_ the authorization server cryptographically binds the refresh token to a certain client <del> instance, e.g. by utilizing DPoP RFC9449 or mTLS RFC8705. </del>  _Refresh token rotation:_ the authorization server issues a new refresh token with every access token refresh response.  The

Reviewer comments:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Revised text:
_Sender-constrained refresh tokens:_ the authorization server cryptographically binds the refresh token to a certain client  <ins> instance, e.g., by utilizing DPoP RFC9449 or mTLS RFC8705. </ins> _Refresh token rotation:_ the authorization server issues a new refresh token with every access token refresh response.  The
Original text:
9. <del> Browser-based apps are are clients that run in a web browser, typically written in JavaScript, also known as "single-page apps". These types of apps have particular security considerations similar to native apps. </del>  TODO: Bring in the normative text of the browser-based apps BCP when it is finalized.

Reviewer comments:
cb2616f30c91b68b99f8eb492cce400bf394bc08 - Removes a duplicate "are".

Revised text:
9.  <ins> Browser-based apps are clients that run in a web browser, typically written in JavaScript, also known as "single-page apps".  These types of apps have particular security considerations similar to native apps. </ins> TODO: Bring in the normative text of the browser-based apps BCP when it is finalized.
Original text:
authorization server during the client registration process. The redirect URI MUST be an absolute URI as defined by RFC3986 <del> Section 4.3.  The redirect URI MAY include an "application/x-www- form-urlencoded" formatted query component (WHATWG.URL), which MUST be retained when adding additional query parameters.  The redirect URI MUST NOT include a fragment component. </del>  2.3.1.

Reviewer comments:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Revised text:
authorization server during the client registration process. The redirect URI MUST be an absolute URI as defined by RFC3986  <ins> Section 4.3.  The redirect URI MAY include an query string component (query-string-serialization), which MUST be retained when adding additional query parameters.  The redirect URI MUST NOT include a fragment component. </ins> 2.3.1.
Original text:
the authorization server's metadata document (RFC8414). The authorization endpoint URL MUST NOT include a fragment component, <del> and MAY include an "application/x-www-form-urlencoded" formatted query component WHATWG.URL, which MUST be retained when adding additional query parameters. </del>  The authorization server MUST support the use of the HTTP "GET" method Section 9.3.1 of RFC9110 for the authorization endpoint and

Reviewer comments:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Revised text:
the authorization server's metadata document (RFC8414). The authorization endpoint URL MUST NOT include a fragment component,  <ins> and MAY include a query string component query-string-serialization, which MUST be retained when adding additional query parameters. </ins> The authorization server MUST support the use of the HTTP "GET" method Section 9.3.1 of RFC9110 for the authorization endpoint and
Original text:
metadata document (RFC8414) and fetched programmatically at runtime. The token endpoint URL MUST NOT include a fragment component, and MAY <del> include an "application/x-www-form-urlencoded" formatted query component (WHATWG.URL). </del>  The client MUST use the HTTP "POST" method when making requests to the token endpoint.

Reviewer comments:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Revised text:
metadata document (RFC8414) and fetched programmatically at runtime. The token endpoint URL MUST NOT include a fragment component, and MAY  <ins> include a query string component query-string-serialization. </ins> The client MUST use the HTTP "POST" method when making requests to the token endpoint.
Original text:
3.2.2. The client makes a request to the token endpoint by sending the <del> following parameters using the "application/x-www-form-urlencoded" format per application-x-www-form-urlencoded with a character encoding of UTF-8 in the HTTP request content: </del>  REQUIRED.  Identifier of the grant type the client uses with the particular token request.  This specification defines the values

Reviewer comments:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Revised text:
3.2.2. The client makes a request to the token endpoint by sending the  <ins> following parameters using the form-encoded serialization format per form-serialization with a character encoding of UTF-8 in the HTTP request content: </ins> REQUIRED.  Identifier of the grant type the client uses with the particular token request.  This specification defines the values
Original text:
%x5D-7E. The parameters are included in the content of the HTTP response using <del> the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each parameter at the highest structure level.  Parameter names and string values are included as JSON strings.  Numerical values are included as JSON numbers.  The order of parameters does not matter and can vary. </del>  For example:

Reviewer comments:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Revised text:
%x5D-7E. The parameters are included in the content of the HTTP response using  <ins> the "application/json" media type as defined in json-serialization. </ins> For example:
Original text:
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI <del> using the "application/x-www-form-urlencoded" format, per application-x-www-form-urlencoded: </del>  REQUIRED.  The authorization endpoint supports different sets of request and response parameters.  The client determines the type

Reviewer comments:
This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM

Revised text:
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI  <ins> as described by query-string-serialization: </ins> REQUIRED.  The authorization endpoint supports different sets of request and response parameters.  The client determines the type