Top 5 Identity Fallacies: #4 Identity is Monolithic

Top 5 Identity Fallacies: #4 Identity is Monolithic

Summary: There are several fallacies which appear and reappear in identity discussion, technologies, and deployments. This is the fourth article in a series which examines these fallacies, why they are so easy to fall into, and what their consequences are in networked computing.

SHARE:
TOPICS: Security
2

Those who have been reading these identity fallacies will find a theme emerging from them. That theme is what I refer to as "The Einstein Fallacy." I derive that moniker from the apocryphal comment attributed to Einstein that "Everything should be made as simple as possible, but no simpler." The Einstein fallacy is thus to conceptually oversimplify a problem in an attempt to make it easier to solve, creating a conceptually flawed model.

A great many technological fallacies fall into this category, because part of good technology thinking and design is to simplify things where possible. When doing so on new and incompletely understood concepts, however, people can easily oversimplify things, leading to fallacies such as those I highlight in this series. If these fallacies become institutionalized in early technological developments, they create both bad paradigms and groups of people committed to perpetuating them. In extreme cases, this can dramatically retard technological understanding and development. This has happened in the development of identity technology, but thankfully we are being forced to move beyond many of these conceptual roadblocks by market forces.

Webster defines Monolithic as "consisting of or constituting a single unit" or "constituting a massive undifferentiated and often rigid whole" Dictionary.com defines it as "Constituting or acting as a single, often rigid, uniform whole." So how does this apply to identity, and why is such appliation a fallacy?

Identity management began as an effort to build network authentication and authorization to replace what had been lost with the move from a mainframe computing environment to a networked computing environment. The mainframe environment was a closed silo with a clearly defined perimeter. Once a "user" was authenticated to the mainframe O/S, applications could leverage that authentication to do such authorization as was required and all was well. The initial mission of identity management was thus to find ways to restore that type of authentication and authorization as an abstraction layer in a networked environment, and its focus was largely on employees in the enterprise.

With the problem thus narrowly defined, many simplifications were possible. Some of these, such as Identity is Hierarchical, and Centralized Management Means Centralized Data seemed logical, as this was the structure of the original mainframe environment authentication and authorization systems. It also followed that identity must mean a globally unique identifier for each employee, with the various attributes of that employee (such as address, telephone number, access permissions, etc.) hung off of that identifier. In other words, a monolithic data construct known as a digital identity would become the basis of networked identity management.

As long as identity was able to remain confined within the strict domain-centric enterprise intranet environment the assumptions stemming from the over simplification that "Identity is Monolithic" could largely be dealt with - albeit often at tremendous cost in skilled human labor. The first glimpses that identity might not be monolithic began to arise even in this environment, however, as enterprise identity management scaled to address networked applications that spanned multiple enterprise domains. Even doing what seemed a conceptually simple identity based task such as SSO began to reveal that the monolithic identity was becoming extremely context sensitive.

For some time, identity management attempted to deal with this by making the attributes of the monolithic identity richer and more granular. But the concept of a globally unique identifier (GUID) as the handle for a "bag of attributes" monlithic identity started to exhibit side effects, some of which even ran afoul of laws when crossing country boundaries. But the myth of the monolithic identity largely survived this. With the addition of context, distributed data sets, virtualizing views, etc. most problems could be solved without realizing that the nature of identity itself had been misperceived.

The advent of using identity to automate compliance, however, has brought us to the moment when the concept of a monolithic identity must ultimately crumble, being revealed as an over simplification of the model (or paradigm) of digital identity. The rapid growth in the understanding of the nature of identity being forced by the looming deployment of significant user-centric identity systems, coupled with the growing cross-domain requirements for enterprise domain-centric identity, is attacking the monolithic identity model from still other directions.

It is all revealing that identity is not just contextual, it is multi-dimensional - a distributed, nuanced multi-vectored concept all its own. And using digital versions of identity to manage networked computing without creating large scale highly undesirable side effects will ultimately require models of identity that reflect that while Identity *is* Center in networked computing, identity is distinctly *not* monolithic.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • Top 5 Identity Fallacies

    The concept if simplicity appears to have been introduced by William of Occam with a concept that was paraphrased by Newton as, "When you have several explanations as to whyor how something happens, the simplest is usually correct." I feel that the result of your debate is correct, but am less happy about how you got there. And, to take your analystical approach, the reason it all went wrong is because the approach was flawed. The question should have been, "What is the simplest way to achieve the requirements that networked identity managemen is supposed to deliver?" The question that was actually put was, "What do we have to do to make what we already have appear to do something it was not designed to do?" Similar criticism would apply to the idea that SSL provides full protection for the data (it doesn't. it just protects a connection), or that PKI is a business tool (it isn't because it is applied to individuals and not businesses). That's why I think you are right.

    Internation standards such as ISO 15944-1 recognize the multiplicity of requirements that can be used to define the Person. But of course most suppliers trot out the argument that 20% of the work required to do the job will meet 80% of the theoretical requirements. That is valid where the implementation architecture is 100% correct. The IT industry has no shortage of examples when it was not and the products died.

    Let us hope Identity Management does not have to go through the catharsis of PKI before it sees the light.

    Kind regards

    Steve Mathews
    ArticSoft
    stevem_001
  • A Web site as a central identity repository

    Hi, I'd be interested to see what you think of my post at http://jasonkolb.typepad.com/weblog/2006/06/defragging_my_o.html

    I kind of went through the same thought process you're describing in this post and ended up here--I'd be interested to see what other think of the idea.
    jasonkolb