Meta/Virtual/Directory Hubs and the Need for the Identity Bus

If I wanted to get tangled up in public debate, I think that Jackson Shaw, Dave Kearns, Kim Cameron, Jeff Bohren, Eve Maler, Phil Hunt and other identity bloggers would be some of that last people with whom I would I want to argue.

Then again, I do have a different point view that I have not seen explicitly stated. So here it goes…

I really tried to stay out of the meta vs. virtual directory conversation and I think it’s mostly blown over now, but I think none of the above bloggers mentioned one particular aspect of meta/virtual/directories that is relevant and important. In fact, I think there is a crucial limitation of meta and virtual directories that is leading us to the next phase of identity systems. The limitation is the political result of use of those tools. Meta/virtual/directories have valid uses within a single area of control — at least control of the central service — but they are still political silos. The notion of a hub or silo is great within a particular scope, but is a limitation when moving beyond that scope.

I think it was Eric Norlin that started the bus blog-thread by quoting Stuart Kwan’s use of the phrase “identity bus”. At first I thought the phrase was completely unnecessary. As I have read more and more posts and articles that echoed the phrase and saw how it resonates with people, I just wish I had thought of it. Stuart Kwan. Hip Internet terminologist. Who knew?

I think an identity bus would be similar to a message bus — a system that allows for loose coupling between a number of message publishers and consumers in sequence where there is no single point of control. That’s what we’ve been working on for years in the identity metasystem. Many people have recognized the need for it, so there are many terms. Years ago, my colleague Steve Carter referred to it as crafted identity tokens moving across an identity fabric. John Clippinger has called it the missing layer of the Internet. Kim Cameron calls it the backplane of the identity metasystem. Dick Hardt calls it Identity 2.0. All are fine terms. What is important to me is that it is a system that allows for loose coupling between identity data publishers and consumers in sequence where there is no single point of administrative control. It’s a way of passing identity data between a number of control points. It is explicitly about moving beyond hub tools like meta/virtual/directories.

Dave and Kim combined Eric’s post about the identity bus with a comment from Jackson about metadirectories. After that Dave, Kim, et al., exchanged very pleasant posts representing strongly contrasting viewpoints about meta directories and virtual directories. Kim likes meta directories (as would be expected) and Dave likes virtual directories. Both have long histories of preferring their respective technologies. Dave maintains that virtual directories are nimble and lightweight, whereas meta directories are large, cumbersome, and slow. In my experience, both meta and virtual directories are very useful tools within a particular administrative area or hub — i.e. an area where an particular political entity such as an IT dept of a corporation controls a central service that disseminates identity information.

Meta directories synchronize the identity data from multiple sources via a push or pull protocols, configuration files, etc. They are useful for synchronizing, reconciling, and cleaning data from multiple applications, particularly systems that have their own identity store or do not use a common access mechanism to get their identity data. Many of those applications will not change, so synchronizing with a metadirectory works well.

Virtual directories are useful to pull identity data through the hub from various sources dynamically when an application requests it. This is needed in highly connected environments with dynamic data, and where the application uses a protocol which can be connected to the virtual directory service. I am also well aware that virtual directory fans will want to point out that the authoritative data source is not the service itself, but my point here is that, if the owners shut down the central service, applications can’t access the data. It’s still a political hub.

Personally, I think all this meta and virtual stuff are useful additions to THE key identity hub technology — directory services. When it comes to good old-fashioned, solid scalable, secure directory services, I even have a personal favorite. But I digress.

The key point here as I see it is ‘hub’ vs. ‘bus’ — a central hub service vs. passing identity data between services along the bus.

The meta/virtual/directory administration and configuration is the limiting problem. In directory-speak, the meta/virtual/directory must support the union of all schema of all applications that use it. That means it’s not the mass of data, or speed of synchronization that’s the problem — it’s the political mass of control of the hub that becomes immovable as more and more applications rendezvous on it.

scooter hubA hub is like the proverbial silo. In the case of meta/virtual/directories the problem goes beyond the inflexibility of large identity silos like Yahoo and Google — those silos support a limited set of very tightly coupled applications. In enterprise deployments, many more applications access the same meta/virtual/directory service. As those applications come and go, new versions are added, some departments are unwilling to move, the central service must support the union of all identity data types needed by all those applications over time. It’s not whether the service can technically achieve this feat, it’s more an issue of whether the application administrators are willing to wait for delays caused by the political bottleneck that the central service inevitably becomes.

More and more we are seeing applications that do not fit within a single administrative area. Even within medium-sized corporations there are almost always renegade departments, divisions in different countries or jurisdictions, outsourcing of employee services. The perimeter continues to dissolve. We can say that these applications are more distributed, not in the technology sense, but in the sense of administrative control. The application itself may not be distributed, but it needs to understand identity information from administrative areas outside of it’s own.

To me, this fits very well the notion of an identity bus — like a message passing bus. Not a hub. It needs to be a chain or channel where a particular chunk of identity data (e.g. a token) can be passed through, and potentially acted on, by multiple administrative control points. Most emerging identity systems support some notion of passing tokens or assertions between identity domains for this reason. For example, information cards does this via chaining of tokens through multiple security token services, orchestrated by the client. I think this is particularly powerful in the RP/STS scenario.

As Dave points out, I will be on his panel at the European Identity Conference, and I suspect these issues may come up. I was so looking forward to a peaceful time in Munich, now I think I may get roasted. Should be interesting.