Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt

From: [email-masked]
Date: Fri, 03 Aug 2018 20:39:08 -0700

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-00
https://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/

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 5 Aug 2018 15:12:25 +0200

Hi Brian,

here are my text proposals (and a comments):

- Section 2, resource parameter definition 

„It MUST be an absolute URI, as specified by Section 4.3 of[RFC3986],
      and MUST NOT include a query or fragment component.“

Why does the draft preclude query components? 

- I would propose to add the following text at the end of Section 2 (before the last paragraph):

"The authorization server SHOULD adapt the scope value associated 
with an access token to the value the respective resource(s) is 
able to process and needs to know. This further improves privacy as
scope values give an indication of what services the resource owner
uses and it improves security as scope values may contain confidential
data. The authorization server MUST indicate the access token’s 
effective scope to the client in the „scope" response value.

The authorization server MUST ensure the client is able to obtain other sub sets of 
the underlying grant or the whole scope in subsequent transactions. In case of 
a confidential client, the authorization server might associate the grant with 
its client_id. In case of a public client, a refresh token could be used to represent
the grant."

I think it would make sense to establish the link to William‘s draft, as I see
common patterns re grant handling.

- I’m proposing to add the following text re resource indicators and the code response type (potentially in a new section).

„The authorization server MAY require clients to specify the resource(s) they intend to 
access in requests to the authorization endpoint with response type „code". The 
authorization server might use this data to inform the user about the resources
the client is going to access on her behalf, to meet policy decision (e.g. refuse the 
request due to unknown resources), and determine the set of 
resources that can be used in subsequent access token requests.“

kind regards,
Torsten. 

> Am 04.08.2018 um 05:39 schrieb [email-masked]:
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Aug 2018 11:56:32 -0600

Hi Torsten and thanks for the comments and suggestions.

Generally I think I follow the reasoning behind the the suggestions and
believe it all makes sense. I'll endeavor to incorporate the text and/or
the sentiment behind the text into the next revision of the draft.

On Sun, Aug 5, 2018 at 7:12 AM Torsten Lodderstedt <[email-masked]>
wrote:

> - I’m proposing to add the following text re resource indicators and the
> code response type (potentially in a new section).
>

-- 
_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: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 22 Aug 2018 22:23:42 +0300

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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 27 Aug 2018 15:27:57 -0600

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:

> value fails, wouldn't the existing general "invalid_request" error code be
> more appropriate?
>
> 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
>
>
> 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
>
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 30 Aug 2018 15:00:15 -0400

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 inSection 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/" 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/" 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" as the AS could probably infer that from 
the scope parameter.

Thanks,
George