Backwards compatibility

Dick Hardt dick at sxip.com
Tue Sep 26 01:01:08 UTC 2006


On 25-Sep-06, at 5:41 PM, Brad Fitzpatrick wrote:

> On Mon, 25 Sep 2006, Dick Hardt wrote:
>
>> So you would not support inames,
>
> LiveJournal would not.
>
>> Yadis,
>
> We already do!  And will continue to improve that as spec changes.
>
>> nonces,
>
> Already do, via the Net::OpenID::* modules, which do it for me, in  
> OpenID 1.x.

I must be missing where nonces are in the 1.1 spec.

>
>> IdP-driven identifier selection on LiveJournal?
>
> Not right away.  Not sure there's a demand from the userbase, nor  
> is it
> exciting enough in the they-just-don't-know-it-yet way to be worth  
> pushing
> on them.

Fair enough. But you are limiting users that do have it from their IdP.

>
>> I guess that would include attribute exchange as well?
>
> I thought that was an extension, so can't I use it without 2.0?  I can
> use JanRain's SimpleReg attribute exchange extension with 1.x.

Given there is so little difference between 1.1 and 2.0, and one of  
them being support for extensions, I am confused
why you would not just support 2.0.

>
>> Given that, I would say calling this OpenID 2.0 is a misnomer.
>>
>> usually a new version name implies there is some incompatibility, and
>> there is not anything worth you upgrading, then perhaps this should
>> just be called OpenID 1.2 and use the extension mechanism to add in
>> other things so that message compatability is not broken.
>
> I'm not against that.  I don't really care what it's called.  I  
> just don't
> think there's a reason to break all the existing OpenID users and  
> confuse
> the spec just to rename some stuff.

I was looking to clarify names for people. Not a huge issue, what  
became the issue was
how much compatability was needed.

You seemed to like renaming trust_root to realm! :-)


>
> Look at successful HTTP-NG (HTTP/2.0) became.  Compare with the  
> HTTP/1.0
> ... HTTP/1.1, DAV, etc.
>
> OpenID just needs some HTTP/1.0 -> HTTP/1.1-style loving from what  
> I can
> tell (that is, spec clarifications, few changes).  Nothing's  
> fundamentally
> broken from what I've heard.

Rich Client support is really hard to do. Lots of things like  
attribute exchange are missing.
Agreed it is reasonable base. It assumes that you are doing an  
identifier exchange.
Many impedance mismatches with SXIP/DIX have been resolved.

I thought the consistent message format and naming was a GOOD thing.
If not, then let's move on!

>
>> ie. new parameters and functionality would be all discovered and only
>> invoked if the IdP supports it
>
> I'm all about capability advertisements and discovery.

This looks like the best way to layer on additional functionality and  
security per the RP identity concepts I posted about earlier.

-- Dick



More information about the specs mailing list