The formats for 1.0 and 2.0 are sufficiently different that it is possible to unambiguously figure out what version is being used.
-Naitik On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > where is the relation between token version and HTTP authentication scheme > version? > > regards, > Torsten. > > Am 15.07.2010 23:34, schrieb Naitik Shah: > > I though we'd come to a decision on the versioning too :) IMHO, it's better > to push this burden of versioning into the token itself if necessary. I > think it's better from a developers perspective to pass an oauth_token, > because it's cleaner. Most deployments will already have versioned tokens to > enable upgrading these for internal changes, so why can't the OAuth version > be contained in there too? Given the option to simplify the implementation > for a API provider (Big Company, or someone who has to know how OAuth works) > vs API consumer (Developer, or someone who usually just wants some data), I > hope everyone agrees our focus should be the Developer. > > While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so > don't have the same backward compatibility issues, we've already changed our > tokens and introduced new ones a couple of times and this had no impact on > the parameter name being used. > > > -Naitik > > On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer <jric...@mitre.org> 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 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 >> > > > _______________________________________________ > OAuth mailing listoa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
