Re: [OAUTH-WG] Versioning

[Rob Richards <[e-mail]>]

With this the spec needs to including some wording to explicitly define 
how to handle the case when running an endpoint supporting both OAuth 
1.0 and 2.0 and the oauth2_token is missing then the call is handled 
according to the OAuth 1.0/a spec. Whatever is decided, be it a version 
parameter, the use of oauth2_token or the check for the existence of the 
oauth_signature_method parameter, etc///, the spec needs to define and 
be explicit on how a resource endpoint determines between a 1.0 and 2.0 
call when both are supported.

Rob

Justin Richer wrote:
> An easy fix here is to use oauth2_token instead of oauth_token here,
> since that's the only place we seem to be using the oauth_ namespace
> now. Makes figuring out the two completely deterministic since it's a
> different parameter name when passed as a GET or POST variable, and a
> different header name when passed as a header (using the current Token
> scheme or an OAuth2 scheme or whatever).
>
>  -- Justin
>
> On Thu, 2010-07-01 at 14:25 -0400, William Mills wrote:
>   
>> +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:[e-mail]] 
>>> Sent: Thursday, July 01, 2010 11:16 AM
>>> To: Eran Hammer-Lahav
>>> Cc: William Mills; Rob Richards; [e-mail]
>>> Subject: Re: [OAUTH-WG] Versioning
>>>
>>> On Thu, Jul 1, 2010 at 10:59 AM, Eran Hammer-Lahav 
>>> <[e-mail]> 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:[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
>>>>
>>>>         
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>     
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>