private_key_jwt and mTLS can be sender PoP method for code too.
> 2020/06/07 23:00、Francis Pouatcha <f...@adorsys.de>のメール: > > I am a little bit confused. Let me break it down: > > code : > -> sender : Client > -> consumer : AS > -> sender PoP : > --> confidential client: code_verifier (PKCE) > --> public client: code_verifier (PKCE)? > > refresh_token : > -> sender : Client > -> consumer : AS > -> sender PoP : > --> confidential client: private_key_jwt, mTLS > --> public client: DPoP? > > access_token : > -> presenter : Client > -> consumer : RS > -> sender PoP : > --> confidential client: private_key_jwt, mTLS > --> public client: DPoP? > > Is this correct? > > On Sun, Jun 7, 2020 at 8:42 AM Nov Matake <mat...@gmail.com > <mailto:mat...@gmail.com>> wrote: > * 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 <mailto: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 >>> <mailto:neil.mad...@forgerock.com>> wrote: >>> >>> >>> Answers inline: >>> >>>> On 7 Jun 2020, at 13:07, Nov Matake <mat...@gmail.com >>>> <mailto: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 >>>>> > > > -- > 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 https://www.ietf.org/mailman/listinfo/oauth
