Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Vladimir Dzhuvinov]

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?





 * 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




The proposal:

A new section "DPoP with Token Exchange":

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: At present the DPoP spec defines the DPoP header in such a way that only one DPoP proof may be submitted. 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 )

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.





Vladimir

Vladimir Dzhuvinov

On 25/06/2022 15:23, Vladimir Dzhuvinov wrote:

Registration of a new token type identifier to indicate the token is a DPoP access token: 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.

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)





Vladimir Dzhuvinov
On 25/06/2022 13:33, Warren Parad wrote:

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.

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?

    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:

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:

    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



    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth

-- Vladimir Dzhuvinov

_______________________________________________
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