Before we can have user-centric identity in the enterprise…

…we need to understand what user-centric identity is.

That is the current state of discussion in the identity community. Many people are debating what user-centric identity is. Is it an architecture, is it a design philosophy, or is it a set of business agreements governing user interactions in certain systems? During the course of the debate (still on-going), the only thing to become clear is that it is still early enough in the evolution that everyone has their own definition. That is why you will probably see a lot of products emerge in the market that claim to be user-centric, yet have very little in common.

A recurring theme in the discussion is that user-centric identity is about giving the user control of their identity. The question is “how”? One persistent topic of debate is whether “user-centric” is the same as “user-in-the-middle” in the context of identity flows. In other words, to be user-centric, is it necessary that all identity flows involve the user in the middle of the flow, providing the explicit go ahead before the identity data can cross some domain boundary? The reasonable answer would seem to be “No”, since putting the user in the middle would create a scalability issue gated on the capacity of the user to respond. Imagine having to approve every single identity flow that occurs pertaining to you. It also creates issues of responsiveness and timeliness around flows that happen while you sleep, while your email server is down, etc.

Digging a bit deeper, it would seem that “user-centric” identity is about creating an “agent-in-the-middle” architecture for identity systems. An agent (usually automated) for the user sits in the middle of the identity flow, analyzing the flow request and determining how to handle the response. The determination would be based on policies defined by the user. It may require the agent to bring the user in for an explicit approval, or it may automatically approve or reject the flow based on previous user preferences (similar to the user checking the box that says “do not ask me again”). It may also apply a configured rule or policy to the identity flow that determines the action to take – ask user, approve, reject.

The agent could be the IdP, or some other kind of identity system. There seems to be a lot of skepticism about whether IdP’s would ever be in a position to act in the users best interest. In some cases, it could be a self-asserted IdP. However, in all cases, it enables automated decision making while not preventing user involvment, preventing user control from becoming user headache.

What all this means in the corporate world is still to be seen. An interesting side effect of this discussion is that people have actually started to examine the impact of the “user-centric” notion on federation, even debating what exactly constitutes federation.

This promises to be an interesting debate, with the outcome having the potential to impact the way we interact with systems in our daily life. Stay tuned.