Earlier this year there were a number of interesting comments from Eric Norlin and Dave Kearns about the term “user-centric”. Since reading those comments I have become more aware of some ambiguous meanings ascribed to the term. I definitely agree that “user-centric” is unproductive as some sort of vague mantra — though I also believe that we should be aware of what values are enabled or enforced by the code we produce. What would be most useful now would be to focus on what user-centric identity systems actually do for users and companies.

Along those lines, at Novell’s Brainshare conference there was a panel discussion about “Open Source and User-centric Identity in the Enterprise”. The discussion was moderated by Carolyn Ford, and included Kim Cameron, Pamela Dingle, Patrick Harding, and myself. A video of the session is available (though there are technical difficulties and the guy on the far right looks like a complete dork).

Before we could discuss how user-centric identity systems may or may not be useful in the enterprise, we needed to get some idea of what we mean by “user-centric”. That was the opening question to the panel. Since audio is not clear in the recording, I thought I would write up some of what I may have said.

I see three possible ways that an identity system could be thought of as “user-centric”.

1. User as source of identity data

The user is the authoritative source of self-asserted identity data. Duh. This may sound circular, but it is helpful to contrast it with the next statement. Network services are not authoritative for self-asserted data — yet they currently often handle such data as if they were.

I have read articles where this meaning for user-centric identity is used to explain why it is of no value to the enterprise. The conclusion is that self-asserted data is of no value in enterprise systems. The implication sequence is: self-asserted => ability to lie => untrustworthy => low assurance => no business value. But this reasoning is overly simplistic. Users are authoritative for some information, e.g. their password, or their home address, or any information related to their intent as an employee within a business transaction.

Note that authoritative depends on the context. A self-asserted shipping address may be good enough for some network services and not others. Anything that a user puts in forms now is self-asserted data and currently accepted as authoritatve within that context. I hate forms and I want a system to help me with them.

So user-centric could mean helping users manage self-asserted identity data.

2. User as control point for release of identity data.

In this perspective, the user may not assert the identity data — but has a vested interest in where it is released. I may not determine my social security number, or my credit score, but I care to whom that information is given. In this view, identity data is more like a controlled substance and the user is an active participant in it’s distribution.

For example, information card systems allow for assertions of identity data to be securely transmitted from an authoritative source to a network service in such a way that the user cannot tamper or see the data, yet is a control point for the release of the data.

Managed information cards can also be issued in auditing or non-auditing mode. In auditing mode, the identity provider knows where the identity data is to be sent and can control if and what data is securely sent. In non-auditing mode the identity provider does not know where the data is to be sent, which also has valid use cases. In either case, the identity provider is authoritative for the information, but the user in the center has a valid interest in controlling where the data is released as well.

So user-centric could mean helping users appropriately manage the dissemination of information about them.

3. User as center of their identity world

Yet another aspect is that user-centric could mean that only the user can corelate all of their accounts. In this view, user-centric is opposed to a central repositories for general identification of users. Only the user knows she is LacrosseMom to one service, acct 345678 in another service, and Sally in a third service.

So user-centric could mean the user is only point of linkage between some identity sources.

All of these perspectives are useful, and they are all useful within the enterprise, outside of the enterprise, and especially when crossing such boundaries.

For me, I think the 1st and 3rd perspectives are important, but the 2nd perspective is the most interesting and significant for current system development.