> -----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. If anyone wants to propose a versioning of any parts of this protocol, they must present specific objectives. The vague objective of "allow future versions" isn't valid because it has failed for 1.0 (and many other protocols). Instead, I suggest people pay more attention to the extensibility and ensure that it offers enough support for future needs, without having the change the protocol. We tried adding version support in OAuth 1.0 and failed. The version parameter does not help in any real way, is incompletely, and poorly defined. The quality of this new discussion is as low as that of the 1.0 attempt. Let's learn from our mistakes. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
