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.

Identity and E-Commerce: Talk @ Cloud Identity Summit 2011

I am attending Cloud Identity Summit in Keystone, CO. It is fast becoming THE identity conference of the year where you can see all, be it small group of,  "identeratees".

I am also giving a talk tomorrow (7/20/2011) @ 4:00pm titled "Role of Identity in E-Commerce' where we share our findings and observations over the past year while building an identity provider for e-commerce sites.

You can see the presentation here:

Identity and E-Commerce

View more presentations from Farhang Kassaei

The slides are not meant to be read, but to support my talk, so they may feel a bit choppy when you read it.

If I want to summarize it, it is

"A viable commercial identity is a Super Identity, one that is not just an identifier but a complete, accurate and up-to-date federated profile compose of attributes from multiple trusted providers, obtained with users' consent and control in exchange for real value"

If you attend the talk tomorrow, please stop by and say hi.

UMA - User Managed Access - Webinar , July 13 9 AM PST

UMA Working group is holding a Webinar tomorrow @ 9am PST. See UMA home page for full details.

If you own/author public APIs or if you write applications that access such APIs, chances are you have heard or know about OAuth, UMA is the next thing you should know about.
No you don't need to implement this tomorrow, but it informs your opinion about a very important and emerging topic: where the right intersection between access to an individual's information and enabling individuals to control that access should be. UMA aims to be the corner stone of that enablement.

Attend tomorrow's Webinar to learn more about UMA.

Power to the People - Data Sharing Power That is - UMA Draft Recommendation Released

After more than a year of hard work, UMA WG (User Managed Access Working Group ) announced the draft recommendation for UMA protocol.

UMA is a communication protocol and is defined by its formal FAQ as

User-Managed Access (UMA, pronounced "OOH-mah" like the given name) is a protocol designed to give a web user a unified control point for authorizing who and what can get access to their online personal data (such as identity attributes), content (such as photos), and services (such as viewing and creating status updates), no matter where all those things live on the web.

Former colleague and current lead of UMA WG @ Kantara Eve Maler gave a very good presentation last year at Cloud Identity Summit that you can see here. There is also a Webinar on July 13.

To explain UMA and what it tries to do, I feel an example works the best (the spec and the terminology are not the easiest way to understand UMA).


Alice is an on demand speaker and celebrity chef, she travels a lot. She uses 

•         A Calendar application,
•         A general purpose social networking site
•         A niche professional networking/community site of food enthusiast
•         Owns a selling account with a popular marketplace for high end kitchen gadgets and appliance.

(All above service are called resources and Alice is a resource owner)

She uses the services of several useful applications:

• Travelers Guide: An application that recommends restaurants and activity in all major cities based on Alice’s preferences of profile on general purpose social network.
• Chef Tracker: An application that notifies Alice’s professional connections and fans when she is coming to their town and where she speaks.
• Merchandise Lister: A web application that lists Alice’s autographed recipe books and limited edition appliances to multiple online channels including the marketplace.

(All above are called consumer or requester)

Alice can grant authorization to the three applications above using OAuth directly. In this case the four resource servers (Social network, professional network, calendar server and marketplace) each maintain Alice’s authorization to respective application(s).

However Alice (a busy professional) does not have a centralized and easy to access location where she can see all the authorization she granted to different applications.  It is true that each resource server maintains a record of Alice’s granted authorization, but since each server has a different way to display the authorization (and they often buried in random places around the resource server) it is unlikely that Alice ever gets a clear view of how different applications are using her information.

Or alternatively, Alice can go to a one server – called Authorization Manager (AM) – and give authorization to three applications at one place.

The benefits are clear. Alice can literally see all applications that access her information (and the extent of their access) at one place. For example Alice can limit the access of Travelers Guide to one week (during which she travels)  

To understand why UMA is important and what UMA does, we should first understand some of the implicit assumptions (or some may argue simplifications) behind OAuth 2.0 authorization.

OAuth 2.0 does require an authorization step, where the “resource owner” authorizes a consumer application to access a resource on his/her behalf. This authorization however requires and assumes:

-       

• Authorization is performed at the time of resource access by consumer
• Resource owner should be present to grant authorization
• Authorization assume that future access to resource is always made on behalf of resource owner  by requester (consumer application) – not on behalf of someone else (say Alice’s assistant in the example above) - This is very important point and deserves its own post :-) OAuth scope does not cover this class of use cases at all.

And more importantly in my view (and from giving the power back to people point of view)

•        Resource owner (user) has to keep track of application/consumers s/he has authorized to access various resource on his/her behalf (how many of you know how many application you have authorized to access the collection of your online accounts? And exactly what type of privileges you granted to them? Think about it!)

Now, granted, this is not OAuth problem, by it is the byproduct of individual consumer obtaining authorization to access variety of resources individually.

UMA is set to address all the above with the introduction of a central Access Manager (AM – in UMA terminology) and, the protocols to connect Resource Server and Consumer to AM.

UMA is an ambitious undertaking (in my experience all authorization initiatives are!) primarily because its success depends on whether users (resource owners) can successfully express policies the govern consumer access to the resources owned by them. This is the linchpin of any authorization project I have ever seen or been part of.

Whether UMA is adopted and implemented as a viable product is remained to be seen, but UMA protocol is a firm step in the right direction.

In the next entry, I will focus on UMA model and associated communication protocol among its participants.