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.*
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
