Re: [OAUTH-WG] semantics of scope parameter

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

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Sunday, June 27, 2010 11:10 PM
> To: Dick Hardt; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] semantics of scope parameter
> 
> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Dick Hardt
> > Sent: Sunday, June 27, 2010 10:49 PM
> > To: OAuth WG (oauth@ietf.org)
> > Subject: [OAUTH-WG] semantics of scope parameter
> >
> > 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
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth