Subject: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Apr 2016 19:25:53 +0200

Hi all,

this is the call for adoption of 'Resource Indicators for OAuth 2.0', see
http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/

Please let us know by April 20th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Note: If you already stated your opinion at the IETF meeting in Buenos
Aires then you don't need to re-state your opinion, if you want.

The feedback at the BA IETF meeting was the following: ~10 persons
for accepting the document and 0 persons against.

Ciao
Hannes & Derek

---

From: William Denniss <[email-masked]>
Date: Wed, 06 Apr 2016 17:31:17 +0000

I support the adoption of this draft by the working group.

We have an immediate use-case with the Token Binding for OAuth efforts.
On Wed, Apr 6, 2016 at 2:26 PM Hannes Tschofenig <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 6 Apr 2016 15:07:25 -0300

I would like to have more discussion before wg adoption. 

I support the work and am willing to help. 

Phil

> On Apr 6, 2016, at 14:25, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Apr 2016 21:02:05 +0200

Phil,

we have discussed this concept already for years. In fact, it dates back
to the days of the OAuth base specification and the security
consideration section even talks about it.

We have had the content of this in the PoP key distribution draft and we
are now moving it into a separate document.

I am not sure how much longer you want to discuss it.

Ciao
Hannes

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 6 Apr 2016 16:06:31 -0300

With the process of immediate wglc I think we should review all documents more thoroughly before adoption. 

As I said I support the work. 

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig <[email-masked]> wrote:
> 
> Phil,
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Apr 2016 16:51:59 -0300

I don't think an immediate WGLC was expected here.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 6 Apr 2016 20:04:54 +0000

I would like to see the multiple resources servers, interaction with Token Exchange resolved before this is adopted to see if this will actually solve the problems

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

On Wed, Apr 6, 2016 at 4:06 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
With the process of immediate wglc I think we should review all documents more thoroughly before adoption.

Phil

> On Apr 6, 2016, at 16:02, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>
> Phil,
>
>>> On Apr 6, 2016, at 14:25, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Hi all,
>>>
>>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=byM3LOXoRTVhgT8pECwr18fH8mpi69bReWGFiuOEbMA%3d>
>>>
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>
>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Apr 2016 17:12:40 -0300

Multiple resources are there now.

I have no idea what "interaction with Token Exchange" means. Can you please
explain?

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin <[email-masked]>
wrote:

> I would like to see the multiple resources servers, interaction with Token
> Exchange resolved before this is adopted to see if this will actually solve
> the problems
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Wednesday, April 6, 2016 12:52 PM
> *To:* Phil Hunt (IDM) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
> OAuth 2.0
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=byM3LOXoRTVhgT8pECwr18fH8mpi69bReWGFiuOEbMA%3d>
> >>>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>
> >
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c0db8d93df16c4462a54508d35e550020%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ITHT4xb2D%2bsq4auvEuOv1VUwqFl9lRON5aOL6oOst8U%3d>
>
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 6 Apr 2016 20:16:55 +0000

I don’t see anything in the document that allows multiple resource servers where the token can be used. Token Exchange allows delegation and impersonation, so I have no idea of the semantics when I use both of these together

From: Brian Campbell [mailto:[email-masked]]
Sent: Wednesday, April 6, 2016 1:13 PM
To: Anthony Nadalin <[email-masked]>
Cc: Phil Hunt (IDM) <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Multiple resources are there now.
I have no idea what "interaction with Token Exchange" means. Can you please explain?

On Wed, Apr 6, 2016 at 5:04 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
I would like to see the multiple resources servers, interaction with Token Exchange resolved before this is adopted to see if this will actually solve the problems

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Wednesday, April 6, 2016 12:52 PM
To: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Phil

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Apr 2016 17:23:40 -0300

Please read the draft.

On Wed, Apr 6, 2016 at 5:16 PM, Anthony Nadalin <[email-masked]>
wrote:

> I don’t see anything in the document that allows multiple resource servers
> where the token can be used. Token Exchange allows delegation and
> impersonation, so I have no idea of the semantics when I use both of these
> together
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Wednesday, April 6, 2016 1:13 PM
> *To:* Anthony Nadalin <[email-masked]>
> *Cc:* Phil Hunt (IDM) <[email-masked]>; [email-masked]
>

---

From: John Bradley <[email-masked]>
Date: Wed, 6 Apr 2016 18:03:10 -0300

I support adoption by the WG.

> On Apr 6, 2016, at 2:25 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 7 Apr 2016 07:39:29 -0300

Surprisingly ;-), I kind of agree with Tony.

We need to hash out the requirements more fully.

Nat

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Justin Richer <[email-masked]>
Date: Thu, 7 Apr 2016 19:11:43 -0400

I support adoption of this document as a starting point for working group work.

 — Justin

> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 7 Apr 2016 16:23:40 -0700

While this work addresses a gap in the existing OAuth specification set, I am very concerned that this
incremental extension will lead to even more confusion around the areas of “scope”, “audience” and “resource server”.

I think we should try to solve this problem via  a framework that provides better guidance and implementation
models for OAuth use-cases. In other words, I feel that a broader discussion is needed here.

> On Apr 7, 2016, at 4:11 PM, Justin Richer <[email-masked]> wrote:
>

---

From: "Hardt, Dick" <[email-masked]>
Date: Fri, 8 Apr 2016 11:30:36 +0000

+1 to Prateek's comments

-- Dick

> On Apr 7, 2016, at 8:24 PM, Prateek Mishra <[email-masked]> wrote:
>

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 10 Apr 2016 17:43:05 +0000

So, my understanding on the rationale/requirements for having this spec
right now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format
depending on the resource server and to do that, you need to know which RS
is gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to
audience restrict the token, but the same can be achieved by sender
constraining the token, e.g., by token binding. As far as I can see, the
sentiment of the WG seems to be to use the sender constraint through Token
Binding, so from this respect, this spec is not the one to do R1. Besides,
the current proposal only takes care of the code flow. The same requirement
should be there for implicit flow as well, so the current proposal is not
covering the R1 anyways.

I can sort of understand R2, but I have two critique on the current
proposal:

C1. Current proposal does not support the implicit flow. To support it, the
resource URI has to be sent to the Authz endpoint instead of the Token
endpoint.
C2. It is much more direct to send the required token format rather than
the RS uri and probably better as:
  1) There are use cases where the AS does not maintain the list of RSs
that it supports, e.g., AOL.
       In such a case, even if the RS uri were sent to the AS, the AS
cannot mint the tokens in the appropriate format.
  2) When it is sent in the Authz request, it is leaking the information
about the resource that the client is going to the browser.
  3) There are use cases where it is desirable not to let the AS knows
where the Client is going from the privacy point of view.

So, my suggestion is to drop R1 and concentrate on R2. And to solve R2,
send token type instead of the resource indicator in the request.
This also necessitates the Client to be able to find out what token type
the resource requires, perhaps in the unauthorized response web link header
at the resource in the manner of oauth-meta.

Cheers,

Nat

2016年4月8日(金) 8:23 Prateek Mishra <[email-masked]>:

> incremental extension will lead to even more confusion around the areas of
> “scope”, “audience” and “resource server”.
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Apr 2016 13:30:10 -0600

Sending a token type is not sufficient. There's more involved than the
format. Many cases need to know if to encrypt and whom to encrypt to.  What
claims to put in the token (or reference by the token). What algorithms and
keys to use for signing/encryption.

The statement that the "Current proposal does not support the implicit
flow" is incorrect. Among other things, sec 2 has, "When an access token
will be returned from the authorization endpoint, the "resource" parameter
is used in the authorization request to the authorization endpoint as
defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura <[email-masked]> wrote:

> C1. Current proposal does not support the implicit flow. To support it,
> the resource URI has to be sent to the Authz endpoint instead of the Token
> endpoint.
>> incremental extension will lead to even more confusion around the areas
>> of “scope”, “audience” and “resource server”.
>>
>> I think we should try to solve this problem via  a framework that
>> provides better guidance and implementation

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 11 Apr 2016 20:18:31 +0000

So now you are adding more requirements for encryption ? The more this thread goes on shows how unstable and not fully thought out this draft is to go through WG adoption.

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimura <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Sending a token type is not sufficient. There's more involved than the format. Many cases need to know if to encrypt and whom to encrypt to.  What claims to put in the token (or reference by the token). What algorithms and keys to use for signing/encryption.

The statement that the "Current proposal does not support the implicit flow" is incorrect. Among other things, sec 2 has, "When an access token will be returned from the authorization endpoint, the "resource" parameter is used in the authorization request to the authorization endpoint as defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."

On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
So, my understanding on the rationale/requirements for having this spec right now is:

R1. Authz server wants toprevent the replay by the server that received it.
R2. Authz server needs to mint the access token in a variety of format depending on the resource server and to do that, you need to know which RS is gong to be receiving it.

To achieve R1, there are couple of methods. The proposed method here is to audience restrict the token, but the same can be achieved by sender constraining the token, e.g., by token binding. As far as I can see, the sentiment of the WG seems to be to use the sender constraint through Token Binding, so from this respect, this spec is not the one to do R1. Besides, the current proposal only takes care of the code flow. The same requirement should be there for implicit flow as well, so the current proposal is not covering the R1 anyways.

I can sort of understand R2, but I have two critique on the current proposal:

C1. Current proposal does not support the implicit flow. To support it, the resource URI has to be sent to the Authz endpoint instead of the Token endpoint.
C2. It is much more direct to send the required token format rather than the RS uri and probably better as:
  1) There are use cases where the AS does not maintain the list of RSs that it supports, e.g., AOL.
       In such a case, even if the RS uri were sent to the AS, the AS cannot mint the tokens in the appropriate format.
  2) When it is sent in the Authz request, it is leaking the information about the resource that the client is going to the browser.
  3) There are use cases where it is desirable not to let the AS knows where the Client is going from the privacy point of view.

So, my suggestion is to drop R1 and concentrate on R2. And to solve R2, send token type instead of the resource indicator in the request.
This also necessitates the Client to be able to find out what token type the resource requires, perhaps in the unauthorized response web link header at the resource in the manner of oauth-meta.

Cheers,

Nat

2016年4月8日(金) 8:23 Prateek Mishra <[email-masked]<mailto:[email-masked]>>:
While this work addresses a gap in the existing OAuth specification set, I am very concerned that this
incremental extension will lead to even more confusion around the areas of “scope”, “audience” and “resource server”.

> On Apr 7, 2016, at 4:11 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y869Fk9987ff09hvHIN%2bVGl%2fqxwWDmkvOwzcQcWqXZw%3d>
>>
>> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>
> https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Apr 2016 14:33:50 -0600

No, I'm not adding requirements for encryption. I was pointing out some of
the ways that an access token might be different for different RSs.

On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <[email-masked]>
wrote:

> So now you are adding more requirements for encryption ? The more this
> thread goes on shows how unstable and not fully thought out this draft is
> to go through WG adoption.
>
>
>
> *Sent:* Monday, April 11, 2016 12:30 PM
> *To:* Nat Sakimura <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y869Fk9987ff09hvHIN%2bVGl%2fqxwWDmkvOwzcQcWqXZw%3d>
> >>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
> >
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 11 Apr 2016 20:35:06 +0000

So it’s an incomplete solution then ?

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, April 11, 2016 1:34 PM
To: Anthony Nadalin <[email-masked]>
Cc: Nat Sakimura <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

No, I'm not adding requirements for encryption. I was pointing out some of the ways that an access token might be different for different RSs.

On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
So now you are adding more requirements for encryption ? The more this thread goes on shows how unstable and not fully thought out this draft is to go through WG adoption.

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimura <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Cheers,

Nat

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 12 Apr 2016 07:30:08 +0200

Indicating the resource server to the AS allows the AS to automatically select token type, encryption scheme and user data to be put into the access token based on a RS-specific policy. So there is no need to explicitely ask the AS for a certain token format or encryption scheme. 

> Am 11.04.2016 um 22:35 schrieb Anthony Nadalin <[email-masked]>:
> 
> On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <[email-masked]> wrote:

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Apr 2016 08:46:19 -0400

+1 to Torsten’s point.

And a reminder to Tony that call for adoption is the *start* of the document editing process, not the end. We’re not saying this is a complete solution with everything thought out when we adopt the document, we’re saying it’s a problem we want to work on and a direction that we want to move in. Stop trying to confuse people.

 — Justin

> On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Am 11.04.2016 um 22:35 schrieb Anthony Nadalin <[email-masked] <mailto:[email-masked]>>:
> 
>>   <>
>> From: Brian Campbell [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Anthony Nadalin <[email-masked] <mailto:[email-masked]>>
>> Cc: Nat Sakimura <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
>> On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <[email-masked] <mailto:[email-masked]>> wrote:
>>   <>
>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Campbell
>> To: Nat Sakimura <[email-masked] <mailto:[email-masked]>>
>> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
>> On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>> 2016年4月8日(金) 8:23 Prateek Mishra <[email-masked] <mailto:[email-masked]>>:
>> > On Apr 7, 2016, at 4:11 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y869Fk9987ff09hvHIN%2bVGl%2fqxwWDmkvOwzcQcWqXZw%3d>
>> >>
>> >> [email-masked] <mailto:[email-masked]>
>> >> https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>> >
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d>
>>  
>>  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 12 Apr 2016 13:03:53 +0000

Specifications should be somewhat complete and not open ended/not thought out, you should think about the issues, requirements and use cases first before you try to force this into the working group process and confuse people , we had too many of these specifications lately.

We are now up to 15+ specifications that someone has to read and understand how these all may or may not fit together and all the interactions that may occur. So much for the simple Oauth.

From: Justin Richer [mailto:[email-masked]]
Sent: Tuesday, April 12, 2016 5:46 AM
To: Torsten Lodderstadt <[email-masked]>
Cc: Anthony Nadalin <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

+1 to Torsten’s point.

 — Justin

On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Am 11.04.2016 um 22:35 schrieb Anthony Nadalin <[email-masked]<mailto:[email-masked]>>:
So it’s an incomplete solution then ?

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, April 11, 2016 1:34 PM
To: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Cc: Nat Sakimura <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

Cheers,

Nat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 12 Apr 2016 17:24:32 +0100

Hi
On 12/04/16 14:03, Anthony Nadalin wrote:
> Specifications should be somewhat complete and not open ended/not
> thought out, you should think about the issues, requirements and use
> cases first before you try to force this into the working group process
> and confuse people , we had too many of these specifications lately.
>
I'm not an expert yet I'm not consider myself confused :-). It is a 
basic incremental improvement, trying to come up with a standard 
approach toward restricting tokens to very specific resource servers.

> We are now up to 15+ specifications that someone has to read and
> understand how these all may or may not fit together and all the
> interactions that may occur. So much for the simple Oauth.
This particular text is simpler than a token exchange draft :-).
By the way there was a proposal recently to have OAuth 2.1 document 
where the best practices/etc are suggested, I suppose that can help 
consolidate various texts created since original OAuth 2.0

Thanks, Sergey
>
> *From:*Justin Richer [mailto:[email-masked]]
> *Sent:* Tuesday, April 12, 2016 5:46 AM
> *To:* Torsten Lodderstadt <[email-masked]>
> *Cc:* Anthony Nadalin <[email-masked]>; <[email-masked]>
> <[email-masked]>
> And a reminder to Tony that call for adoption is the *start* of the
> document editing process, not the end. We’re not saying this is a
> complete solution with everything thought out when we adopt the
> document, we’re saying it’s a problem we want to work on and a direction
> that we want to move in. Stop trying to confuse people.
>
>   — Justin
>
>     On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Indicating the resource server to the AS allows the AS to
>     automatically select token type, encryption scheme and user data to
>     be put into the access token based on a RS-specific policy. So there
>     is no need to explicitely ask the AS for a certain token format or
>     encryption scheme.
>
>
>     Am 11.04.2016 um 22:35 schrieb Anthony Nadalin
>     <[email-masked] <mailto:[email-masked]>>:
>
>         *From:*Brian Campbell [mailto:[email-masked]]
>         *Sent:*Monday, April 11, 2016 1:34 PM
>         *To:*Anthony Nadalin <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:*Nat Sakimura <[email-masked]
>         <mailto:[email-masked]>>; <[email-masked]
>         <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
>         *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource Indicators
>         for OAuth 2.0
>
>         No, I'm not adding requirements for encryption. I was pointing
>         out some of the ways that an access token might be different for
>         different RSs.
>
>
>         On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             So now you are adding more requirements for encryption ? The
>             more this thread goes on shows how unstable and not fully
>             thought out this draft is to go through WG adoption.
>
>             *From:*OAuth [mailto:[email-masked]
>             <mailto:[email-masked]>]*On Behalf Of*Brian Campbell
>             *Sent:*Monday, April 11, 2016 12:30 PM
>             *To:*Nat Sakimura <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:*<[email-masked] <mailto:[email-masked]>>
>             <[email-masked] <mailto:[email-masked]>>
>             *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource
>             Indicators for OAuth 2.0
>
>             Sending a token type is not sufficient. There's more
>             involved than the format. Many cases need to know if to
>             encrypt and whom to encrypt to.  What claims to put in the
>             token (or reference by the token). What algorithms and keys
>             to use for signing/encryption.
>
>
>             The statement that the "Current proposal does not support
>             the implicit flow" is incorrect. Among other things, sec 2
>             has, "When an access token will be returned from the
>             authorization endpoint, the "resource" parameter is used in
>             the authorization request to the authorization endpoint as
>             On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 R2. Authz server needs to mint the access token in a
>                 variety of format depending on the resource server and
>                 to do that, you need to know which RS is gong to be
>                 receiving it.
>
>                 To achieve R1, there are couple of methods. The proposed
>                 method here is to audience restrict the token, but the
>                 same can be achieved by sender constraining the token,
>                 e.g., by token binding. As far as I can see, the
>                 sentiment of the WG seems to be to use the sender
>                 constraint through Token Binding, so from this respect,
>                 this spec is not the one to do R1. Besides, the current
>                 proposal only takes care of the code flow. The same
>                 requirement should be there for implicit flow as well,
>                 so the current proposal is not covering the R1 anyways.
>
>                 C1. Current proposal does not support the implicit flow.
>                 To support it, the resource URI has to be sent to the
>                 Authz endpoint instead of the Token endpoint.
>
>                 C2. It is much more direct to send the required token
>                 format rather than the RS uri and probably better as:
>
>                    1) There are use cases where the AS does not maintain
>                 the list of RSs that it supports, e.g., AOL.
>
>                         In such a case, even if the RS uri were sent to
>                 the AS, the AS cannot mint the tokens in the appropriate
>                 format.
>
>                    2) When it is sent in the Authz request, it is
>                 leaking the information about the resource that the
>                 client is going to the browser.
>
>                    3) There are use cases where it is desirable not to
>                 let the AS knows where the Client is going from the
>                 privacy point of view.
>
>                 So, my suggestion is to drop R1 and concentrate on R2.
>                 And to solve R2, send token type instead of the resource
>                 indicator in the request.
>
>                 This also necessitates the Client to be able to find out
>                 what token type the resource requires, perhaps in the
>                 unauthorized response web link header at the resource in
>                 the manner of oauth-meta.
>
>                 Cheers,
>
>                 Nat
>
>                 2016年4月8日(金) 8:23 Prateek Mishra
>                 <[email-masked]
>                 <mailto:[email-masked]>>:
>
>                     While this work addresses a gap in the existing
>                     OAuth specification set, I am very concerned that this
>                     incremental extension will lead to even more
>                     confusion around the areas of “scope”, “audience”
>                     and “resource server”.
>
>                     I think we should try to solve this problem via  a
>                     framework that provides better guidance and
>                     implementation
>                     models for OAuth use-cases. In other words, I feel
>                     that a broader discussion is needed here.
>
>
>                      > On Apr 7, 2016, at 4:11 PM, Justin Richer
>                     <[email-masked] <mailto:[email-masked]>> wrote:
>                      >
>                      >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>                      >>
>                      >> Hi all,
>                      >>
>         <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>
>
>     <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>
>
>
>

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: William Denniss <[email-masked]>
Date: Tue, 12 Apr 2016 09:50:27 -0700

On Tue, Apr 12, 2016 at 9:24 AM, Sergey Beryozkin <[email-masked]>
wrote:

>> I'm not an expert yet I'm not consider myself confused :-). It is a basic
> incremental improvement, trying to come up with a standard approach toward
> restricting tokens to very specific resource servers.

Yes, so basically you have a refresh token with scopes A & B. You want to
get an access token for use at Resource Server 1 (RS1) with only scope A,
then one for Resource Server 2 (RS2) with only scope B, so you would refresh
<https://tools.ietf.org/html/rfc6749#section-6> the token stating
scope=A&resource=RS1, and then scope=B&resource=RS2.  OAuth already
supports the ability to request a scope sub-set during refresh, Brian's
spec adds the ability to indicate what RS you intend to use the resulting
access token at.

This topic has also came up in the context of Token Binding which is one
place where it is relevant to have RS-specific tokens, and I had the
impression from that meeting that some method of specifying the intended
resource would be helpful.

This is a really simple proposal that just standardizes that pattern so
people don't try to jam everything but the kitchen sink into 'scope'.

> By the way there was a proposal recently to have OAuth 2.1 document where
> the best practices/etc are suggested, I suppose that can help consolidate
> various texts created since original OAuth 2.0
>

At some point this may make sense, but I think for now the better
consolidated approach is online documentation and books
<https://www.manning.com/books/oauth-2-in-action>. Not everyone needs to
start at the RFC level.

As Mike Jones suggested earlier we should have some rounds of iteration and
get experience with the various extension specs before we attempt to merge
them together into 1 document. For example, it's likely that not all the
specs would get included in such a document and we need more deployment
experience to know what to include, and what not to.

>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y869Fk9987ff09hvHIN%2bVGl%2fqxwWDmkvOwzcQcWqXZw%3d
>> >
>>                      >>
>>                     <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>                      >
>>                     <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>>                     <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>>
>>                 <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>>         <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d
>> >
>>
>>     <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d
>> >
>>
>>
>>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 19 Apr 2016 00:24:58 +0000

+1

We should distill the use cases to get a set of requirements before jumping
onto a solution.

On Tue, Apr 12, 2016 at 14:04 Anthony Nadalin <[email-masked]> wrote:

> Specifications should be somewhat complete and not open ended/not thought
> out, you should think about the issues, requirements and use cases first
> before you try to force this into the working group process and confuse
> people , we had too many of these specifications lately.
>
>
>
> *From:* Justin Richer [mailto:[email-masked]]
> *Cc:* Anthony Nadalin <[email-masked]>; <[email-masked]> <
> [email-masked]>
>
>
> document editing process, not the end. We’re not saying this is a complete
> solution with everything thought out when we adopt the document, we’re
> saying it’s a problem we want to work on and a direction that we want to
> move in. Stop trying to confuse people.
>
>
>
>  — Justin
>
>
>
> Indicating the resource server to the AS allows the AS to automatically
> select token type, encryption scheme and user data to be put into the
> access token based on a RS-specific policy. So there is no need to
> explicitely ask the AS for a certain token format or encryption scheme.
>
>
> *From:* Brian Campbell [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, April 11, 2016 1:34 PM
> *Cc:* Nat Sakimura <[email-masked]>; <[email-masked]> <[email-masked]>