You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the user's token is a sender constraint token "DPoP", can it be exchanged by the client to an authorization grant for another domain? Does the authorization server verify proof of possession?
The text was updated successfully, but these errors were encountered:
I don't think we should disallow it but I also I don't know what or how much we can or should say about it in the draft. Also DPoP isn't the only key-binding / proof-of-possession / sender constraining mechanism for OAuth tokens (there's also RFC8705 for MTLS, for example). All the sender constraining mechanisms can be tricky in the context of any kind of exchange.
In the case that the client making the token exchange request is an RS that'd received a sender constrained access token on an inbound API call, I imagine it similar to how Introspection works with sender constrained tokens - the RS does the PoP validation locally but sends the token to the AS who does not verify proof of possession.
DPoP (or MTLS FWIW) could reasonably be used to bind the access token returned from the JWT authz grant call.
Some of the other cases are harder to nail down and/or not feasible due to sender-constrained being sender constrained.
Sorry, I'm not sure if any of the above rambling is helpful. But it's what I could come with.
If the user's token is a sender constraint token "DPoP", can it be exchanged by the client to an authorization grant for another domain? Does the authorization server verify proof of possession?
The text was updated successfully, but these errors were encountered: