+1 on this. Makes life interesting on the PR. > When tokens are passed in the query string there is no scheme.
> -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Thursday, July 01, 2010 11:16 AM > To: Eran Hammer-Lahav > Cc: William Mills; Rob Richards; oauth@ietf.org > Subject: Re: [OAUTH-WG] Versioning > > On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav > <e...@hueniverse.com> 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? > > When tokens are passed in the query string there is no scheme. > > Marius > > > > > 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
