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

+1

> On 11 Jun 2020, at 07:36, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
> 
> I generally agree with the proposal, but I would suggest to limit it to public clients. 
> 
> In case of confidential clients, the refresh token is (via the client_id) already bound to the client’s secret(s) and those can be rotated. Additionally binding the refresh token to a DPoP key would limit it’s applicability w/o a benefit. 
> 
>> On 11. Jun 2020, at 01:35, Francis Pouatcha <fpo@adorsys.de> wrote:
>> 
>> 
>> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <jricher@mit.edu> wrote:
>> 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?
>> 
>> Fully agree. I will add a refresh_token shall always be PoP bound. Independent of the type of PoP.
>> 
>> 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?
>> Key rotation shall be handled separately from the refresh_token process. If a refresh_token is bound to a key, the client shall keep that key till the refresh_token is consumed. A key rotation process shall be designed such as to allow the key holder to keep obsolete keys for the completion of pending processes.
>> 
>> — 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.
>> 
>> 
>> -- 
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth