Re: [OAUTH-WG] Versioning

Perhaps it's enough if in the spec we make clear that we are also defining a scheme usable for other things.  I don't think that's quite spelled out.  Then other specs just refer to the specific section like we're pulling in the WWW-Authenticate part from another spec. 

> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
> Sent: Thursday, July 01, 2010 11:42 AM
> To: Marius Scurtescu
> Cc: William Mills; Rob Richards; oauth@ietf.org
> Subject: RE: [OAUTH-WG] Versioning
> 
> It was and this approach was rejected by this group as 
> confusing. At this point, it's specification is so short, it 
> can live anywhere.
> 
> EHL
> 
> > -----Original Message-----
> > From: Marius Scurtescu [mailto:mscurtescu@google.com]
> > Sent: Thursday, July 01, 2010 11:28 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:19 AM, Eran Hammer-Lahav 
> > <eran@hueniverse.com> wrote:
> > > I think HTTP authentication schemes should be generally 
> useful. In 
> > > this
> > case, OAuth defines a few ways to obtain an token, and a 
> few ways to 
> > use a token with HTTP resources. What it doesn't do is say anything 
> > useful about the token itself, or implies that the tokens 
> are "OAuth 
> > tokens" (i.e. that the nature of the token is bound to the 
> OAuth protocol).
> > >
> > > I can envision use cases where someone wants to use 
> existing tokens
> > (obtained via other means than those provided by OAuth) to access 
> > protected resources. What about using a token as currently 
> defined is 
> > OAuth-specific?
> > >
> > > In other words, the scheme name is generic because OAuth 
> tokens are
> > generic and for the most part left undefined. Naming the 
> scheme OAuth 
> > implies that there is a link between the token properties 
> and how they 
> > are obtained, and the current protocol does not specify any 
> such link. 
> > The same applies to using HTTP Basic for client 
> credentials, not to log-in an end-user.
> > 
> > Sure, but then I think the "Token" scheme needs its own standalone 
> > spec and not be defined as part of the OAuth 2 spec.
> > 
> > Marius
> > 
> > >
> > > EHL
> > >
> > >> -----Original Message-----
> > >> From: William Mills [mailto:wmills@yahoo-inc.com]
> > >> Sent: Thursday, July 01, 2010 11:08 AM
> > >> To: Eran Hammer-Lahav; Rob Richards; oauth@ietf.org
> > >> Subject: RE: [OAUTH-WG] Versioning
> > >>
> > >> Why is using the string "Token" better than "OAuth2"?  
> 1.0 used "Oauth".
> > >>
> > >>
> > >> If it's purely a question of aesthetics, I prefer 
> "Oauth_2" to "Token"
> > >> because I feel it's clearer and more descriptive.
> > >>
> > >> > -----Original Message-----
> > >> > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> > >> > Sent: Thursday, July 01, 2010 11:00 AM
> > >> > To: William Mills; Rob Richards; oauth@ietf.org
> > >> > Subject: RE: [OAUTH-WG] Versioning
> > >> >
> > >> > Why is a version better than a new scheme name? 
> Version is only 
> > >> > helpful when the protocol is practically the same with 
> some minor 
> > >> > changes, and if that is the case, extensibility alone 
> should be 
> > >> > enough.
> > >> >
> > >> > 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
> > >
> 