Browser Extension Convergence

Convener and Note Taker: Paul Trevithick

We had a session on trying to converge towards a single browser extension for these four browsers: IE, FF, Safari, Chrome. Or, at least that’s how it started off.

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 or…). 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.

We started by creating a quick inventory of the existing browser extensions:
 * 1) Firefox: Sxipper (OpenID, UN/PW)
 * 2) Firefox: Higgins: HBX4FF (I-Card)
 * 3) Firefox: OpenInfoCard (I-Card)
 * 4) Firefox: DigitalMe (I-Card)
 * 5) Firefox: OpenLiberty (SAML)
 * 6) Firefox: Verisign Seatbelt (OpenID)
 * 7) Firefox: IDIB (OpenID…)
 * IE: Microsoft’s I-Card built-in
 * IE: Higgins: HBX4IE

We then made a list of protocol “families” that we think each extension should support: We also made a list of possible “packaging” options for these extensions, though this didn’t really lead to any discussion: 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… Part 2: Browser Support for RP Auth Discovery Everyone agreed that creating common specs for this was a good idea, whether or not they were interested in creating implementations. We saw that we could use XRDS as the basis for discovery of a relying party (RP) site’s authentication support for multiple protocols. The RP site would publish an XRDS document that would allow a “smart client” (well, a browser extension) to discover information about what protocols were supported and how they might be used to authenticate to the site. Today I-Card tech embeds an HTML tag, but Axel Nennker has put forward here [1] and here [2] a variation where instead of an embedded tag we use a link/rel approach. Meanwhile, Scott Kventon and other OpenID folks have also been looking at using XRDS to discover RP auth metadata. In a similar manner XRDS SEPs could be defined for SAML, UN/PW and Kerberos.
 * 1) Username/Password (Form-based, HTTP Auth, WS-Security)
 * 2) OpenID (OpenID, SAML)
 * 3) I-Card (ISIP‡IMI-TC)
 * 4) Kerberos
 * 5) SAML (SAML SSO, SAML ECP)
 * 1) Browser-native add-on/extension/plug-in
 * 2) Flash
 * 3) Java
 * 4) Gears
 * 5) Silverlight

So the consensus was that we should pursue this common approach to RP Auth Discovery.

[1]http://ignisvulpis.blogspot.com/2008/10/information-cards-with-xrds.html

[2]http://iiw.idcommons.net/Iiw2008b_XRDS_for_OpenId_and_Information_Cards_and_other_%22Services%22