-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DPoP Authorization Code Binding #47
Comments
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? |
Proposed update based on feedback in issue #47 Open question for reviewers (and @bc_pi) whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpop_jkt) or an authorization challenge endpoint specific one?
I think the |
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.
The text was updated successfully, but these errors were encountered: