Re: [OAUTH-WG] Issue: Scope parameter

[David Recordon <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>