Closed bc-pi closed 8 months ago
That makes sense, we should do it the same way that's recommended for PAR.
@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?
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.
Closing this as it was resolved in #59
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.