Eran Hammer-Lahav wrote:
-----Original Message-----
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, July 01, 2010 10:37 AM
To: Eran Hammer-Lahav
Cc: Rob Richards; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Versioning
On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav <e...@hueniverse.com>
wrote:
Hi Rob,
-----Original Message-----
From: Rob Richards [mailto:rricha...@cdatazone.org]
Sent: Thursday, July 01, 2010 3:26 AM
To: OAuth WG (oauth@ietf.org); Eran Hammer-Lahav
Subject: Versioning
Versioning is still something that needs to be addressed before being
being able to consider the draft core complete.
Versioning rarely works because when you define it, you have no idea
what the requirements will be for the next version. A good example is the
OAuth 1.0 version parameter. When we worked to revised 1.0 into 1.0a, we
had a long debate on changing the protocol version number. We had a hard
time agreeing on what the version meant and what was it a version *of*: the
signature method or the token flow.
If this protocol will require significant changes in the future that go beyond
its extensibility support, such a new version will need to use different
endpoints (token or end-user authorization) and/or different HTTP
authentication scheme.
I don't think the authz server endpoints are an issue, but the protected
resources. The auth scheme is very generic, "Token". So either the scheme
should be more specific, like "OAuth2", or a version should be added as a
parameter. Maybe a token type as Dick suggested.
HTTP Basic has no version, and I believe Digest doesn't have a version either
(though it has been revised from 2069 to 2617). The Token scheme is generic,
but also wide open. The only required parameter is 'token' (which makes sense
for a Token scheme). I can't come up with a single requirement that would
require an explicit version parameter.
Version discussions are almost always a waste of time because at the time they
are debated, no one knows what the requirement for such a feature will be.
Versioning usually makes sense in a follow-up revision where the protocol needs
a way to differentiate itself from the previous version.
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.
Rob
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
