Re: [OAUTH-WG] 'Scope' parameter proposal

[John Kemp <[e-mail]>]

Hi Brian,

On Apr 22, 2010, at 1:36 PM, Brian Eaton wrote:

> On Mon, Apr 19, 2010 at 3:17 PM, Eran Hammer-Lahav <[e-mail]> wrote:
>>> The scope doesn't have to match the base URI of the resource which the
>>> client tried and got the 401 from?
>> 
>> That's a security issue we need to address (when to trust the resource server and reuse an existing token). We need to figure it out either way.
> 

[...]

> I'd rather we didn't put stuff in the OAuth 2 spec that we aren't 100%
> sure is going to work.  Ideally there should be lots of examples in
> production.

I agree.

> 
> I do like the idea of defining the scope parameter to be a delimited
> list of otherwise opaque strings.

So what we get in OAuth is simply an agreed parameter name in which to carry a list of opaque strings which might be used in any way imaginable (ie. not documented by the spec, no model in relation to the token) with usage model basically as decided by the various parties at deployment time. 

I'm not really seeing the *interoperability* value of that at all without some more rigorous description of the underlying model (note: I'm not saying we should necessarily make that model, but merely that without any described model, you don't have very much interoperability) 

>  Several service providers have
> already adopted this approach, and it seems to work reasonably well.

I agree that 'scope' is something that many SPs want. If they don't want it roughly the same way though (something more than a "bucket of opaque strings with a standard name") I don't know if I understand the point to standardizing it. 

Even those who write libraries won't get much value since they'll have to provide an extension point to do whatever is needed according to the particular deployment here anyway, and that extension point could already exist without the existence of an already-named parameter for "scope" functionality. 

[...]

- johnk