Re: [OAUTH-WG] Issue: Scope parameter

On 4/19/10 8:51 AM, "Evan Gilbert" <uidude@google.com> wrote:

> 
> 
> On Mon, Apr 19, 2010 at 8:14 AM, Eran Hammer-Lahav <eran@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 Oscope¹ 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 Oscope¹ 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.

Why? I made a simple proposal that is in line with how Google and FB use it
and how others indicated they will use it. Why not spend some time
discussing it instead of just dismissing it with 'we're not ready'. This was
the argument 3 years ago! Isn't 3 years enough time to discuss and solve
this? Surely Google knows what it wants from a scope parameter.

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

What do you call this parameter today in your 1.0 implementation? Why can't
you continue to support this with a g_scope parameter?

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

Only if you reserve it for future use and forbid anyone from using it now.
Once each vendor uses it in their own way, you lose the ability to
standardize this in the future. That's a much bigger problem (changing the
format of a parameter already in wide use).

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

I agree. So lets solve it the right way and stop being lazy about it.

I'll post my proposal in a follow up message.

EHL

>>  
>> EHL
>>  
>>  
>>  
>> 
>> From: Anthony Nadalin [mailto:tonynad@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-bounces@ietf.org [mailto:oauth-bounces@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 Oscope¹.
>>  
>> 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 Ocustom1¹, Ocustom2¹, and Ocustom3¹ 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 Opermission¹ and
>> Oduration¹ parameters, equally undefined, because it is easier for my
>> developers to have the library pass these.
>>  
>> EHL
>>  
>>  
>>  
>> 
>> From: Dick Hardt [mailto:dick.hardt@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 Oredelegation¹, Oduration¹, Opermission¹, Omethods¹,
>> 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
>> 
> 
> 