To elaborate a bit: Since there is no discovery in 1.0, the only place this can create a conflict is on the server side, when servers support both new and old schemes, and need to tell which version the client is using. This is the same issue as using the 'oauth_token' parameter in the query or body. Since there is no discovery, no 2.0 client is going to try and talk to a 1.0 server because that would be a like trying to speak SMTP to an XMPP port. On the server side, adding support for 2.0 already requires code changes.
If this proves to be an actual issue with a deployed system, I don't care about using a different name but: - 'OAuth2' is "ugly as sin", and puts us on the broken path to produce an 'OAuth3', etc. - We need to have more discussions about using different schemes with different token properties (i.e. Bearer, Signed, etc.). Some here want to break this into highly specialized schemes, while others want to use 2, and some a single scheme for everything (similar to 1.0). Using multiple headers doesn't break much on the 'Authorization' side because the server can easily handle it. But on the 'WWW-Authenticate' side it means having to define multiple schemes with their own discovery parameters, their own extensions, etc. This will turn into an complex and messy framework with too many confusing headers, etc. So bikeshedding aside, we need to reach consensus on how to architect the headers first, then we can find a name or names that don't annoy people like 'Token', 'OAuth', or 'OAuth2'. EHL On 7/15/10 6:07 AM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: I would like people to raise their hand and explain how this will break actual 1.0 deployments. EHL On Jul 15, 2010, at 1:38, Brian Eaton <bea...@google.com> wrote: > Draft 10 switched from "Token" scheme in the authorization header to > "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. > "Token" is ugly as sin, but is better than "OAuth". > > Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 > > The problem with reusing "OAuth" is that there are existing > implementations in the wild that have special behavior implemented for > OAuth authorization headers. Since OAuth2 headers don't have the same > semantics, we're going to break those implementations. We shouldn't > reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > "NTLM", "Digest", or "Basic. > > Cheers, > Brian > _______________________________________________ > 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
