How BrowserID works (in Federated Identity terms)

The point of this post is to delve a little into how BrowserID works in the context of what those of us in the Identity & Access Management (IAM) world understand as Enterprise Identity Federation. I'm NOT advocating that BrowserID be used in place of SAML (or any other Federation protocol). I'm merely trying to put on my IAM-glasses and taking a look at the flows in a BrowserID environment.

If you want a less technical, introductory view, read my previous post relating to BrowserID.

Here are the important parts of the "BrowserID dance" and how they map (roughly) to the common terms we understand in the IAM world:

• Email Address - Persona
• Relying Party - Service Provider (SP)
• Email Provider - Identity Provider (IDP)
• Web Browser - Identity Proxy (I know there's not a common definition for what an Identity proxy is but this is the closest I could think of - better suggestions welcome)

Mozilla has specific terms for each of the components, but I've used more commonly understood references to make things a little less confusing. For example, the web browser is officially the "Implementation Provider" in the BrowserID world. Mozilla uses a generic term to allow for the use of something other than a web browser as the medium for accessing an Internet service (e.g. a mobile or desktop client).

The way a relying party validates that you are the rightful owner of an email address is by validating the assertion that is presented along with it. The assertion uses proper cryptographic mechanisms and hence is fairly secure in terms of one NOT being able to generate a valid assertion without being in possession of the relevant certificate (of course, if your browser is compromised, all bets are off). The assertion is signed by the email provider (which as I've pointed out above, is the IDP in the whole scheme of things).

Sound familiar? If you have experience with Enterprise Federated Sign-On concepts, the notion of signed assertions should be second nature to you. The main difference here is that the signed assertion is stored in the browser and presented to the relying party by the browser without necessarily having to interact with the email provider (the IDP). The relying party is then expected to validate the assertion with the email provider before allowing the user access. In a typical Enterprise Federation scenario, the browser is simply a facilitator of information and interactions between the IDP and the SP.

Using Gmail as an example, the (simplified) flow to sign in to myfavefictionalsite.com (obviously not a real site) using BrowserID would go something like this:

1. Visit myfavefictionalsite.com and click "sign in with BrowserID".
2. If your browser is clueless about your Gmail email address, it will ask you for it (if it already knows about your Gmail address, skip to the next step). Once you are signed in to Gmail, the browser will do the "BrowserID dance" with Gmail to get an assertion provisioned to (stored in) your browser for your Gmail email address.
   
3. At this point, your browser knows about your Gmail account and has a valid assertion. It will pass the assertion to myfavefictionalsite.com and you will be registered (if you are a new user) and signed in (after myfavefictionalsite.com does whatever it needs to do to validate your assertion).

Sound simple? Yes, but as always, the devil is always in the details. For BrowserID to work this way, the email provider (Gmail in the example) needs to support the "BrowserID dance". Gmail does not. In fact, I don't know of any email provider that currently supports BrowserID.

This brings me to the fall-back option, which is how the prescribed demo site (http://myfavoritebeer.org/) works. BrowserID has this notion of "Secondary Identity Authorities". The email providers are known as "Primary Identity Authorities". If the email address you are trying to use belongs to a provider that does not support BrowserID, the use of a "Secondary Identity Authority" is used. At the moment, the default is browserid.org.

Mozilla states that anyone can be a "Secondary Identity Authority" if they so choose. A "Secondary Identity Authority" is supposed to hold user information (e.g. username, password, email) and also facilitate the process required to validate ownership of an email address. The typical way to do this is to send the user an email with a validation link which the user must visit. Only when the URL within the link is visited can an email address be designated as valid. In essence, a "Secondary Identity Authority" is an IDP which validates that your email address is actually "owned" by you and also signs you in.

Because there are no email providers today that support BrowserID, the only way a user can sign in using BrowserID is by using a "Secondary Identity Authority".

The best way to understand this is to try signing in to Mozilla's My FavoriteBeer demo. When you attempt to sign in, you will be asked for an email address. The demo's sign-in prompt will wait there until you check your email and click the validation link. Doing so validates your email address and the demo site will proceed to log you in.

I've tried to keep things in this post at a fairly high level in terms of technicality. If you're interested in getting your hands a little dirtier with the flows and specific interactions, the best description I've come across of how BrowserID hangs together is by Lloyd Hilaiel, who works for Mozilla and is responsible for the My FavoriteBeer demo. It's quite detailed and should give those of you interested a lot more "guts" than I have here.

Finally, my previous BrowserID post mentioned a few issues. But I've just come across a question about BrowserID in the IT Security section of StackExchange that has answers which bring up a few more more valid technical issues. Check it out if you're interested in that kind of thing.

Blog RSS feed strangeness

If you're a reader of my blog via the RSS feed and use Google Reader, I've noticed it's doing something strange.

There was only one published post yesterday/today before this one and it was titled "BrowserID - The browser as a Federated Identity proxy" and should appear immediately after this in the RSS feed (and obviously on the web).

For some reason, the RSS feed is publishing 2 additional posts that I had in draft and have since deleted:

1. BrowserID - The browser as a Federated Identity proxy (part 1)
2. BrowserID - The browser as a Federated SSO proxy (part 2)

Please ignore them. If you follow the links through, you'll notice the pages don't exist. I've since turned part 1 into the aforementioned "BrowserID - The browser as a Federated Identity proxy" post which was published. If you happened to read what was to be part 2, you've basically been given a preview of a follow up post I'll publish right after this (update: I've since published the follow up post here).

Apologies for the issue. There doesn't seem to be anything I can do about it. If I had to guess, I'd say there's some Google Reader caching strangeness happening here.

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.