-----Original Message-----
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Friday, July 02, 2010 4:05 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Versioning
Eran Hammer-Lahav wrote:
[Replying to everything at once...]
-----Original Message-----
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 11:43 AM
Exactly. While it might be needed in the future, there is a need to
differentiate OAuth 1.0 from 2.0 on resource endpoints right now.
Outside of requiring an oauth_version parameter (or equivalent) all
other suggestions leave versioning as a grey area, where things can
be interpreted one way or another with no consistency. Grey areas in
specs are a bad thing.
You end up with different languages/libraries dealing with things in
completely different and incompatible ways because something was not
clearly spelled out.
This is an area that is clearly on the server side, not the client. Since the
core specification leaves discovery out, client developers need to know what
version of OAuth is supported by the server and use the right one. Without
discovery, the client must know ahead of time what to do. With discovery,
the client can choose the right protocol. Either way, the client never just
sends a 1.0 or 2.0 requests and hopes for the best.
On the server side, the challenge isn't that significant. When not using a
header, the server can use multiple methods to differentiate the version
used by the client:
1. Token syntax
2. Presence of 'oauth_signature_method'
3. Presence of 'oauth_signature'
4. Presence of no other 'oauth_' parameter than 'oauth_token'
Never said this was hard just that it needs to be documented.
With this the spec needs to including some wording to explicitly
define how to handle the case when running an endpoint supporting
both OAuth
1.0 and 2.0 and the oauth2_token is missing then the call is handled
according to the OAuth 1.0/a spec. Whatever is decided, be it a
version parameter, the use of oauth2_token or the check for the
existence of the oauth_signature_method parameter, etc///, the spec
needs to define and be explicit on how a resource endpoint determines
between a 1.0 and 2.0 call when both are supported.
The damage done by interpreting a malformed 1.0 request (the odd
attempt to use 1.0 by only including 'oauth_token') is at most returning an
'invalid-token' response. I hope every server developer understands that
they should not share tokens between 1.0 and 2.0 with completely different
security properties.
Still the issue that different error codes returned which a client may handle
differently.
I think there are more issue with regard to 1.0 to 2.0 migration that should
be addressed, and I have asked those who care about this to propose a draft.
Given that such a draft will not be useful for a long time, given that the vast
majority of OAuth implementation 1-2 years from now will be 2.0, I do not
want to include it in the core specification.
In order for your argument to stand, you need to show how the current
setup leads to interoperability problems. Given the 4 options above, and the
fact that a malformed 1.0 request will still fail, I do not agree that interop
is
affected.
OAuth is a service that my company provides to other companies and we will
need to run both versions in parallel for many of the customers.
There are other companies out there who provide similar service, so this isn't
just an isolated problem. We may be transitioning customers to/from our
service and the behaviors of the systems need to be the same pre and post
migration.
There is also the WTF factor for developers. If I make calls to 2 providers (1.0
client), each of which is missing the oauth_signature, I would expect the
same response back. An error that its missing a required signature. If one of
the providers interprets a missing signature as meaning the call is a 2.0 based
call then it will return back a different error code.
I would expect that if I implemented 2 independent systems based on a spec
they would operate and behave the exact same way, otherwise you can just
throw the spec in the pile with the rest of them that have ambiguous
sections left to interpretation and cause for argument over who
implemented what correctly in their system.
Rob
