Re: [OAUTH-WG] Versioning

[Rob Richards <[e-mail]>]

Eran Hammer-Lahav wrote:
>   
>> -----Original Message-----
>> From: Marius Scurtescu [mailto:[e-mail]]
>> Sent: Thursday, July 01, 2010 10:37 AM
>> To: Eran Hammer-Lahav
>> Cc: Rob Richards; OAuth WG ([e-mail])
>> Subject: Re: [OAUTH-WG] Versioning
>>
>> On Thu, Jul 1, 2010 at 9:35 AM, Eran Hammer-Lahav <[e-mail]>
>> wrote:
>>     
>>> 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.
>>
>> I don't think the authz server endpoints are an issue, but the protected
>> resources. The auth scheme is very generic, "Token". So either the scheme
>> should be more specific, like "OAuth2", or a version should be added as a
>> parameter. Maybe a token type as Dick suggested.
>>     
>
> HTTP Basic has no version, and I believe Digest doesn't have a version either (though it has been revised from 2069 to 2617). The Token scheme is generic, but also wide open. The only required parameter is 'token' (which makes sense for a Token scheme). I can't come up with a single requirement that would require an explicit version parameter.
>
> Version discussions are almost always a waste of time because at the time they are debated, no one knows what the requirement for such a feature will be. Versioning usually makes sense in a follow-up revision where the protocol needs a way to differentiate itself from the previous version.
>
>
>   
Exactly. While it might be needed in the future, there is a need to 
differentiate OAuth 1.0 from 2.0 on resource endpoints right now. 
Outside of requiring an oauth_version parameter (or equivalent) all 
other suggestions leave versioning as a grey area, where things can be 
interpreted one way or another with no consistency. Grey areas in specs 
are a bad thing. You end up with different languages/libraries dealing 
with things in completely different and incompatible ways because 
something was not clearly spelled out.

Rob