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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 19 Jul 2018 16:01:53 -0400

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0'
document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

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

Regards,
Rifaat

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Jul 2018 20:29:14 +0000

I support adoption.  The “resource” request parameter that it defines is already widely used.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 4:02 PM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0' document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:

Regards,
Rifaat

---

From: William Denniss <[email-masked]>
Date: Thu, 19 Jul 2018 13:32:13 -0700

Question: if this is adopted along with https://datatracker.ietf.
org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be the
authoritative definition, and Distributed OAuth to take a reference instead
of redefining?

On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones <Michael.Jones=40microsoft.
[email-masked]> wrote:

> *From:* OAuth <[email-masked]> *On Behalf Of * Rifaat Shekh-Yusef
> *Sent:* Thursday, July 19, 2018 4:02 PM
> *To:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] Call for adoption for "Resource Indicators for
> OAuth 2.0"
>
>
>
> Hi all,
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 19 Jul 2018 16:33:23 -0400

Yes

On Thu, Jul 19, 2018 at 4:32 PM William Denniss <[email-masked]> wrote:

> Question: if this is adopted along with
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/, is the
> plan for this spec to be the authoritative definition, and Distributed
> OAuth to take a reference instead of redefining?
>
> On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones <
> Michael.Jones=[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Jul 2018 20:34:44 +0000

Hi William,

that was the idea.

Ciao
Hannes

From: OAuth [mailto:[email-masked]] On Behalf Of William Denniss
Sent: 19 July 2018 16:32
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

Question: if this is adopted along with https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be the authoritative definition, and Distributed OAuth to take a reference instead of redefining?

On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>> wrote:
I support adoption.  The “resource” request parameter that it defines is already widely used.

                                                       -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 4:02 PM
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

Hi all,

Here is the document:

Regards,
Rifaat

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: William Denniss <[email-masked]>
Date: Thu, 19 Jul 2018 13:39:36 -0700

Thanks! I assume then that there are use-cases for this that are outside
the Distributed OAuth use-case? Did we document them?  I'm supportive (of
both drafts), but think we should get the rationale on the record since the
option to incorporate this spec in Distributed OAuth was raised in the
meeting.

On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi William,
>
>
>
> that was the idea.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *William
> Denniss
> *Sent:* 19 July 2018 16:32
> *To:* Mike Jones
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for
> OAuth 2.0"
>
>
>
> org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be
> the authoritative definition, and Distributed OAuth to take a reference
> instead of redefining?
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Rifaat Shekh-Yusef
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Jul 2018 20:53:05 +0000

Microsoft’s Azure AD OAuth server has used the resource= parameter since at least 2012 to indicate what resource the requested access token is to be for.

                                                       -- Mike

From: William Denniss <[email-masked]>
Sent: Thursday, July 19, 2018 4:40 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Mike Jones <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

Thanks! I assume then that there are use-cases for this that are outside the Distributed OAuth use-case? Did we document them?  I'm supportive (of both drafts), but think we should get the rationale on the record since the option to incorporate this spec in Distributed OAuth was raised in the meeting.

On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi William,

that was the idea.

Ciao
Hannes

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of William Denniss
Sent: 19 July 2018 16:32
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

                                                       -- Mike

Hi all,

Here is the document:

Regards,
Rifaat

---

From: John Bradley <[email-masked]>
Date: Thu, 19 Jul 2018 16:54:26 -0400

I accept the adoption of this document.

Sent from Mail for Windows 10

From: Rifaat Shekh-Yusef
To: oauth

Hi all,

Here is the document:

Regards,
Rifaat

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jul 2018 17:10:19 -0400

I support adoption of this document.

On Thu, Jul 19, 2018 at 4:54 PM, John Bradley <[email-masked]> wrote:

> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Rifaat Shekh-Yusef <[email-masked]>
> *Sent: *Thursday, July 19, 2018 4:02 PM
> *To: *oauth <[email-masked]>
> *Subject: *[OAUTH-WG] Call for adoption for "Resource Indicators for
> OAuth 2.0"
>
>
>
> Hi all,
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jul 2018 17:11:16 -0400

William: there was discussion in the meeting about the PoP document using
"resource" rather than "aud"

On Thu, Jul 19, 2018 at 4:53 PM, Mike Jones <
Michael.Jones=[email-masked]> wrote:

> Microsoft’s Azure AD OAuth server has used the resource= parameter since
> at least 2012 to indicate what resource the requested access token is to be
> for.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* William Denniss <[email-masked]>
> *Sent:* Thursday, July 19, 2018 4:40 PM
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; oauth <[email-masked]>

---

From: William Denniss <[email-masked]>
Date: Thu, 19 Jul 2018 15:36:16 -0700

Yes there was.

+1 to adopt this document.

On Thu, Jul 19, 2018 at 2:11 PM, Dick Hardt <[email-masked]> wrote:

> On Thu, Jul 19, 2018 at 4:53 PM, Mike Jones <Michael.Jones=40microsoft.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 19 Jul 2018 18:42:12 -0400

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Jul 2018 23:55:43 +0000

I also support the adoption. I had been pushing for this work in OAuth for a long time and now we also need it for the work in ACE as well.

From: OAuth [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: 19 July 2018 16:02
To: oauth
Subject: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

Hi all,

Here is the document:

Regards,
Rifaat

---

From: n-sakimura <[email-masked]>
Date: Fri, 20 Jul 2018 06:20:03 +0000

+1

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Here is the document:

Regards,
Rifaat

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 20 Jul 2018 09:32:17 +0200

I would like to point out (again) a single resource is not sufficient for most use cases I implemented in the last couple if years. I‘m advocating for enhancing the draft to support multiple resources and a clear definition of the relationship between resource(s) and scope.

> Am 20.07.2018 um 08:20 schrieb n-sakimura <[email-masked]>:
> 
> +1
>  
> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> Hi all,
>

---

From: Filip Skokan <[email-masked]>
Date: Fri, 20 Jul 2018 09:43:20 +0200

Hi Torsten,

> Multiple "resource" parameters may be used to indicate that the issued
token is intended to be used at multiple resource servers.

That's already in. Furthermore what about logical names for target
services? Like was added in -03 of token exchange?

Best,
*Filip Skokan*

On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <[email-masked]>
wrote:

> I would like to point out (again) a single resource is not sufficient for
> most use cases I implemented in the last couple if years. I‘m advocating
> for enhancing the draft to support multiple resources and a clear
> definition of the relationship between resource(s) and scope.
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Brian Campbell
> *Sent:* Friday, July 20, 2018 7:42 AM
> *To:* Rifaat Shekh-Yusef <[email-masked]>
> *Cc:* oauth <[email-masked]>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 20 Jul 2018 10:18:11 -0400

The current draft does allow multiple "resource" parameters. However, there
seemed to be consensus in the WG meeting yesterday that only a single
"resource" parameter was preferable and that a client could obtain an
access token per resource (likely using a refresh token). I'm personally
sympathetic to that point. But maybe it's too restrictive. I would like to
see some more text about the complexity implications of multiple "resource"
parameters and perhaps some discouragement of doing so. I believe logical
names are more potentially useful in an STS framework like token exchange
but should be out of scope for this work.

On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan <[email-masked]> wrote:

> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <
> [email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 20 Jul 2018 15:13:47 +0000

While I agree that a single requested resource is the common case, enough people have spoken up with a need for multiple requested resources over the years that I think everyone will be better served by leaving the ability to specify multiple requested resources in the specification.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 10:18 AM
To: Filip Skokan <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

The current draft does allow multiple "resource" parameters. However, there seemed to be consensus in the WG meeting yesterday that only a single "resource" parameter was preferable and that a client could obtain an access token per resource (likely using a refresh token). I'm personally sympathetic to that point. But maybe it's too restrictive. I would like to see some more text about the complexity implications of multiple "resource" parameters and perhaps some discouragement of doing so. I believe logical names are more potentially useful in an STS framework like token exchange but should be out of scope for this work.

On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Torsten,

> Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at multiple resource servers.

That's already in. Furthermore what about logical names for target services? Like was added in -03 of token exchange?

Best,
Filip Skokan

On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
I support adoption of this document.

Am 20.07.2018 um 08:20 schrieb n-sakimura <[email-masked]<mailto:[email-masked]>>:
+1

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

Here is the document:

Regards,
Rifaat

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Jul 2018 13:46:18 -0400

There are a few places where multiple resources could be used:

One is in the code flow where it is desirable to optimize the user
experience so that the user is granting authorization once, and not
multiple times.

The second is in the access token request, which leads to the third
instance, which is in the access token. If an access token is being
returned for each resource, then making a single request is simpler, it
seems to complicate the interface more.

If we want to have audience constrained access tokens, then it is safer to
have only one resource in the access token - otherwise each resource can
use the access token to access the other resources.

All of these examples assume that it is a single AS. Supporting multiple AS
in a single request seems super complicated and wrought with security and
trust issues.

On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones <
Michael.Jones=[email-masked]> wrote:

> While I agree that a single requested resource is the common case, enough
> people have spoken up with a need for multiple requested resources over the
> years that I think everyone will be better served by leaving the ability to
> specify multiple requested resources in the specification.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of * Brian Campbell
> *Sent:* Friday, July 20, 2018 10:18 AM
> *To:* Filip Skokan <[email-masked]>
>
> The current draft does allow multiple "resource" parameters. However,
> there seemed to be consensus in the WG meeting yesterday that only a single

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Jul 2018 18:34:34 +0200

Hi Brian,

> Am 20.07.2018 um 16:18 schrieb Brian Campbell <[email-masked]>:
> 
> The current draft does allow multiple "resource" parameters. However, there seemed to be consensus in the WG meeting yesterday that only a single "resource" parameter was preferable

I think this makes sense for the token request. This allows the AS to audience restrict and token bind the access token to a single resource server URL.

> and that a client could obtain an access token per resource (likely using a refresh token).

I think the refresh token may represent the overall grant whereas the token request may issue an access token representing the whole or a subset of the overall grant.

The question is what this means with respect to the scope. I assume scope values are typically bound to a certain resource service. For example, “openid email mediacloud#read emailservice#read” would match to permission on a OpenID OP, a private cloud and an email service. I therefore would suggest the AS may filter the scope down to the values applicable to the resource server for which the access token is being minted.

Another question relates to the applicable resource URIs. Do you envision any way to constraint the resource URIs for which an access token might be created for a particular grant? My feeling is the resource owner should have a chance to consent or not in order to prevent the client to access resource servers the resource owner does not want it to do so.

> I'm personally sympathetic to that point. But maybe it's too restrictive. I would like to see some more text about the complexity implications of multiple "resource" parameters and perhaps some discouragement of doing so.

As stated above, I’m fine with a single parameter. I could provide some text on how the resource parameter could govern the AS behavior in case of code and refresh token grant.

> I believe logical names are more potentially useful in an STS framework like token exchange but should be out of scope for this work.

Are you referring to logical resource names?

kind regards,
Torsten.

>>> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <[email-masked]> wrote:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Jul 2018 18:40:09 +0200

Hi Dick,

> Am 20.07.2018 um 19:46 schrieb Dick Hardt <[email-masked]>:
> 
> One is in the code flow where it is desirable to optimize the user experience so that the user is granting authorization once, and not multiple times. 
> 

I agree. That’s the reason why I’m advocating multiple resource.

> The second is in the access token request, which leads to the third instance, which is in the access token. If an access token is being returned for each resource, then making a single request is simpler, it seems to complicate the interface more.

I agree.

> 
> If we want to have audience constrained access tokens, then it is safer to have only one resource in the access token - otherwise each resource can use the access token to access the other resources.

Yes and no. Yes because it’s safer to use tightly audience restricted access tokens.

No because token binding or cert-bound access tokens can prevent abuse in such a case.

> 
> All of these examples assume that it is a single AS. Supporting multiple AS in a single request seems super complicated and wrought with security and trust issues.

I don’t see a use case for multiple AS (yet ;-).

kind regards,
Torsten.
> 
> 
> 
> 
>> On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Mon, 23 Jul 2018 11:26:29 -0600

My sense is that there's enough WG support to keep the multiple "resource"
parameters at both endpoints. The contextual meaning might be a bit
different at each endpoint - as you point out the refresh token may
represent the overall grant whereas the token request may issue an access
token representing the whole or a subset of the overall grant. There's also
the implicit grant to consider where the access token is returned from the
authorization endpoint.

The draft hasn't seen any real changes since the initial -00 individual
posting a couple years ago.  So, with its impeding adoption, it's overdue
for some updates - especially some more text and/or clarifications on
what's being discussed in this thread. I'm always happy to consider
proposed text from you, Torsten, for any of this stuff.

On Sat, Jul 21, 2018 at 10:34 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> Hi Brian,
>
> Am 20.07.2018 um 16:18 schrieb Brian Campbell <[email-masked]
> >:
>
> "resource" parameter was preferable
>
>
> I think this makes sense for the token request. This allows the AS to
> audience restrict and token bind the access token to a single resource
> server URL.
>
> I think the refresh token may represent the overall grant whereas the
> token request may issue an access token representing the whole or a subset
> of the overall grant.
>
> The question is what this means with respect to the scope. I assume scope
> values are typically bound to a certain resource service. For example,
> “openid email mediacloud#read emailservice#read” would match to permission
> on a OpenID OP, a private cloud and an email service. I therefore would
> suggest the AS may filter the scope down to the values applicable to the
> resource server for which the access token is being minted.
>
> Another question relates to the applicable resource URIs. Do you envision
> any way to constraint the resource URIs for which an access token might be
> created for a particular grant? My feeling is the resource owner should
> have a chance to consent or not in order to prevent the client to access
> resource servers the resource owner does not want it to do so.
>
> I'm personally sympathetic to that point. But maybe it's too restrictive.
> I would like to see some more text about the complexity implications of
> multiple "resource" parameters and perhaps some discouragement of doing so.
>
>
> As stated above, I’m fine with a single parameter. I could provide some
> text on how the resource parameter could govern the AS behavior in case of
> code and refresh token grant.
>
> I believe logical names are more potentially useful in an STS framework
> like token exchange but should be out of scope for this work.
>
>
>>> I would like to point out (again) a single resource is not sufficient
>>> for most use cases I implemented in the last couple if years. I‘m
>>> advocating for enhancing the draft to support multiple resources and a
>>> clear definition of the relationship between resource(s) and scope.
>>>
>>> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators
>>> for OAuth 2.0"
>>>
>>>
>>>
> review, use, distribution or disclosure by others is strictly prohibited.