Re: [OAUTH-WG] Issue: Scope parameter

[Evan Gilbert <[e-mail]>]

On Mon, Apr 19, 2010 at 8:14 AM, Eran Hammer-Lahav <[e-mail]>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:[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
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>