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