In Context

Kudos to Kaliya and Phil for another great IIW. There was a great spirit of collaboration and I got the feeling that a lot of important work got done.

Browser Extension Convergence

I led a session on trying to converge towards a single browser extension for these four browsers: IE, FF, Safari, Chrome. Today we’ve got lots of browser extensions for different browsers each of which generally supports a specific protocol (e.g. OpenID or I-Card). What we’d like to get to is having one multi-protocol browser extension for each browser–that is, a total of four extensions. And eventually, we’d like to see these built into the browsers themselves. In the meeting we discovered that there was an opportunity to first agree on the specifications for auth discovery across protocols. This became the next part of the meeting…

Browser Support for RP Auth Discovery

Everyone agreed that creating common specs for this was a good idea, whether or not folks were interested in building implementations. (BTW, Phil was in this session and also blogged about this sub-topic). We saw that we could use XRDS as the basis for both OpenID as well as I-Card RP auth discovery, and perhaps others. Today I-Card tech embeds an HTML <object> tag, but Axel Nennker has put forward here and here a variation where instead of an embedded <object> tag we use a link/rel approach. Meanwhile, various OpenID folks have also been looking at using XRDS to discover RP auth metadata. Phil wrote:

Once the discovery protocol is decided upon, standard plugins could be written for Firefox, IE, Chrome, and Safari that would implement the discovery process for identity enable the browser for whatever identity system(s) the relying party supports. Four open source, community supported plugins could replace the myriad proprietary plugins available today. That would lead to greater penetration and also give browser manufacturers something to code against when the time comes that they want to build the discovery code into their product.

In an otherwise excellent article entitled When will Windows Live stop treating CardSpace as the unwanted stepchild? Simon Bisson and Mary Branscome confuse a technology with an implementation. They refer to CardSpace when they mean Information Card. This undermines the ecosystem and is ultimately not good for Microsoft.

The use of the word “CardSpace” in the article’s title was incorrect. The authors also wrote things like (emphasis added):

So why is Windows Live ID proudly announcing that it’s issuing OpenIDs but not CardSpace IDs?

I don’t even know what a CardSpace ID is. Information Card is the name of an open standard that has multiple competing implementations. One of these implementations is a Selector called Microsoft CardSpace™. Other implementations of Selectors and other components include Novell Bandit’s DigitalMe™, Higgins, OpenInfoCard, CardPress™, Azigo™, and so on. Information Card tech already has the non-profit Information Card Foundation backed by over 50 corporate members including Intel, Deutsche Telekom, Equifax, Novell, Google, and Oracle as well as a growing community of independents, FOSS developers, etc.