Perhaps it's enough if in the spec we make clear that we are also defining a scheme usable for other things. I don't think that's quite spelled out. Then other specs just refer to the specific section like we're pulling in the WWW-Authenticate part from another spec.
> -----Original Message----- > From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Sent: Thursday, July 01, 2010 11:42 AM > To: Marius Scurtescu > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: RE: [OAUTH-WG] Versioning > > It was and this approach was rejected by this group as > confusing. At this point, it's specification is so short, it > can live anywhere. > > EHL > > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurte...@google.com] > > Sent: Thursday, July 01, 2010 11:28 AM > > To: Eran Hammer-Lahav > > Cc: William Mills; Rob Richards; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Versioning > > > > 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
