Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header

[Justin Richer <[e-mail]>]

> Framing the argument against "having a 2 in it" as bikeshedding is missing the point. My reason against using OAuth2 is that is will undermine all the work put in to build an extensible framework that can evolve without needing a whole new version. By putting a version number, we make it more attractive to change the protocol than extend it.

I think that it is bikeshedding. You can build new and amazing things on
a framework named oauth2 as much as you can on something named oauth. If
OAuth3 is as backwards-incompatible as OAuth2 is, then it's going to
need its own namespace anyway, isn't it? 

> So far the arguments made are all theoretical.

Putting the '2' in there solves an issue that several WG members have
brought up when dealing with both OAuth1 and 2 simultaneously -- a case
that I think is actually going to happen. I have servers that need to
support both 1.0 and 1.0a flows simultaneously, right now. I cannot see
OAuth2 adoption and cutover being instantaneous enough across all these
different systems for these endpoints to not also support OAuth2. 

> I will maintain  my objection and preference to reuse the existing names until someone with an existing 1.0 deployment can make a compelling reason why they can rely on the presence of the oauth_signature_method to differentiate. 

I'm sorry, but I simply don't understand your staunch opposition to a
simple, low-negative-impact, and decently supported request such as
this. I've heard two supporting reasons on the list already: how do I
tell the difference between a misbehaving OAuth1 and a properly-behaving
OAuth2, and how do I branch early? And I'll also add in something that I
admit is more style than anything: It just feels better to branch on the
*presence* of something rather than the *absence* of something, if we
have that choice. 

Conversely, I see no compelling reason (technical, political, or
otherwise) to *not* have it be named "oauth2".

 -- Justin

PS: I think the bikeshed is where we keep the boatcar... :)



> On Jul 15, 2010, at 14:24, "Luke Shepard" <[e-mail]> wrote:
> 
> > 
> > On Jul 15, 2010, at 10:51 AM, Justin Richer wrote:
> > 
> >> It was discussed before, but I don't remember there being any consensus
> >> in the group. What are the practical reasons for not using "oauth2"
> >> namespacing in the one place we still use namespacing? Most of what I've
> >> heard seems to sound like "I don't like it to have a 2 on it". 
> > 
> > I don't like it to have a 2 in it.
> > 
> >> I don't want to have to set up the OAuth 2 system to have to catch
> >> failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad
> >> OAuth 1 call should be distinguishable from the start. Also, what about
> >> when we finally get a signed-request going? I would assume that that's
> >> going to add back in things like oauth_signature, oauth_nonce, and the
> >> other parameters whose absence you should filter on. 
> > 
> > The latest signature discussions have all focused on a single, self-contained, signed parameter that includes both data and signature. I think it's unlikely that we will introduce the plethora of parameters that we had in OAuth 1.0.
> > 
> >> -- Justin
> >> 
> >> On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote:
> >>> I thought this topic had been beaten to death before. An OAuth 1.0
> >>> protected resource request includes a variety of oauth_ parameters
> >>> whereas OAuth 2.0 just has oauth_token.
> >>> 
> >>> 
> >>> --David
> >>> 
> >>> 
> >>> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <[e-mail]>
> >>> wrote:
> >>>       On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer
> >>>       <[e-mail]> wrote:
> >>>> +1 on OAuth2 header, and I also want to see oauth2_token in
> >>>       URI and form
> >>>> parameter methods.
> >>> 
> >>> 
> >>>       Good point about the query parameter names needing to be
> >>>       unambiguous.
> >>> 
> >>>       _______________________________________________
> >>>       OAuth mailing list
> >>>       [e-mail]
> >>>       https://www.ietf.org/mailman/listinfo/oauth
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> > 
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth