Re: [OAUTH-WG] Versioning

An easy fix here is to use oauth2_token instead of oauth_token here,
since that's the only place we seem to be using the oauth_ namespace
now. Makes figuring out the two completely deterministic since it's a
different parameter name when passed as a GET or POST variable, and a
different header name when passed as a header (using the current Token
scheme or an OAuth2 scheme or whatever).

 -- Justin

On Thu, 2010-07-01 at 14:25 -0400, William Mills wrote:
> +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:mscurtescu@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 
> > <eran@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:wmills@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-bounces@ietf.org [mailto:oauth-bounces@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:rrichards@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