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

[Olivier POITREY <[e-mail]>]

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?


On 10 sept. 2010, at 15:19, Paul Tarjan wrote:

> 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
> 
> On Sep 10, 2010, at 4:46 AM, Olivier POITREY wrote:
> 
>> 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:
>> 
>>> 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
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>