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