> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Thursday, July 01, 2010 11:16 AM > To: Eran Hammer-Lahav > Cc: William Mills; Rob Richards; [email protected] > Subject: Re: [OAUTH-WG] Versioning > > On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav > <[email protected]> wrote: > > Why is a version better than a new scheme name? > > Sure, but then make the scheme more specific. What will the scheme name > be for OAuth 3?
I don't think there should be a new scheme for OAuth 3. The only reason why we need to define a new scheme for OAuth 2 is that we so poorly defined the header for 1.0 and made it unworkable for new requirements. Reusing the OAuth scheme from 1.0 would result in something closer to a hack than a properly designed protocol, and the current cost of a new scheme is largely negligible. If you would like to discuss a version for the header, please provide examples and requirements for what changes in the future you would like to support. EHL > When tokens are passed in the query string there is no scheme. > > Marius > > > > > EHL > > > >> -----Original Message----- > >> From: William Mills [mailto:[email protected]] > >> Sent: Thursday, July 01, 2010 10:49 AM > >> To: Eran Hammer-Lahav; Rob Richards; [email protected] > >> 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: [email protected] [mailto:[email protected]] On > >> > Behalf Of Eran Hammer-Lahav > >> > Sent: Thursday, July 01, 2010 9:36 AM > >> > To: Rob Richards; OAuth WG ([email protected]) > >> > Subject: Re: [OAUTH-WG] Versioning > >> > > >> > Hi Rob, > >> > > >> > > -----Original Message----- > >> > > From: Rob Richards [mailto:[email protected]] > >> > > Sent: Thursday, July 01, 2010 3:26 AM > >> > > To: OAuth WG ([email protected]); 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 > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
