Re: [OAUTH-WG] Issue: Scope parameter

[Eran Hammer-Lahav <[e-mail]>]

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*.

EHL



From: Anthony Nadalin [mailto:[e-mail]]
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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
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