BrowserID is a method, presented in July 2011, to use email addresses to prove an identity and sign in to a website quickly and safely.
The system was developed by Mozilla Labs.
It's designed to be easier and faster than the esisting method of a site sending you an email and you clicking a link to verify your true identity.
So why is it important and how will it work? We decided to find out.
Q. How would it work in practice?
A. In order to log in on a website that supports BrowserID, you would only have to click on a Sign In button and then select from a menu what email address you want to use. Your browser and the website would take care of everything else.
Q. What about logging in via Facebook, Twitter or Google? That would be even faster and simpler, wouldn't it?
A. Yes, when you're browsing while logged in to any of those portals, you don't have to do anything, since any website connected with them will immediately know who you are. And that's the problem. Outsourcing these tasks to giant private providers creates lots of lock-in and privacy protection issues.
Q. That's surely true, but wait a second! Wasn't OpenID supposed to provide (more or less) the same service?
A. Indeed it was. In practice, it looks as if OpenID failed to reach critical mass for several reasons. Probably the biggest one was the need to temporarily go to another website to gain access to the one you wanted to visit.
Unless someone really understands the value of reliable online authentication services (and cares about it) that's much more cumbersome than just telling a browser to remember all passwords, or click on the Remember Me boxes provided by most log-in web forms. BrowserID tries to provide the same level of security and trust as OpenID, but in a much more transparent way.
Q. Tell me more about privacy protection in BrowserID, please.
A. First of all, unlike other sign-in systems, BrowserID does not force the user to share or transmit online personal, sensitive data, such as date of birth. In addition to this, BrowserID is designed not to pass to any server data about which web pages you visit.
Q. Why is BrowserID based on email addresses?
A. First of all, because everybody using the web on a regular basis already has at least one email address and knows it's already used as an identity and authorisation token. Next, because email addresses are not controlled or controllable by any single organisation.
Finally, because practically all websites that require their users to log in already store their email addresses to handle direct communications, password reset requests and other services: therefore, BrowserID gives them a better way to use for authentication some user data that they have already.
Q. Would BrowserID prevent me from using my favourite nicknames on those websites?
A. Not at all. The email address is used only for the initial authentication. BrowserID doesn't limit in any way how a website lets you configure your local account.
Q. Could I have multiple BrowserID identities then?
A. Of course. The only requirement is that each of them is associated with a different email address.
Q. What about other applications, such as chat clients? Could I use BrowserID with them too, or is it a browser-only thing?
A. Yes you could, as long as those programs implement the protocol, and provide their users with an interface to log in to their identity provider to get the keys. These may then be stored in Kwallet or any other desktop-based password manager.
Q. Sorry, what protocol and keys? Is BrowserID based on some sort of proprietary technology?
A. No. Technically speaking, BrowserID is an application of the Verified Email Protocol; a decentralised authentication system based on public/private key cryptography, through which users can prove to a website that they own an email address.
Q. Does BrowserID work on all browsers?
A. BrowserID can work on every modern browser, including mobile ones. The only requirement is that those browsers be compatible with the BrowserID JavaScript API. This said, even if you were forced to use a noncompliant browser, it would still be possible to use an equivalent web-based service.
Q. What should I do to start using BrowserID?
A. You should log in the old way to the website of your identity provider. That server will then tell your browser, through a JavaScript API, to generate a public/private pair of cryptographic keys.
Right after that, the browser will send the public key to the identity provider and get back a signed identity certificate. The browser will then store the private key and certificate as it would do with traditional passwords.
Q. What would happen next, when I visit a BrowserID-compliant website?
A. That website will tell your browser to run a JavaScript function that asks you if you want to log in and with which identity – that is email address.
Q. And when I accept...
A. The browser will send to the website the identity certificate, signed with the private key. At that point, the website will download your public key from your identity provider and verify that the signature is authentic.
Q. And that's how I'll prove to that website that I really am who I say I am?
A. Yes… and no. What this procedure provides is a third-party confirmation (unlike what happens with cookies!) that the authentication request comes from a browser that has the secret key associated to the provided email address. Which means that…
Q. I should never let other people use my browser!
A. That's absolutely true. However, that's the same risk you already face with every other authentication system that doesn't force you to enter a password every time, isn't it?
Q. I suppose that's true, but this also means I won't be able to authenticate from other browsers, right?
A. It depends. That's really up to you. In and by itself, BrowserID does allow you to have one certificate for each computer or smartphone you use, including borrowed or public ones such as internet kiosks. Of course, in those cases you would have to delete the private key and certificate as soon as you're done!
Q. Let's go back to identity providers. You keep mentioning them – who are they?
A. In the simplest and most natural scenario, your BrowserID identity provider would be your email provider.
Q. What if it doesn't support the system?
A. You could still use, without problems, a trusted, secondary identity provider that offers the same services. The Mozilla Foundation, for example, has set up a website called BrowserID.org for this very purpose, in order to speed up testing and adoption of BrowserID.
Q. Ah, yes, adoption. What is the current status of BrowserID? Is anybody already using it?
A. At the time of writing this piece (late November), BrowserID is still in its infancy. Most browser developers haven't announced any official plans to integrate BrowserID support in their software. That's not the main problem, though.
Q. Really? What is it then?
A. The real open issue is if and when the major email providers and online communities, such as Facebook and Twitter, will support BrowserID – that is become identity providers. Especially when, like Facebook, they have their own in-house alternative.
Besides, all these providers would need to agree on a standard way to make public keys accessible. Luckily, none of this makes it impossible to try BrowserID or implement it on your website.
Q. That's cool. How can I try it today?
A. For the moment, the best way to see how using BrowserID looks is to visit the official demo site at Myfavoritebeer.org.
Q. What about webmasters?
A If they use popular open source software, such as WordPress or Drupal, they're lucky: BrowserID plug-ins for those content management systems already exist.
Alternatively, they'd have to follow the instructions for developers published at browserid.org. Even in that case, though, they'd be able to use BrowserID without having to write any authentication code by themselves.
--------------------------------------------------------------------------------------------------
First published in Linux Format Issue 154
