Re: [OAUTH-WG] Versioning

> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com] 
> Sent: Thursday, July 01, 2010 11:36 AM
> To: Eran Hammer-Lahav
> Cc: William Mills; Rob Richards; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Versioning
> 
> On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav 
> <eran@hueniverse.com> wrote:
> >
> > 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.
> 
> Not sure about the future, but looking at OAuth 1 vs OAuth 2. 
> A protected resource request filter may want to decide early 
> what protocol it deals with so it can call the appropriate 
> handler, or to enforce HTTPS for OAuth 2 for example. Sure, 
> it can apply heuristics right now, but it would be nice to 
> have a more deterministic way which can also be extended in 
> the future. You can always embed the protocol version inside 
> the token I guess, so I don't think this is a huge issue.

Yeah, unfortunately early selection of a handler might require peeking into the post body.  

> 
> I was not part of the 1.0 vs 1.0a discussions, so not sure 
> what was the conclusion there.
> 
> Marius
> 
> >
> > EHL
> >
> >> 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
> >> >
> >
> 