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

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

This suggests we need to rethink our goal of interop and replace it with library re-use.

To me interop means that a client can interact with an unknown server by simply speaking the protocol (the way an email can be delivered to any server). Library re-use means that we define a set of configuration values (client identifier, endpoints, cryptographic algorithms, scope, realm policy, etc.) and once those are manually set (or via a discovery specification that is completely out of scope) to make the library work.

If we are not going to enable a client to access a protected resource hosted by an unfamiliar server, we need to stop pretending this (alone) is about interop. In other words, if we take this approach we are mandating paperwork to make the protocol work, at least based on this single specification. We can also drop advertising the authorization and token endpoints in a 401 or really *any* parameter in a WWW-Authenticate response.

I'm not opposed to that, and it is in line with the charter (which left discovery out).
 
Regardless, I disagree with your conclusion that the scope proposal doesn't accomplish interop. It allows a client to interact with an unknown server, obtain an access token for the required scope, and access it. It doesn't address the trust issue of when to reuse an existing token, but that's going to be a problem with or without a scope. If the client never attempts to reuse a token but always obtain a new access token when encountering an unknown server, it can interop perfectly well. And making scope a list of values allows secure reuse of tokens using same-origin policy (which is still useful even if limited).

OAuth 1.0 doesn't accomplish interop because it is under-specified. I have no problems keeping 2.0 at the same level. I just think it is premature to give up.

EHL

> -----Original Message-----
> From: John Kemp [mailto:[e-mail]]
> Sent: Thursday, April 22, 2010 11:39 AM
> To: Brian Eaton
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
> 
> 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