Re: [OAUTH-WG] Issue: Scope parameter

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
>