Re: [OAUTH-WG] Versioning

[Marius Scurtescu <[e-mail]>]

On Thu, Jul 1, 2010 at 11:24 AM, Eran Hammer-Lahav <[e-mail]> 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.

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:[e-mail]]
>> >> Sent: Thursday, July 01, 2010 10:49 AM
>> >> To: Eran Hammer-Lahav; Rob Richards; [e-mail]
>> >> 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: [e-mail] [mailto:[e-mail]] On
>> >> > Behalf Of Eran Hammer-Lahav
>> >> > Sent: Thursday, July 01, 2010 9:36 AM
>> >> > To: Rob Richards; OAuth WG ([e-mail])
>> >> > Subject: Re: [OAUTH-WG] Versioning
>> >> >
>> >> > Hi Rob,
>> >> >
>> >> > > -----Original Message-----
>> >> > > From: Rob Richards [mailto:[e-mail]]
>> >> > > Sent: Thursday, July 01, 2010 3:26 AM
>> >> > > To: OAuth WG ([e-mail]) 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
>> >> > [e-mail]
>> >> > https://www.ietf.org/mailman/listinfo/oauth
>> >> >
>> > _______________________________________________
>> > OAuth mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>