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: (please, consider that openid federation brings policy languages, trust marks and multiple protocol specific metadata) I'm worried about these aspects: loop required for parse/matching the correct DPoP when multiple DPoP are present, while WIA~WIA-POP doesn't bring this problem. What's the benefit of having this breaking change that reduce the flexibility while increasing the complexity? size limitations: Do we have to imagine to standardize something upon the assumption that a federation topology should not have more than 2 or 4 or 8 intermediates, since this decision is out of scope on this specification.
A bit off-topic for the current discussion: We need to fix the examples - they are way too long which breaks the rendering/conversion and will cause problems with the datatracker. I do believe that this is also the reason why the html file was not created.
Note that rfc9449 does not allow for multiple DPoP headers. It could maybe have been stated more clearly but is kinda implied and was absolutely the intent of the RFC overall and specific text like URL
NAME as I implied with my earlier comment, the current draft text doesn't support multiple attestations so I don't view this proposal to shift to headers as removing functionality, it appears this is a new usecase and I think we should discuss it in a seperate issue. No I dont think we do, what was identified above is that there is no size limit on headers in HTTP rather defaults that servers apply which can be adjusted, in reality web servers also apply limits to the body of an HTTP request (although often much larger then what is allocated for headers).
Discussed with NAME I will add an implementation consideration around the default size limits for HTTP headers.
NAME what about using compressed values? unfortunately this sounds like giving a solution that may bring other problems, at the same time we can consider zlib (RFC 1950) for doing this.
Something broke with linking the html rendered versions properly Rendered html: URL
It just (re)occurred to me that specs defining new HTTP headers (which the cool kids call fields nowadays) are supposed to request their registration in the . I don't want to hold up this PR for this but will create an issue from this comment so as not to lose track of it.