Okay, I'll look at adding a refresh example and some additional explanation.
There are client authentication methods that use asymmetric cryptography so sender-constraining a refresh token with an asymmetric key pair (indirectly via the client's credentials) is already possible and happening in practice (JWT client auth and MTLS client auth). Nothing in DPoP is trying to discourage that. DPoP is just avoiding the added complexity and operational problems that would come with sender-constraining the RT with two different mechanisms. On Wed, Oct 28, 2020 at 4:35 PM Dick Hardt <dick.ha...@gmail.com> wrote: > Hey Brian > > A refresh example would make it more clear, and would also assist in > communicating that DPoP could be used just for refresh. > > I see in the updated text that using DPoP with confidential clients is > discouraged. I understand the RT is sender constrained -- but > asymmetric cryptography is much stronger than a shared secret. Why > discourage its use? > > > > > ᐧ > > On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> I'm currently working on the draft and hope to have a new revision >> published relatively soon. Just the other day I made some changes to the >> text around RTs with >> https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974 >> that maybe/hopefully makes some of it more clear? But basically the RTs are >> only bound for public clients and the exact mechanism to do it is left up >> to the AS. The AS both creates and consumes the RT so however it chooses to >> associate the DPoP key with the RT is its own implementation detail. >> Getting a new bound access token using an RT is meant to be covered in sec >> 5 "Token Request (Binding Tokens to a Public Key)" with RT being just one >> of the grants that could be presented in the token request in conjunction >> with the DPoP proof, and the AS would bind the AT it issues to the key in >> that DPoP proof. I'd sort of assumed that would just be understood. But do >> you think it (including the recent changes) needs more explanation? >> >> I do think using DPoP only for token refresh (only for public clients >> though) would be appropriate, for some cases anyway. This has come up on >> the list here previously and the general consensus was also that it'd be >> useful. I plan to add some language describing that (and loosening some >> language that could be perceived as prohibiting it) but haven't gotten to >> that item on the editing todo list yet. >> >> >> >> >> On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt <dick.ha...@gmail.com> wrote: >> >>> Hello >>> >>> I was reviewing the latest DPoP draft[1] and saw numerous mentions of >>> using a DPoP proof for refreshing an access token, but no explicit >>> description of how to do that, nor an example. Was this intentional? >>> >>> Perhaps a new section "Refreshing an Access Token"? >>> >>> Additionally, I can imagine that an AS can improve its security posture >>> by adding support for DPoP *just* to token refresh and not requiring >>> existing resource servers to upgrade. Rotating refresh tokens would not be >>> as critical for public clients using DPoP for token refresh. >>> >>> Would using DPoP only for token refresh be appropriate? If so, language >>> describing that would be helpful. :) >>> >>> /Dick >>> >>> [1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04 >>> ᐧ >>> _______________________________________________ >>> 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.* > > -- _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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
