> -----Original Message-----
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Dossy Shiobara
> Sent: Friday, May 01, 2009 1:47 PM
> To: oauth@googlegroups.com
> 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 oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
