Eric and Dave have recently written about their views of the waves of identity. Dave’s post gave me a wave of nostalgia since it mentioned both the NetWare Bindery and Novell Directory Services. Sometimes it feels like I’ve been around as long as Dave.

Mr Peabody, set the Wayback Machine for somewhere near 1990…

My first server-side coding assignment at Novell was to show that the Bindery could be separated from the core NetWare OS and into a loadable module (NLM) — thus showing that a directory services NLM could be developed by another team of engineers in parallel with the next version of NetWare. I think my prototype was initially done on the NetWare 3.0 codebase, but it was a long time ago. I do remember that, after my prototype worked, the task of doing it “for real” was assigned to a member of the core OS team, and they threw out my code. Sigh. Nevertheless, what became known as the “name services” interface in NetWare 3.1 enabled a team of misfits to start coding something called Global Directory Services. By the time it shipped it was called NetWare Directory Services, then Novell Directory Services, then eDirectory. I worked on that code for most of the 90s as it changed to support new upstart protocols like LDAP, and new platforms like Windows NT and Linux.

Now I work on Identity Services, including newfangled concepts like federation, information cards, OpenID, and OAuth, and projects like Bandit, Higgins, OSIS, etc.

I think I can see both Eric’s and Dave’s perspectives.

I don’t know how or if the waves should be divided up, but it seems to me that in the 90s we were working on Directory Services — i.e. a standard model for identity data (generally around x.500) and systems to access that identity data (LDAP, meta/virtual/directories). This roughly corresponds to Dave’s first 3 waves.  With the appearance of federation protocols and the Liberty Alliance, the industry started layering an Identity Provider Model on top of Directory Services. Information Cards and OpenID are more recent additions to that model.  This could be Eric’s first wave of Identity after 3 waves of Directory Services.

But what really matters to me is Eric’s point about identity state vs identity action. Right on. It  may be useful to make a distinction between Directory Services (which allow applications to access identity data), and Identity Services (which perform identity actions). The Identity Provider Model was necessary to get to identity services, if for no other reason than that it externalized authentication — but that’s a post for another day.

To do is to be – Nietzsche
To be is to do – Sartre
Do be do be do – Sinatra

The Bandit project has built an identity services interface layer called OTIS (Onramp to Identity Services). We have been asked how it differs from a virtual directory, and the answer is exactly relevant to this discussion. OTIS provides open interfaces to identity services (actions). A virtual directory gives access to identity data. Both have valid uses, and, in fact, identity services are generally layered on directory services (identity actions based on identity data).

So we have moved from Directory Services, to an Identity Provider Model. Now we need to determine what identity services are needed to enable network services to focus on doing useful things, rather than handling identity data, regardless of whether it’s wave 2 or 5.

Gunnar Peterson is as prolific as he is knowledgeable. It seems like an old post now, due to his steady stream of great content, but a few weeks ago he made some prescient comments about the problems that come from custom security software. The post is humorous as well as insightful and explains why not enough IT budget is spent on software security.

He makes a strong point that other security areas such as network security get the bulk of the IT budget, but that not enough is spent on ensuring software security. It’s just not taken seriously. Hence the name of the post, “Golf Driven Security”, referring to his estimation that the IT decision makers play golf with their network security product sales rep — and sign up for their renewals while determining that internal folks can roll their own software security.

Rolling your own custom code in software security is dangerous business.

At the end of the post, he says this:

People don’t write their own virus protection, but for some reason attempt to do their own input validation, it is the same exact problem. People routinely write their own authentication, authorization and audit. I could go on.

Gunnar’s post was written on Aug 24. A Few weeks later ZDNet published an article describing a security vulnerability in Google’s implementation of the SAML 2.0 Browser-based SSO protocol. The Google coders had rolled their own software security.

Personally, I found the original paper about the flaw rather heavy on formalism, but I can see that it makes an important point: if we can formally define such protocols and their possible attacks, we can automate analyses to find flaws in the protocols.

On the other hand, the flaws actually found so far seem very basic. For example:

Any authentication mechanism should not be transitive. If I authenticate to service A, service A should not be able to authenticate to service B as me. Of course, any system that accepts usernames and passwords can often do exactly that, which is one reason username/password authentication sucks at service provider sites. If service A is evil, it should not be able to impersonate me. The Google implementation essentially assumed that all Google services and their partners were good. That seems to be a little beyond even the Google code of conduct.

Kim had a strong reaction to the emphasis of the reporting – pointing out the importance of partitioning (which Google’s implementation disabled) as a defense against insider attacks. Many identity bloggers commented and offered helpful suggestions to the Google coders.

It wasn’t a flaw in the SAML 2.0 protocol, it was in Google’s implementation. They rolled their own security code and, in this case, omitted some important aspects of the protocol.

I found all this interesting because I have been working on a project for the past few years that specifically aims to build reusable open source components that provide solid authentication, authorization, and auditing capabilities to network services. I agree with Gunnar that it’s surprising that people don’t seem to care much about software security. Our approach is that, if we make it easy enough to enable applications with such capabilities – if it’s easier for developers to use Bandit code than to roll their own, we can avoid many security holes. And, for my employer, sell more identity management products.

Perhaps our project motto should be:

Don’t roll your own Authentication, Authorization, and Audit code. Steal it from others. Be a Bandit.

Gunnar’s “Golf Driven Security” post concludes with this statement:

I have rarely seen an industry so ripe for disruptive innovation as software security.

Indeed.

The OSIS working group of the Identity Commons is completing their third interop. In OSIS-speak, an interop is a set of features and a time period where many projects and vendors test with others’ components to ensure that user-centric identity systems actually work together. Interops have always been concluded with one or more public demonstrations of the progress. It’s been greatly expanded this time with many more participants and test cases. We had demos for 2 days at the RSA conference, and will be showing more at the European Identity Conference in Munich next week.One part of this interop that I think is most significant is that we have are testing some features that are particularly useful in enterprise identity management scenarios. In my sessions and in discussing the OSIS interop at RSA, I found that many people were not aware of some of these capabilities.

For example, managed information cards can be issued in auditing or non-auditing mode. In auditing mode, the identity provider knows who the relying party is and can control if and what data is securely sent to the Relying Party. In non-auditing (or privacy) mode the identity provider does not know where the data is to be sent — and hence cannot audit or change what data is sent based on that knowledge.

The capabilities of auditing and non-auditing cards exactly fit with some enterprise use cases I have experienced. It’s almost like they were designed with those use cases in mind. In fact, I remember hearing Kim Cameron and Mike Jones describe these modes at the very first Internet Identity Workshop in 2005, for just such use cases. Now it’s great to see them implemented and working — and it’s very cool to see it first in 100% open source implementations.

To see how auditing information cards could be used in an enterprise scenario, the Bandit project put together a live demo for Brainshare. It’s still operational and we continue to use these sites for OSIS testing. Check out the demo overview, instructions and links for more detail.

The quick overview of sites and services:

• We added to our existing Bandit Cards identity provider the ability for users to be issued auditing and non-auditing cards.
• We deployed a community identity provider
• Various other sites that illustrate how identity information can be appropriately used and managed.

More information about Bandit Employee Cards, and Bandit Member cards from the demo information page about the Bandit Cards IdP:

This is an instance of the Bandit Identity Provider. It is the repository of user account information, and (for purposes of this demo) represents a corporate identity source. It issues a number of types of information cards:

• An Employee Card. This card could be used to access information that should only be used in corporate approved sites, therefore Employee cards are issued in auditing mode. All uses of the card (each time a token is retrieved) are audited and the destination site for the token is recorded. If the card is attempted to be used at an unapproved site, no token is issued.
• A Member Card. This card is not used to access sensitive corporate identity data, it can be used to get member discounts at various sites. It essentially conveys a token which states that the bearer is an member.

Another site is the Bandit Blog. The intent is that only holders of Bandit Employee Cards should be able to post to the blog.

We also instantiated an identity provider service that is intended to represent a community site, The Identity Paparazzi. It issues non-auditing cards to it’s members. They like to post photos to a hypothetically contentious photo sharing site called “Identerati Exposé“.

Hence, in our twisted little hypothetical minds we could see some scenarios.

(Note: use “view image” to see more detail in the following diagrams, and the photos above)

We should be able to guarantee that the Bandit Employee card could only be used at sites approved by the identity provider (Bandit Cards). The data would not be rejected by the rogue Exposé site, so if the user attempts to present their Employee card at the Exposé site, the operation must rejected at the IdP/STS. However, a Bandit Employee card should allow the user to post to the Bandit blog site. All uses of the Employee card should be audited.

A Bandit Employee, on their own time, should be able to be a card carrying member of the Identerati Paparazzi and post photos to Identerati Exposé. Identerati Paparazzi cards should allow the user to post photos to the Identerati Exposé site, but be rejected if used to post to the Bandit Blog site.

All of these demo systems are in place and have been working in many instances for months. When you actually start using the cards as described, it’s rather intuitive.

Try it out!

Anyone can be a Bandit Employee — just create an account in Bandit Cards and issue yourself an employee card (when getting a card there is a drop-down list of card types). Unfortunately, being a self-asserted Bandit employee does not mean you get paid. Likewise you can be an Identerati Paparazzi.

So feel free to try it yourself, but please be aware that is software under active development. Some things are bound not to work. For more information or help we have mailing lists, IRC channels, bug reporting systems.

Earlier this year there were a number of interesting comments from Eric Norlin and Dave Kearns about the term “user-centric”. Since reading those comments I have become more aware of some ambiguous meanings ascribed to the term. I definitely agree that “user-centric” is unproductive as some sort of vague mantra — though I also believe that we should be aware of what values are enabled or enforced by the code we produce. What would be most useful now would be to focus on what user-centric identity systems actually do for users and companies.

Along those lines, at Novell’s Brainshare conference there was a panel discussion about “Open Source and User-centric Identity in the Enterprise”. The discussion was moderated by Carolyn Ford, and included Kim Cameron, Pamela Dingle, Patrick Harding, and myself. A video of the session is available (though there are technical difficulties and the guy on the far right looks like a complete dork).

Before we could discuss how user-centric identity systems may or may not be useful in the enterprise, we needed to get some idea of what we mean by “user-centric”. That was the opening question to the panel. Since audio is not clear in the recording, I thought I would write up some of what I may have said.

I see three possible ways that an identity system could be thought of as “user-centric”.

1. User as source of identity data

The user is the authoritative source of self-asserted identity data. Duh. This may sound circular, but it is helpful to contrast it with the next statement. Network services are not authoritative for self-asserted data — yet they currently often handle such data as if they were.

I have read articles where this meaning for user-centric identity is used to explain why it is of no value to the enterprise. The conclusion is that self-asserted data is of no value in enterprise systems. The implication sequence is: self-asserted => ability to lie => untrustworthy => low assurance => no business value. But this reasoning is overly simplistic. Users are authoritative for some information, e.g. their password, or their home address, or any information related to their intent as an employee within a business transaction.

Note that authoritative depends on the context. A self-asserted shipping address may be good enough for some network services and not others. Anything that a user puts in forms now is self-asserted data and currently accepted as authoritatve within that context. I hate forms and I want a system to help me with them.

So user-centric could mean helping users manage self-asserted identity data.

2. User as control point for release of identity data.

In this perspective, the user may not assert the identity data — but has a vested interest in where it is released. I may not determine my social security number, or my credit score, but I care to whom that information is given. In this view, identity data is more like a controlled substance and the user is an active participant in it’s distribution.

For example, information card systems allow for assertions of identity data to be securely transmitted from an authoritative source to a network service in such a way that the user cannot tamper or see the data, yet is a control point for the release of the data.

Managed information cards can also be issued in auditing or non-auditing mode. In auditing mode, the identity provider knows where the identity data is to be sent and can control if and what data is securely sent. In non-auditing mode the identity provider does not know where the data is to be sent, which also has valid use cases. In either case, the identity provider is authoritative for the information, but the user in the center has a valid interest in controlling where the data is released as well.

So user-centric could mean helping users appropriately manage the dissemination of information about them.

3. User as center of their identity world

Yet another aspect is that user-centric could mean that only the user can corelate all of their accounts. In this view, user-centric is opposed to a central repositories for general identification of users. Only the user knows she is LacrosseMom to one service, acct 345678 in another service, and Sally in a third service.

So user-centric could mean the user is only point of linkage between some identity sources.

All of these perspectives are useful, and they are all useful within the enterprise, outside of the enterprise, and especially when crossing such boundaries.

For me, I think the 1st and 3rd perspectives are important, but the 2nd perspective is the most interesting and significant for current system development.

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.