DPoP Authorization Code Binding

[bc-pi]

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 DPoP says to do w/ PAR but here you could probably get away with just using the DPoP proof.

[aaronpk]

That makes sense, we should do it the same way that's recommended for PAR.

[PieterKas]

@bc-pi I was reading the rationale for requiring both the dpop_jkt parameter and adding the DPoP header to the PAR request: https://www.rfc-editor.org/rfc/rfc9449.html#name-dpop-with-pushed-authorizat

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 dpop_jkt, 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 dpop_jkt 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 dpop_jkt 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?

[bc-pi]

I think the dpop_jkt 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 auth_session needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.

[aaronpk]

Closing this as it was resolved in #59