> On 11. Jun 2020, at 19:24, Francis Pouatcha <fpo=40adorsys...@dmarc.ietf.org> > wrote: > > > > On Thu, Jun 11, 2020 at 3:26 AM Neil Madden <neil.mad...@forgerock.com> wrote: > +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. > I meant PoP and not DPoP. The client secret is also a variant of PoP. This > does not change the value of this sentence: "refresh_token shall always be > bound to a PoP".
This means you agree DPoP shall be used for refresh tokens issued to public clients only? As you said, client authentication is a kind of PoP as well, so confidential clients don’t need DPoP protection for refresh tokens. > > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
