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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 3 Aug 2018 08:09:37 -0400

All,

Based on the feedback during the meeting in Montreal and on the mailing
list, we think that the WG has decided to adopt this draft.

*Authors,*

Feel free to submit a new WG -00 draft.

Regards,
 Rifaat & Hannes

On Mon, Jul 23, 2018 at 1:27 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

> 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]
>> >:
>>
>> 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 3:43 AM, Filip Skokan <[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]> wrote:
>>>
>>>> I support adoption of this document.
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> *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]>
>>>> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators
>>>> for OAuth 2.0"
>>>>
>>>>
>>>>
>>>> I support adoption of this document.
>>>>
>>>>
>>>>
>>>> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef <
>>>> [email-masked]> wrote:
>>>>
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> *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.*
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>> *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.*
>>
>>
>
> *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.*_______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>