Subject: [OAUTH-WG] Draft progress update

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 31 Mar 2010 18:22:29 -0700

I'm making good progress working off David's draft and bringing text from
WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
it is largely in line with David's proposal and the majority of changes are
purely editorial.

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.

You can follow my progress (changes every few hours) at:

http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
.txt

Please feel free to comment on anything you like or dislike. I will publish
the whole thing as an I-D once it is feature complete for the WG to discuss
before we promote this to a WG draft.

I hope to be done with the initial draft by middle of next week (I'll be
flying most of Fri-Sat so no progress over the weekend).

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 31 Mar 2010 20:37:48 -0700

> 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. Also, quite
often parameters
are added to existing URLs, and a prefix helps prevent collisions.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 31 Mar 2010 21:17:32 -0700

Hey Marius,

On 3/31/10 8:37 PM, "Marius Scurtescu" <[email-masked]> wrote:

> 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

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

---

From: Luke Shepard <[email-masked]>
Date: Wed, 31 Mar 2010 22:28:17 -0700

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" <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
wrote:

Also, quite
often parameters

What do you think?

EHL

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