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

[Brian Campbell <[e-mail]>]

I'm not sure if a token type URI is needed, to be honest. But I think it
would be more in the realm of a URI defined for this particular purpose of
DPoP tokens in token exchange, which would be independent from the DPoP
document itself.

On Mon, Jul 18, 2022 at 10:35 PM Vladimir Dzhuvinov <[e-mail]>
wrote:

> 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 [e-mail]://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.*
>
>

-- 
_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._