On Mon, Apr 19, 2010 at 8:14 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> Where does it say you cannot add a parameter named scope? To suggest that > you can’t use the specification because it doesn’t define a placeholder for > something called ‘scope’ is ridiculous. > > > > Simpler client interface is a valid argument, but so is striving for actual > interop. Almost every single company is going to add a custom parameter to > their implementation. Are you suggesting that if we define ‘scope’ we will > significantly reduce the need to define **any** vendor-specific > parameters? Because if not, libraries will still need to pass custom > parameters as key-value pairs in their interface. > > > > So far no one has made an argument why this parameter **has** to be > defined as a server-specific value! What breaks if we define it as a > comma-separated list of URIs or realms (the server will need to use realm > values it can distinguish from resource URIs in case it uses URIs for realm > values, which is trivial to do)? Please explain to me how this proposal > doesn’t work for you. > > > > When the group discussed signatures you demanded we start with use cases. > So let’s do that now. How do people plan to use this parameter? What are you > going to include as scope? What’s the internal encoding/structure you are > going to use? > > > > The burden is on **you** to explain why a parameter in an interop > specification MUST be left vendor specific, or why we can’t figure it out * > *now**. > We all want to move towards a common syntax for scopes, but I don't think we will be able to generalize this on day one. Even if we agreed on a common syntax we all are aiming for, we would need to support existing vendor scopes until we get there. Google today uses a list of URLs for scope definition, and we want OAuth to support this even if we decide to move towards something better. Standardizing only on a parameter name may seem to be low-value, but it both provides some consistency and also a clear placeholder for where to put a parameter to ask for access to a specific resource / set of scopes. Think that people feel strongly about keeping this in because the spec feels incomplete if it doesn't have some way to ask for specific resources - I'd much rather have custom parameter values than custom parameter names. > > > EHL > > > > > > > > *From:* Anthony Nadalin [mailto:tony...@microsoft.com] > *Sent:* Monday, April 19, 2010 5:53 AM > *To:* Eran Hammer-Lahav; Dick Hardt > *Cc:* OAuth WG > *Subject:* RE: [OAUTH-WG] Issue: Scope parameter > > > > > I’m strongly opposed to writing a spec that must be profiled in order to > be implemented and the proposed definition of the scope parameter mandates > profiling the spec. > > > > I’m strongly opposed to having a specification that can’t be used because > it’s so restrictive > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Eran Hammer-Lahav > *Sent:* Sunday, April 18, 2010 11:03 PM > *To:* Dick Hardt > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Issue: Scope parameter > > > > I’m strongly opposed to writing a spec that must be profiled in order to be > implemented and the proposed definition of the scope parameter mandates > profiling the spec. > > > > If it has a structure – what is it? If it is an opaque string, where does > the client get it from? You cannot have interop if the protocol requires > reading paperwork. There is a difference between reusing code (which is what > your argument is about) than interop. > > > > The fact it is easier to pass a named parameter than a list of key-value > pairs is just not a good enough reason. I can live with a parameter with an > opaque value, but it needs to be better defined than ‘scope’. > > > > I have seen services with both scope and permission parameters. What’s the > guidance to these services? Drop permissions and encode it into the scope? > Define it as server-specific? Toss a coin? How about also putting the > desired username into scope instead of another parameter? > > > > How about we add ‘custom1’, ‘custom2’, and ‘custom3’ parameters to make it > easier for servers to use generic libraries with their own extensions? I’m > sure we can find a few more generally useful words to throw in there. > > > > --- > > > > Interop is accomplished when a standard authentication protocol is used > together with a standard API protocol. For example, Portable Contacts uses > OAuth with a standard API and schema to achieve transparent interop. Clients > don’t need to know anything specific about the server to request an address > book record if they know where the Poco endpoint is, and can speak OAuth to > get permission to private data. > > > > If we define a scope parameter, Poco will stop working unless Poco defines > how to use the scope parameter when asking for a token capable of accessing > Poco resources. But it cannot do it without breaking existing services with > their completely incompatible definition and format for scope. > > > > On the other hand, if we defined a basic way to use scope, Poco will be > able to use that in a consistent way across services and work in the same > automagical way. > > > > I am not arguing against having a scope parameter. I think we should and > have enough implementation experience to do it now (we didn’t 3 years ago). > I am arguing that the current proposal is ignoring the responsibility we > have to improve interop. If people want scope they need to do a better job > defining what it is. > > > > From anything I heard so far on this list, a comma-separated list of URIs > or realms would work. > > > > --- > > > > My service requires: > > > > Resources – list of resource URIs or realms > > Permission – read / change / add / delete > > Duration – access token lifetime > > > > Reading the definition of the scope parameter I don’t know how to map my > requirements to it. Am I expected to invent an encoding scheme to get all > this information into the scope parameter? It seem that **every** server > developer will need to invent such a scheme. > > > > Using your exact argument, I can also request that we add a ‘permission’ > and ‘duration’ parameters, equally undefined, because it is easier for my > developers to have the library pass these. > > > > EHL > > > > > > > > *From:* Dick Hardt [mailto:dick.ha...@gmail.com] > *Sent:* Sunday, April 18, 2010 10:28 PM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Issue: Scope parameter > > > > > > > > On 2010-04-18, at 9:56 PM, Eran Hammer-Lahav wrote: > > > > The client_id parameter is not expected to have an internal structure known > to clients. > > > > The client developer needs to understand it. > > > > The likelihood of a client library treating this value as anything other > than an opaque string is practically zero. client_id is well defined, > especially when it comes to how clients are expected to interact with it. I > have not seen a single implementation or requirement to put client-aware > meaning into the client_id parameter value. It is an opaque, server-issued > string. > > > > > > What about the format parameter that specifies that assertion? > > > > > > > > The proposed scope parameter is expected to always have an internal > structure and clients are expected to read some documentation explaining how > to use it. The likelihood of a client library to implement one such > structure based on the first service it is used for is not insignificant. > And once one popular service use it in one way, others are likely to do the > same to make their developers life easier. So why leave this up to the first > popular service to decide. > > > > This does not make sense. Services are already defining scope parameters, > libraries are adding them in. > > The client library should treat the scope parameter as a string just like > all the other strings that are passed around. Given that a number of popular > services have a scope like parameter now, I don't know of a situation where > a library developer has done what you fear. > > > > > > Libraries are expected to pass up and down **any** parameter, regardless > of its status as a core protocol parameter or not. A library that doesn’t is > broken. If they do that, defining a scope parameter adds absolutely nothing. > For example, we can add a language parameter which will be used by the > client to request a specific UI language experience but leave the value to > be server specific. Clearly this is useless without defining how the > parameter shall be used. From an interop and spec perspective, how is scope > different? > > > > It is much simpler for the library to have an interface where you specify > specific values than hand in an arbitrary set of name value pairs. > > > > > > The current proposal is to pick an ambiguous term and add it as a parameter > with no clear meaning, purpose, or structure. I don’t know what scope means. > > Does it include permissions? The desired access lifetime? The ability to > share the tokens with other providers? Different HTTP methods? All the > examples I have seen treat it as a list of resources either directly (list > of URIs) or indirectly (list of sets or service types). > > > > It could be any of those things. The scope of access that the client is > asking for. > > > > > > How about we also add a ‘redelegation’, ‘duration’, ‘permission’, > ‘methods’, and a few more and leave them all server specific? According to > the proposal logic, why not? > > > > Those would all be included under scope. > > > > Many implementors are saying they want the scope parameter. Are there > implementors / deployers that don't want it? You seem to have a strong > opinion on this point that is based on a potential interop fear you have > that is contrary to many implementors. > > > > -- Dick > > _______________________________________________ > 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
