jiebi/CodeConvo huggingface dataset:
Code change:
To address issue
From Yaron's : how is "azd" different from "rctx"? There's a whole section about "rctx" and nothing about "azd".
Discussed in meeting on 06/14/2024: Add a subsection for azd, like we agreed to add a section for purp.
Looks good

Related discussion:
text: that have requested Txn-Tokens as part of the transaction processing. <del> 5.2.1.1. </del> <ins> 5.2.2. The Txn-Token SHOULD contain an "azd" claim.  The value of this claim is a JSON object that contains name/value pairs (wherein the value could itself be an object), which together assert the details that remain immutable through the call-chain where this Txn-Token is used. Txn-Tokens are primarily used to assure identity and context for a transaction, and the content of this field is a critical part of that context. Whereas the "rctx" field contains environmental values related to the request, the "azd" field contains the actual authorizaiton details that are determined by the TTS.  These values are used by services using the Txn-Token to reliably obtain specific parameters needed to perform their work.  The content of the "azd" field is determined by the Txn-Token Service and they may be computed internally or from parameters it receives from the service that requests the Txn-Token. The following is a non-normative example of an "azd" claim: 5.2.2.1. </ins> It is useful to be able to track the set of workloads that have requested a Txn-Token.  The "req_wl" claim allows for tracking this
Code change:
To address issue
From Yaron's : how is "azd" different from "rctx"? There's a whole section about "rctx" and nothing about "azd".
Discussed in meeting on 06/14/2024: Add a subsection for azd, like we agreed to add a section for purp.
Looks good

Related discussion:
text: single value, then "req_wl" will be prepresented by an array of StringOrURIs. <del> 5.2.2. </del> <ins> 5.2.3. </ins> The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:
Code change:
An invalid link to the OpenID core spec has been fixed, as well as a section number referencing the draft.

Related discussion:
text: string of URIs as per Section 4.3.2 of Refresh tokens for public clients must either be sender- <del> constrained or one-time use as per Section 4.12.2 of </del> <ins> constrained or one-time use as per Section 4.13.2 of </ins> 10.1.
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: 1.3.3. The client credentials or other forms of client authentication (e.g. <del> a "client_secret" or a private key used to sign a JWT) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </del> <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, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </ins> 1.4.
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: the process of issuance/registration and distribution of the underlying credentials ensures their confidentiality. <del> If the client is confidential or credentialed, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </del> <ins> If the client is confidential, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </ins> It is RECOMMENDED to use asymmetric (public-key based) methods for client authentication such as mTLS RFC8705 or "private_key_jwt"
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: credentials to a counterfeit client after obtaining resource owner authorization. <del> The authorization server MAY establish a client authentication method with public clients, which converts them to credentialed clients. However, the authorization server MUST NOT rely on credentialed client authentication for the purpose of identifying the client. </del> The client MUST NOT use more than one authentication method in each request to prevent a conflict of which authentication mechanism is authoritative for the request.
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: 3.2.1. <del> Confidential or credentialed clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint. </del> <ins> Confidential clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint. </ins> Client authentication is used for:
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: supported by the token request.  The details of those grant types are defined below. <del> Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client- authentication. </del> <ins> Confidential clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </ins> For example, the client makes the following HTTP request (with extra line breaks for display purposes only): The authorization server MUST: <del> require client authentication for confidential and credentialed clients (or clients with other authentication requirements), </del> <ins> require client authentication for confidential clients (or clients with other authentication requirements), </ins> authenticate the client if client authentication is included
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: authorization server MUST: ensure that the authorization code was issued to the authenticated <del> confidential or credentialed client, or if the client is public, ensure that the code was issued to "client_id" in the request, </del> <ins> confidential client, or if the client is public, ensure that the code was issued to "client_id" in the request, </ins> verify that the authorization code is valid,
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: the scope of this specification). The client credentials grant type MUST only be used by confidential <del> or credentialed clients. </del> <ins> clients. </ins> The use of the client credentials grant illustrated in fig-client- credentials-grant includes the following steps:
Code change:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Related discussion:
text: Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the <del> client to which it was issued.  Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </del> <ins> client to which it was issued.  Confidential clients MUST authenticate with the authorization server as described in token- endpoint-client-authentication. </ins> For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes
Code change:
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.

Related discussion:
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> <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
Code change:
Fixed URL
Thank you!
The following link appears to be broken. URL I have confirmed that the link works correctly by fixing `.

Related discussion:
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> <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
Code change:
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

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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> <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
Code change:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Related discussion:
text: 1.3.3. <del> The client credentials or other forms of client authentication (e.g. </del> <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,
Code change:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Related discussion:
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> <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",
Code change:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Related discussion:
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> <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.
Code change:
657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"

Related discussion:
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> <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
Code change:
cb2616f30c91b68b99f8eb492cce400bf394bc08 - Removes a duplicate "are".

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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