Why is a version better than a new scheme name? Version is only helpful when the protocol is practically the same with some minor changes, and if that is the case, extensibility alone should be enough.
EHL > -----Original Message----- > From: William Mills [mailto:wmi...@yahoo-inc.com] > Sent: Thursday, July 01, 2010 10:49 AM > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning > > 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
