> On 7. Jun 2020, at 16:18, Nov Matake <mat...@gmail.com> wrote: > > private_key_jwt and mTLS can be sender PoP method for code too.
Seems we need to distinguish certain “kinds” of PoP for code. 1) private_key_jwt, mTLS and other client secrets can be used to authenticate the client and thus check the binding of the code to a particular client_id. 2) PKCE is different in that it allows to tie the code to a certain transaction running on a certain device. (2) detects code replay at the same client_id on a different device, (1) does not. Regarding PoP for access tokens: private_key_jwt does not provide this capability. mTLS and DPoP provide it for both confidential and public clients. > >> 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> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
