Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt: Error code on failure to parse resource URI

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 1 Sep 2018 11:47:30 +0300

Thanks Brian.

I assume for a request which contains multiple "resource" parameters, if
one or more of those are invalid, this should also cause an
"invalid_resource" error?

How about the situation when the request includes a "scope" parameter,
with one or more values which don't match the "resource(s)" (or vice
versa) - how should the AS respond in that case?

Have there been thoughts about specifying AS metadata parameters for
publishing the supported resources and potentially their scope mappings?
Mappings could be especially useful for clients to figure out which
scopes belong to which resource, and prevent "invalid_resource" errors.

Similarly, allowed "resources" in OAuth client metadata?

About the statement

>    Scope, from Section 3.3
> <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00#section-3.3> of OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>], sometimes is
>    overloaded to convey the location or identity of the resource server,
>    however, doing so isn't always feasible or desirable.
The rationale for the resource indicators spec (for new adopters)
appears to rest on that statement. But what is the actual argument
against overloading scopes, i.e. including the resource URL in the scope
value ;)

Readers of the spec will likely be pondering whether it's better to
encode the resource URL / identifier in the scope, or use the separate
"resource" parameter approach. I think we can greatly help them with a
honest discussion of the pros & cons of the two approaches. And perhaps
suggest how to migrate between the two.

>    Bearer tokens, currently the only defined type of OAuth
>    access token, allow any party in possession of a token to get access
>    to the associated resources.
Worth mentioning token binding and mTLS here?

Vladimir

On 28/08/18 00:27, Brian Campbell wrote:
> Sorry for the slow response Vladimir,
>
> It seemed worthwhile to have an error code that was more specific than
> "invalid_request" to convey back to the client that there was an issue with
> the value(s) it provided for the resource parameter - it's similar to
> "invalid_scope" from RFC 6749 in that regard. Token exchange has something
> similar for the resource parameter and I actually need to reconcile the
> wording and naming in the resource indicators draft to better align with
> that. I just haven't had a chance to get back into doing the spec edits on
> this one yet.
>
>
> On Wed, Aug 22, 2018 at 1:24 PM Vladimir Dzhuvinov <[email-masked]>
> wrote:
>
>> Hi Brian,
>>
>>       If the
>>       authorization server fails to parse the provided value or does not
>>       consider the resource server acceptable, it MUST reject the
>>       request and provide an error response with the error code
>>       "invalid_resource".
>>
>> If the resource parameter is not an absolute URI, i.e. parsing of the
>> value fails, wouldn't the existing general "invalid_request" error code be
>> more appropriate?
>>
>> https://tools.ietf.org/html/rfc6749#section-4.1.2.1
>>
>>          invalid_request
>>                The request is missing a required parameter, includes an
>>                invalid parameter value, includes a parameter more than
>>                once, or is otherwise malformed.
>>
>> Vladimir
>>
>> On 04/08/18 06:39, [email-masked] wrote:
>>
>>
>> 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           : Resource Indicators for OAuth 2.0
>>         Authors         : Brian Campbell
>>                           John Bradley
>>                           Hannes Tschofenig
>> 	Filename        : draft-ietf-oauth-resource-indicators-00.txt
>> 	Pages           : 8
>> 	Date            : 2018-08-03
>>
>> Abstract:
>>    This straw-man specification defines an extension to The OAuth 2.0
>>    Authorization Framework that enables the client and authorization
>>    server to more explicitly to communicate about the protected
>>    resource(s) to be accessed.
>>
>>
>> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/
>>
>> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-00
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 5 Sep 2018 16:10:18 -0600

Thanks for the review, George. I'll add some more color to the text around
the RFC 6749 references/links so one can know what they are without having
to follow the reference (or have RFC 6749 memorized :)).  And adding some
more guidance/discussion about the interplay of scope and resource is
already on my todo list for the next revision based on feedback/requests
from several other folks. The content of the draft is long overdue for some
updates but I just haven't had the chance to do the work yet. I don't think
there's anything that precludes using a logical URI for a resource but I
think the text should be focused on the nominal case of the resource
indicating the location of the resource.

On Thu, Aug 30, 2018 at 1:00 PM George Fletcher <[email-masked]> wrote:

> Comments...
>
> I found the following paragraph a little confusing:
>
>    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 <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00#section-4.2.1> of
>    OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>].  An example of an authorization request where
>    the client tells the authorization server that it wants a token for
>    use at "https://rs.example.com/" <https://rs.example.com/> is shown in Figure 1 below.
>
> I don't have RFC 6749 memorized to the level of section numbers:) I would recommend calling out that for the co
>
> I don't have RFC 6749 memorized to the level of section numbers so it took
> a bit to realize you were talking about Implicit and "Hybrid" flows.
> Suggested text addition...
>
>    When an access token will be returned from the authorization
>    endpoint (such as the Implicit flow [Section 4.2.1 <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00#section-4.2.1> of
>    OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>]]), the "resource" parameter is used in the authorization
>    request to the authorization endpoint.  For OAuth flows that only return an
>    access token from the token endpoint, the resource parameter MUST NOT be
>    used in the authorization request. An example of an authorization request where
>    the client tells the authorization server that it wants a token for
>    use at "https://rs.example.com/" <https://rs.example.com/> is shown in Figure 1 below.
>
>
> Or something like that.
>
> Also, should there be some discussion regarding using logical URIs for
> resources rather than requiring a specific physical path? The AS can always
> translate the resource URI to a physical endpoint if necessary.
>
> Finally, should we define more guidance on the separate of scopes and
> resource indicators? For example, for an instant messaging services there
> might be scopes of "sendIM", "readBuddyList", "adminAccount". And then the
> resource indicator might be https://api.im.example.com. Given the client
> is requesting a token with a scope of "sendIM" is it really necessary to
> also specify a resource indicator of "https://api.im.example.com"
> <https://api.im.example.com> as the AS could probably infer that from the
> scope parameter.
>
> Thanks,
> George
>
> On 8/3/18 11:39 PM, [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: Brian Campbell <[email-masked]>
Date: Fri, 7 Sep 2018 13:40:36 -0600

Sorry again for the slow response Vladimir, I've tried to respond inline
below.

On Sat, Sep 1, 2018 at 2:47 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> with one or more values which don't match the "resource(s)" (or vice versa)
> - how should the AS respond in that case?
>
As I mentioned before, Token Exchange has (and registers) a similar
parameter and error code and I need to reconcile the wording and naming in
the resource indicators draft to better align with that because it's
ultimately the same parameter with just a more generalized usage in this
draft. In particular the error code there is "invalid_target" and I think
that it would be appropriate for issues with the resource parameter as well
as for problematic combinations of resource and scope. And the
"error_description" is always available to provide a more human meaningful
explanation of the problem.

> Mappings could be especially useful for clients to figure out which scopes
> belong to which resource, and prevent "invalid_resource" errors.
>
There was quite a bit of discussion around this kind of thing when the
draft was introduced and the general consensuses was not to have AS
metadata about resources. There are ASs that don't know all the resources
or can't know or don't want to have to know. And more generally it just
doesn't scale well.

> Similarly, allowed "resources" in OAuth client metadata?
 The client metadata side hasn't really been discussed as far as I know.
But my inclination would similarly be to not define any new metadata.

> About the statement
>
>    Scope, from Section 3.3 <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00#section-3.3> of OAuth 2.0 [RFC6749 <https://tools.ietf.org/html/rfc6749>], sometimes is
> The rationale for the resource indicators spec (for new adopters) appears
> to rest on that statement. But what is the actual argument against
> overloading scopes, i.e. including the resource URL in the scope value ;)
>
> Readers of the spec will likely be pondering whether it's better to encode
> the resource URL / identifier in the scope, or use the separate "resource"
> parameter approach. I think we can greatly help them with a honest
> discussion of the pros & cons of the two approaches. And perhaps suggest
> how to migrate between the two.
>
I can look to expand the discussion some. But I'm honestly not sure what
else to say or is appropriate to say. It's a complex and somewhat loaded
topic. It's not exactly related but makes me think of this recent blog from
Vittorio about scopes
<https://auth0.com/blog/on-the-nature-of-oauth2-scopes/>. Anyway, if you
have some concrete suggestions here, please share them.

> Yeah, that text was written before the MTLS draft existed and should be
updated to more accurately reflect the current situation and options.
Thanks for pointing that one out.