As a datapoint ­ OAuth 1.0a deliberately did not change the version string
from 1.0 to 1.0a, and it was determined that the version parameter did not
add any value. I can¹t quite recall the reasoning behind this off the top of
my head though.

Big +10000 to trying to harmonize OpenID and Oauth WRAP.
Allen



On 2/25/10 8:22 PM, "Nat Sakimura" <[email protected]> wrote:

> 
> 
> On Fri, Feb 26, 2010 at 11:55 AM, Dick Hardt <[email protected]> wrote:
>> 
>> On 2010-02-25, at 4:11 PM, Nat Sakimura wrote:
>> 
>>> Hi
>>> 
>>> This may have come up earlier but ...
>>> 
>>> I think Wrap should have a namespace / versioning syntax.
>>> Invariably, it will evolve, and will require version number etc. so, it
>>> seems better to me to have one from the beginning.
>>> 
>>> e.g., 
>>> 
>>>> wrap_ns=http://whatever/wrap/1.0
>>>> wrap_client_id ... 
>> 
>> Versioning was discussed. I don't recall the details, but it was decided it
>> did not add value.
>> 
> 
> I actually think it does. 
> Perhaps not in the initial version, but in the future for sure. 
> So, it is better to have it in the design from the beginning. 
>  
>> 
>>> 
>>> I would go further. Why is underscore '_' is used for the delimiter?
>>> If we make it dot '.', it will improve the future compatibility with OpenID.
>> 
>> Or OpenID could change to using '_'  :-)
> 
> If you use '_' as the namespace delimiter, then '_' should be disallowed in
> the parameter name, which is not the case right now. 
>  
>> 
>> 
>>> So, we could do something like:
>>> 
>>>> openid.ns=http://whatever/wrap/1.0
>>>> openid.client_id ...
>>> 
>>> The same applies for OpenID. For an unknown reason, though OpenID has
>>> namespace so that we write:
>>> 
>>>> openid.ns= http://specs.openid.net/auth/2.0
>>> 
>>> the prefix "openid" is fixed. We should be able to change it like:
>>> 
>>>> wrap.ns=http://specs.openid.net/auth/2.0
>>> 
>>> Now, the third point.
>>> 
>>> Could we not try to harmonize the variable names between the two specs?
>>> 
>>> OpenID is in use widely, so it is kind of hard to change it,
>> 
>> Interesting assumption. At IIW we discussed OpenID v Next that was NOT
>> backward compatible. It would seem that there is an oppportunity to make
>> changes to OpenID as well as OAuth WRAP.
> 
> yes. The above also requires changes on the OpenID side, but I am seeing
> an opportunity to make the transition smoother. 
>  
>> 
>>> so I would request Wrap community to come closer.
>> 
>> WRAP followed OAuth, which has much broader adoption from what I know than
>> OpenID
>> 
> 
> Arguably yes, but at the same time, 'wrap_' is not 'oauth_' ;-)
>>> 
>>> IMHO, we should try to harmonize/unite instead of fragmenting.
>> 
>> Agreed, but perhaps the changes could happen in OpenID or a combination?
> 
> Definitely in combination. 
> 
> It is good that OpenID Foundation finally can start creating WGs again. 
>  
>> 
>> -- Dick
>> 
>> _______________________________________________
>> specs mailing list
>> [email protected]
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> 
> 
> 

_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs

Reply via email to