jiebi/CodeConvo huggingface dataset:
Code change:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Related discussion:
text: 3. <ins> Client Attestation JWT A JSON Web Token (JWT) generated by the client backend that authenticates the client instance. Client Attestation Proof of Possession (PoP) A Proof of Possession generated by the client instance for the key that is used in the Client Attestation JWT. Client Instance Key A cryptographic, asymmetric key generated by the client instance and proven to the client backend.  The public key is contained in the Client Attestation JWT and is used to sign the Client Attestation Proof of Possession 4. </ins> To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. The value of the "client_assertion_type" is <del> "urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation". </del> <ins> "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation". </ins> The value of the "client_assertion" parameter contains two JWTs, separated by a '~' character.  It MUST NOT contain more or less than <del> precisely two JWTs seperated by the '~` character.  The first JWT MUST be the client key attestation JWT defined in client-key- attestation-jwt, the second JWT MUST the client key attestation PoP defined in client-key-attestation-pop-jwt. </del> <ins> precisely two JWTs seperated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST the client attestation PoP defined in client- attestation-pop-jwt. </ins> The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only): <del> 3.1. </del> <ins> 4.1. </ins> In order to authenticate the client using this scheme, the authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below. It is RECOMMENDED that the authorization server validate the Client <del> Key Attestation prior to validating the Client Key Attestation PoP. </del> <ins> Attestation JWT prior to validating the Client Attestation PoP. </ins> <del> 3.1.1. </del> <ins> 4.1.1. </ins> <del> The following rules apply to validating the client key attestation JWT.  Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the client attestation JWT. Application of additional restrictions and policy are at the </ins> discretion of the authorization server. The JWT MUST contain an "iss" (issuer) claim that contains a
Code change:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Related discussion:
text: The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 3.1.2. </del> <ins> 4.1.2. </ins> <del> The following rules apply to validating the client key attestation PoP JWT.  Application of additional restrictions and policy are at the discretion of the authorization server. </del> <ins> The following rules apply to validating the client attestation PoP JWT.  Application of additional restrictions and policy are at the discretion of the authorization server. </ins> The JWT MUST contain an "iss" (issuer) claim with a value corresponding to the "client_id" of the OAuth client.
Code change:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Related discussion:
text: authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client key attestation JWT. </del> <ins> the "cnf" claim of the corresponding client attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.
Code change:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Related discussion:
text: The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4. </del> <ins> 5. </ins> <del> 4.1. </del> <ins> 5.1. </ins> Implementers should be aware that the design of this authentication mechanism deliberately allows for a client instance to re-use a
Code change:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Related discussion:
text: ultimately controls how long a client instance can re-use a single Client Attestation JWT. <del> 4.2. </del> <ins> 5.2. </ins> Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt- <del> key-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion- type:jwt-key-attestation" authentication method.  The client MUST also use the same client attestation key that was used for authentication when the refresh token was issued. </del> <ins> client-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" authentication method.  The client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued. </ins> <del> 5. </del> <ins> 6. </ins> <del> 5.1. </del> <ins> 6.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of
Code change:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Related discussion:
text: are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 6. </del> <ins> 7. </ins> TODO <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> <del> This section registers the value "client-assertion-type:jwt-key- </del> <ins> This section registers the value "client-assertion-type:jwt-client- </ins> attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. <del> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-key- </del> <ins> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- </ins> attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC <del> 7.2. </del> <ins> 8.2. </ins> <del> This section registers the value "attest_key_client_auth" in the IANA </del> <ins> This section registers the value "attest_jwt_client_auth" in the IANA </ins> "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. <del> o Token Endpoint Authentication Method Name: "attest_key_client_auth" </del> <ins> o Token Endpoint Authentication Method Name: "attest_jwt_client_auth" </ins> o Change Controller: IESG o Specification Document(s): TBC
Code change:
As discussed over email, this PR drafts some text to capture the requirement around refresh token binding to the client instance not just the client. The PR also addresses some broken links. Personally I'm still not convinced that the best way to do this binding is through the client attestation key, instead I think we could add a claim that identifies the client instance in the client key attestation
few suggestions

Related discussion:
text: ultimately controls how long a client instance can re-use a single Client Attestation JWT. <ins> 4.2. Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt- key-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion- type:jwt-key-attestation" authentication method.  The client MUST also use the same client attestation key that was used for authentication when the refresh token was issued. </ins> 5. TODO
Code change:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Related discussion:
text: Note that the protocol for steps 2 and 4 and how the client instance authenticates with the client backend is out of scope of this <del> specification. </del> <ins> specification.  Note also that this specification can be utilized without the client having a backend server at all; in this case, each client instance will perform the functions described as being done by the backend for itself. </ins> This specification defines the format of the Client Attestation that a client instance uses to authenticate in its interactions with an authorization server, which is comprised of two key parts: <del> A Client Attestation JWT- produced by the client backend. </del> <ins> A Client Attestation JWT - typically produced by the client backend. </ins> A Client Attestation Proof of Possession (PoP) - produced by the client instance.
Code change:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Related discussion:
text: 3. <del> Client Attestation JWT A JSON Web Token (JWT) generated by the client backend which is bound to a key managed by a client instance which can then be used by the instance for client authentication. Client Attestation Proof of Possession (PoP) JWT A Proof of Possession generated by the client instance using the key that the Client Attestation JWT is bound to. Client Instance Key A cryptographic, asymmetric key generated by the client instance and proven to the client backend.  The public key is contained in the Client Attestation JWT and is used to sign the Client Attestation Proof of Possession. </del> 4. To perform client authentication using this scheme, the client
Code change:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Related discussion:
text: attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. <del> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC </del> <ins> URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </ins> 8.2.
Code change:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Related discussion:
text: "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. <del> o Token Endpoint Authentication Method Name: "attest_jwt_client_auth" o Change Controller: IESG o Specification Document(s): TBC </del> <ins> Token Endpoint Authentication Method Name: "attest_jwt_client_auth" Change Controller: IESG Specification Document(s): TBC </ins>
Code change:
Addresses issues with language about the jti claim in the client attestation and pop jwt.
The spec states: "The JWT MUST contain a "jti" (JWT ID) claim that provides a unique identifier for the token. The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant." However the is not shown in the example in the same section.
The text says jti is required URL but the example doesn't have jti URL
Duplicate of
The Client Attestation JWT seems like a long(er) lived credential that should be reusable so the client instance doesn't have to go get a new one each time (right?). But this text for the Client Attestation JWT has 'The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant' that suggests the AS might limit them to single use. I think that sentence can just be removed. \ right: URL
Agreed, need to remove this sentence from step 7 of 4.1.1.

Related discussion:
text: time at which the JWT was issued. The JWT MAY contain a "jti" (JWT ID) claim that provides a unique <del> identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. </del> <ins> identifier for the token. </ins> The JWT MAY contain other claims.
Code change:
Minor language tweaks aligning more to RFC 7521 in how the client authentication mechanism is defined as to not limit its application to only being used at the token endpoint.
There is an idea to send the Client attestation already in Authorization Request or PAR instead of with the Token Request. I see the following advantages: the client attestation could act as some kind of mobile capability descriptor, thus allowing the Authorization Server(Issuer) to check these before the user performs user authentication, otherwise this could result in poor UX as the user authenticates and the AS realizes only afterwards in Token Request that the level of client attestation is not enough (e.g. wallet can only handle key type xyz or LoA low) I see the following disadvantage: some flows do not require Authorization Request the user usually does not give consent before sending Authorization Request
The client attestation can for sure be used to authenticate with PAR. The HAIP already requires that.
The draft just needs to be clarified that this is a general purpose client authentication method that can be used with any interaction with an AS that is requiring or making use of client authentication.

Related discussion:
text: To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. <del> The value of the "client_assertion_type" is "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation". The value of the "client_assertion" parameter contains two JWTs, separated by a '~' character.  It MUST NOT contain more or less than precisely two JWTs seperated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST the client attestation PoP defined in client- attestation-pop-jwt. </del> <ins> The value of the "client_assertion_type" parameter (as defined in RFC7521) set to "urn:ietf:params:oauth:client-assertion-type:jwt- client-attestation". The value of the "client_assertion" parameter (as defined in RFC7521) set to a value containing two JWTs, separated by a '~' character.  It MUST NOT contain more or less than precisely two JWTs separated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST be the client attestation PoP defined in client-attestation-pop-jwt. </ins> The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an
Code change:
As highlighted in the title this PR adds a privacy consideration around potential client instance tracking along with a recommendation for client deployments to mitigate such risk.

Related discussion:
text: 5. <del> TODO </del> <ins> 5.1. Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of the end user using the client instance through claim values (including the public key in the "cnf" claim).  Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers. </ins> 6. <del> 6.1. </del> <ins> TODO 7. 7.1. </ins> This section registers the value "client-assertion-type:jwt-key- attestation" in the IANA "OAuth URI" registry established by "An IETF
Code change:
As highlighted in the title this PR adds a privacy consideration around potential client instance tracking along with a recommendation for client deployments to mitigate such risk.

Related discussion:
text: Authentication Authentication o Change Controller: IESG o Specification Document: TBC <del> 6.2. </del> <ins> 7.2. </ins> This section registers the value "attest_key_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by
Code change:
Add security consideration for replay attack prevention and add nonce as optional value for PoP JWT URL
Currently the specification does not define a mechanism for an AS contributed nonce to feature in the client attestation PoP meaning replay attack detection by authorisation servers requires tracking the JTI within the time window set by the PoP's iat claim. We should elaborate on an AS contributed nonce for the specification.
What about using the authorization code or pre auth code as suggested in our demo?
I think this is an option, however the nonce for client authentication becomes dependent on the grant type which creates a bit of an awkward coupling when an application wants to say use this mode of client authentication for grant type other than pre auth code or authorisation code.
How many implemantations out there actually use different grant types than auth-code? Given that this serves our purposes and imo everybody is using auth-code, I think that we should RECOMMEND that scenario but I#m ok with showing up alternatives as you suggested. NAME What's your opinion on this?
I think the flow can be used with and without nonce. If it is used without nonce, jti and short expiration must be used to limit the risk. If a nonce is used, I think using the codes is a pragmatic option. Alternatively, the AS could provide a dedicated nonce with the credential offer or authorization response. It could also provide the nonce with a token error response.
discussion on 23.05 is leaning towards DpoP-style error providing nonce
can we please bring this issue forward, it is very important? I see some advantages in that approach as it would allow the AS to request nonce use for all endpoints (including PAR).
on that topic, I would suggest such an AS provided nonce should be good up until the AS says otherwise. That would allow a client to use the same nonce for PAR and token endpoint.
Update provided in
PR
PR

Related discussion:
text: be used as a value for an "aud" element to identify the authorization server as the intended audience of the JWT. <ins> The JWT MAY contain an "nonce" claim containing a String value that is provided by the authorization server to associate the Client Attestation PoP JWT with a particular transaction and prevent replay attacks. </ins> The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.
Code change:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Related discussion:
text: 7.2. <ins> The "scopes_supported" parameter is the list of scopes the resource server is willing to disclose that it supports.  It is not meant to indicate that an OAuth client should request all scopes in the list. The client SHOULD still follow OAuth best practices and request tokens with as limited scope as possible for the given operation, as described in Section 2.3 of OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics. 7.3. </ins> TLS certificate checking MUST be performed by the client, as described in TLSRequirements, when making a protected resource metadata request.  Checking that the server certificate is valid for
Code change:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Related discussion:
text: value in the protected resource metadata document received by the client. <del> 7.3. </del> <ins> 7.4. </ins> Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to
Code change:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Related discussion:
text: this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.4. </del> <ins> 7.5. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this
Code change:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Related discussion:
text: against one another for consistency when these lists are used by the application profile. <del> 7.5. </del> <ins> 7.6. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server
Code change:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Related discussion:
text: recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.6. </del> <ins> 7.7. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource