If the client would register for every transaction. And don’t forget, DPoP also supports sender constrained access to resource servers, which dyn registration does not.
> Am 07.06.2020 um 13:04 schrieb Nov Matake <mat...@gmail.com>: > > 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>のメール: >>>> >>>>> >>>>> > 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
