Hi Rob, > -----Original Message----- > From: Rob Richards [mailto:[email protected]] > Sent: Thursday, July 01, 2010 3:26 AM > To: OAuth WG ([email protected]); 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. If you want to discuss versioning, you must provide your requirements for such a feature, and clearly show how they are not served by the current extensibility proposal. > On this I'm still of the opinion that at the very minimum you will need to > require an oauth_version parameter for the resource endpoints, if not also > for the others as well. I think the difficulty of differentiating a 1.0 from a 2.0 protected resource request is exaggerated. As said before, you can tell the difference based on the presence of other parameter (oauth_signature_method), or by examining the provided token (assuming you issue different tokens for each version). The argument that a 2.0 request can also be a malformed 1.0 request is silly. I have yet to hear about that level of incompetence for a 1.0 developer (and I've heard about a lot) - omitting every other required parameter. At most, I'm open to renaming the oauth_token parameter to something else (oauth_access_token, oauth.token, oauth-token, etc.) but I think even that is not needed. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
