Subject: [OAUTH-WG] Issue: Scope parameter

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:07:19 -0700

WRAP includes a loosely defined scope parameter which allows for
vendor-specific (and non-interoperable) use cases. This was requested by
many working group members to be included in OAuth 2.0 with the argument
that while it doesn't help interop, it makes using clients easier.

The problem with a general purpose scope parameter that is completely
undefined in structure is that it hurts interop more than it helps. It
creates an expectation that values can be used across services, and it
cannot be used without another spec defining its content and structure. Such
as spec can simply define its own parameter.

In addition, it is not clear what belongs in scope (list of resources,
access type, duration of access, right to share data, rights to
re-delegate).

The rules should be that if a parameter cannot be used without another
documentation, it should be defined in that other document.

Proposal: Request proposals for a scope parameter definition that improve
interop. Otherwise, keep the parameter out of the core spec.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 12:20:49 -0700

I still have not seen any arguments why scope structure is needed for
interop. Client and server side libraries do not need to understand
the scope, they just pass it around. Client and server code do need to
understand the scope, but we are not dealing with that.

Yes, a scope parameter does not buy much, it only prevents each authz
server from inventing their own custom parameter.

Marius

On Thu, Apr 15, 2010 at 12:07 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 12:26:24 -0700

Marius, why don't we write a one page spec which defines scope as an
extension? We end up with agreement around if scope is a useful
parameter and a simple parameter name for multiple vendors (because it
is an extension). Since you seem to be advocating for including scope
the most, would you mind trying to write out a few paragraphs?

Thanks,
--David

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:28:15 -0700

Don't they need to pass any other extension parameter around too? What makes this one so special?

EHL

On 4/15/10 12:20 PM, "Marius Scurtescu" <[email-masked]> wrote:

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 12:38:28 -0700

Sure. Do we have a mechanism to define extensions?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:51:02 -0700

1. Write it
2. Comply with naming policy of new parameters*
3. Publish and get feedback.
4. Fix and repeat #3 as needed.
5. Register new parameter name*

:-)

* Pending new parameter name policy

For now just call it 'scope'.

EHL

On 4/15/10 12:38 PM, "Marius Scurtescu" <[email-masked]> wrote:

Marius

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 13:00:15 -0700

Even put it on the wiki (http://wiki.oauth.net/) if you don't want to
deal with IETF formatting yet. Eran and I are happy to clean stuff up.
:)

On Thu, Apr 15, 2010 at 12:51 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> For now just call it ‘scope’.
>
> EHL
>
>

---

From: Justin Smith <[email-masked]>
Date: Thu, 15 Apr 2010 23:39:10 +0000

I don't see how the presence of a scope parameter hurts interoperability.

It think scope needs to be a 1st class citizen in the spec, not an extension. Without it, a client cannot request access to a specific set of resources (whether its represented as a string, URI, or anything else). Does the group think it Is important for an Authorization Server to be able to make auth decisions based on requested resources?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, April 15, 2010 12:51 PM
To: Marius Scurtescu; [email-masked]
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

1. Write it

:-)

EHL

Marius

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Apr 2010 11:40:18 +1000

> I don’t see how the presence of a scope parameter hurts interoperability.

Scopes so far have all been specific to a specific service. Knowing how Google uses ‘scope’ tells you nothing about interoperating with Microsoft.

Requesting access to specific sets of resources is important. However, you can do it by providing different user-authorization URIs — even if the URIs only differ in the value of a ‘scope’ query parameter.

For a library that isn’t service-specific, a scope value offers no semantic value. All the library can do is tack it onto a supplied user authz URI. In which case it is simpler for the library to just accept a user authz URI that has had the scope tacked on before being passed to the library.

--

James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Smith
Sent: Friday, 16 April 2010 9:39 AM
To: Eran Hammer-Lahav; Marius Scurtescu; [email-masked]
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

I don’t see how the presence of a scope parameter hurts interoperability.

---

From: Justin Smith <[email-masked]>
Date: Fri, 16 Apr 2010 03:49:18 +0000

I get the point, but I’ll set that aside for a moment.

Is it important for an Authorization Server to be able to protect multiple resources? If so, how should the client specify which resource it intends to access (it seems like that is required)?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, April 15, 2010 6:40 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Apr 2010 14:08:59 +1000

> Is it important for an Authorization Server to be able to protect multiple resources?

YES

>  If so, how should the client specify which resource it intends to access (it seems like that is required)?

By redirecting the user to an authz URI that represents the intended resource.

If the client is interoperating with a resource it has no special knowledge about, then it can learn the authz URI from the 401 WWW-Auth.: OAUTH header it received when trying to access the resource directly. The server returning this header knows what resource the client asked for so the server can encode that information into the returned authz URI in whatever way it has prearranged with its AS.

--

James Manger

 

-- 

James Manger

---

From: Justin Smith <[email-masked]>
Date: Fri, 16 Apr 2010 04:31:05 +0000

Great.

So, let’s say there is an Authorization Server available at http://as.com and it protects the http://foo.com and http://bar.com resources.

A client requests  http://foo.com. The foo.com server responds with a WWW-Auth that contains the http://as.com URI. The client then sends an access token request to http://as.com. Is that right?

If so, then how does http://as.com know that the intended resource is http://foo.com?

From: Manger, James H [mailto:[email-masked]]
Sent: Thursday, April 15, 2010 9:09 PM
To: Justin Smith; OAuth WG
Subject: RE: [OAUTH-WG] Issue: Scope parameter

YES

--
James Manger

--
James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 21:41:38 -0700

On Thu, Apr 15, 2010 at 9:31 PM, Justin Smith <[email-masked]> wrote:
> Great.
>
>
>
> So, let’s say there is an Authorization Server available at http://as.com
> and it protects the http://foo.com and http://bar.com resources.
>
>
>
> A client requests  http://foo.com. The foo.com server responds with a
> WWW-Auth that contains the http://as.com URI. The client then sends an
> access token request to http://as.com. Is that right?

I think James is suggesting that WWW-Auth will contain something like
http://as.com?scope=foo.com

If that's the case, the scope is basically a custom parameter.

Also, this assumes that protected resources are simple URLs that can
be fetched. In many cases the protected resource is some API and this
API will require specific scopes depending on the context (actual
user, operation, etc). So a 401 may not be able to specify exactly
what scope is needed. The client programmer will have to understand
the API and provide proper scopes.

Marius

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Apr 2010 14:43:48 +1000

> If so, then how does http://as.com know that the intended resource is http://foo.com?

Foo.com should point the client at, say, http://as.com/foo/ or http://foo.as.com/ or http://as.com/?scope=foo or http://as.com/?encrypted_resource_id=273648264287642 or whatever it has agreed to with its AS.

The WWW-Auth response from foo.com should not be just http://as.com.

Foo is much better placed to know it shares as.com with Bar than a client is.

--

James Manger

---

From: Mark Mcgloin <[email-masked]>
Date: Fri, 16 Apr 2010 14:33:33 +0100

I know we will control scope server side based on the calling client

 I can see why others may want to have a scope parameter though to allow a
client app to decrease the scope they request (assuming short duration
access), e.g. client app is entitled to request contacts and files based on
their client identifier but they only request contacts for some operation,
and the user feels more secure. Is this the main reason for scope?

James, how does your proposal work if the client needs access to more than
one set of resources?

Mark McGloin

             "Manger, James H"                                             
             <James.H.Manger@t                                             
             eam.telstra.com>                                              
             Sent by:                                                      
             oauth-bounces@iet                                             
             f.org                                                         

             16/04/2010 05:43                                              

      > So, let’s say there is an Authorization Server available at
      http://as.com and it protects the http://foo.com and http://bar.com
      resources.

      > A client requests  http://foo.com. The foo.com server responds with
      a WWW-Auth that contains the http://as.com URI. The client then sends
      an access token request to http://as.com. Is that right?

      > If so, then how does http://as.com know that the intended resource
      is http://foo.com?

Foo.com should point the client at, say, http://as.com/foo/ or
http://foo.as.com/ or http://as.com/?scope=foo or
http://as.com/?encrypted_resource_id=273648264287642 or whatever it has
agreed to with its AS.
The WWW-Auth response from foo.com should not be just http://as.com.
Foo is much better placed to know it shares as.com with Bar than a client
is.

--
James Manger_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Apr 2010 23:54:29 +1000

Mark,

> James, how does your proposal work if the client needs access
> to more than one set of resources?

I think a client app will need service-specific knowledge to realise it needs access to more than one set of resources (ie the app needs to know how the service divides resources into sets). That service-specific knowledge may as well include the service-specific authz URIs for requesting access to multiple sets of resources. http://as.com/foo,bar/, for instance.

If a client with a token for one scope tries to accesses a resource in a second scope, the 401 response could include an authz URI indicating both scopes.

-- 
James Manger

---

From: Justin Smith <[email-masked]>
Date: Fri, 16 Apr 2010 15:25:10 +0000

It isn’t clear to me how those options are better for interop than a scope parameter in the token request.

Also, the proposal forces the protected resource to know the context of the request and respond with the appropriate URI. This simply won’t work in many situations. For example, let’s say foo.com and bar.com may be bundled and available individualy. A client might need one access token that grants permission to both resources, another client might only get an access token that grants permission to one resource. With the proposal below, foo.com can’t respond with the correct value in the 401 (should the URI reference the individual service or the bundle).

From: Manger, James H [mailto:[email-masked]]
Sent: Thursday, April 15, 2010 9:44 PM
To: Justin Smith; OAuth WG
Subject: RE: [OAUTH-WG] Issue: Scope parameter

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 08:51:12 -0700

You are make my point. A scope parameter is useless without another vendor-specific spec in which case the vendor spec can define its own scope parameter. The argument of library support doesn't hold because libraries must pass any extension parameter anyway.

If people still want a scope parameter, they must define it in a way that it doesn't require vendor-specific knowledge. I am not sure this is possible or that useful.

EHL

On 4/16/10 8:25 AM, "Justin Smith" <[email-masked]> wrote:

It isn't clear to me how those options are better for interop than a scope parameter in the token request.

Also, the proposal forces the protected resource to know the context of the request and respond with the appropriate URI. This simply won't work in many situations. For example, let's say foo.com and bar.com may be bundled and available individualy. A client might need one access token that grants permission to both resources, another client might only get an access token that grants permission to one resource. With the proposal below, foo.com can't respond with the correct value in the 401 (should the URI reference the individual service or the bundle).

> So, let's say there is an Authorization Server available at http://as.com and it protects the http://foo.com and http://bar.com resources.

--
James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Apr 2010 10:48:04 +0200

in a recent discussion, another proposal was to use the realm attribute 
of the WWW-Authenticate header to indicate the scope

So in your example the header would include two attributes
authz-uri=http://as.com
realm=foo

What do you think?

regards,
Torsten.

Am 16.04.2010 06:43, schrieb Manger, James H:
> http://as.com/?encrypted_resource_id=273648264287642 or whatever it 
> has agreed to with its AS.
>

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 22:30:26 +1000

> What do you think?

I can’t see any benefit in making the client app combine the realm and authz-uri, over the server just returning an authz-uri with that information already included (in whatever concise form it wants).

Matching realm values allows a client to recognize when the same credential (eg token) can be used. This might preclude realm values differing between Foo and Bar services that can accept the same tokens.

--

James Manger

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Saturday, 17 April 2010 6:48 PM
To: Manger, James H
Cc: Justin Smith; OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

in a recent discussion, another proposal was to use the realm attribute of the WWW-Authenticate header to indicate the scope

What do you think?

regards,
Torsten.

--

James Manger

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Apr 2010 14:38:48 +0200

Am 17.04.2010 14:30, schrieb Manger, James H:
>
> > authz-uri=http://as.com
> > realm=foo
> >
> > What do you think?
>
> I can’t see any benefit in making the client app combine the realm and 
> authz-uri, over the server just returning an authz-uri with that 
> information already included (in whatever concise form it wants).
>
> Matching realm values allows a client to recognize when the same 
> credential (eg token) can be used. This might preclude realm values 
> differing between Foo and Bar services that can accept the same tokens.
>

How shall the client recognize if the same token can be used for Foo and 
Bar? Realm would be an option-

regards,
Torsten.
>
> -- 
>
> James Manger
>
> *From:* Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Saturday, 17 April 2010 6:48 PM
> *To:* Manger, James H
> *Cc:* Justin Smith; OAuth WG
> *Subject:* Re: [OAUTH-WG] Issue: Scope parameter
>
> in a recent discussion, another proposal was to use the realm 
> attribute of the WWW-Authenticate header to indicate the scope
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 18:12:29 -0700

The scope parameter was included in WRAP at the request of library and AS
implementors to standardize a commonly included parameters.

The client_id parameter seems similar to the scope parameter. The meaning of
client_id is not defined in the spec and is AS specific. A client_id that a
developer uses with one AS may be different at a different AS.

The argument that defining the scope parameter will cause more confusion is
confusing itself. Why would a developer think they can use the same scope at
two different AS? The developer has to manage different client_ids,
different endpoint URIs and different PRs: not to mention different APIs.
Having a different scope between AS seems natural. Having a vendor defined
parameter name for different AS that all mean scope seems suboptimal.

A related example. Email has a subject parameter, we all have a similar idea
what it means, and it can be used differently in different situations, but
it was useful to create the placeholder for the optional subject of an email
message.

Proposal: put optional scope parameter back into all calls to obtain an
access token. Put optional scope parameter into calls to refresh an access
token.

-- Dick

---

From: David Recordon <[email-masked]>
Date: Sun, 18 Apr 2010 18:38:21 -0700

I think we need to add a bit more definition to the scope parameter.
Maybe as simple as a comma-separated list of strings.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 18:47:15 -0700

I would leave that to be AS defined -- different delimiters make sense in different environments -- it could be an expression -- just make it a string -- it will need to be URL encoded which will deal with any magic characters.

-- Diok

---

From: David Recordon <[email-masked]>
Date: Sun, 18 Apr 2010 19:04:39 -0700

Does anyone have an implementation example where comma separated
strings wouldn't work for the scope parameter?

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 18 Apr 2010 21:12:28 -0700

> strings wouldn't work for the scope parameter?

Yes, Google currently is using a space separated list of URIs.

Why does the format matter?

Marius

---

From: Luke Shepard <[email-masked]>
Date: Sun, 18 Apr 2010 21:35:16 -0700

> Why does the format matter?

I agree. Facebook uses comma-separate strings, Google uses space-separated URLs- why is this a problem?

It seems we have three options:

1/ We leave the scope parameter as an Auth Server-specific, opaque parameter.
2/ We all agree on a format and spec for the scope parameter.
3/ We drop the scope parameter and make each server define their own, non-standard scope param.

I think David proposed #2 as a way to address concerns on this list that #1 would be a hindrance to interop. But I personally vote for #1 now - we would add a spec later if it proves to be a problem.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Apr 2010 21:56:18 -0700

The client_id parameter is not expected to have an internal structure known to clients. 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.

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.

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?

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

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?

EHL

From: Dick Hardt [mailto:[email-masked]]
Sent: Sunday, April 18, 2010 6:12 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

The scope parameter was included in WRAP at the request of library and AS implementors to standardize a commonly included parameters.

The client_id parameter seems similar to the scope parameter. The meaning of client_id is not defined in the spec and is AS specific. A client_id that a developer uses with one AS may be different at a different AS.

The argument that defining the scope parameter will cause more confusion is confusing itself. Why would a developer think they can use the same scope at two different AS? The developer has to manage different client_ids, different endpoint URIs and different PRs: not to mention different APIs. Having a different scope between AS seems natural. Having a vendor defined parameter name for different AS that all mean scope seems suboptimal.

A related example. Email has a subject parameter, we all have a similar idea what it means, and it can be used differently in different situations, but it was useful to create the placeholder for the optional subject of an email message.

Proposal: put optional scope parameter back into all calls to obtain an access token. Put optional scope parameter into calls to refresh an access token.

-- Dick
On Thu, Apr 15, 2010 at 12:07 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:

EHL

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 22:25:40 -0700

+1 to #1

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 22:27:35 -0700

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 imp…

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Apr 2010 23:02:34 -0700

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:[email-masked]]
Sent: Sunday, April 18, 2010 10:28 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

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

-- Dick

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 19 Apr 2010 12:53:17 +0000

> 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: [email-masked] [mailto:[email-masked]] 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

---

---

My service requires:

EHL

-- Dick

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 19 Apr 2010 15:03:38 +0200

+1 to #1 (as starting point)

In my opinion, the WG should try to work towards #2. Would it be  
possible to first collect what kind of "scope" implementations use  
today and what ideas exists?

Based on our experiences with implementing OAuth 1.0a at Deutsche  
Telekom, I see the following aspects:

- resource: specification of the protected resource to be accessed. An  
example could be: "http://www.example.de/photos/" or just "photos".

This is a more conceptual view that can be understood by users  
(relevant for user consent), whereas the service id is a more  
technical view.

- service id: identifier of a web service exposing certain functions  
to access/manipulate resources on a particular channel using a  
particular technology (Rest, SOAP, ...).
Examples could be: "photos-rest-proxy-iptv", "photos-soap-intf-mobile".

Different services may need different user data, thus content of  
self-contained tokens typically varies between service id's.

- permissions:  permissions on resources or services the client wants  
to get authorized by the user (comma-separated list of opaque  
strings). The range of permissions is defined by the resource/service  
as part of its API design. This could be something like "upload",  
"download", "sent", or "establish connection".

- duration: specification of the token duration the client asks for

- device: the device the OAuth clients resides on. This allows to have  
different tokens for the same client (application) on different  
devices and is intended to reduce the impact of token theft. The token  
is bound to a particular device during user authz flow and usage of  
the token is restricted to that device only (typically mobile/smart  
phones, but also set top boxes, tv sets, gaming consoles).

regards,
Torsten.

Zitat von Luke Shepard <[email-masked]>:

> I agree. Facebook uses comma-separate strings, Google uses  
> space-separated URLs- why is this a problem?
>
> I think David proposed #2 as a way to address concerns on this list  
> that #1 would be a hindrance to interop. But I personally vote for  
> #1 now - we would add a spec later if it proves to be a problem.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 08:14:47 -0700

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:[email-masked]]
Sent: Monday, April 19, 2010 5:53 AM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Issue: Scope parameter

---

---

My service requires:

EHL

-- Dick

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 19 Apr 2010 08:51:09 -0700

On Mon, Apr 19, 2010 at 8:14 AM, Eran Hammer-Lahav <[email-masked]>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:[email-masked]]
> *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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Eran Hammer-Lahav
> *Sent:* Sunday, April 18, 2010 11:03 PM
> *To:* Dick Hardt
> *Cc:* OAuth WG
> 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.
>
>
>
> 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:[email-masked]]
> *Sent:* Sunday, April 18, 2010 10:28 PM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> 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.
>
>
>
>
>
> 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.
>
>
>
> 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).
>
>
>
> 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?
>
>
>
> 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
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Apr 2010 11:54:15 -0400

+1 to the "Device" idea. About a year ago I brought up the idea of
having an instance identifier as an OAuth extension, but that never got
traction and I dropped the thread.

 -- justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 09:18:29 -0700

On 4/19/10 8:51 AM, "Evan Gilbert" <[email-masked]> 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.
>>  
>> 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*.

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.

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

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

> 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

>>> I¹m strongly opposed to writing a spec that must be profiled in order to be
>> I¹m strongly opposed to having a specification that can¹t be used because
>> it¹s so restrictive
>>  
>> 
>> I¹m strongly opposed to writing a spec that must be profiled in order to be
>> 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.
>>  
>> opaque value, but it needs to be better defined than Oscope¹.
>>  
>> I have seen services with both scope and permission parameters. What¹s the
>> 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
>> don¹t need to know anything specific about the server to request an address
>> 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.
>>  
>> 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
>> this information into the scope parameter? It seem that *every* server
>> Using your exact argument, I can also request that we add a Opermission¹ and
>> Oduration¹ parameters, equally undefined, because it is easier for my
>> 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.
>> 
>>  
>> 
>>  
>> 
>> 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.
>> 
>>  
>> 
>> 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?
>> 
>>  
>> 
>> with no clear meaning, purpose, or structure. I don¹t know what scope means.
>>> 
>> 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?
>> 
>>  
>> 
>> opinion on this point that is based on a potential interop fear you have that
>> is contrary to many implementors.
>> 
>>  
>> 
>> -- Dick
>>