It's time to decide how we want to treat access token scope in the
specification. Note that this discussion is limited to *requesting* an access
token with a specific scope and does not include how to decide when a token
should be reused against an unfamiliar server (i.e. resource server adverti
+1 on option 3.
Am 30.04.2010 17:43, schrieb Eran Hammer-Lahav:
3. Space-Delimited Scope Parameter Value
Define a 'scope' parameter with value of space-delimited strings (which can
include any character that is not a space - the entire parameter value is
encoded per the transport rules regard
I vote for #3
There are already plenty of implementations that use a scope parameter:
Facebook:
http://developers.facebook.com/docs/authentication/
Google:
http://code.google.com/apis/accounts/docs/OAuth_ref.html#RequestToken
Flickr: (called "perm")
http://www.flickr.com/services/api/auth.spec.
I also vote for #3. I think our field experience has shown that a) lack of a
standard place to stick scope info in access token requests leads to
per-provider inconsistencies that further complicate libraries, b) lots of
providers do want to offer scoped access tokens (and show the list of scopes
b
+1 for #3
Since google implemented I always thought it an elegant simple way of
requesting access.
On Fri, Apr 30, 2010 at 4:52 PM, Joseph Smarr wrote:
> I also vote for #3. I think our field experience has shown that a) lack of a
> standard place to stick scope info in access token requests lea
Piling on: +1 for #3.
--justin
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Pelle
Braendgaard
Sent: Friday, April 30, 2010 2:13 PM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
+1 for #3
Since google
On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt
wrote:
> In my opinion, automatic discovery on scope values is as valuable or not
> valuable as automatic discovery for a service API. I would like to echo one
> of my postings:
>
> A scope defines the set of permissions a client asks for and t
+1 for #3.
If the delimiter becomes an issue then:
- for application/x-www-form-urlencoded and query parameters we can
allow multiple values for this parameter
- for json this parameter can be defined as an array
Marius
On Fri, Apr 30, 2010 at 12:08 PM, Allen Tom wrote:
> I vote for #3
>
> Th
Am 01.05.2010 03:07, schrieb Marius Scurtescu:
On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt
wrote:
In my opinion, automatic discovery on scope values is as valuable or not
valuable as automatic discovery for a service API. I would like to echo one
of my postings:
A scope defines
On 30 Apr 2010, at 11:00 PM, Torsten Lodderstedt wrote:
> Am 01.05.2010 03:07, schrieb Marius Scurtescu:
>> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt
>> wrote:
>>
>>> In my opinion, automatic discovery on scope values is as valuable or not
>>> valuable as automatic discovery for a
I agree with approach #3.
As for the delimiter, I'm fine if the spec wants to do space-delimited.
Just FYI Facebook will also continue to support and document commas in addition
to whatever the spec says, because spaces are typically URL-encoded while
commas are considered reserved characters
On 2010-05-01, at 3:48 PM, Luke Shepard wrote:
> I agree with approach #3.
>
> As for the delimiter, I'm fine if the spec wants to do space-delimited.
>
> Just FYI Facebook will also continue to support and document commas in
> addition to whatever the spec says, because spaces are typically
A comma is a better separator here.
Allow URIs as scopes -- as long as the chosen URIs don't have commas. This
isn't a big restriction on services.
[If a service provider really needs to include arbitrary URIs in an
authorization URI they can still do so by defining another parameter, say
"urls
+1 on option 3.
Commas seem slightly cleaner, but can go either way.
We should also consider naming this parameter "scopes" if we go with option
3
Evan
On Mon, May 3, 2010 at 6:23 AM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> A comma is a better separator here.
> Allow URIs a
+1 to option 3
I think the suggestion below from Torsten makes great sense, especially in
relation to standardized apis such as mail
Mark
On 01 May 2010, at 13:36 PM, Eve Maier wrote:
> Am 01.05.2010 03:07, schrieb Marius Scurtescu:
>> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Monday, May 03, 2010 6:24 AM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
>
> A comma is a better
16 matches
Mail list logo
