If you read only one blog post this week, or this month, I recommend this one from Pamela Dingle. I know it’s long, but it is well worth it to read the whole thing. Multiple times.

My favorite lines:

We need a way for communities to form and flourish and decay that is organic. To that end, if you were to ask me what the vision is for any technology that follows the Identity Provider paradigm, I would say that the “why” is so that we can make a system where communities can interact, transact, and relate to each other without the tech getting in the way. This is the ultimate end goal for me – if I didn’t believe that we can build a much better house, I certainly wouldn’t spend so much time perfecting the engineering on a radically new foundation.

I couldn’t agree more.

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.

A 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.

The Bandit project, like many open source projects, does not have seek to produce only one release of an application or service. Its goal is to build a number of open source identity system components that are useful in enterprise environments. In pursuit of that goal, the project has evolved and will continue to evolve.

A small change in perspective…

Sometimes it evolves in small ways. You may have noticed a change in the attire of Bandit (the dog in our logo). Bandit used to look like this:

Now he sports are really cool cape like this:

Perhaps he used to be just some kind of terrier mutt, but now he’s a superhero. Or maybe he always was a superhero, and the mutt is his alter ego. I don’t really know if there is a marketing story line about saving the world to go with the logos, but I’d be happy if he could just make digital identity services a little better for humans. I’d even be happy if he could help get my passwords down to less than 10 while increasing the flexibility, security, and usefulness of my online interactions. It could just happen. In fact, it is happening. So I like the cape and the superhero look.

A bigger change in Bandit community sites…

A significant change in the project collaboration system is also in progress. We have been moving some of the Bandit Project support services from the Novell Forge site to our own servers. Axel recently came across some of the reasons for the change, as well as some brokenness in the main Bandit web site that was due to links that had not been updated since the change.

Moving to our own servers will allow us to use our own code to support the collaboration and development of Bandit components. The two most significant new sites are Bandit Cards and Bandit Code.

The Bandit Cards identity provider site was introduced last Fall. It is a source of identity and information cards for the Bandit collaboration sites. Bandit Cards is the hub of the bandit community and collaboration services. Of course, we want people to collaborate with us with their own identity sources and systems such as information cards and OpenID, but we do like to eat our own dogfood — so we will also use our own identity provider. Besides providing user account management and issuing information cards, the Cards site will also host some sample card-enabled services such as the sites to get project related podcasts, and, of course, register to win the famous Bandit t-shirts.

For developers, the new Bandit Code server is a more useful. It will support many of the developer tools such as a Trac instance for project management, the subversion repository, mailing lists and archives. The services on Code include bug tracking, roadmap, and a developer wiki. These all come courtesy of a Trac instance — but with one new Bandit component from Duane Buss (to whom I would link if he had a blog): a python information card plugin. The subversion repository has been moved to the same server and is integrated with the Trac system. We don’t have information card access to the subversion repository, yet, but it’s coming. In the meantime, accounts from the Bandit Cards server control access to the source code repository.

The developer wiki and project roadmap are undergoing fairly heavy changes these past few weeks, but you can find pointers to the new Bandit mailing lists, subversion repository, and bug tracking systems on the developer landing page.

A number of pieces of our project transition are still incomplete. Most notable is that the main wiki site at www.bandit-project.org has only recently started to reflect the underlying changes, and the links to the new mailing lists were out of date, as Axel discovered. Cleaning up the wiki at www.bandit-project.org will be the next step.

In the meantime, please go to Bandit Code site to get developer information, enter bug reports, use information cards, and get Bandit source code.

I was rather surprised today to read a post by Ben Laurie where he writes that “there is no practical difference between Cardspace and Passport.” Please read the whole post to understand the context. It’s not long.

He contends that Cardspace is only supported on Microsoft systems, and that, since the identity provider and consumer are therefore the same entity, there is no privacy advantage. I think there are a number of huge and hugely invalid assumptions in that contention. A centralized service hosted by a single vendor is very different than a distributed service — even if the service components are implemented by a single vendor. But it is not true that information card systems are implemented only by Microsoft. In fact, no Microsoft code at all is needed to deploy a complete system.

Ben also makes some rather general statements about lack of support for OpenID and that it “has no consumers of note.” Hmmph. I use OpenID all the time and find it useful. I wonder what I need to do to be a consumer of note.

I’m all for bloggers getting to vent their opinions, and, in that respect, there’s a lot in the post to love. I’m also for pointing out reality, and I think pointing out real users and deployments is important. I expect that Ben is right that there are currently more enterprise deployments of SAML federations than information cards or OpenID. But I disagree that OpenID has no consumers of note, and I disagree that Microsoft controls all identity providers and consumers of information card systems.

For example, please consider this shamelessly self-serving, but complete, illustration:

Novell and the Bandit Project just launched a campaign to promote awareness of information card technologies. The campaign site consists of an identity provider which is running on OpenSUSE 10.2 and includes a Security Token Service from the Higgins project, as well as various authorization and auditing components from the Bandit project. The same domain also hosts sites running Joomla and WordPress that receive information cards using plugins from the Pamela Project. There are links provided so that users can get an identity selector for Linux, Mac, and even Windows. Most of the identity selectors are open source and developed by the Higgins and Bandit projects. We do throw in a link to a Microsoft site for those who are running Windows and need to download Cardspace. We didn’t think that would be offensive.

Ben, please check it out. You might win an iPhone. You can use information cards to access the site, or even deploy your own identity provider or consumer using 100% open source software.

In the past few years there have been many times when people have told me that they really want simplification and convergence in digital identity systems. Their requests can take many forms. Sometimes it’s that they want just one way of identifying themselves — one username and password or one smart card that’s good everywhere. Sometimes they want to know which system will ‘win’, i.e. which vendor’s product or which identity system protocol is going to be adopted to the exclusion of other protocols. I’m sure I don’t want what they say they want. I also don’t think they actually want those things.

I do want simplification and convergence in digital identity systems — to a point. Managing all my identity data, and especially a gazillion usernames and passwords, is a pain. Too many passwords make me unsecure and insecure. I’m all for making the whole thing simpler and more manageable. But I don’t want convergence to a single identity information source, or a single authentication method, or a single identity information exchange protocol. My identity data is too valuable for that.

My identity information is valuable, like money. In fact, if someone can assume my identity they have a good chance of getting all my money, so the two are connected. Perhaps I can illustrate why I don’t want too much convergence in identity systems by way of an analogy with financial systems. I’m going to make an analogy that involves several accounts and systems for handling financial transactions, and correspond them to Internet identity systems. Please keep in mind that it’s just an analogy that seems to fit my current perceptions of the intent of some systems. Please don’t try to take the analogy beyond that intent; I do not intend to extol or bash the technical merit of any system, though I will give some of my preferences.

In the financial world, I don’t want to keep all my money in one account. If something happens to one account — it’s compromised in some way such as I lose the credit card or check book — I have other accounts to finance my attempts to repair the situation. Similarly, I don’t want a single way to access those accounts. Right now I commonly use credit/debit cards, but I also still use checks and scheduled withdrawals by linked accounts — three distinct access mechanisms, each with their own mechanisms to control access my money. They each have their own advantages and disadvantages. They are all useful, but I also appreciate that they are all different.

Checks are very easy to understand. They are like a paper promise that can be easily accepted by many individuals and businesses. The promise is to be paid with money withdrawn from the account identified on the check. There is very low cost for businesses to accept checks. But checks are not very secure for some purposes. Some problems with checks can be reduced by combining a them with another system, such as an identification or credit card.

Linked accounts are also quite useful for some purposes. By linked accounts, I mean a system in which I fill out a form that authorizes one business to take money from one of my accounts when a charge has been incurred. For example, I authorize my dentist to charge my insurance account. Linked accounts are a little heavy on the paperwork side. I have to set up everything and make sure both entities know their role. It’s easier when I can present a card, like my insurance card, to set up the initial link. I generally don’t like linked accounts because I prefer knowing when the money is going to leave my account. But there are times I use them and don’t know a better way to handle some situations, like the dentist.

Credit and debit cards are personally what I use the most for financial transactions. I tend to like them because they are both convenient and a point of control for me to authorize money taken from one account and given to a business. Credit cards are more burdensome for businesses than checks, but more secure. Credit cards are less burdensome for businesses than establishing a link to each customers bank. I also like that I can easily have multiple cards for multiple purposes. I can even easily keep track of purchases from a single business when I am in different roles by using my work card vs. my personal card. I’m sure I could do that with the other systems as well, but I don’t. It seems more natural with cards.

Furthermore, I don’t expect my financial world to be limited to these systems. If I lose all my cards and checks, I still want to be able to walk into the bank and authenticate in person to gain access to my account. And there may be new systems in the future.

So how does this correspond to identity systems? Just like my finances, I want multiple accounts for my identity information, and I want identity systems to co-exist peacefully and work well together (and that’s what the Bandit project is working towards). I personally think the information card metaphor will be the most common way to access my identity information, but I also find OpenID and federated accounts to be useful. And in some cases I actually want access via username and password to remain supported.

The only thing that I want to be able to correspond my accounts and access mechanisms — the thing that is in the center — is me, not an external identity information store. You might even say that my account correlation preferences are user-centric (for some definitions of user centric).

So why do multiple systems reduce my risk and still end up being more manageable?

It’s a matter of convenience, points of control, and manageability. In my current financial world I have less than 10 accounts; I commonly use less than 10 cards; I rarely write checks; I rarely link accounts, and even more rarely go into the bank to access my account in person, but I generally manage to keep my accounts current. In the online world I have hundreds of accounts and passwords. Incorrect information abounds because I can’t keep track of it all. My online world is more easily compromised in the sense that someone could get into my accounts without my knowledge. It’s harder to keep track of it all due to the sheer volume of accounts. If I can get to an online world that uses a combination of information cards, OpenID, and federated accounts, but in which I have less than 10 accounts to manage, that will be much better than what I have now and I would still be able to divide up the risk.

So that’s my analogy. It’s not a perfect analogy, but I think it fits how this space feels to me. It even has some other interesting illustrative points.

For example, it’s not surprising that a specialist in electronic funds transfers would scoff at paper checks. It’s also likely that a professor of economics would think checks, electronic funds transfers, and credit cards all have their place.

We can also see that there is value is some integration points between systems. There are a number of cases that I get cash with a card from an ATM (a financial token service as opposed to a security token service), or use a card in combination with other systems. But I don’t want them too enmeshed either. In my financial systems, I want integration at key points, but not complete convergence. Same with my identity systems.

What makes the overall financial system work is an underlying conceptual framework built on this rather vague notion called money. There are common concepts and principles that underly all the systems, even though they are often abstract and not well understood by everyone that uses the system. Sounds like identity systems to me.

So what is the One True Identity System that I want? It’s diversity of access mechanisms and sources of identity information built around a common conceptual foundation of identity, authentication, authorization, delegation, auditing, etc. Sounds complicated, but we do it all the time with money.

Please note that in this whole post I didn’t use any word that started with ‘meta‘ … yet. But if I was going to discuss anything meta-ish I would start with Bob‘s discussion of a meta-identity system and the identity oracle, and I would use this photo. The question is, which box is more like the meta-identity system oracle?

My fellow Bandit Andy Hodgkinson is not a prolific blogger. So far he’s averaging one post every 1.25 years or so. But his post today will interest a lot of people.

Earlier this year we showed a version of an open source identity selector running on Linux and the Mac. It was announced with the name DigitalMe, and we donated the code to the Higgins project, where it is affectionately referred to as “the Higgins H2 Native Identity Agent”. But there were some problems. Even though the selector works fine for me on OpenSUSE Linux 10.2 and sports a lovely GTK UI, the Mac UI was a port and it required too many dependencies to install easily. It really needed to have a native Mac OS X UI. So Andy and Jim Norman set about this summer to learn Objective C and write a Cocoa UI, in addition to enhancing the selector interoperability and their regular jobs. And it needed to be conveniently packaged for Mac users, so Andy fixed that too.

Last Friday, Andy quietly posted the Mac binary packages. Drag and drop install. We have tested it with many relying parties and identity provider sites (many more than those linked). We have also notified a few interested power users and got some initial feedback. It’s looking good so far.

So if you’d like to run an easily installed, 100% open source package for OpenSUSE 10.2 or Mac OS X, you can get from the Bandit instructions and download page.

It’s shiny and new, and just might work. Please let us know how it works for you!

What follows is actually a portion of an email I wrote earlier this summer, but the principle it is attempting to pin down came up again today in an analysis of government requirements for identity systems. It keeps coming up. I’m posting it in hopes of sparking a link or thought to take it farther.

There are a few slogans I have accumulated over the years that I think are worth repeating. One is “working code wins”. Another is more subtle, but I think it was at the root of many important lessons we learned in distributed directory services development and deployments. It applies to most distributed systems that appear as a seamless whole, and I also think it affects designs for everything from file system ACLs to the ASP business model. The problem is that there can be very subtle problems in these systems based on where a policy is actually stored, who can access the policy, what is the security for retrieving the policy, etc.

And the slogan sounds very silly. It is “the physical location of the data matters”.

It’s really an identity issue. Any distributed system has to account for the identities of the constituent parts that run the system. Even the book I’m reading (“Code 2.0” by Lessig) is discussing how we often think of cyberspace as a separate space from the real world. It is not. His point is that there are legal interactions between them. My experience is that there are physical, and especially administrative, interactions. The two are often intertwined and we need to be aware of how they are intertwined. It is not like the Matrix, or the Metaverse; it matters to me in real, tangible ways who runs the servers and where my data is stored ‑‑ and who is liable when there is a failure.

The photo is not much related to the slogan, though it is of a physical location where I’d like my personal data to spend more time.