date:20200607

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

2020-06-07 Thread Torsten Lodderstedt



> On 7. Jun 2020, at 16:18, Nov Matake  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 のメール:
>> 
>> 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  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 のメール:
>>> 
>>> 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  wrote:
 
 
 Answers inline: 
 
> On 7 Jun 2020, at 13:07, Nov Matake  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 のメール:
>> 
>> 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

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

2020-06-07 Thread Francis Pouatcha

On Sun, Jun 7, 2020 at 10:18 AM Nov Matake  wrote:

> private_key_jwt and mTLS can be sender PoP method for code too.
>
>
Yes,correct thanks for pointing this out: So we have
code :
  -> sender : Client
  -> consumer : AS
  -> sender PoP :
   --> confidential client: [code_verifier (PKCE)  AND [
private_key_jwt XOR mTLS ] ]
   --> public client:  code_verifier (PKCE) AND ?

refresh_token :
  -> sender : Client
  -> consumer : AS
  -> sender PoP :
   --> confidential client: private_key_jwt, mTLS
   --> public client:  DPoP AND ?

access_token :
  -> presenter : Client
  -> consumer : RS
  -> sender PoP :
   --> confidential client: private_key_jwt, mTLS
   --> public client:  DPoP AND ?

@Daniel Fett   I still have some question marks in
here. Am I missing anything?
-- 
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

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

2020-06-07 Thread Nov Matake

private_key_jwt and mTLS can be sender PoP method for code too.

> 2020/06/07 23:00、Francis Pouatcha のメール:
> 
> 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  > 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 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 >> > wrote:
>>> 
>>> 
>>> Answers inline: 
>>> 
 On 7 Jun 2020, at 13:07, Nov Matake >>> > 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  >のメール:
> 
> 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

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

2020-06-07 Thread Francis Pouatcha

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

Re: [OAUTH-WG] Mix-Up Revisited

2020-06-07 Thread Daniel Fett

Hi all,
I was wondering if we should move towards introducing and (more
explicitly) recommending the iss parameter in the security BCP, for the
reasons laid out below and in the article (which is now at
https://danielfett.de/2020/05/04/mix-up-revisited/).

Any thoughts on this?

-Daniel

Am 04.05.20 um 19:34 schrieb Daniel Fett:
>
> Hi all,
>
> to make substantiated recommendations for FAPI 2.0, the security
> considerations for PAR, and the security BCP, I did another analysis
> on the threats that arise from mix-up attacks. I was interested in
> particular in two questions:
>
>   * Does PAR help preventing mix-up attacks?
>   * Do we need JARM to prevent mix-up attacks?
>
> I wrote down several attack variants and configurations in the
> following document:
> https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html
>
> The key takeaways are:
>
>  1. The security BCP needs to make clear that per-*AS* redirect URIs
> are only sufficient if OAuth Metadata is not used to resolve
> multiple issuers. Otherwise, per-*Issuer* redirect URIs or the iss
> parameter MUST be used.
>  2. PAR-enabled authorization servers can protect the integrity better
> and protect against Mix-Up Attacks better if they ONLY accept PAR
> requests.
>  3. We should emphasize the importance of the iss parameter (or
> issuer) in the authorization response. Maybe introduce this
> parameter in the security BCP or another document?
>  4. Sender-constrained access tokens help against mix-up attacks when
> the access token is targeted.
>  5. Sender-constraining the authorization code (PAR + PAR-DPoP?) might
> be worth looking into.
>
> I would like to hear your thoughts!
>
> -Daniel
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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

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

2020-06-07 Thread Nov Matake

* 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 のメール:
> 
> 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  wrote:
>> 
>> 
>> Answers inline: 
>> 
>>> On 7 Jun 2020, at 13:07, Nov Matake  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 >>> >のメール:
 
 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
 
> On 7 Jun 2020, at 12:34, Nov Matake  > wrote:
> 
> Confidential clients can also use DPoP.
> 
>> 2020/06/07 20:25、Torsten Lodderstedt > >のメール:
>> 
>> If the client would register for every transaction.
>> 
>> And don’t forget, DPoP also supports sender constrained access to 
>> resource servers, which dyn registration does not.
>> 
>>> Am 07.06.2020 um 13:04 schrieb Nov Matake >> >:
>>> 
>>> Since each client instance has at least one key, those are same level 
>>> of state management.
>>> 
 2020/06/07 16:24、Torsten Lodderstedt >>> >のメール:
 
 There are similarities in this particular use case but I would argue 
 DPoP is more light weight than dynamic client registration, less state 
 management in particular.
 
> Am 07.06.2020 um 05:41 schrieb Nov Matake  >:
> 
> DPoP-bound refresh token seems feature duplication with dynamic 
> client registration.
> 
>> 2020/06/07 7:57、Francis Pouatcha > >のメール:
>> 
>> 
>> > Am 05.06.2020 um 22:17 schrieb George Fletcher > > @dmarc..ietf.org >:
>> > 
>> > Secondly, I do think we need a way to allow for the refresh_token 
>> > to be bound while leaving the access_tokens as bearer tokens. This 
>> > adds useful security without impacting existing RS deployments.
>> 
>> +1 that’s a very useful 
>> feature___
>> AFAIK a refresh_token is always bound. What am I missing here?
>> -- 
>> 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 
>> 
> 
>>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
>>> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai

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

2020-06-07 Thread Nov Matake

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  wrote:
> 
> 
> Answers inline: 
> 
>>> On 7 Jun 2020, at 13:07, Nov Matake  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 のメール:
>>> 
>>> 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
>>> 
> On 7 Jun 2020, at 12:34, Nov Matake  wrote:
> 
 Confidential clients can also use DPoP.
 
> 2020/06/07 20:25、Torsten Lodderstedt のメール:
> 
> If the client would register for every transaction.
> 
> And don’t forget, DPoP also supports sender constrained access to 
> resource servers, which dyn registration does not.
> 
>>> Am 07.06.2020 um 13:04 schrieb Nov Matake :
>>> 
>> Since each client instance has at least one key, those are same level 
>> of state management.
>> 
>>> 2020/06/07 16:24、Torsten Lodderstedt のメール:
>>> 
>>> There are similarities in this particular use case but I would argue 
>>> DPoP is more light weight than dynamic client registration, less state 
>>> management in particular.
>>> 
> Am 07.06.2020 um 05:41 schrieb Nov Matake :
> 
 DPoP-bound refresh token seems feature duplication with dynamic 
 client registration.
 
> 2020/06/07 7:57、Francis Pouatcha 
> のメール:
> 
>> 
>> > Am 05.06.2020 um 22:17 schrieb George Fletcher 
>> > :
>> > 
>> > Secondly, I do think we need a way to allow for the refresh_token 
>> > to be bound while leaving the access_tokens as bearer tokens. This 
>> > adds useful security without impacting existing RS deployments.
>> 
>> +1 that’s a very useful 
>> feature___
> AFAIK a refresh_token is always bound. What am I missing here?
> -- 
> 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
 
>> 
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2020-06-07 Thread Neil Madden

Answers inline: 

> On 7 Jun 2020, at 13:07, Nov Matake  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 のメール:
>> 
>> 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
>> 
 On 7 Jun 2020, at 12:34, Nov Matake  wrote:
 
>>> Confidential clients can also use DPoP.
>>> 
 2020/06/07 20:25、Torsten Lodderstedt のメール:
 
 If the client would register for every transaction.
 
 And don’t forget, DPoP also supports sender constrained access to resource 
 servers, which dyn registration does not.
 
>> Am 07.06.2020 um 13:04 schrieb Nov Matake :
>> 
> Since each client instance has at least one key, those are same level of 
> state management.
> 
>> 2020/06/07 16:24、Torsten Lodderstedt のメール:
>> 
>> There are similarities in this particular use case but I would argue 
>> DPoP is more light weight than dynamic client registration, less state 
>> management in particular.
>> 
 Am 07.06.2020 um 05:41 schrieb Nov Matake :
 
>>> DPoP-bound refresh token seems feature duplication with dynamic client 
>>> registration.
>>> 
 2020/06/07 7:57、Francis Pouatcha のメール:
 
> 
> > Am 05.06.2020 um 22:17 schrieb George Fletcher 
> > :
> > 
> > Secondly, I do think we need a way to allow for the refresh_token 
> > to be bound while leaving the access_tokens as bearer tokens. This 
> > adds useful security without impacting existing RS deployments.
> 
> +1 that’s a very useful 
> feature___
 AFAIK a refresh_token is always bound. What am I missing here?
 -- 
 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
>>> 
> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2020-06-07 Thread Nov Matake

So, you mean…

If a frontend client want to use
* sender-constrained code, bearer access token and sender-constrained refresh 
token, use DynReg.
* sender-constrained code, sender-constrained access token and 
sender-constrained refresh token, use DynReg + DPoP.
* bearer code, sender-constrained access token and sender-constrained refresh 
token, use DPoP only.
* bearer code, bearer access token and bearer refresh token, use neither.

is my understanding correct??

> 2020/06/07 20:49、Neil Madden のメール:
> 
> 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
> 
>> On 7 Jun 2020, at 12:34, Nov Matake  wrote:
>> 
>> Confidential clients can also use DPoP.
>> 
>>> 2020/06/07 20:25、Torsten Lodderstedt >> >のメール:
>>> 
>>> If the client would register for every transaction.
>>> 
>>> And don’t forget, DPoP also supports sender constrained access to resource 
>>> servers, which dyn registration does not.
>>> 
 Am 07.06.2020 um 13:04 schrieb Nov Matake >>> >:
 
 Since each client instance has at least one key, those are same level of 
 state management.
 
> 2020/06/07 16:24、Torsten Lodderstedt  >のメール:
> 
> There are similarities in this particular use case but I would argue DPoP 
> is more light weight than dynamic client registration, less state 
> management in particular.
> 
>> Am 07.06.2020 um 05:41 schrieb Nov Matake > >:
>> 
>> DPoP-bound refresh token seems feature duplication with dynamic client 
>> registration.
>> 
>>> 2020/06/07 7:57、Francis Pouatcha >> >のメール:
>>> 
>>> 
>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher >> > @dmarc..ietf.org >:
>>> > 
>>> > Secondly, I do think we need a way to allow for the refresh_token to 
>>> > be bound while leaving the access_tokens as bearer tokens. This adds 
>>> > useful security without impacting existing RS deployments.
>>> 
>>> +1 that’s a very useful 
>>> feature___
>>> AFAIK a refresh_token is always bound. What am I missing here?
>>> -- 
>>> 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 
>>> 
>> 
 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

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

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

2020-06-07 Thread Neil Madden

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

> On 7 Jun 2020, at 12:34, Nov Matake  wrote:
> 
> Confidential clients can also use DPoP.
> 
>> 2020/06/07 20:25、Torsten Lodderstedt のメール:
>> 
>> If the client would register for every transaction.
>> 
>> And don’t forget, DPoP also supports sender constrained access to resource 
>> servers, which dyn registration does not.
>> 
 Am 07.06.2020 um 13:04 schrieb Nov Matake :
 
>>> Since each client instance has at least one key, those are same level of 
>>> state management.
>>> 
 2020/06/07 16:24、Torsten Lodderstedt のメール:
 
 There are similarities in this particular use case but I would argue DPoP 
 is more light weight than dynamic client registration, less state 
 management in particular.
 
>> Am 07.06.2020 um 05:41 schrieb Nov Matake :
>> 
> DPoP-bound refresh token seems feature duplication with dynamic client 
> registration.
> 
>> 2020/06/07 7:57、Francis Pouatcha のメール:
>> 
>>> 
>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher 
>>> > :
>>> > 
>>> > Secondly, I do think we need a way to allow for the refresh_token to 
>>> > be bound while leaving the access_tokens as bearer tokens. This adds 
>>> > useful security without impacting existing RS deployments.
>>> 
>>> +1 that’s a very useful 
>>> feature___
>> AFAIK a refresh_token is always bound. What am I missing here?
>> -- 
>> 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
> 
>>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2020-06-07 Thread Nov Matake

Confidential clients can also use DPoP.

> 2020/06/07 20:25、Torsten Lodderstedt のメール:
> 
> If the client would register for every transaction.
> 
> And don’t forget, DPoP also supports sender constrained access to resource 
> servers, which dyn registration does not.
> 
>> Am 07.06.2020 um 13:04 schrieb Nov Matake :
>> 
>> Since each client instance has at least one key, those are same level of 
>> state management.
>> 
>>> 2020/06/07 16:24、Torsten Lodderstedt >> >のメール:
>>> 
>>> There are similarities in this particular use case but I would argue DPoP 
>>> is more light weight than dynamic client registration, less state 
>>> management in particular.
>>> 
 Am 07.06.2020 um 05:41 schrieb Nov Matake >>> >:
 
 DPoP-bound refresh token seems feature duplication with dynamic client 
 registration.
 
> 2020/06/07 7:57、Francis Pouatcha  >のメール:
> 
> 
> > Am 05.06.2020 um 22:17 schrieb George Fletcher  > @dmarc..ietf.org >:
> > 
> > Secondly, I do think we need a way to allow for the refresh_token to be 
> > bound while leaving the access_tokens as bearer tokens. This adds 
> > useful security without impacting existing RS deployments.
> 
> +1 that’s a very useful 
> feature___
> AFAIK a refresh_token is always bound. What am I missing here?
> -- 
> 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 
> 
 
>> 

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

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

2020-06-07 Thread Torsten Lodderstedt

If the client would register for every transaction.

And don’t forget, DPoP also supports sender constrained access to resource 
servers, which dyn registration does not.

> Am 07.06.2020 um 13:04 schrieb Nov Matake :
> 
> Since each client instance has at least one key, those are same level of 
> state management.
> 
>> 2020/06/07 16:24、Torsten Lodderstedt のメール:
>> 
>> There are similarities in this particular use case but I would argue DPoP is 
>> more light weight than dynamic client registration, less state management in 
>> particular.
>> 
 Am 07.06.2020 um 05:41 schrieb Nov Matake :
 
>>> DPoP-bound refresh token seems feature duplication with dynamic client 
>>> registration.
>>> 
 2020/06/07 7:57、Francis Pouatcha のメール:
 
> 
> > Am 05.06.2020 um 22:17 schrieb George Fletcher 
> > :
> > 
> > Secondly, I do think we need a way to allow for the refresh_token to be 
> > bound while leaving the access_tokens as bearer tokens. This adds 
> > useful security without impacting existing RS deployments.
> 
> +1 that’s a very useful 
> feature___
 AFAIK a refresh_token is always bound. What am I missing here?
 -- 
 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

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

2020-06-07 Thread Nov Matake

Since each client instance has at least one key, those are same level of state 
management.

> 2020/06/07 16:24、Torsten Lodderstedt のメール:
> 
> There are similarities in this particular use case but I would argue DPoP is 
> more light weight than dynamic client registration, less state management in 
> particular.
> 
>> Am 07.06.2020 um 05:41 schrieb Nov Matake :
>> 
>> DPoP-bound refresh token seems feature duplication with dynamic client 
>> registration.
>> 
>>> 2020/06/07 7:57、Francis Pouatcha >> >のメール:
>>> 
>>> 
>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher >> > @dmarc..ietf.org >:
>>> > 
>>> > Secondly, I do think we need a way to allow for the refresh_token to be 
>>> > bound while leaving the access_tokens as bearer tokens. This adds useful 
>>> > security without impacting existing RS deployments.
>>> 
>>> +1 that’s a very useful 
>>> feature___
>>> AFAIK a refresh_token is always bound. What am I missing here?
>>> -- 
>>> 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
>> 

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

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

2020-06-07 Thread Torsten Lodderstedt

There are similarities in this particular use case but I would argue DPoP is 
more light weight than dynamic client registration, less state management in 
particular.

> Am 07.06.2020 um 05:41 schrieb Nov Matake :
> 
> DPoP-bound refresh token seems feature duplication with dynamic client 
> registration.
> 
>> 2020/06/07 7:57、Francis Pouatcha のメール:
>> 
>>> 
>>> > Am 05.06.2020 um 22:17 schrieb George Fletcher 
>>> > :
>>> > 
>>> > Secondly, I do think we need a way to allow for the refresh_token to be 
>>> > bound while leaving the access_tokens as bearer tokens. This adds useful 
>>> > security without impacting existing RS deployments.
>>> 
>>> +1 that’s a very useful 
>>> feature___
>> AFAIK a refresh_token is always bound. What am I missing here?
>> -- 
>> 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

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

2020-06-07 Thread Torsten Lodderstedt

That’s correct for confidential clients.

For a public client, the refresh token is just bound to the client id. DPoP 
allows binding to an ephemeral key pair for this kind of clients.

> Am 07.06.2020 um 00:57 schrieb Francis Pouatcha 
> :
> 
> 
>> 
>> > Am 05.06.2020 um 22:17 schrieb George Fletcher 
>> > :
>> > 
>> > Secondly, I do think we need a way to allow for the refresh_token to be 
>> > bound while leaving the access_tokens as bearer tokens. This adds useful 
>> > security without impacting existing RS deployments.
>> 
>> +1 that’s a very useful 
>> feature___
> AFAIK a refresh_token is always bound. What am I missing here?
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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

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

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

Re: [OAUTH-WG] Mix-Up Revisited

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

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

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

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

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

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

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

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

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

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

15 matches

Site Navigation

Mail list logo

Footer information