There are similarities in this particular use case but I would argue DPoP is more light weight than dynamic client registration, less state management in particular.
> Am 07.06.2020 um 05:41 schrieb Nov Matake <mat...@gmail.com>: > > DPoP-bound refresh token seems feature duplication with dynamic client > registration. > >> 2020/06/07 7:57、Francis Pouatcha <fpo=40adorsys...@dmarc.ietf.org>のメール: >> >>> >>> > Am 05.06.2020 um 22:17 schrieb George Fletcher >>> > <gffletch=40aol....@dmarc..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/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
