There are multiple issues with using dynamic client registration for this. If a user uninstalls and later reinstalls an app then they can end up with multiple registrations for the same client, which makes it harder for them to manage access. Additionally, client registrations typically don’t expire so the AS doesn’t know when it can remove unused clients.
Besides, this ship already sailed with mTLS cert-bound refresh tokens. Neil > On 7 Jun 2020, at 12:34, Nov Matake <mat...@gmail.com> wrote: > > Confidential clients can also use DPoP. > >> 2020/06/07 20:25、Torsten Lodderstedt <tors...@lodderstedt.net>のメール: >> >> 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 >>>>> >>> > > _______________________________________________ > 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
