BrowserID - The browser as a Federated Identity proxy

The latest and greatest piece of technology doing the rounds looks to be Mozilla's release of BrowserID into the wild. It's even attracted a fair amount of interest outside the Identity & Access Management (IAM) community.

Mozilla pitches BrowserID as "a better way to sign in" using your email address and from the bits and pieces of commentary I've read, a fair number are raving about how great it is. Of course, there are also doubters and the most common question being asked is how it's different from OpenID. In fact, it's such a common question that Mozilla's already posted an official response.

To simplify it, all BrowserID does is validate (or assert) that you "own" the email address being presented to the service (e.g. a website you need to sign in to) being accessed. Whether the service chooses to accept it as a valid credential is completely up to the service in question. It ultimately comes down to trust and whether a service wants to allow you to use a particular email address to sign in. In this respect, it's not much different to using OpenID to sign-in to a site.

Mozilla's response to how BrowserID differs to OpenID touches upon some valid points. But the main advantage BrowserID potentially has over OpenID, is in its ease of use. It benefits mainly from being tied to the web browser, although Mozilla states that this does not need to be the case down the track. I should stress that a lot of the supposed usability benefits are theoretical at the moment because the primary method for using BrowserID is currently not implemented (more on this in a few paragraphs).

Usability in Identity matters (particularly when it comes to consumers) has always been key. If the act of registering or signing in is too confusing or difficult, people will not use it. The fact that Mozilla is trying to make everything happen transparently (and securely) through the browser means that if they get it right, there is very little the user has to do. No longer will users have to constantly get jolted from site-to-site while they complete the "Federated Single Sign-On dance". For someone who does not understand what is going on, it is a very jarring experience and the industry has yet to solve it properly. The closest we've been able to get is Facebook Connect and arguably Twitter's OAuth experience. But we owe the success of those efforts more to brand recognition than any real improvement in the user experience.

In addition, if something is difficult to implement from a development perspective, there is no chance of user adoption because the functionality in question will never see the light of day. I've personally done quite a lot of work in the past 2 years with OpenID and OAuth within a relying party (a service that accepts identity credentials from a separate, trusted site) and it's not the easiest thing in the world to get right. There are various libraries around to make the implementation less painful, but after taking a look at the source code for Mozilla's BrowserID demo site and the way one enables BrowserID within a relying party, I have to commend them for making it easy (side note: Facebook Connect's success can also be partially attributed to the fact they make it easy for relying parties to embed Facebook Connect functionality within websites).

BrowserID-enabling an email provider however, is much more difficult. There is currently no nice, easy way to do it. I'm guessing Mozilla will get around to making this easier in time. Also, email providers are typically large companies (e.g. Google, Yahoo, Microsoft) so if they really wanted to BrowserID-enable their email service, they will find a way to do it irrespective of any difficulties. But therein lies the challenge for BrowserID; getting email providers to support BrowserID. Without their support, BrowserID has to rely on what Mozilla calls "Secondary Identity Authorities", which are essentially email validation services that hold user account details for sign-in purposes. For example, a "Secondary Identity Authority" requires that you sign up for an account with it so it becomes your Identity Provider in the event that your email provider does not support BrowserID (which at the moment would mean 100% of the time). It also performs the sending of emails to your specified email address to verify that it belongs to you before it will allow you to use it to sign on to a relying party. As of the time of writing, the only known "Secondary Identity Authority" is Mozilla's browserid.org (which means it will probably be the default "Secondary Identity Authority" moving forward).

A glaring weakness those of us in IAM will notice with BrowserID is the apparent lack of any way to pass user details from the email provider to the relying party. This may not be a problem in cases where the relying party doesn't need to know anything about a person, but in situations where the relying party wants to store details about a person, they still need to go through a registration process instead of having information approved by the user sent as part of the federated provisioning process (which OpenID, OAuth and Facebook Connect are capable of doing - I'm ignoring SAML on purpose for now because it would be like comparing apples with oranges).

One major issue I noticed was that once your browser has an assertion that you own a specified email address, you are no longer prompted for validation (until I assume the time the assertion expires). I'm not entirely sure if this is just the way it's been done for the demo or if it's the expected norm, but this is bad. Very bad. It may be convenient, but I don't believe the benefit outweighs the security risk posed. Why? Because it gives anyone with access to your web browser full access to all the sites you use BrowserID for without having to know your password. You are simply asked which email address you want to use and if the relying party site accepts it, you're in! Bad bad bad! I'm not aware of any written guidance by Mozilla on when assertions should expire (although I must admit I have not read ALL their documentation), but I hope email providers choosing to support BrowserID set short assertion validation lifetimes.


It's still very early days for BrowserID so it's difficult to be too critical. They're off to a decent start, but do we really need another way to do Federated Sign-On where the main difference is that the browser plays a more critical role? I'm not sure we do. Could we not do something similar with browser plugins built to support OpenID or OAuth? We'll just have to see where Mozilla go with this. If they manage to make registration and sign-on dead simple, perhaps they'll be in with a chance.