+1 > On 11 Jun 2020, at 07:36, Torsten Lodderstedt > <torsten=40lodderstedt....@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 <f...@adorsys.de> wrote: >> >> >> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <jric...@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....@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
