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: Right but to be clear, the current draft does not handle multiple wallet attestations either though so I think this a new requirement that we should discuss separately, would you mind opening a seperate issue?
The issue extends beyond the realm of multiple wallet attestations, as there could also be multiple DPoP tokens involved. An additional consideration, which we have not yet fully addressed but may emerge as a future requirement, is the scenario where a wallet instance operates under more than one trust framework, necessitating specialized assertions for each. While we have consciously chosen to limit the scope to a single wallet attestation to simplify implementation, it's important to acknowledge that this decision does not preclude the possibility of requiring multiple assertions in the future. Implementers may need to adapt or extend the specification to accommodate such needs. However, to avoid digressing further, let's focus on the matter of handling multiple DPoP headers for now. The approach currently documented, which aims to streamline the process by limiting it to a single attestation, is designed to offer the same benefits while minimizing computational overhead.
While it is possible to reconfigure these options, it is important to keep default values of the wide-spread implementations in mind to allow an easy path for adoption. I took the time to look at some of the frameworks I would say are good indicators: nginx: --> 8KB for 1 header max envoy (used in istio): --> 60 KB for headers URL --> 16KB for headers traefik: --> re-uses go/http: 1MB for headers --> After looking at this, I would say we can go with headers
An OpenID Federation trust chain with two intermediates, the trust anchor entity configuration with a long list of trust mark issuers and the leaf entity configuration with a very verbose configuration, such as an AS + Openid4VCI + OpenID4VP (considering an EAA provider), with policies and a consistent number of trust mark might be 20KB. A serialized X.509 certificate chain, with 4 intermediates, custom extensions and QWACs ... Considering each certificate up to 2.2KB, might it be 8.8KB?