Re: [OAUTH-WG] Scope - Coming to a Consensus
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 URL-encoded > while commas are considered reserved characters and so not encoded. It's > easier to write "read,write" than "read%20write". Just in case it was not evident: a comma is a valid URL character, it would be legal for it to be contained in a URL scope, leading a library parsing scopes to inadvertently split up a single scope into one or more. Since the proposal says a scope can be a URI/URL, a space is a better delimiter. -- Dick ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 'Scope' parameter proposal
I'm intrigued by the idea of returning scopes in the 403 response to a resource. I'll see if we can provide a working example of it. On Apr 23, 2010, at 5:05 PM, Brian Eaton wrote: > On Thu, Apr 22, 2010 at 6:11 PM, Manger, James H > wrote: >> We mustn't drop advertisements (details in 401 responses). >> We mustn't drop the goal of a standard for interoperability. > > I share the goals, I just don't think that a specification is the way > to get there. I think working examples in the wild would help > enormously. > >> Defining a scope field in a 401 response is the novel aspect that “might not >> actually work”. Allowing a 'scope' query parameter in authz URIs is be quite >> separate. > > Yeah, I agree with that analysis. > > Though I don't know of any providers that are returning authorization > URLs in 401 responses right now. That's novel, too. > > Cheers, > Brian > ___ > 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
Re: [OAUTH-WG] Scope - Coming to a Consensus
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 and so not encoded. It's easier to write "read,write" than "read%20write". On Apr 30, 2010, at 6:11 PM, Marius Scurtescu wrote: > +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 >> >> 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.html >> >> Yahoo currently requires developers to tell us the scopes that they need >> when registering for a consumer key. We've received plenty of feedback that >> developers would rather specify the scope(s) at authorization time, so we >> would support a multi-valued scope parameter. Space is a reasonable >> delimiter. >> >> Allen >> >> >> >> On 4/30/10 8:43 AM, "Eran Hammer-Lahav" wrote: >> >>> >>> 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 regardless). Space allows using URIs or >>> simple >>> strings as values. >>> >>> Pros: >>> >>> - A separator-delimited list of values is the common format for scope >>> parameters in existing implementations and represents actual deployment >>> experience. >>> - Most vendors define a set of opaque strings used for requesting scope. >>> This >>> enables libraries to concatenate these in a standard way. >>> - Enables simple extensions in the future for discovering which scope is >>> required by each resource. >>> >>> Cons: >>> >>> - Defining a format without a discovery method for the values needs doesn't >>> offer much more than the other options. >>> - Doesn't go far enough to actually achieve interoperability. >>> - Adds complexity for little value. >>> >>> >>> >>> ___ >>> 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 >> > ___ > 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
Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
On Fri, Apr 30, 2010 at 10:33 PM, Eran Hammer-Lahav wrote: > If we end up with JSON as the only *core* format, we can still extend the > protocol in another spec to add a format request parameter with other > serializations. I think that's the right way to look at it. The fact that JSON is always Unicode and the character encoding is easily determined by examining the first few bytes should be enough to make the group jump for it.[1] You can skip all the inaccurate metadata in the HTTP headers for both requests and responses. And even kind of hobbled embedded implementations can do ASCII only and we'll pretend it's UTF-8. :) But maybe none of this is a problem for existing implementations? The spec seems strangely silent on internationalization. - Rob [1] noo: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#url-encoded-form-data -- Robert Sayre "I would have written a shorter letter, but I did not have the time." ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Scope - Coming to a Consensus
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 service API. I would like to echo one >>> of my postings: >>> >>> A scope defines the set of permissions a client asks for and that becomes >>> associated with tokens. I don't see the need (and a way) for automatic scope >>> discovery. In my opinion, scopes are part of the API documentation of a >>> particular resource server. So if someone implements a client, it needs to >>> consider the different scopes this client needs the end users authorization >>> for. If the resource server implements a OAuth2-based standard API (e.g. for >>> contact management or e-Mail), a client might be interoperable (in terms of >>> scopes) among the resource servers implementing this standard. >>> >> Not sure I understand, are you saying that for a standard API, like >> IMAP for example, there should be a standard scope (or set of scopes)? >> > > Yes, that's what I said. > > Scopes (~permissions) should be defined allong with the corresponding API. So > developers should know upfront > which scope is required to perform a particular action. For example, > "uploading documents requires scope 'upload'". > The same holds for IMAP. Depending on the IMAP feature set you want to use > there could be plenty of scopes, > ranging from "read users INBOX" to sharing scenarios, where users have access > to other users IMAP folders. This makes a ton of sense. It's one of the reasons that, in UMA, we tried to specify a generic way of expressing scope that naturally and closely matches a resource-oriented (RESTful) API: resource + HTTP method is a reliable shorthand for an access feature. For read and write and even delete permissions on (say) identity data accessed by URL, it's pretty much all the expressiveness you need, and ideally the same documentation easily covers both features and scopes. For any API that's more "compressed" (e.g. one complex endpoint for many operations), it doesn't really help. Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
