Our good friend Ian Glazer from Gartner is out with an excellent but provocative new video, where he proposes that we need to kill identity in order to save it. Now, I prefer evolution to revolution, but this video should spark a conversation that’s long overdue—about how yesterday’s identity infrastructure can meet the demands of today’s Internet, where we’re all a hundred different “personas” on a thousand different sites. Where the forces of access, security, and privacy are all dueling it out (and privacy is losing). Where the world is smaller than ever before, but also overflowing with information, opportunity, and—yes—risk.

There’s a great discussion of this new reality in last week’s The Economist, about who’s going to profit from online identity, and how acting as a certified, trusted identity provider is a key function that should not be left to government entities or loosely managed by Facebook or other new social networking “properties.” But today, I want to focus on Ian’s battle cry. In this video, he has come down the mountain with tablets for a new identity, ready to wage war against the “comma.” It’s time to replace the existing identity management—based on LDAP—with REST, JSON, OpenID Connect, OAuth 2.0 and SCIM, he tells us. IdM is all over but the shouting.

Now, don’t get me wrong. I welcome those standards—in fact, our latest version of RadiantOne supports SCIM and a REST interface to our federated identity system, while our CFS service supports OpenID Connect and OAuth 2.0. And I totally buy into Ian’s analysis about the core issues facing our current approach to identity and access management. But I don’t think we need to sacrifice anything.

What Ian Gets Right: The Issues Facing IdM Today

Ian begins with the notion that today’s identity is static, which no longer works when everything is interconnected. We must be able to mirror the relationships, the graphs, the networks that are driving everything around us, he says. And he’s absolutely right! I love how he looks at the current provisioning life cycle, saying that it doesn’t move as quickly as our partners or their customers—or even our own employees—which is really the crux of the challenge. To make identity a competitive advantage instead of an IT cost, it must enable you to collaborate across and outside the corporate walls, and to expand your customer base beyond your current channels. And true, this is a huge challenge, given current constraints. But then Ian jumps to some observations, recommendations, and conclusions that strike me as controversial.

Where He Goes Wrong: Is the Remedy Worse than the Disease?

According to Ian, comma-separated values (CSV) are too simplistic a mechanism for data representation and data transfer in today’s web-driven world—and LDAP is way too inflexible with its hierarchical infrastructure. Instead, we need a graph, a full network of the relationships between nodes/entities. The solution, he says, are new standards, such as OAuth 2.0 and REST. And we need to kill our current IdM systems to get there.

We could not agree more with Ian’s analysis of the state of IdM—but we disagree on the solution. I’ll be looking at why over the rest of this post, then developing these ideas in greater depth over the next few weeks. (I’ll even give a defense of the poor old comma, which gets quite beaten up through the course of Ian’s video.)

Meet the New Standards: Same as the Old Standards?

Like any IdM veteran, I understand how static the current system is, with its jumble of application silos and data stores, where any changes take months of your life, big bites of your budget—and often hairs off your head. You need a system where the definition of identity attributes can evolve depending on context. Do I like the definition of an identity OAuth 2.0 style? Sure, as much as I like LDAP’s “InetOrgperson” in some use cases or even Microsoft AD’s definition of a “User” in other circumstances. There is no ultimate definition of identity—it all depends on needs and requirements. Here at Radiant, we’re pretty agnostic about how identities are described. We like them all, in the same way we’ll like whatever’s part of OAuth 3.0, or any other future standard.

The only certainty is that the definition of identity will evolve as we develop new standards to solve new challenges—and if our definition of identity itself evolves, why not our identity management system? That’s why our federated identity service is based on virtualization, so you can define, remap, and deliver any view of identity you need.

As for REST, we love it and support it in our upcoming release of RadiantOne version 6.1 (look for it in March!). But we also love SOAP when and where it’s not smart, secure, or scalable to use HTTP as a transport protocol. And we even love plain old RPC, when it’s the only mechanism supported in some outmoded, legacy system that’s currently deployed. Like I said, we always try to work with what we have to, to get where we need to be—and that’s a big part of our evolutionary strategy based on virtualization.

Hierarchies, Networks, and Relations: Looking to History to Lead Us Forward

Ian bangs the anti-hierarchical drum in his video, claiming that the hierarchies of LDAP are insufficient and incomplete. A graph is better, he says, because a network of relationships is the most faithful representation of reality. And sure, that’s totally true… But I do think this raises a key issue: as it stands right now, IdM standards (and LDAP as a hierarchical repository) stand apart from the rest of IT, and especially data management. After all, LDAP is not SQL.

However, Ian is short on details here. If he does not want hierarchies, is he thinking about some sort of graph or network database to store those multiple identity relationships? If this is the case, his thought about a graph database—a database that captures all the links of a full network of relationships—should give a big jolt to any relational database practitioner. Did we not settle this debate 40 years ago between SQL and Codasyl and other IMS hierarchical databases? I thought that the first lesson in Database 101 is about how a relation (hence, a relational database system) can represent any graph and, as a consequence, any hierarchy? So we all know that SQL can generate all possible hierarchies and networks. And this is the main reason why the relational database and SQL won the war and now dominates data management as a key mechanism to capture and store application information.

But why then, around the end of the 1990s and beginning of 2000, did we see this resurgence of the hierarchical database model in the X500, which finally yielded LDAP? And why did we in the IT realm—who were fully aware of the limitations of hierarchy versus relational—accept this move, which has led to the current IdM situation? Could there be something useful about hierarchies that we were hoping to capture back then? Couldn’t that value still exist, even in our siloed, static identity environments?

Even in our IdM-isolated world, we should not ignore the growing momentum for attribute and keyword search on all kinds of “Big Data” stored in systems such as Hadoop and other “NoSQL” databases, nor the advantages these technologies might bring. What we need is a good way to unlock all those advantages.

Unless we analyze our past clearly, we are condemned to repeat the same mistakes in the future. So I think it’s essential to step back and look at:

• What makes hierarchies, along with graphs, are so important (think contextual relationships);
• How SQL databases can capture information without redundancy, but still need a materialization layer (think cache) to deliver contextual views at the speeds required for security and context-aware applications (think mobile); and
• Why virtualizing both identity and context is key to breathing new life into IdM, while respecting your current identity investments (think Radiant).

I told you I was about evolution, not revolution. Now, I’ve addressed some of these topics before, but I want to dig a little deeper in coming posts—stay tuned!

And thanks, Ian, for your thought-provoking call to arms!