If you glance at Johannes Ernst's latest blog post, Why We Really Don't Need an "Identity Selector", you might think he's speaking out against identity clients, but in reality, he's speaking out against identity "selectors." That is, the idea that the most important, useful feature of such a client is "selecting" an identity. He says:

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.

From Johannes Ernst's Blog » Why We Really Don't Need an "Identity Selector"
Referenced Tue Nov 10 2009 21:25:44 GMT-0700 (MST)

I agree, but I'd argue that it ought to do even more than this.

At Kynetx we're building a platform for creating what we call purpose-centric applications. These apps are necessarily client-side because the client is the only place that sees all of the user's activity and thus the only place that can mediate on the user's behalf.

Consequently, I think that the client ought to also:

• Help users manage the apps that mediate their online experiences on their behalf
• Provide a way for users to provide feedback about such applications and show the reputation of each app based on that feedback (among other things)
• Provide security and privacy warnings to the user
• Mediate data requests for the user's personal data store and other data sources (i.e. data authorization)

Of course, it ought to do the things Johannes recommends too--why not? But as he correctly points out, authentication is a small part of the overall experience and we ought not name the whole client based on 0.5% of the interactions. What should we call it? I don't know yet, but I'm sure Craig Burton could come up with a few suggestions.

Why put this in the identity client and not somewhere else? My first answer is that we've we've been using a selector to do this for 12 months and it feels natural. The second answer is that client-side, experience-mediating apps deal with lots of personally identifying information. Indeed the security, privacy, and data autorization tasks I mention are part and parcel of the larger "identity management" world.

You might say, but couldn't this be built into the browser? No, unfortunately. That would be easier in the short term, but it won't solve the problem; the apps might be mediating the user's email or IM interactions outside of the browser. I think a separate interface provides greater opportunity for a better user experience.

Kynetx apps need a client that performs these services. Whether we can define them for some generic "action card" concept inside Information Cards or whether we end up building a client that functions as an Information Card selector but also adds additional features like Johannes and I propose is an open question. I've never been shy about building what I need, but I'm also not anxious to reinvent to wheel if something out there meets the need.

In any event, I'm convinced that more full featured identity-management, app-management clients will need to be built to support the coming purpose-centric web that is unfolding. If that idea intrigues you, join us next week at Kynetx Impact.