Should we allow identity chaining with DPoP tokens?

[arndt-s]

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?

[bc-pi]

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.

[kburgin3]

I'd like mTLS sender constrained tokens. Can we consider adding sender constraining mechanisms to the draft?

[bc-pi]

some more related discussion in "Add sender constraining mechanisms #86"

[PieterKas]

I a don't think we should disallow this. The constrained access token is being used for another purpose. I would also argue the constrain was introduced to prevent it from being replayed as an access token. In this case it is. being used for something different. I imagine it will also be impractical to require proof of the sender constraining as the key bound to the token is probably not be under control of the resource server.