Building an Identity Bus, Part 1

One of the most interesting "panel discussions" I had at the European Identity Conference didn't have anyone in the audience. Kuppinger & Cole senior analyst Felix Gaehtgens gathered Microsoft's Kim Cameron, Quest's Jackson Shaw (former colleagues at Zoomit) and Novell's Dale Olds for a video interview (which may or may not show up at the KCP Web site) about the "Identity Bus" .

Dale led off the discussion with an analogy about his daughter and a school field trip.

The class would be making a field trip to the planetarium, and Dale had to sign a permission slip. On the slip he also had to indicate whether he would drive his daughter or whether she should go on the bus. He returned this document to the school via what he called “a rather unreliable medium” (his daughter). There this document would be collated with similar documents (presumably by the teacher) and a list of students who would ride the bus was compiled. This was forwarded to a school official who would create another document ordering the right sized bus to appear at the school (and at the planetarium) at the proper time. The list would ensure that the correct students, and only the correct students (so no parent who drove would begin to panic) were on the bus.

The point of the story is that there’s really no central authority for the entire group of transactions yet they are interdependent as data (including identity data) exchanged between and among disparate systems (family, school, bus company, etc.). That’s roughly how he sees the identity bus operating.

Jackson, Kim and I quibbled a bit (as we always do), but generally agreed with this description. It is elastic enough to encompass any of the loosely coupled systems that we are tossing about as a potential “identity bus,” or hub or fabric or other name for a system by which services, applications and datastores can effectively and automatically carry on “conversations.”

It was surprising, actually, that we so readily agreed on what was needed. How to get there, though, is the problem. Do we build this onto the already highly encumbered LDAP protocol? Should we create a brand new transport mechanism and communications protocol? Could we, as Felix suggested, design a “publish & subscribe” system that is protocol agnostic? The opinions ranged back and forth but, in the end, we did reach a bit of an agreement. I’ll tell you about it, next time.