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

[Vladimir Dzhuvinov <[e-mail]>]

Thanks Brian for your response.

Do you think DPoP should have an own token type URI registered?

https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri

I did not think about the possibility of having the DPoP proof and the 
token value put together in the subject/actor_token parameter. It makes 
good sense because the proof and the token can be considered 
inseparable, i.e. the "complete token".

The DPoP JWT has a well defined syntax, so I am now thinking of 
appending the token to the DPoP JWT with a dot (.) delimiter. This is 
sufficient to make the new string parseable and thus solve the case. 
Having a std DPoP token type URI would be nice for clients to hint to 
the AS that the subject/actor_token is a combination of DPoP proof and 
access token.

Vladimir

Vladimir Dzhuvinov

On 18/07/2022 21:46, Brian Campbell wrote:
> While there are potentially more tokens involved in a RFC 8693 token 
> exchange, it's still a single client and it's not evident (to me 
> anyway at this point) that there's sufficient need to give it distinct 
> DPoP treatment beyond other token endpoint interaction 
> <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-10.html#name-dpop-access-token-request>s. 
> Should the need arise more, I'd suggest maybe considering having the 
> new token type define how the token and associated proof be conveyed 
> together as the value of the subject/actor_token parameter rather than 
> introducing new parameters.
>
> On Mon, Jul 18, 2022 at 9:34 AM Vladimir Dzhuvinov 
> <[e-mail]> wrote:
>
>     I find the token exchange RFC to be quite flexible, it allows the
>     subject_token, actor_token and the output token to be of any type,
>     and there is a mechanism to define (register) new
>     urn:ietf:params:oauth:token-type values. The only concrete need is
>     to define a way to pass the accompanying DPoP proof. I don't think
>     that could have been anticipated at the time when the exchange
>     spec was devised. And the token exchange spec is not explicit in
>     prohibiting extensions.
>
>     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
>>     <[e-mail]> 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
>>>>         <[e-mail]> 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
>>>>             [e-mail]
>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         [e-mail]
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail]
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./