Yeah, both PKCE and Client Credential provide sender-constrained code... lots of choices
Sent from my iPhone > On Jun 7, 2020, at 21:26, Neil Madden <neil.mad...@forgerock.com> wrote: > > > 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
