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
