Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[Francis Pouatcha <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>のメール:
>
> 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 <[e-mail]> wrote:
>
> 
> Answers inline:
>
> On 7 Jun 2020, at 13:07, Nov Matake <[e-mail]> 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 <[e-mail]>のメール:
>
> 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/