I think HTTP authentication schemes should be generally useful. In this case, OAuth defines a few ways to obtain an token, and a few ways to use a token with HTTP resources. What it doesn't do is say anything useful about the token itself, or implies that the tokens are "OAuth tokens" (i.e. that the nature of the token is bound to the OAuth protocol).
I can envision use cases where someone wants to use existing tokens (obtained via other means than those provided by OAuth) to access protected resources. What about using a token as currently defined is OAuth-specific? In other words, the scheme name is generic because OAuth tokens are generic and for the most part left undefined. Naming the scheme OAuth implies that there is a link between the token properties and how they are obtained, and the current protocol does not specify any such link. The same applies to using HTTP Basic for client credentials, not to log-in an end-user. EHL > -----Original Message----- > From: William Mills [mailto:wmi...@yahoo-inc.com] > Sent: Thursday, July 01, 2010 11:08 AM > To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning > > 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
