Subject: [OAUTH-WG] Facebook updates to Draft 10

From: Paul Tarjan <[email-masked]>
Date: Thu, 9 Sep 2010 18:43:35 +0000

Hi Fellow OAuthers,

We just updated our Graph API's OAuth2 implementation to be draft 10 complaint. Yay!

Well, I should say we are pretty close to draft 10. Some places we differ:

* For now errors are not in the standard format :( This would break backwards compatibility and existing applications, so we are only going to turn it on for opted in applications until the spec is finalized. If anyone wants to use the new formats, send me your Facebook app's ID and I'll opt you in.
* if grant_type is not included, it is assumed to be "authorization_code" since that is what draft-00 did.
* If response_type is not included, it is assumed to be "code" since that is what draft-00 did.

When the spec is finalized, we plan on doing a single opt-in migration for all non-backwards compatible changes. New application will be automatically on the final version, and older applications will have a time period to update.

Some new things you can do:

Here are a few links showing some of the new parameters to help you with discovery:
code_and_token: 
http://graph.facebook.com/oauth/authorize?client_id=150629244948164&redirect_uri=http://paulisageek.com/facebook/app/&response_type=code_and_token
token: 
http://graph.facebook.com/oauth/authorize?client_id=150629244948164&redirect_uri=http://paulisageek.com/facebook/app/&response_type=token
new error format:
http://graph.facebook.com/oauth/access_token?client_id=150629244948164&redirect_uri=http://paulisageek.com/facebook/app/
error redirects:
http://graph.facebook.com/oauth/authorize?client_id=150629244948164&redirect_uri=http://paulisageek.com/facebook/app/&grant_type=junky_junk

Feel free to ask questions and let me know if there are any places you don't think we are spec complaint. We plan on keeping up with changes as we all run this last mile to the final version.

Thanks!
Paul

---

From: Olivier POITREY <[email-masked]>
Date: Fri, 10 Sep 2010 10:46:49 +0200

Hi Paul,

Your implementation (and most other oAuth 2.0 implementations I've seen so far) are not using whitespace delimiter for the scope field. As I'm currently working on an oAuth 2.0 implementation for Dailymotion, I'm wondering why nobody seems to follow this part of the spec and use comas instead of whitespaces. Note that I would prefer coma over whitespace, whitespace have to be encoded and I find it a bit counter intuitive for this field.

Best,

On 9 sept. 2010, at 20:43, Paul Tarjan wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Paul Tarjan <[email-masked]>
Date: Fri, 10 Sep 2010 13:19:58 +0000

Hi Olivier,

We should be accepting both (since we are trying to be backwards compatible with Draft 00)

http://graph.facebook.com/oauth/authorize?client_id=150629244948164&redirect_uri=http://paulisageek.com/facebook/app/&scope=publish_stream%20offline_access%20xmpp_login

Does one of our docs pages recommend a comma separated string? If so, please send me the URL and I'll update it.

Paul

---

From: Olivier POITREY <[email-masked]>
Date: Fri, 10 Sep 2010 16:00:24 +0200

http://developers.facebook.com/docs/authentication/

Section: "Requesting Extended Permissions"

"[…]To request permissions via OAuth, use the scope argument in your authorization request, and include a _comma_ separated list of all the permissions you want to request.[…]"

The example shows comma as well.

Accepting both is ok for compat, but how can you be backward compatible in responses? Will whitespace be the long term delimiter for the scope field? Github for instance uses commas as well in their current implementation. I've actually never seen a public implementation using whitespaces so far. Wouldn't it be better to change the spec to comply with most current implementations? What motivated this choice in the first place?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 10 Sep 2010 07:56:33 -0700

That's not true. Both spaces and commas have to be encoded in form-encoded query parameters.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Olivier POITREY
> Sent: Friday, September 10, 2010 1:47 AM
> To: Paul Tarjan
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Facebook updates to Draft 10
> 
> Hi Paul,
> 
> Your implementation (and most other oAuth 2.0 implementations I've seen
> so far) are not using whitespace delimiter for the scope field. As I'm currently
> working on an oAuth 2.0 implementation for Dailymotion, I'm wondering why
> nobody seems to follow this part of the spec and use comas instead of
> whitespaces. Note that I would prefer coma over whitespace, whitespace
> have to be encoded and I find it a bit counter intuitive for this field.
> 
> Best,
> 
> 
> > * For now errors are not in the standard format :( This would break
> backwards compatibility and existing applications, so we are only going to
> turn it on for opted in applications until the spec is finalized. If anyone wants
> to use the new formats, send me your Facebook app's ID and I'll opt you in.
> > When the spec is finalized, we plan on doing a single opt-in migration for all
> non-backwards compatible changes. New application will be automatically on
> the final version, and older applications will have a time period to update.
> >
> http://graph.facebook.com/oauth/authorize?client_id=150629244948164&re
> direct_uri=http://paulisageek.com/facebook/app/&response_type=code_a
> nd_token
> > token:
> >
> http://graph.facebook.com/oauth/authorize?client_id=150629244948164&re
> direct_uri=http://paulisageek.com/facebook/app/&response_type=token
> > new error format:
> >
> http://graph.facebook.com/oauth/access_token?client_id=15062924494816
> 4&redirect_uri=http://paulisageek.com/facebook/app/
> > error redirects:
> >
> http://graph.facebook.com/oauth/authorize?client_id=150629244948164&re
> direct_uri=http://paulisageek.com/facebook/app/&grant_type=junky_junk
> >
> > Feel free to ask questions and let me know if there are any places you
> don't think we are spec complaint. We plan on keeping up with changes as
> we all run this last mile to the final version.
> >
> > Thanks!
> > Paul
> >

---

From: Olivier POITREY <[email-masked]>
Date: Fri, 10 Sep 2010 20:58:00 +0200

Are you sure ?

http://stackoverflow.com/questions/2366260/whats-valid-and-whats-not-in-a-uri-query/2375597#2375597

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 10 Sep 2010 16:56:14 -0700

The character is allowed, but query parameter encoding does now. Clearly, people have been sending and accepting comma despite the fact that they should be encoded. The reason why we chose spaces and not commas is to allow the scope to be a list of URIs which is used by a few companies.

EHL

> From: Olivier POITREY [mailto:[email-masked]]
> Sent: Friday, September 10, 2010 11:58 AM
> To: Eran Hammer-Lahav
> Cc: Paul Tarjan; OAuth WG
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Olivier POITREY
> >> Your implementation (and most other oAuth 2.0 implementations I've
> >> seen so far) are not using whitespace delimiter for the scope field.
> >> As I'm currently working on an oAuth 2.0 implementation for
> >> Dailymotion, I'm wondering why nobody seems to follow this part of
> >> the spec and use comas instead of whitespaces. Note that I would
> >> prefer coma over whitespace, whitespace have to be encoded and I find
> it a bit counter intuitive for this field.
> >>
> >> Best,
> >>
> >>
> >> backwards compatibility and existing applications, so we are only
> >> going to turn it on for opted in applications until the spec is
> >> finalized. If anyone wants to use the new formats, send me your
> Facebook app's ID and I'll opt you in.
> >>> * If response_type is not included, it is assumed to be "code" since
> >>> that is
> >> what draft-00 did.
> >>>
> >> non-backwards compatible changes. New application will be
> >> automatically on the final version, and older applications will have a time
> period to update.
> >>>
> >>> Here are a few links showing some of the new parameters to help you
> >>> with
> >> discovery:
> >>> code_and_token:
> >>>
> >>
> >> don't think we are spec complaint. We plan on keeping up with changes
> >> as we all run this last mile to the final version.
> >>>
> >>> Thanks!
> >>> Paul
> >>>