Re: [OAUTH-WG] Standardizing Attestation Tokens

2018-06-22 Thread Wheeler, David M
Laurence, It is good to hear your name again! I look forward to seeing you in Montreal. I have skimmed through the proposal, but I still need to read it more deeply and carefully – please excuse me if I missed something in the reading. What seems to be missing from the proposed structure is the

Re: [OAUTH-WG] Standardizing Attestation Tokens

2018-06-22 Thread Laurence Lundblade
> On Jun 22, 2018, at 7:02 AM, Wheeler, David M > wrote: > > Laurence, > It is good to hear your name again! I look forward to seeing you in Montreal. Yes, good to hear from you too! > I have skimmed through the proposal, but I still need to read it more deeply > and carefully – please excu

Re: [OAUTH-WG] Standardizing Attestation Tokens

2018-06-22 Thread Laurence Lundblade
Android Key Attestation does this today. It is part of the Android Keystore that is usually implemented in the TEE. This feature is on Android P (maybe O too, I can’t recall for sure). It implements some of the same fun

Re: [OAUTH-WG] Dynamic Scopes

2018-06-22 Thread Torsten Lodderstedt
Hi Nat, > Am 21.06.2018 um 10:35 schrieb Nat Sakimura : > > It depends on the use case but if you are talking about payment etc., putting > the transaction details in the scope and sending it over the regular RFC6749 > redirect to the authorization server is inherently a bad idea, as it is not

Re: [OAUTH-WG] Dynamic Scopes

2018-06-22 Thread Nat Sakimura
Hi Torsten, Re: using request object Carrying the scope parameter in the request object solves the integrity issue. However, it does not solve the confidentiality issue unless you also encrypt it, and encryption is not so easy. Re: 2 extra roundtrips You can actually cut the extra roundtrips to

Re: [OAUTH-WG] Dynamic Scopes

2018-06-22 Thread George Fletcher
I like the concept of parameterized scopes but I'm not sure they should be used for per-transaction use cases. It seems like the use cases presented are about operating on parameters specific to the transaction. Why are these part of the authorization flow? Is the goal to bind an access token

[OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-07.txt

2018-06-22 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones Brian Campbell

[OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-token-binding-07.txt

2018-06-22 Thread Brian Campbell
-07 is a pretty minor update to OAuth 2.0 Token Binding. Changes copied from the doc history are listed below for easy/lazy reference. draft-ietf-oauth-token-binding-07 o Explicitly state that the base64url encoding of the tbh value doesn't include any trailing pad characters, line b

Re: [OAUTH-WG] Dynamic Scopes

2018-06-22 Thread Torsten Lodderstedt
Hi George, > Am 22.06.2018 um 19:51 schrieb George Fletcher : > > I like the concept of parameterized scopes but I'm not sure they should be > used for per-transaction use cases. It seems like the use cases presented are > about operating on parameters specific to the transaction. Why are thes

Re: [OAUTH-WG] Dynamic Scopes

2018-06-22 Thread George Fletcher
On 6/22/18 4:31 PM, Torsten Lodderstedt wrote: Hi George, Is the goal to bind an access token to a particular transaction? If this is the case, would it not be better to either extend the refresh_token flow or may better yet, create a new grant_type that takes the refresh_token and addition