On Thu, Apr 1, 2010 at 12:23 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > On 4/1/10 11:06 AM, "Justin Smith" <justi...@microsoft.com> wrote: >> General comment on the flows: >> Comment 2: The scope parameter (from WRAP) is missing from all of the flows. >> How does the client indicate which protected resource it intends to access? >> In >> WRAP this was an optional parameter, but it seems important when a single AS >> controls access to many resources. > > I removed it (for now) because it was (way way) under specified. The only > reason for a spec is interop. This parameter hurts interop because it forces > library to implement something they cannot understand, or understand based > on one deployment. > > This debate has been going on for a long time and solving it by simply > adding a placeholder for scope without *any* structure or definition is not > how well designed protocols are written. > > I have always maintained that OAuth needs a basic facility to negotiate > scope. It can be as simple as an opaque string identifying a set of > resources (e.g. HTTP auth realms), a JSON string of key/value pairs, etc. > But as present in WRAP and imported by David it is utterly useless (it is > and under-specified SHOULD - I am not really sure what it is to be used > for). > > Write a proposal and we can add it back.
Except for trivial cases, the client needs to have custom code to access and process the protected resources. Scopes have meaning only for these resources and while obtaining an access token I think the scope can be treated as an opaque string. There is another issue with removing the scope parameter. In most cases a scope parameter will be needed in practice, if the spec does not specify one then an additional non-standard parameter must be used. But you also dropped the additional parameters. I don't see why an opaque scope parameter would create any problems for a library implementation. Working on such an implementation right now and opaque scopes are perfectly fine. >> Sec. 2.3. Client Credentials: "When requesting access from the authorization >> server, the client identifies itself using its authorization-server-issued >> client credentials." >> Comment 3: This isn't the case when the client is presenting a token issued >> by >> another server. I suggest a change to something like the following: "When >> requesting access from the authorization server, the client identifies itself >> using client credentials known to the authorization server." > > What token? The authorization endpoint isn't an OAuth-protected resource. > >> Sec. 2.4. User Delegation Flows: "Instead, the end user authenticates >> directly with the authorization server, and grants client access to its >> protected resources." >> Comment 4: This is a minor nit, but the AS may not grant access to all of the >> PRs it controls access to. I suggest a change to something like the >> following: >> "... and grants client access to the requested protected resources." > > This isn't the old testament. No need to look for hidden meaning. The spec > is about getting access to protected resources, generally dealing with *a* > protected resource. How resources are segmented is beyond the scope. I think > it is more useful to talk about it using simpler assumptions - it doesn't > prevent the more complex use cases. I think this ties in with the scope parameter. When requesting authorization, if a client can also pass a scope parameter, then access is granted only to the resources that accept that scope and not to all resources controlled by this Authorization Server. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
