Lots of things can be done. Checking presence of oauth_signature_method implies that the format is the same in all cases including the auth header right?
What you seem to be arguing for right now is parsing the entire line to decide which auth you do. I would *much* prefer a leading tag or scheme name so I don't have to go there. To me this is an argument about complexity. Your solution involves more complex code to differentiate. > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, July 15, 2010 11:36 AM > To: Luke Shepard > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header > > 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. > > So far the arguments made are all theoretical. > > 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. > > EHL > > > > On Jul 15, 2010, at 14:24, "Luke Shepard" > <lshep...@facebook.com> 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 <bea...@google.com> > >>> wrote: > >>> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer > >>> <jric...@mitre.org> 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 > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
