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.

[martin-lindstrom]

The Authorization server acting as client example is a pretty appealing use case, where much of the inter-organization configuration and trust can be handled by the Authorization Servers in domain A and B, and the clients and resources servers can stay pretty "simple". However, what if the resource server in B requires DPoP?
I saw a comment about the difficulties concerning using DPoP for this example in #86 but I haven't seen any further discussions about it.

Before people start inventing their own solutions to this, wouldn't it be a good idea to define a mechanism for including some sort of DPop-related info in the authorization grant JWT issued by AS A?

[kburgin3]

The Authorization server acting as client example is a pretty appealing use case, where much of the inter-organization configuration and trust can be handled by the Authorization Servers in domain A and B, and the clients and resources servers can stay pretty "simple". However, what if the resource server in B requires DPoP? I saw a comment about the difficulties concerning using DPoP for this example in #86 but I haven't seen any further discussions about it.

Before people start inventing their own solutions to this, wouldn't it be a good idea to define a mechanism for including some sort of DPop-related info in the authorization grant JWT issued by AS A?

Speaking for myself (other co-authors can reply if they disagree), defining a mechanism is left to implementations. If you would like to define such a mechanism, I suggest taking this to the list or creating a draft, maybe a profile of this document?

[arndt-s]

@martin-lindstrom we spent a lot of time talking about this and while we see value in this there's plenty of work that needs to happen in order to standardize it in a way that it can be "easily picked up and implemented". I believe we could have done a better job keeping issues up to date with it, sorry about that.

Our main reasons we don't define it as such in this document:

• Delegated key binding: AS A would need to request access_token from AS B that is bound to the client, not AS A. Related to this, how would AS A present proof of possession to AS B if it doesn't have the key in it's possession?
• We would need to specify the token exchange between client and AS A that results in the access_token from AS B and not in the assertion. This would be a 2nd profile of token exchange on top of the existing profile defined in this specification. I believe this would cause a lot of confusion.
• Neither token exchange RFC8693 nor the assertion flow RFC7523 define PoP - something that we believe should be addressed more "globally" - not hidden behind ID chaining.

We decided that this document should rather be a "framework" and profiles of it can go into the details of deployment variations. We already have one going into a totally different deployment direction. As @kburgin3 mentioned, if you have need to define this we believe that this should be a dedicated profile of this document solving the unique challenges I described.

[brockallen]

I spoke to Kelley at OSW and promised I'd put my idea somewhere, just to add to the conversation (albeit late and likely already identified and discussed by others), so sorry if this is redundant.
In short it seems given the "physics" of mTLS it doesn't seem possible to support that as an approach where AS(A) is acting as the client to AS(B) and trying to obtain PoP access tokens. Given that, it seems fair to call that out in the document and not try to solve it.
But it does seem that DPoP is possible (in a variety of ways), so that could either be described in this document or left to an extension doc (I don't know which makes the most sense from a IETF procedure process).
I know some approaches were floated for making DPoP work (ahem tmb), but one that I didn't hear (but again, doesn't mean it hasn't been identified/discussed elsewhere) was it seems that given that the params from AS(A) to AS(B) to the token endpoint are fairly well-known and expected values, then why can't the RS(A) provide that proof as part of its request to AS(A) when it needs the proxying behavior? IOW, RS(A) creates a DPoP proof token as part of the request to AS(A), but with all the values that AS(A) will be sending to AS(B). Then with this proof token, AS(A) can just pass it along in its request to AS(B).
This is different than the approach mentioned in the current document where RS(A) only provides a proof for the direct request to AS(A).
My thinking was that if RS(A), acting as the real client, knows all the details of AS(B) then it can create the proof as part of it's initial request to AS(A). But if it doesn't, or if AS(B) requires a DPoP nonce, then there could be an error response all the way back to RS(A) including the information it needs (e.g. the htu, and/or the nonce, and where htm is assumed to always be POST). So in this proxying architecture, some error response would need to be defined to identify the values needed to be provided in the proof token.
I know just sending stuff to RS(A) to sign feels like maybe some attack vector, but the RS(A) trusts the AS(A), right? Also, what I've not thought about is there some additional detached signature needed with this idea (similar to the ath)?
Also, I know the back-and-forth perf aspects of this approach are not ideal, but if you're stuck in an architecture given your other constraints where you have to proxy, then you're already resigned to the extra hops.
Is this idea just too far out there?

Ok, I see there was an update at IETF122 on this, so that sounds like the best approach. Also, it sounds like there will be some effort along these lines from Justin's Deferred Key Binding proposal (which was a more serious version of the original half-joking tmb idea).

[PieterKas]

Thanks @brockallen for your thoughtful comment and input. I believe the best venue for continuing to explore this idea is in the discussions Justin Richer (@jricher) is leading in the OAuth working group (perhaps something to contribute to the upcoming interim)