> 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" <[email protected]> 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 <[email protected]> > >>> wrote: > >>> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > >>> <[email protected]> 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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
