Vladimir
Vladimir Dzhuvinov On 18/07/2022 17:03, Warren Parad wrote:
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 list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
