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
