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

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 <
torsten@lodderstedt.net> wrote:

> Hi Brian,
>
> Am 20.07.2018 um 16:18 schrieb Brian Campbell <bcampbell@pingidentity.com
> >:
>
> 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 <panva.ip@gmail.com> 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 <
>> torsten@lodderstedt.net> 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 <n-sakimura@nri.co.jp>:
>>>
>>> +1
>>>
>>>
>>>
>>> *From:* OAuth [mailto:oauth-bounces@ietf.org <oauth-bounces@ietf.org>] *On
>>> Behalf Of *Brian Campbell
>>> *Sent:* Friday, July 20, 2018 7:42 AM
>>> *To:* Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
>>> *Cc:* oauth <oauth@ietf.org>
>>> *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 <
>>> rifaat.ietf@gmail.com> 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
>>> OAuth@ietf.org
>>> 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
>>> 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
>>
>>
>
> *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._