My feeling on this is that versioning explicitly in the protocol adds clarity and some small level of compatibility. Different auth and token endpoints are easy, what's harder is supporting multiple protocols on the same protected resource. It's on the protected resource I'd like to see some clearer protocol version spec so I'm not having to figure out from the variable names which protocol it is.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, July 01, 2010 9:36 AM > To: Rob Richards; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Versioning > > 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. > > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
