Re: [OAUTH-WG] Issue: Scope parameter

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

On 2010-04-18, at 6:38 PM, David Recordon wrote:

> I think we need to add a bit more definition to the scope parameter.
> Maybe as simple as a comma-separated list of strings.
> 
> 
> On Sun, Apr 18, 2010 at 6:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>> 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 <eran@hueniverse.com>
>> wrote:
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> 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
>> 
>> 