Re: [OAUTH-WG] DPoP and refresh tokens

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 <bcampbell@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.hardt@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.*