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

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 09:45:52 -0700

Hi Eran,

On Wed, Mar 31, 2010 at 9:17 PM, Eran Hammer-Lahav <[email-masked]> 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.

I agree that non-standard parameters are far from ideal, but they are used in
practice for various reasons.

> 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.

That's a different issue IMO. In general if you use non-standard stuff you
are on your own. We should try to protect the standard part and I think
a prefix helps.

> 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.

I don't see how dropping the prefix solves any of these problems. I think it
just makes matters worse.

>> 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).

Yes, this is only for OAuth endpoints, but all kinds of frameworks will be used
to implement them I can imagne that many of them will use their own parameters.

Also, many implementation will probably choose to pass state through
the callback
URL, as query parameters (even though there is a special OAuth
parameter for that).

> What do you think?

What are the reasons we would drop the prefix? So far the only one I heard was
shorter messages, but I am not convinced this is a real problem.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 09:51:04 -0700

Hi Luke,

On Wed, Mar 31, 2010 at 10:28 PM, Luke Shepard <[email-masked]> 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

The fact that the endpoint URL has "oauth" in it will not prevent any
collisions.

> 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

Yes, shorter in general is better. In this case it is just a bit shorter, it is
exactly 18 chars shorter, regardless of the URL length. What is this buying
us? End users don't have to type these URLs.

Marius

---

From: David Recordon <[email-masked]>
Date: Thu, 1 Apr 2010 11:22:48 -0700

> The fact that the endpoint URL has "oauth" in it will not prevent any

I think Luke's point is that OAuth deployment today is not being done
by complex frameworks which add their own parameters, rather the
majority of deployers make custom endpoints specifically for OAuth.  I
also don't see how the Authorization Server's web framework would add
random parameters given that an unknown client is making the HTTP
request to it.

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

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 11:29:17 -0700

> random parameters given that an unknown client is making the HTTP

Not random, they can be query parameters that are part of the
published URL, something like:
http://example.com/auth?mode=oauth

Also, not only the Authorization Server URLs can receive OAuth
parameters in the query,
the same applies to the client callback URL, and that one definitely
can have random
parameters.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 12:29:25 -0700

> the same applies to the client callback URL, and that one definitely

We are discussing just the authorization endpoint, but if you look at the
current draft, it proposes we limit client customization of the callbacks to
the state parameter (i.e. No query allowed). This is a new. My take is that
either we use the state parameter or we use custom query parameters (with
prefix) but not both. I like the state parameter better (stronger interop
and easier to pre-register URIs).

EHL