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#uriI 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 <vladi...@connect2id.com> 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 <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_______________________________________________ OAuth mailing list OAuth@ietf.org 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./
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
