On Thu, Jul 1, 2010 at 11:19 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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.
Sure, but then I think the "Token" scheme needs its own standalone spec and not be defined as part of the OAuth 2 spec. Marius > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
