IDENTITY FALLACIES

Phil Becker is Editor In Chief of Digital ID World.  His analysis consistently seems on-time and profound.  I don't think it's well known, but besides his wisdom in business matters, he has an amazing technical background: he wrote some of the code that helped put men on the moon. 

I have to admit that I'm a bit biased towards Phil because his magazine once gave me a prize, which, from a design point of view, was of a distinctly superior quality.  That's a good sign.

But since meeting him I've turned to Phil for a reality check more than once.  Like Doc Searls, Jamie Lewis and Craig Burton, he sees the big picture.  What example should I choose?  Recently, when we were chatting about how to explain InfoCard to enterprise architects, he said, “Kim, stop explaining it.  Start telling people how they can be part of it.  That's what they want to know.”   

Now he has written his “Identity Fallacies” – or three of them, at least.  They offer practical advice for the enterprise and beyond.  You have to love the way Phil explains things.  I hope this post will get those new to the identity metasystem reading his work (the left-brained may want to start at the first fallacy and read forward from there):

Like the second identity fallacy the identity data centralization fallacy recurs frequently because it seems so logical. It has kept identity management the province of very large companies for many years. Thankfully this is finally changing, albeit somewhat slowly.

A significant goal for many identity management initiatives is to gain centralized management and control, and intuitively it seems that the easiest path to that result is to aggregate all the identity data in a centralized data store. But identity data by its nature has distributed origins, and attempting to aggregate the data itself leads to an insoluble set of problems and side effects, especially at internet scale.

Centralization of any data suffers from reliability and performance problems at scale, requiring significant “brute force” to overcome. But when identity data is centralized a huge number of side effects occur that will ultimately undermine the success of the endeavor – even if the technical aspects are successfully worked out. Perhaps the most visible example of this was the Microsoft Passport project. Microsoft demonstrated that the technical problems of an internet scale centralized identity system could be solved. They also pretty well demonstrated that the side effects were so numerous and undesirable that a successfully implemented centralized identity data system wouldn't be accepted by the marketplace. This experience was a major factor in Microsoft's Identity Architect Kim Cameron formulating his Laws of Identity which attempt to describe the attributes an internet scale identity system must have to achieve marketplace acceptance.

It still might seem that in an enterprise centralizing identity data is a good idea. But it generally isn't, for a variety of reasons. First, identity data is a very dynamic thing. It requires constant updating to remain current, and if it isn't current then using it to manage other things becomes risky. Even in an enterprise where identity data seems pretty straightforward, it turns out that it has many different natures that end up forcing portions of it to be managed by very different parts of the business. For example, HR tends to manage actual employees as they onboard and offboard. But department managers tend to manage things like promotions, temporary assignments, etc. that create changes in their identity data and corporate resource access requirements. And who in the company handles contract labor, consultants, business partnerships, etc? Certainly not any centralized business process for them all exists.

The result is that if IT tries to centralize identity data because that makes it easier for them to use it to manage their networked computing resources, they end up creating a structure that is politically and structurally at odds with the business processes of the enterprise. This has brought many identity management projects up short, severely lengthening their deployment times, reducing their scope, and limiting their effectiveness dramatically. In governmental identity projects, centralization of identity data creates most of the limitations that cause political reactions as well.

Thankfully the technology of identity management has begun to move past the concept of centralizing the identity data and is now providing tools such as virtualization and federation that allow the identity data stores to be organized to align with the identity data management while allowing them to be networked, managed by centralized policy, and presented in a variety of ways that don't reflect back on their management. The shift from a directory-centric view of identity management to a provisioning-centric view of identity management is the first step down this road. many more steps are now emerging to widen the applicability of identity to manage broad, networked business process oriented views of computing for regulatory compliance auditing as well.

But as each new person approaches identity management, it seems they have to go through the step of learning why identity data centralization is always a bad idea. it seems only after they realize the implications of this identity fallacy can they move on to understand how identity must really be deployed to be successful.

This is so interesting I can barely keep myself from making a number of comments.  But I need to concentrate on some other burning issues.  I'll come back to this as soon as I can.