I agree this is a problem, but as I see it as a problem for Token Exchange, and the lack of flexibility in that standard, it does not make sense to add to the DPoP spec.
On Mon, Jul 18, 2022 at 3:33 PM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > I would like to resurrect this thread and propose a new section to the > current DPoP draft which changes nothing in regard to DPoP itself, only > adds new parameters to enable DPoP with OAuth 2.0 token exchange (RFC 8693): > > https://datatracker.ietf.org/doc/html/rfc8693 > > Why? > > Token exchange lets a client submit a subject_token (and potentially > actor_token) to obtain a new token from the AS. > > If the submitted token(s) and the minted token are DPoP bound there is a > need to submit a DPoP proof for each one: > > - A DPoP proof for the subject_token > - Potentially a DPoP proof for the actor_token (if there is one) > - A DPoP proof for the token that is going to be minted by the AS > > At present the DPoP spec defines the DPoP header in such a way that only > one DPoP proof may be submitted. > > > The proposal: > > A new section "DPoP with Token Exchange": > > Specifies the following new optional form request parameters for use in > the token exchange grant, so that any DPoP proofs can be submitted together > with the subject_token / actor_token as form parameters: > > subject_token_dpop - To pass the DPoP proof for a subject_token that is > DPoP bound > > actor_token_dpop - To pass the DPoP proof for an actor_token that is DPoP > bound > > > (the existing std token exchange params can be seen here > https://datatracker.ietf.org/doc/html/rfc8693#section-2.1 ) > > > Registration of a new token type identifier to indicate the token is a > DPoP access token: > > https://datatracker.ietf.org/doc/html/rfc8693#section-3 > > urn:ietf:params:oauth:token-type:dpop_access_token > Indicates that the token is an OAuth 2.0 DPoP bound access token issued > by the given authorization server. > > > I hope it's not too late to include this addition to the DPoP spec. The > token exchange grant is standard and is seeing use. With the introduction > of DPoP it is likely such tokens will become involved in token exchanges. > We tried a work around where the client uses a single DPoP proof for the > submitted tokens and the one to be minted, but this has issues, including > potential security issues. So I've come to the conclusion that a spec > change of some sort is the proper way to solve this. The proposed solution > has no effect on DPoP core and it preserves the existing token exchange > semantics. > > > Vladimir > > Vladimir Dzhuvinov > > On 25/06/2022 15:23, Vladimir Dzhuvinov wrote: > > Hi Warren, > > The case looks like this: > > - An OAuth client registered with AS1 for code flow, with AS2 for > token exchange > - API1 secured by AS1, API2 secured by AS2 > - For API1 the client obtains DPoP tokens from AS1 > - For API2 the client presents DPoP token from AS1 as grant at AS2 to > obtain its own DPoP token (AS2 trusts selected AS1 token scopes for this) > > So we have a case where the token endpoint at AS2 needs once a DPoP proof > for the submitted access token (in the subject_token form parameter), and a > second time to bind the token that is going to be issued. I.e. a situation > where the token endpoint is also "addressed" as a DPoP aware protected > resource. > > If only one DPoP HTTP header is permitted one work around I see is to > insist on a single DPoP proof for both jobs, by including the "ath" claim > in the proof to the AS2 token endpoint and requiring the client to use the > same JWK with both ASes. Another possibility is to include the DPoP proof > in the form parameters alongside the subject_token, but this will require a > spec change. > > Vladimir Dzhuvinov > > On 25/06/2022 13:33, Warren Parad wrote: > > What's the flow here? Assuming we are talking about RFC 8693, what's the > situation where you would need to do a token exchange, and you actually > have access to the subject's DPoP key? If you have access to the subject's > key, then you are the subject and can request a new token. Or am I missing > something fundamental here? > > Also, according to the RFC, the request must be made with client > authentication, you don't need DPoP, because if the client's credentials > are compromised, you have a different problem. Unless the goal is to DPoP > instead of client credentials, in which case, I think I'm back to the > previous question. > > On Sat, Jun 25, 2022 at 12:19 PM Vladimir Dzhuvinov < > vladi...@connect2id.com> wrote: > >> I have a question to the DPoP spec authors - do you have a suggestion how >> to approach a token exchange case where the client requests a DPoP token >> and the submitted subject(actor)_token is / are also DPoP bound? >> >> My first thought was to simply let the client send two DPoP JWTs, one for >> the submitted token and another for the requested token, and then find a >> way in the AS to figure out which is which, but then I found this in >> section 4.3.1: >> >> To validate a DPoP proof, the receiving server MUST ensure that that >> there is not more than one DPoP HTTP request header field, >> >> >> Thanks, >> >> Vladimir >> >> -- >> Vladimir Dzhuvinov >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
