Since each client instance has at least one key, those are same level of state management.
> 2020/06/07 16:24、Torsten Lodderstedt <tors...@lodderstedt.net>のメール: > > 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 >>> <mailto:fpo=40adorsys...@dmarc.ietf.org>>のメール: >>> >>> >>> > Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=40aol.com >>> > <http://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 <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
