Dick Hardt dot org

The Mozilla Identity Team  recently released BrowserID, a user-centric identity initiative that uses email as the identifier. The Drupal community, typically quick to support open identity protocols, released support within 24 hrs, which shows how easy it is to implement.

If you read my recent post on the OpenID Foundation, you will know I am disappointed in the direction of OpenID. I am encouraged that BrowserID has many of the core features I was hoping would emerge in OpenID v.Next. There has been a reasonable amount of online coverage of BrowserID, what it is, and how it compares to OpenID. I’ll focus on what I think are important issues that I have not seen covered. 

User-centric

Unlike OpenID Connect, BrowserID is user-centric aka Identity 2.0. With the demise of InfoCards and the service-centric approach of OpenID Connect, it is encouraging to see the emergence of user-centric proposals. While in some ways subtle, I think this is an overlooked feature.

Email as Identifier for Others

There has been plenty of discussions on the pros and cons of using email as an identifier. There is an important pro that seems to be missed. It is the only widely adopted, non-proprietary identifier for other people. When you want to share information or communicate to someone online, we usually have an email address for the other person. With the rise of sharing online as supported by Zuckerberg’s Law of Social Sharing, critical function of an identity system is how we identify other people.

Will BrowserID Succeed?

At IIW 11 I led a session on the Decline of User-Centric Identity  which tried to cover reasons why InfoCards and OpenID failed to provide a wide spread, user-centric identity solution.

Business Motivation: While the idealists amongst us are keen to promote the “Open Web”, the business reality of running a website will trump idealism for most sites. The BrowserID web site answers questions about how to implement BrowserID, but punts on why an Identity Provider should implement and there is no mention on why a Relying Party will implement. Without appropriate financial incentives, there will be no widespread adoption. The financial incentives of course tend to be indirect: my site has less friction for user registration, I have a deeper relationship with my users etc.

Open Web: Facebook, and to a lesser degree, Twitter, are becoming the defacto identity services on the internet. I currently don’t see any motivation for either Facebook or Twitter to adopt BrowserID — they have their own identity systems which strengthen their respective positions as critical internet infrastructure. While idealists talk about the virtues of “open”, the business driver behind “open” has been to unseat incumbents. As a non-profit whose raison d’être is to ensure the web is open, it is clear why BrowserID came from Mozilla. But why would any of the other players participate? To succeed, the BrowserID community needs to figure out how to bring in enough other players that are motivated to have an alternative to Facebook and Twitter.

Non Browser Support: The web has evolved since the introduction of OpenID. Support for non-browser applications has become critical with the explosion of native mobile applications. Authenticating a user on a mobile device is more cumbersome than the traditional web SSO challenges, and a good solution to mobile SSO can gain significant traction because of the current pain. A number of us in the identity community have commented that if a good solution to mobile SSO emerges, that likely will become the web SSO solution. Unfortunately, BrowserID has been positioned as a web SSO solution, and the lack of native client support is an issue. While BrowserID has many of the right attributes, it may not succeed because it does not solve the new, emerging pain points.