Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <ins> 4.4. To validate an HTTP request which contains the client attestation headers, the receiving server MUST ensure the following with regard to a received HTTP request: There is precisely one OAuth-Client-Attestation HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in []{client-attestation-jwt}. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in []{client-attestation-pop- jwt}. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the public key contained in the "cnf" claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header. </ins> 5. <del> 5.1. </del> <ins> While usage of the the client attestation mechanism defined by this draft can be used in a variety of different HTTP requests to different endpoints, usage with token endpoint as defined by RFC6749 has particular additional considerations outlined below. The authorization server MUST perform all of the checks outlined in checking-http-requests-with-client-attestations for a received access token request which is making use of the client attestation mechanism as defined by this draft. The following example demonstrates usage of the client attestation mechanism in an access token request (with extra line breaks for display purposes only): 6. 6.1. </ins> Implementers should be aware that the design of this authentication <del> mechanism deliberately allows for a client instance to re-use a </del> <ins> mechanism deliberately allows for a Client Instance to re-use a </ins> single Client Attestation JWT in multiple interactions/requests with an authorization server, whilst producing a fresh Client Attestation PoP JWT.  Client deployments should consider this when determining the validity period for issued Client Attestation JWTs as this <del> ultimately controls how long a client instance can re-use a single </del> <ins> ultimately controls how long a Client Instance can re-use a single </ins> Client Attestation JWT. <del> 5.2. </del> <ins> 6.2. </ins> Authorization servers issuing a refresh token in response to a token <del> request using the "urn:ietf:params:oauth:client-assertion-type:jwt- 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 key that was present in the "cnf" claim of the client attestation that was used for client authentication when the refresh token was issued. 5.3. </del> <ins> request using the client attestation mechanism as defined by this draft 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 use the client attestation mechanism when refreshing an access token.  The client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used when the refresh token was issued. 6.2.1. Because the Client Attestation and Client Attestation PoP are communicated using HTTP headers, implementers should consider that web servers may have a default maximum HTTP header size configured which could be too low to allow conveying a Client Attestation and or Client Attestation PoP in an HTTP request.  It should be noted, that this limit is not given by the HTTP RFC9112, but instead web server implementations commonly set a default maximum size for HTTP headers. As of 2024, typical limits for modern web servers configure maximum HTTP headers as 8 kB or more as a default.  ## Rotation of Client Instance Key </ins> This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim.  If the

Related discussion:
text: Based on the discussions had at IETF 119 in the OAuth WG, this PR attempts to make the following changes to the draft Move away from usage of the assertion framework defined in RFC 7521 and RFC 7523 for conveying the client attestation and client attestation pop. Instead use two newly defined HTTP headers OAuth-Client-Attestation and OAuth-Client-Attestation-PoP for conveyance in an HTTP request, akin to how DPoP works. Explicitly mention this mechanism could be used in a variety of places including with a resource server. Note, there are still many outstanding items I would like to add, however I felt this PR was already big enough as it is, these include Error responses for the token endpoint Optimisation for when this mechanism is used with DPoP to avoid having to send two PoP's Formalising whether this mechanism still constitutes a form of client authentication
For some reason it seems to not create an html version? This is the rendered text: URL
I think there were potential objections mentioned about moving to headers as to whether we'd run into size limits (I think 8 KB was mentioned as a common restriction) and people felt jwts with embedded x5c headers etc may get close to these limits?
NAME indeed. We may have a client attestation with an huge x509 certificate chain or an openid federation trust chain with several metadata, trust marks and jwks. I don't see the benefit of moving from what it is actually more efficient (wa~wa-pop) more over, technically we can have multiple client_assertions that embedes their pop (using ~), while having multiple http headers that divide attestation from pop forces the implementations to loop all the assertions and all the pop to find the matching ones
Added client instance definition and updated to use US based spelling of authorization instead of authorisation.
NAME NAME I can understand the desire to want to use X.509 certificates to validate the client assertion (e.g as an alternative key resolution mechanism to resolving a JWKS document from a domain), however I don't see how the certificate chain would be more then 1 certificate (maybe 2) in length (bearing in mind the root certificate(s) would be communicated to the issuer out of band and pre-trusted for the client).