Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

What if we simply declare that refresh tokens are always bound to the DPoP key used to request them? Is there value in NOT binding the refresh token?

As for access tokens, the way I read it, all of this is true:

- The AS could still decide to issue a Bearer token, using the token_type field, for whatever policy reason.
- A client getting back a Bearer token from a DPoP request would do Bearer headers. 
- A client getting a DPoP token from a DPoP request would do DPoP headers.
- An client should never send a DPoP token as a Bearer header.
- An RS should ALWAYS look for a DPoP binding signature from a DPoP scheme token. Missing that is an error.

So if we just declare that a refresh token must always be DPoP bound when DPoP is used to request it and a refresh token is issued, then we’re in the clear here, as best as I can tell, and it allows the AS some flexibility.

Some problems with this:

1) Pretty much every single OAuth client in the world ignores the “token_type” field. But clients being updated to support DPoP wouldn’t ignore it, so that’s probably ok.
2) If we wanted to make refresh token binding switchable we’d need a “refresh_token_type” field or similar, and the client would need to know how to understand it and deal with its absence (since most servers won’t send it).
3) This presumes the client will not rotate its key before using the refresh token. If it does it’ll have to do a whole new grant.
4) None of this prevents an RS from ignoring the DPoP signature, but I think that’s a separate problem.
5) It’s arguable that we’d want a client to be able to bind a NEW DPoP key during a refresh, using the old key as proof for the refresh token and the new key going forward. Is this a case we want to enable?

 — Justin

> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
> 
> That’s correct for confidential clients.
> 
> For a public client, the refresh token is just bound to the client id. DPoP allows binding to an ephemeral key pair for this kind of clients.
> 
>> Am 07.06.2020 um 00:57 schrieb Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>:
>> 
>> 
>> 
>> > Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=40aol.com@dmarc..ietf.org <http://ietf.org/>>:
>> > 
>> > Secondly, I do think we need a way to allow for the refresh_token to be bound while leaving the access_tokens as bearer tokens. This adds useful security without impacting existing RS deployments.
>> 
>> +1 that’s a very useful feature_______________________________________________
>> AFAIK a refresh_token is always bound. What am I missing here?
>> -- 
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth