BrowserID...and the search for perfect Identity Selector

This is a long post, and here is the gist of it:

In general I think we, as identity community, are still looking for a practical solution to a simple yet adequate "identity selector", CardSpace represent a solution on the rich and complex end and BrowserID represent a solution on the simple (but not rich) end, every solution is a valuable iteration to the final solution of the perfect identity selector - I feel the iterations will continue.

Now, here is for those you are interested in the details:

A few days ago Mozilla announced the availability ofBrowserID. Identity is a hot topic these days, so almost immediately the community (and my mail box) was buzzing with predictable questions such as:

• Is BrowserID the next generation of OpenID?
• What are the differences between OpenID and BrowserID?
• Will BrowserID is the answer to Identity on the web?
• Is BrowserID secure?
• What is the relationship between BroswerID and OAuth or OpenID Connect?
• Should I implement BrowserID now?

All legitimate questions to be sure, but perhaps a few of them could have been clarified more easily if Mozilla had called this feature, say, “Verified Email” – after the title the specification the BrowserID is based on (see Averified email protocol for the browser). I think that would have been a name that reflected the intent and use of this feature and helped answered these questions.

In this post I write about where I think BrowserID would fit in the space and, as risky as it, venture a guess as to whether it will be adopted by identity providers and relying parties (not wise I know…but hey this is a personal blog) - if you want to read more about the implementation details of BrowserID see a very good writeup by Lioyd Hilaiel here, and I also recommend reading Dick Hardt notes on BrowerID as well.

To start let me summarize what BrowserID is. BrowserID is a protocol for 

- Verifying users email addresses (as many as a use wants) as reported by an email provider (or Identity Provider)

- Storing it in browser (Firefox as of now) safely - or one would hope so.

- Transmitting email address safely to a "relying party" that is a site that requires an email address securely.

It uses PK cryptography to ensure integrity of all communications. BrowserID requires two key pairs, one generated by IDP (email provider) to sign the assertion (email x belongs to subject y) and another key pair generated later by browser to sign the (subject+email+IDP public key) token and pass it on to relying party (that is your web site). So it is reasonably safe and uses a subject confirmation method known as "Holder of Key.

So how should one use BrowserID? is this OpenID? is this a replacement for OAuth? 

I think the proper use of BrowserID, if it ever gets support from other browser vendors, is to replace the annoying "email verification dance". BrowserID is a fantastic lower level solve for this problem. Is this a replacement for OpenID or OpenID Connect? I think not! does it replace OAuth, absolutely not, there are simply two different things.

BrowserID, in my view, really is not an ID - my definition of identity is something I can replace registration with, not just login panel. 

An identity is more about attributes than about authenticating an identifier (such as email address). and BrowserID is by design is silent about that matter, in the words of Mike Hanson, the author of Email Verification Protocol:

"The idea that led to the BrowserID work was not "how can we fix identity on the web", but "what is the smallest possible claim we could make to make progress on the browser as a claims agent?"

And

 

"...Attribute exchange is deliberately out of scope"

Mike states the design goals clearly and the solution achieve its goals perfectly, the only thing that complicates the matter is the name BrowserID and the fact that identity means so many things to so many people.

Will BrowserID be adopted widely as a form of identity? will it replace your login button? I have my doubts on both counts.

First off, let me say that I would use BrowserID for email verification (if it is adopted by consumers), it is a very elegant solution for that. As for wider adoption as a form of identity, let's look at the three main actors in any identity ecosystems: RPs, IDPs and User/Consumers.

For a large number of relying parties, an identity provider that simply asserts one attribute (email address) is not valuable enough to dedicate scarce real estate of "login page" to (and add to their NASCAR complexity), RPs would opt for richer IDPs (Facebook, G+, Twitter etc.), that way they not only get an email address by rich set of information about a user (you may ask how about privacy? more on that later). 

IDPs (for example email providers such as Gmail, Yahoo, MSN etc.) also do not have clear cut incentive to support BrowserID  - maybe receiving fewer number of "confirmation emails"? Entities such as FB and Twitter are unlikely to support BrowserID (x@y.com does not have to be a real email address, it is simply an identifier so FB could decide to support user@facebook.com) since they are strategically dedicated to have a presence on RPs login pages and not to be inter-mediated by Moziall's sign-in button.

There are also a few questions on the users adoption, prime among them is what happens when a user switches browser or device (with most user today using more than one device/browser to access the internet)

and to lesser degree whether general population of user will sufficiently understand the use experience.

Finally I have to say I am impressed by one aspect of implementation (which I assume was a lesson learned from CardSpace lack of adoption) and that is the near dead simple implementation for RP sites.

In general I think we, as identity community, are still looking for a practical solution to a simple yet adequate "identity selector", CardSpace represent a solution on the rich and complex end and BrowserID represent a solution on the simple (but not rich) end, every solution is a valuable iteration to the final solution of the perfect identity selector - I feel the iterations will continue.