Subject: Re: [OAUTH-WG] Draft progress update

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Apr 2010 16:13:38 -0700

Yes, shorter is better, and we'll get to it later. But all the flows use a
single endpoint (right now), so each request needs a unique type.

EHL

On 4/1/10 7:02 PM, "Paul Walker" <[email-masked]> wrote:

> Along those lines, I would suggest renaming the mode values as the terms
> "request" and "flow" are kinda superfluous.  Perhaps
> 
> mode=web_callback
> mode=web_client
> mode=device
> mode=credentials
> mode=client
> 
> I understand that the Web Callback Flow uses two different values, one for the
> authorization step and another for the access token, but is this really needed
> given that these are different uris?
> 
> 
> On Mar 31, 2010, at 10:28 PM, Luke Shepard wrote:
> 
>> 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_i
>> d=123456789&callback=http://facebook.com/oauth/callback
>> http://facebook.com/oauth/authorize?oauth_mode=web_callback_access_request&oa
>> uth_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" <[email-masked]> wrote:
>>> 
>>>> On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <[email-masked]>
>>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
>