Home of the Mozilla Identity team
We launched Mozilla Labs’ online identity experiment, BrowserID, only 24 hours ago, and the feedback has been incredibly useful already. At Mozilla, we believe in empowering individuals to shape their online experience. Our work on a decentralized identity solution for the Web matches that mission well. Also, because we believe that transparent community-based processes promote participation, accountability, and trust, we will be posting technical explanations, points of debate, and roadmaps on this blog.
One important question we immediately received from early adopters is how BrowserID compares to OpenID. Both projects have three important common goals:
(a) make it easier and safer for users to log in to web sites by reducing the number of passwords they have to remember,
(b) make it easier for web sites to add authentication features, and
(c) accomplish all of this in existing modern browsers.
Beyond these similarities, we think Mozilla Labs’ BrowserID project provides a few key advantages over OpenID. Lloyd Hilaiel has written an excellent technical primer on BrowserID, which highlights our key design goals. These have led us to three key differences.
Users understand that an email address is like a persona. People typically have a work email, a home email, and maybe more. For developers, email addresses are useful, too: they are unique and provide an obvious contact mechanism when developers inevitably need to contact their users. With OpenID, the user’s email address may be available to Web sites requesting authentication, or it may be absent. In any case, it’s not the identifier. We believe that, for both developers and users, an email address is the right identifier.
With BrowserID, by design, your identity providers are not involved in the login transaction. This means they need not be aware of your entire Web activity, a significant privacy advantage. With OpenID, your identity provider is, unfortunately, a necessary participant in the login flow.
Web-based login systems may increase the risk of phishing attacks if users become accustomed to typing their password into a dialog that an untrusted web site opens up for them. So, eventually, we want the login activity to happen within an easily recognizable, fully trusted browser UI. Because OpenID was designed primarily for use with zero browser intervention, it’s difficult for the browser to step in and provide that more secure login experience: we’ve tried, and haven’t found the right user experience. Mozilla Labs designed BrowserID with the specific goal of making it easy for browser vendors to implement directly, without preventing pure HTML implementations like the one we deployed yesterday. To explore how the integration of a secure BrowserID user interface could work in a browser, we’re developing a Firefox add-on. And, in parallel, we are open to working with other browser vendors who want the same functionality, of course.