Answers inline: > On 7 Jun 2020, at 13:07, Nov Matake <mat...@gmail.com> wrote: > > So, you mean… > > If a frontend client want to use > * sender-constrained code, bearer access token and sender-constrained refresh > token, use DynReg.
I’m not really sure what a sender-constrained code would be, but I suspect the right answer here is PKCE + DPoP. PKCE basically is PoP for auth codes. > * sender-constrained code, sender-constrained access token and > sender-constrained refresh token, use DynReg + DPoP. PKCE + DPoP > * bearer code, sender-constrained access token and sender-constrained refresh > token, use DPoP only. Sure, but you should always use PKCE, so PKCE + DPoP. > * bearer code, bearer access token and bearer refresh token, use neither. > > is my understanding correct?? Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS cert-bound tokens, or etc). > >> 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>のメール: >>>> >>>> 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
