So, you mean… If a frontend client want to use * sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg. * sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + DPoP. * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only. * bearer code, bearer access token and bearer refresh token, use neither.
is my understanding correct?? > 2020/06/07 20:49、Neil Madden <neil.mad...@forgerock.com>のメール: > > 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 >>> <mailto: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 >>>> <mailto: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 >>>>> <mailto: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 >>>>>> <mailto: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 >>>>>>> <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
