A potential solution for a long-standing problem on the Web: Identity

As 2012 begins, it isn’t too late to add my voice to the growing chorus of at least provisional support for Mozilla’s web identity scheme, BrowserID, which is the most encouraging proposal being floated for its general purpose so far.  From the standpoint of a web site developer, it should eventually replace most or all uses for OpenID, as well as some of the requirements satisfied by OAuth.

For any identity management protocol to really succeed on the Web, it must offer value to Web sites and users alike.  In practical terms, it has to be open and freely available; it must be free of known security flaws; it must be seen to exceed the value provided by competing solutions; and like all software, it must expose a user interface that assists users to build in their heads a simple (even if incomplete) mental model for how the system works, and how it will help them.

Finally, and perhaps most importantly, a decent identity scheme should model some characteristic of the person or entity using it, that the user already considers to express their identity in some sense reasonable to them.  In the real world, people have proven to be willing to treat government-issued numbers and ID cards as equivalent to their identities within at least the contexts in which the cards and numbers are meant to be used.  In fact, they’ve been far too ready to accept imposed solutions, but this fact in itself proves the point that, for better or worse, in routine use, the user-perceived benefits of an identity solution trump every other consideration.

Practical value, in turn, depends partly on critical masses of users, and of the services that rely on their provided identities.  Ubiquity is a plus for identity solutions because it eases some potential pragmatic concerns, but it isn’t strictly necessary, and of course even ubiquitous availability is worthless if the solution is not otherwise completely satisfactory.

BrowserID gets more of the ingredients right than any other solution I’ve seen:

1. It fundamentally depends upon the unique online characteristic of a user that is more widely already understood as an expression of identity than any other: their email address(es);
2. It delegates trust for password and account management not to any single central authority, or unrelated, possibly self-serving entity such as Facebook or Twitter that purport to provide authenticated identities, but to an institution the user may choose freely but, once chosen, they already must trust: their email service provider(s);
3. It delegates operational responsibility for certificate management to the software component the user already must trust for assuring certificate-based server identity, their web browser(s);
4. It eliminates any responsibility for relying web sites to store and manage user passwords.  The only password in the whole system is the password on the email server that already authenticates the user for access to their email repository.

Most existing identity services provide one or more of these advantages, but none that I am aware of, other than BrowserID in its eventual, complete form, adequately address all of them.

Current Issues

BrowserID is currently incomplete in two key areas.  For one thing, until email services buy into BrowserID and implement it on their sites, a secondary identity provider (IDP) is needed as a proxy between email services on the one hand, and the browser Javascript and web server-side stub that implement the BrowserID relying party and client side.  A separate password is accepted and validated by this secondary provider to allow it to associate a user with their validated email addresses, which weakens BrowserID strengths 2 and 4 (above) until the secondary IDP is eventually superceded.  Meanwhile, Mozilla.org itself has provided a central proxy server as the first secondary IDP.

The second element needing completion, and which is probably crucial for security, is for the BrowserID code to move from its current home in JavaScript served to browsers by relying web servers, to native code integral in browsers, the same as existing SSL certificate management has resided in the browser’s codebase almost since the Web began.

Once these two relatively simple improvements have been made, most or all of the existing security concerns with BrowserID will be resolved, and sites like the “payment system++” that I’m currently working on can safely enough rely on BrowserID to provide assured identities for their users, while never seeing passwords, or making their users create “new”, unfamiliar identity representations such as OpenID URLs.

Unless significant fundamental weaknesses are identified in BrowserID, I look forward to a future in which all leading browsers implement BrowserID for users who choose to use it, so they may safely identify themselves to the web sites they wish to use.  I see BrowserID as the only currently plausible single web standard for identity — analogous to how the existing, much more complex system of X.509 SSL certificates and signing authorities are used as the sole de facto standard for their purpose today.

It’s early in BrowserID’s history, but even so, for the high-level reasons I’ve stated, the new sites and services that I am responsible for architecting will begin to offer BrowserID as relying parties, at least experimentally.

Selected Resources:

• Mozilla’s user-oriented intro to BrowserID
• A third-party BrowserID description (reviewed by Mozilla developers)
• Mozilla’s own BrowserID Security Review
• How BrowserID Works (in federated identity terms)
• A comparison between OpenID, OAuth, and BrowserID