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:
- Firefox: Sxipper (OpenID, UN/PW)
- Firefox: Higgins: HBX4FF (I-Card)
- Firefox: OpenInfoCard (I-Card)
- Firefox: DigitalMe (I-Card)
- Firefox: OpenLiberty (SAML)
- Firefox: Verisign Seatbelt (OpenID)
- 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:
- Username/Password (Form-based, HTTP Auth, WS-Security)
- OpenID (OpenID, SAML)
- I-Card (ISIP‡IMI-TC)
- Kerberos
- SAML (SAML SSO, SAML ECP)
We also made a list of possible “packaging” options for these extensions, though this didn’t really lead to any discussion:
- Browser-native add-on/extension/plug-in
- Flash
- Java
- Gears
- Silverlight
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 <object> tag, but Axel Nennker has put forward here [1] and here [2] a variation where instead of an embedded <object> 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.
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
