Why is using the string "Token" better than "OAuth2"? 1.0 used "Oauth".
If it's purely a question of aesthetics, I prefer "Oauth_2" to "Token" because I feel it's clearer and more descriptive. > -----Original Message----- > From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Sent: Thursday, July 01, 2010 11:00 AM > To: William Mills; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning > > 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
