Code change:
token request.  The authorization server validates the Client Attestation and thus authenticates the Client Instance. <del> Note that the protocol for steps (2) and (4) and how the Client Instance authenticates to the Client Backend is out of scope of this 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. 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: A Client Attestation JWT - typically produced by the client backend. </del> <ins> Please note that the protocol details for steps (2) and (4), particularly how the Client Instance authenticates to the client Backend, are beyond the scope of this specification.  Furthermore, this specification is designed to be flexible and can be implemented even in scenarios where the client does not have a backend server. In such cases, each Client Instance is responsible for performing the functions typically handled by the backend on its own. </ins> <del> A Client Attestation Proof of Possession (PoP) - produced by the client instance. </del> <ins> This approach acknowledges the evolving landscape of OAuth 2.0 deployments, where the ability for public clients to authenticate securely and reliably has become increasingly important. </ins> 2.

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.