Code change:
4. <del> To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. </del> <ins> This draft introduces the concept of client attestations to the OAuth 2 protocol, using two JWTs: a Client Attestation and a Client Attestation Proof of Possession (PoP).  These JWTs are transmitted via HTTP headers in an HTTP request from a Client Instance to an Authorization Server or Resource Server.  The primary purpose of these headers is to authenticate the Client Instance. </ins> <del> The value of the "client_assertion_type" parameter (as defined in RFC7521) set to "urn:ietf:params:oauth:client-assertion-type:jwt- client-attestation". </del> <ins> 4.1. </ins> <del> 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. </del> <ins> A Client Attestation JWT and Client Attestation PoP JWT is included in an HTTP request using the following request header fields. </ins> <del> 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> <ins> The following is an example of the OAuth-Client-Attestation header. </ins> <del> 4.1. </del> <ins> The following is an example of the OAuth-Client-Attestation-PoP header. </ins> <del> 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. </del> <ins> Note that per RFC9110 header field names are case-insensitive; so OAUTH-CLIENT-ATTESTATION, oauth-client-attestation, etc., are all valid and equivalent header field names.  Case is significant in the header field value, however. The OAuth-Client-Attestation and OAuth-Client-Attestation-PoP HTTP header field values uses the token68 syntax defined in Section 11.2 of RFC9110 (repeated below for ease of reference). </ins> It is RECOMMENDED that the authorization server validate the Client Attestation JWT prior to validating the Client Attestation PoP. <del> 4.1.1. </del> <ins> 4.2. </ins> <del> The following rules apply to validating the client attestation JWT. </del> <ins> The following rules apply to validating the Client Attestation JWT. </ins> Application of additional restrictions and policy are at the <del> discretion of the authorization server. </del> <ins> discretion of the Authorization Server. </ins> The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT.  In the

Related discussion:
text: W.r.t other aspects of the client attestation or client attestation pop being too big for an HTTP header could you elaborate on what you see as the contents of your attestation NAME Because IIUC you perhaps want to use the client attestation to convey all client metadata? If that is the case IMO the client attestation isn't for this purpose, client metadata should continue to be communicated outside of these attestations with the pre-existing mechanisms we already have defined. Finally even if we did begin to encroach on header payload limits with a client attestation, we aren't talking about hard limits here, rather just the default maximums that common web server platforms have configured, which can always be adjusted.
there some point for clarification assertion weight: a client assertion may have a x5c or an openid federation trust chain within its JWT header. This is an issuer's choice, allowed by RFC 7515 that might be not supported by httpd maximum header body size, that's a deployment/configuration choice that might be different within different domains. chain length: it could be assumed that a chain may not exceed 2 or 3 certificate breaks. This depends on the number of intermediates, an aspect that falls outside the technical specification and is determined by the federation's topology and composition. client metadata: we have some required claims in the wallet attestations and the possibility to include any other custom claim or any other claims pertaining the wallet capabilities or anything else related to the trust framework. My comment is not related to assertion payload, but to the previous point 1 and 2. However, the payload also impacts in the assertion weight, as pointed out at point 1. The missing point concerns the processing of multiple DPoP tokens within the same request. Handling multiple DPoP tokens necessitates a loop to identify the one that matches a specific assertion. This introduces additional computational and development efforts not present in the current approach (WA~WA-POP), which directly associates an assertion with its proof of possession (PoP), facilitating a straightforward and efficient identification of matching pairs.
Ok great so do we agree that this isn't an issue because servers are freely able to re-configure the max header size based on their application? Because it isn't a hard limit.
Understood but based on the above point is this actually an issue if the limit on header size isn't a hard limit?