Browser Extension Convergence

From IIW

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…)
  8. IE: Microsoft’s I-Card built-in
  9. IE: Higgins: HBX4IE

We then made a list of protocol “families” that we think each extension should support:

  1. Username/Password (Form-based, HTTP Auth, WS-Security)
  2. OpenID (OpenID, SAML)
  3. I-Card (ISIP‡IMI-TC)
  4. Kerberos

We also made a list of possible “packaging” options for these extensions, though this didn’t really lead to any discussion:

  1. Browser-native add-on/extension/plug-in
  2. Flash
  3. Java
  4. Gears
  5. 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.