At first, I had the same first reaction as Marius, but after reading this thread, I agree with Eran. Two observations:
1/ OAuth endpoints are usually already namespaced as "oauth" - if there are other endpoints that accept custom parameters, they can be defined elsewhere. For example: https://www.google.com/accounts/OAuthAuthorizeToken https://api.login.yahoo.com/oauth/v2/request_auth http://twitter.com/oauth/authorize 2/ We should fight to keep URLs short and leave out redundant information where possible. We should leave out redundant information where possible. Here are two sample URLs. The first is 12% shorter than the second. http://facebook.com/oauth/authorize?mode=web_callback_access_request&client_id=123456789&callback=http://facebook.com/oauth/callback http://facebook.com/oauth/authorize?oauth_mode=web_callback_access_request&oauth_client_id=123456789&oauth_callback=http://facebook.com/oauth/callback On Mar 31, 2010, at 9:17 PM, Eran Hammer-Lahav wrote: Hey Marius, On 3/31/10 8:37 PM, "Marius Scurtescu" <mscurte...@google.com<mailto:mscurte...@google.com>> wrote: On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote: The only significant change I have made (which is of course open to debate) is renaming all the authorization flows parameters. I dropped the oauth_ prefix (no real need since these are purely OAuth endpoints, not protected resources), and made most of the parameter names shorter. I am not done so they are not consistent yet. Having a common prefix for all parameters is quite important IMO. It allows parties to define and pass additional, non-standard, parameters. Non-standard parameter hurt interoperability. The question is whether the right approach is to add a prefix to the protocol parameters or to the extension parameters (such as x_), or none. What prevents a custom parameter to collide with a standard extension not supported by the server or someone else's custom parameter? If we are serious about parameter collision (which I doubt given past sentiments on registries etc.), we should require all parameters to register unless they have some special custom prefix. In other word, adding the oauth_ prefix to the core parameters doesn't really accomplish much, other than making requests longer. In the past, people wanted to define extension parameters starting with oauth_ and we didn't really reach consensus on whether to allow it or not. Then we played with xoauth_ for a while, then went back and just allowed oauth_ for extensions. If we keep the oauth_ prefix, do we also require a registry for extensions? Do we define another prefix? Do we create a registry for extension prefixes? This gets bad really fast. Also, quite often parameters are added to existing URLs, and a prefix helps prevent collisions. Extension parameters should never conflict with core parameter because we know all the core parameters before we write custom ones... This is only for the OAuth-specific endpoint (authorization endpoint), not the protected resource endpoint in which we will still use oauth_token (the only parameter added to protected resource requests). What do you think? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
