Why We Really Don’t Need an “Identity Selector”

As of this week’s Internet Identity Workshop, I’m now rather convinced that an “identity selector” is the wrong product and the wrong feature set, regardless of the exact details of a particular vendor’s implementation. Several discussions in several contexts, including how to best make a browser identity-aware, all point to the same conclusion, regardless if the context is a card context or an identifier / OpenID context. Something had always been bothering me about the identity selector concept over all these years since I saw the first CardSpace demo, and now I know what it is.

To make my point, consider the interaction of a user with a site over some period of time:

Here, the user (necessarily) is anonymous at the site when visiting for the first time. As time progresses, the user may chose to register at the site (and log in at the same time), and then continue to have an active session for some time. This session later times out and the user returns to the site after the timeout. The user authenticates again, and later logs off intentionally, after which (one hopes) the user is anonymous again for the site.

The blue sections in the diagram show the times at which an “identity selector” is useful: upon initial registration, and then again upon re-authentication. However, compare these minuscule amounts of time with the time that the user and the site have a relationship with each other centered around the user’s identity. If it takes me 20 seconds to log in, for example, but I stay at the site for an hour with the authenticated session, the “identity selector” helps me with my identity at that site only for 0.5% percent of the time.

What about the other 99.5%?

We need functionality in the browser, or at least somewhere close to the user when using a web browser, that assists the user 100% of the time their digital identity is in the picture, not 0.5% of the time. By thinking of that product as an “identity selector”, we are excluding the other 99.5% and thus are getting the product exactly wrong.

The correct product is not a “selector”. It also must be:

• An identity “de-selector”, with which the user can become anonymous again (or perhaps even remove all the information from the site which was conveyed during the “identity selection” phase). The much-desired “single sign out of the web” button should logically reside there.
• An identity-aware session “visualizer”, which conveys to the user that there they have open sessions with which sites, which of the user’s identities are currently used with which site, which others they have used with which site in the past, whether the session is valid (as opposed to expired), what information about them they have shared with the site and perhaps how to log out.

This is particularly important if the user has multiple active sessions, perhaps with multiple identities, occurring in parallel, such as in multiple browser tabs — increasingly a fact of life for many internet users. Keeping track which sessions are still open, and which can be easily reactivated (e.g. by an OpenID checkid_immediate check) is cognitively impossible for many people (myself included) and computer support in the browser (not on the browser page) would be really useful. Throw in the use case of somebody briefly borrowing the computer to check their e-mail or Facebook account, while the primary user still has all their windows and session open, and perfect confusion ensues with a range of scary security and privacy issues around them.

So, what we need is not an “identity selector” for 0.5% of the time we use identity in the browser. What we need is a continually active, perhaps proactive assistant that helps us create and tear down sessions, watches our sessions, keeps track of the information that flows back and forth and helps us when we need it, 100% of the time.

Now I’m not a usability guy by any stretch of the imagination, but the following strawman picture popped into my head earlier today. It could live somewhere in the sidebar:

Each active session could have a separate section (rather like the Windows task bar). It would show the name of the site, whether or not the user was currently identified there, and the user’s current identifier (or card) there.

To log out, click the “x”. To log out everywhere, click the big button. To reactivate an expired session, click on the red light and it will turn green if re-authentication was successful. Clicking on the section could bring the tab / window to the front that belongs to the site, like in Windows or OSX. Right-click would show the information that has flown between user and site so far, perhaps with a time-based log. And so forth.

An alternate version could sort by identity first and then by site (as opposed to this figure, which is sorted by site and then by identifier). That might be useful, too.

But regardless of the details of this strawman screen shot, which you may or may not link, I think the idea of covering the entire lifecycle of the user’s identity-based relationship with a site would lead to a much more useful product than a mere “selector”. Many others at IIW seemed to think so, too, but I’ll let them speak for themselves if they feel inclined to.

Yes, we don’t have the protocols and conventions for all of this. But I don’t think they are hard either, so that should not be an excuse.

Let’s mull this a bit … at least one major browser manufacturer does not seem to be too disinclined to go in this direction… with a bit of squinting, today’s identity selectors could even be re-interpreted as version 1 of the more inclusive approach…