I prefer a 1.1 version because I find it less confusing to tell Consumers "To use my SP, you must find a library that supports OAuth 1.1" than to say "To use my SP, you must find a library that supports OAuth Core 2009.1"
Upon further reflection, this is a minor issue. What I really care about is having consistent vocabulary for describing what form of OAuth an SP or a library support. I'd be satisfied with either 1.0 or 1.1 if we clearly documented how to refer the different forms of OAuth (perhaps in Appendix A.1?) . Jesse On Fri, May 1, 2009 at 2:01 PM, Eran Hammer-Lahav <[email protected]> wrote: > > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Dossy Shiobara >> Sent: Friday, May 01, 2009 1:47 PM >> To: [email protected] >> Subject: [oauth] Re: This whole version business >> >> >> On 5/1/09 3:06 PM, Eran Hammer-Lahav wrote: >> > They didn't change the protocol version (as in 'GET /something >> > HTTP/1.1') because it added no value and would have just broke the >> web. >> >> Explain how rev'ing HTTP to 1.2 would have "broke the web" ... ? > > Millions of client and server would no longer be able to interoperate without > deploying new software, servers, proxies, caches, etc. When the client and > server speaks a different protocol, they cannot interoperate. But they > *obviously* can even with the changes made to HTTP 1.1 (reality proves this). > If they changed the version to 1.2, old clients will no longer work with new > servers and the change would have added confusion. The key here is 'added no > value'. If you need to change the wire version for an actual technical > reason, do it. But since changing the wire version break stuff, you need to > have a reason to do it. > > >> And similarly, how does changing oauth_version to 1.1 "break" OAuth? >> Can you actually outline an actual scenario where this happens? > > New client speaking version 1.1 tries to talk to a 2-legged OAuth endpoint > which was not upgraded because *there is no reason to*. Pretty much all large > providers use a centralized OAuth token service with distributed API servers. > The server issuing tokens is *different* from the server accepting > OAuth-signed requests. If we leave the wire version as-is, only the > centralized server needs changes, not any of the API servers. This is a *big > fucking difference* to *actual running code*. > >> I thought the whole point of the proposed change to OAuth is to _close >> a >> security hole_. That means, requests made to or from an implementation >> of the previous specification are INSECURE and SHOULD NOT COMPLETE, >> PERIOD. >> >> Or, have I learned a different definition of "security hole" than what >> the OAuth community uses? > > There is no hole in the signature workflow. Only in how new Access Tokens are > being issued. We are solving it with this fix. This fix doesn't require > changes to the wire version because it is easy to identify by any server. So > yes, you are missing the point. Half the spec isn't broken, doesn't suffer > from a security hole, and does not need to be broken. > > EHL > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
