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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
