Original text:
end protection that DPoP provides, so DPoP Authorization Code binding SHOULD be used. <del> To bind the authorization code using the Authorization Challenge Endpoint, the JWK Thumbprint of the DPoP key MUST be communicated to the Authorization Server by including the "dpop_jkt" parameter defined in section 10 of RFC9449 alongside other authorization request parameters in the POST body of the first Authorization Challenge Request.  If it is included in subsequent Authorization Challenge Requests, the value of this parameter must be the same as in the initial request.  If the JWK Thumbprint in the "dpop_jkt" differ at any point, the Authorization Server MUST reject the request.  If the "dpop_jkt" parameter is not included in the first request, but added in subsequent requests, the Authorization Server MUST reject the request (do we need to define a specific error code for that?). </del>  9.5.2.

Reviewer comments:
Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go. Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)

Revised text:
end protection that DPoP provides, so DPoP Authorization Code binding SHOULD be used.  <ins> The mechanism for Authorization Code binding with DPoP is similar as that defined for Pushed Authorization Requests (PARs) in Section 10.1 of RFC9449.  In order to bind the Authorization Code with DPoP, the client MUST add the DPoP header to the Authorization Challenge Request.  The authorization server MUST check the DPoP proof JWT that was included in the DPoP header as defined in Section 4.3 of RFC9449. The authorization server MUST ensure that the same key is used in all subsequent Authorization Challenge Requests, or in the eventual token request.  The authorization server MUST reject subsequent Authorization Challenge Requests, or the eventual token request, unless a DPoP proof for the same key presented in the original Authorization Challenge Request is provided. The above mechanism simplifies the implementation of the client, as it can attach the DPoP header to all requests to the authorization server regardless of the type of request.  This mechanism provides a stronger binding than using the "dpop_jkt" parameter, as the DPoP header contains a proof of possession of the private key. </ins> 9.5.2.