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 <gffle...@aol.com> 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, internet-dra...@ietf.org 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 > > > > -- _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
