> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to