BrowserID: A new web authentication scheme

Identity and authentication on the internet is still an unsolved problem. Some sites are delegating the problem to Facebook, Twitter, and others, but that has obvious privacy and control problems, which makes it worrisome for at least some users. OpenID has never really gained much traction, and alternate user-centric proposals, like the related OpenID Connect, haven't either. There are both technical and "social" barriers that haven't been overcome. Mozilla's recent BrowserID proposal looks toward solving a subset of the identity problem by making it easier for users to log in to web applications without having to remember (or duplicate) multiple usernames and passwords.

One of the main differences between BrowserID and the other solutions is that it decouples the identity question from that of authentication. Essentially, using the Verified Email Protocol (VEP) that underlies BrowserID will simply authenticate that a given email address corresponds to the browser that is being used to sign in. OpenID and others supplement that authentication with the idea of a verified identity that could include things like email address, real name, physical address, photo, and so on. BrowserID and VEP forgo all of that, which may or may not make it more palatable to web site operators.

For users who control their own email domain, or whose email provider implements the protocol, VEP's operation is fairly straightforward. The email provider acts as an "authority" to authenticate its email addresses. A user who wants to have a verified email address would authenticate with the authority (via a username/password in web mail application for example) and the authority would make a JavaScript call that tells the browser that the authentication was successful. That call would then generate a public/private key pair, sending the public key to the authority and storing the private key locally. A user could have multiple identities, each tied to a unique email, at one or more authorities.

When the user logs into a site that allows VEP authentication (i.e. a "relying party" or RP), they would be prompted to choose one of their email addresses to use. The browser would then create an "assertion" that listed the email address, a timestamp, and some other information, sign it with the private key, and send it to the site. The site then contacts the authority to get the public key for the user and verifies that the assertion is correctly signed. At that point, the web site can be sure that it is talking to a browser that is (or was at one point) controlled by a user with that email address.

Obviously, email providers are not likely to be falling all over themselves to implement an in-progress protocol, and it may be years—if ever—before they do, so VEP has the concept of "secondary verifiers" that would be stand-ins for the email provider authorities. If the user trusted the secondary (to respect their privacy for example), they could establish their control of a particular email address via a link in an email sent by the secondary. That would include the browser in the transaction so that the key pair could be generated and the public key sent to the secondary. If an RP also trusted the secondary, it could retrieve the public key from there and verify the authenticity of the email-browser connection that way.

In addition, some smaller web sites might wish (or need) to farm out the verification to a verification service run by a trusted third party. As the VEP wiki page notes: "These services obviously have tremendous power and would need to be constructed with both technical and legal care."

Doing a round-trip SSL transaction to an authority (or secondary verifier) whenever a user logs in may add unacceptable latency to the log in process. It would also leak information about which sites a user is visiting to the authority. One way to handle that is with an "identity certificate" that contains the user's public key and is signed by the authority. That way, a web site would only be retrieving the authority's public key, not the user's, and that authority key could be cached by the site to eliminate all but one of the retrieval round-trips. But that raises the problem of key revocation.

VEP is certainly not alone in having that particular problem. To a certain extent, all public key encryption mechanisms suffer from key revocation problems. In fact, key management is one of the hardest problems to solve for public key cryptography. As the VEP page notes, there are already problems with revocation for SSL certificates:

Much of the actual guts of the protocol are still being worked out, and it is interesting to see that some flexibility in the protocol is envisioned. The wiki document describes it this way:

There are, of course, some concerns about BrowserID, not least the fact that an enormous amount of sensitive information would be stored by the browser (i.e. any public keys the user has generated) on a user's computer or device. In some ways, though, that's not much different than the current practice of storing username/password pairs for multiple web sites. Protecting that data store is clearly of utmost importance (whether BrowserID ever takes off or not).

BrowserID itself is a JavaScript implementation of VEP that will run in "all modern browsers, including recent versions of IE, and on mobile browsers" according to the Mozilla announcement. In addition to that and the VEP documents, Mozilla has set up browserid.org as the central location for information about the protocol and implementation.

Mozilla would clearly like to see other browser makers, users, and web sites work with it to firm up BrowserID and see it headed in a direction toward deployment. It's unclear whether that will happen or whether BrowserID will be yet another failed identity experiment. It certainly does have some interesting properties, and would allow sites to gather the extra information from users that they crave (i.e. beyond just an email address). When a user sets up an account, the application could request or require much more than just the email address it needs for authentication. The lack of that extra information is part of the reason that OpenID has never really taken off (and why OpenID Connect was proposed). One thing seems sure, solutions to this problem (or related set of problems) will keep coming up until something that is easy to use and can cater to privacy-conscious users actually becomes widespread.