Re: [OAUTH-WG] Versioning

+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
> >
>