* sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg or "PKCE + DPoP allowing access token remaining bearer". * sender-constrained code, sender-constrained access token and sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP". * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only. * sender-constrained code, bearer access token and bearer refresh token, use PKCE only. * bearer code, bearer access token and bearer refresh token, use none of them.
> 2020/06/07 21:36、Nov Matake <mat...@gmail.com>のメール: > > 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 >>>> <mailto: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 >>>>> <mailto: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 <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
