Subject: [OAUTH-WG] semantics of scope parameter

From: Dick Hardt <[email-masked]>
Date: Sun, 27 Jun 2010 22:48:38 -0700

The current spec defines scope (when the scope variable is introduced) as:

   scope
         OPTIONAL.  The scope of the access request expressed as a list
         of space-delimited strings.  The value of the "scope" parameter
         is defined by the authorization server.  If the value contains
         multiple space-delimited strings, their order does not matter,
         and each string adds an additional access range to the
         requested scope.

I think the last phrase is adding semantics that may not be true, and that the following is more accurate:

   scope
         OPTIONAL.  The scope of the access request expressed as a list
         of space-delimited strings.  The value of the "scope" parameter
         is defined by the authorization server.  If the value contains
         multiple space-delimited strings, their order does not matter.

A authorization server may define some scope parameters that add restrictions to the access rather than are additive. For example, scope could be defined by an AS as one or more resources (PHOTOS PROFILE FRIENDS) and the type of access (READ WRITE READWRITE) 

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 27 Jun 2010 23:10:29 -0700

First, there is nothing preventing the server from using:

scope=photos:read profile:read friends:read

or:

scope=photos:read profile:readwrite friends:write

---

I think the current language strikes the right balance between interop and scopes definitions. While a generic client will not understand the meaning of each scope, it will be able to tell that "x y" is the same as "y x", that "x y" includes both "x" and "y", and that if it asked for "x y" and was told it needs "y z", it can ask for "x y z" and use it as a replacement of the "z y" token.

Being able to manipulate scope values is essential to accomplish interop. Without that, there is little value in defining any internal structure, and if that is the case, I still maintain that there is no value in defining the entire parameter. The current language is a workable compromise that helps libraries and developers, and does not restrict service providers from defining their own scope syntax (as long as they don't use spaces to mean something else).

For example:

scope=photos,profile,friends,readwrite

is perfectly valid, but treated by a generic client as one opaque scope.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dick Hardt
> Sent: Sunday, June 27, 2010 10:49 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] semantics of scope parameter
> 
> A authorization server may define some scope parameters that add
> restrictions to the access rather than are additive. For example, scope could
> be defined by an AS as one or more resources (PHOTOS PROFILE FRIENDS)
> and the type of access (READ WRITE READWRITE)
> 
> -- Dick
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 27 Jun 2010 23:11:39 -0700

Another way to think about it is that the current text reserves the space character to mean something specific but doesn't prevent service providers from using any other delimiter as they see fit.

EHL

> Of Eran Hammer-Lahav
> Sent: Sunday, June 27, 2010 11:10 PM
> To: Dick Hardt; OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] semantics of scope parameter
> 
> I think the current language strikes the right balance between interop and
> scopes definitions. While a generic client will not understand the meaning of
> each scope, it will be able to tell that "x y" is the same as "y x", that "x y"
> includes both "x" and "y", and that if it asked for "x y" and was told it needs
> "y z", it can ask for "x y z" and use it as a replacement of the "z y" token.
> 
> Being able to manipulate scope values is essential to accomplish interop.
> Without that, there is little value in defining any internal structure, and if that
> is the case, I still maintain that there is no value in defining the entire
> parameter. The current language is a workable compromise that helps
> libraries and developers, and does not restrict service providers from
> defining their own scope syntax (as long as they don't use spaces to mean
> something else).
> 
> For example:
> 
> > restrictions to the access rather than are additive. For example,
> > scope could be defined by an AS as one or more resources (PHOTOS
> > PROFILE FRIENDS) and the type of access (READ WRITE READWRITE)
> >
> > -- Dick
> >