Re: [OAUTH-WG] Issue: Scope parameter

[Marius Scurtescu <[e-mail]>]

On Sun, Apr 18, 2010 at 7:04 PM, David Recordon <[e-mail]> wrote:
> Does anyone have an implementation example where comma separated
> strings wouldn't work for the scope parameter?

Yes, Google currently is using a space separated list of URIs.

Why does the format matter?

Marius

>
>
> On Sun, Apr 18, 2010 at 6:47 PM, Dick Hardt <[e-mail]> wrote:
>> 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 <[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
>>>>
>>>>
>>
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>