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> 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>のメール: > > 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 > > -- 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