I haven’t updated this blog for a while. It hasn’t been due to lack of interest or lack of activity. Actually, quite the opposite. A huge amount has been happening and I have a number of experiences I’d like to relay to illustrate the progress that has been made by Bandit, Higgins, the Pamela Project, and other aspects of the Open Source Identity System community…

But first….

I needed to move this domain and my blog to a new hosting site, move registrars, get a certificate, rent a static IP address, and on and on. What a pain. I wanted to make the move for various reasons; one of which was to have more control so that I can finally start using the cool new emerging identity systems. And I’m a little stubborn about how I manage my own stuff, so I have been futzing around with it between conferences and customer trips for the past few months. I appreciate the patience of my Internet tech supporters as they put up with my questions and peculiar spurts of interest. Now the site is moved, and seems to be operational. I have tried to keep it as much the same as possible, so you won’t notice many changes yet, but it represents a whole new set of possibilities for me.

For now, please notice that the login page now accepts an information card or an OpenID.

The OpenID plugin seems to be operational. There were a few hiccups in installation, but overall it went well.

The PamelaWare wordpress plugin is a development snapshot, but I am very happy with it. The installation was smooth and configuration was straightforward. The nice validation checks on the options page made the whole process much easier, and enabled me to quickly work out a few glitches in my installation.

I wish the certificate management and domain transfer had been that easy.

The co-existance of the OpenID and the PamelaWare WordPress plugins is experimental. Oddly enough, even though they implement different identity protocols, they seem to get along just fine — philosophically and practically. Please let me know (via a comment or my i-name) if you notice any bugs or if you have any suggestions.

Enabling this blog for Internet identity is just a first step. More to come.

This week was Novell’s Brainshare conference. It’s a big deal for Novell folks and it’s a great event. It gives us a place to show off new technologies like the emerging Internet identity systems and some of the recent work that we have done on the Bandit team.

Our most significant demo this year was shown during the technology preview keynote on Friday. The whole series of demos is interesting — I especially liked some of the Linux desktop stuff — but if you want to just skip to the infocard stuff, it starts at about 40 minutes into the video.

For those who may want to know more detailed information about what the demo actually does, let me give some background information here:

There were 3 new open source components written by Bandits and made available this week:

• A fully open source, cross platform identity selector service was contributed to Higgins. Written in C++, this Higgins ISS runs as a daemon (no UI) and provides core infocard selector service: it accesses multiple card stores, enumerates available cards, matches cards based on requested claims, and interacts with the appropriate STS to get a token. It is almost complete on support for personal cards, with an internal STS, etc. The real deal.
• A UI process for the Higgins ISS. It is currently written in C#, runs on Mono, and leverages much of the management UI of the CASA component of Bandit.
• A new OpenID context provider was contributed to Higgins. This context provider plugs into the Higgins IdAS and allows identity data to be accessed from any OpenID Provider. What this means is that, with no change to the Higgins STS code (since the STS uses IdAS), we could set up a demo such that infocards can be generated from any OpenID identity. In other words, using the Higgins STS and the new OpenID context provider, I can access any site that accepts infocards with my openID account.

So what Baber showed in the demo:

1. A fully functional, native infocard selector running on the Mac.
2. He accessed a shopping site with an infocard generated from an OpenID account. Put some things in the cart and logged out.
3. Baber switched to a SUSE Linux Desktop machine. Fully functional infocard selector there as well. Accessed the same site with an OpenID infocard and see stuff in his cart from the Mac session.
4. Goes to check out. The site asks for a card with different claims, needs a payment card.
5. The Higgins Infocard selector supports multiple card stores. In this case Baber selects a credit card from a card store on his mobile phone via bluetooth.
6. He authorizes a (hypothetical) payment and the online shopping site (the relying party) only gets his shipping address and an authorization code from the credit card.

It’s a simple demo, and easy to miss the number of technologies and interactions involved, but this is the kind progress that we have been working towards for a long time.

The Bandits are happy and tired.

There has recently been an interesting blogosphere conversation around Kim’s series of posts on delegation. It started with Kim’s post about a statement attributed to Eve Maler. He focused on the phrase “user absent scenario” that Eve reportedly maintains Cardspace doesn’t support. Kim then goes on through a number of posts to explain the concept of delegation. It’s actually a concept that Eve mentioned as well. I think Kim reacted mostly against the phrase “user absent”, and the conversation was then picked up by others as being confrontational. I’d hate to have my casual conversations over coffee reported to the Internet and scrutinized over a single phrase. So please do not construe this post as picking a side between current identity system brands. I don’t see these concepts being deployed very much at all right now, certainly not to Internet scale. Even in Kim’s post he mentions that, using Cardspace, someone can build a system that can delegate a user’s authority. Such systems are not here yet.

What I’d like to do is expand on Kim’s exposition on delegation. You might even say, embrace and extend those thoughts to capabilities of authorization and audit.

The concepts he explains are, in my experience, right on. This stuff is exciting to old directory services developers. It even drew Pete out of his code for a while. Much of my career has been working on a directory service from the inside — where identity is represented as a flat list of authorization entities on the other end of a connection. Connection based services. They are fine for many purposes and necessary. But they don’t support delegation well. They don’t allow an entity to take a subset of it’s authority and delegate it to service for a specific purpose and time. Nor does it allow much more complicated scenarios, like those that actually happen when I walk into a Starbucks and pay with a credit card.

What we need for many operations is identity data, especially data used for authorization, that is composable — something like a document that allows chunks of data from multiple sources to be combined into a single authorization document. That way the data can pass through multiple entities and be securely transformed and composed, almost like a mini-workflow. Often delegation involves a time-bound subset of the authority of one entity given to another entity. There are probably many ways of doing this, but one way is to call those chunks of data “claims”, and the document an “infocard”. There are even techniques to keep the claims secure and yet properly pseudonymous.

BUT, the authorization data still needs to keep track of all the entities that authorized some portion of each request. It needs to be composable, but separable to individual authorization entities. There are many reasons why we need to keep them separate, but one reason is so that we can audit who did what. In my directory services experience, I’ve seen many other services login to the directory service as a privileged account, say serviceAdmin, and then make requests on behalf of its users. But all the audit logs can record is that serviceAdmin did everything. Imagine a backup service. I want to delegate to the service my authority to back up some of my files for a specific period of time each night. When the backup service reads my financial data at 2am, I want the audit log to indicate that is was the backup service reading my data on my behalf, not that it was me reading the data. Hopefully, I was asleep.

Audit logs can be necessary for a service to prove compliance with various corporate policies, but it can also be of great value to the consumer. When I buy something at a store, I usually use a credit card. I almost always get a document from the store, the relying party, that indicates who I am, what I purchased, how much they agree to charge me, and what they agreed to do for me. It’s an audit record. A document that gives me a record that I delegated a bit of my authority to that store for a specific purpose. It’s called a receipt. Then when I get the financial statement that says how much was debited from my account by that store, I can correspond it with the receipt. These are all documents that give are composed of delegation and audit trails from multiple entities involved in the transaction.

What about the field trip to the planetarium?

These concepts are all illustrated in a this rather simple recent event.

A few weeks ago my daughter brought me a permission form. I had to fill it out before she could go with her class on a field trip to the planetarium. It had a check box for whether I would drive her myself, or delegate that to the bus company with which her school had contracted transportation. It had a place for my name and signature, and what dates this authorization was effective. That document was then transported (via a rather unreliable medium) to my daughters teacher, to the school administration, where it was processed (I assume), and some derivative document was filed with the bus company. It is very important to me that all points of delegated authorization are clear and auditable. If my daughter wanders off after the show, I want the bus service to wait for her. I do not want it recorded that I drove my daughter to the planetarium. Because it wasn’t me. I delegated some of my authority to another service. I want my online transactions to have these same capabilities — only better.

Authorization and audit matter, and need to be composable from multiple entities. Delegation is a key concept.

This is actually a precursor to the another post. While typing that post I became increasingly tired of typing “Identity Metasystem” and “Information Cards”, and have decided to revert to infocards. This is why…

I’m tired of trying to figure out what to call a system of software agents that support a particular style of interactions and data exchanges. Exchanges which are in the style of WS-Trust, use security tokens and security token services, employ an information card metaphor, and are probably to some degree compatible with Microsoft’s Cardspace implementation of an identity selector. What is that system called?

I have read that some feel this system should be called the Identity Metasystem and on my last rereading of Kim’s paper, I mostly think that’s his intent. Mostly. But I’m not sure. And certainly others tell me that the metasystem can’t be meta if it relies on specific protocol exchanges. Protocol exchanges define an identity system, not a metasystem. Also, how can a protocol encompass future systems? It would have to be incredibly fuzzy and abstract (perhaps as fuzzy as WS-*).

So a metasystem should encompass other systems — but does that mean other distibuted systems or other host based systems? Put another way, is a metasystem a conceptual thing only, since actual communications between agents would involve a specific set or system of protocol exchanges. Or is it a metasystem if it is a protocol system that is so incredibly felxible, extensible, and general that connectors can be written to connect all host based identity systems into it?

Reading the paper again just now, I think that Kim’s intent is that the “Identity Metasystem” is a set of protocols and profiles — based on WS-Trust and sometimes called WS-*. But I don’t think it’s commonly understood that way, and I’m not at all sure I’m right.

There’s also the concept of the MetaIdentity System.

And I’m still tired of dancing around what to call it. So, in the posts that follow (until I’m corrected or change my mind) I intend to call it by name of infocard. Using the Microsoft code name as a generic term for the overall paradigm. I know most people now call them “Information Cards”. But that’s so LONG and I’m an old coder that doesn’t type well. It’s as long as “Identity Metasystem”. I like short, but specific names. Preferably all lower case. So I intend to refer to the specific visual metaphor as infocard, and the system as infocards, or perhaps, “an infocard system” when necessary.

In my last post, I talk about three ways that the Bandit Project is contributing to emerging Internet identity space. In this post I want to expand on the third area of that post. This area will be an increased focus of the Bandit project this year. Since the Internet identity systems are happening, we are betting that the Bandit components will be strongly needed, and we expect them to be deployed in real world installations. And we want to accelerate that process.

So we are starting to visit deployment sites and validating these concepts, as well as our component designs and project communication. We’ve been learning a lot. What follows is an excerpt from a letter I sent to some enterprise sites to illustrate our reasoning. It was sent to some Novell customers, hence the Novell focus, but don’t take that too strongly either. Often Novell customers write custom code to integrate web applications, and we want to make the identity integration at those points as easy as possible. But we work with non-Novell customers, partners, and other vendors just as well. Bandit components do not require Novell products (though we do try to make them work well together). Here’s part of the letter:

The Internet identity foundation is coming together quickly. Useful Bandit components are already available. Over the next year, the Bandit team will be focusing more on integrating our development with the community, customers and partners to validate and evolve the project vision.

It also sounds like great fun to me! I’m looking forward to it.

There has been a huge flurry of activity in the Internet identity space in recent months mostly around convergence, working code, and actual deployments.

• OpenID continues to gain momentum.
• Microsoft and AOL announce support for OpenID.
• Higgins is solidifying its support for many identity systems, reaches major milestone
• Higgins gains some really cool technology that adds new capabilities for handling identity information.
• The Pamela Project emerges to fill needed hole in Relying Party territory
• Multiple open source projects show integration with Microsoft Cardspace and Liberty Alliance systems (shameless plug here)
• Real deployments of infocard and OpenID systems are happening in addition to existing Liberty systems.
• Perhaps the proverbial big bang of Internet identity will happen soon

Since I am an unashamed Bandit, I am sometimes asked “where does the Bandit project fit in all this?” I think that it fits in three ways:

First, Bandit supports the above mentioned projects and convergence points.

We participate in the community as much as we can, and we are one of the few projects I have seen that will actively contribute code to other projects. We NEED this stuff to work coherently and we work to accelerate convergence where possible.

In some ways the Bandit project is much like our close ally, the Higgins Project. Both projects write open source code that glues together existing and future systems. Neither project pushes a particular protocol family or identity system. Higgins provides a framework that supports a common interface to multiple identity systems and protocol families. Bandit needs such a framework, so we contribute to Higgins to help it get done faster. We work with Higgins on other shared components as well.

We are also excited to work with the new Pamela Project. It fills a very important need for consistent relying party code that is usable, robust, and handles evolutionary accounts from existing silos to the emerging identity systems. Relying parties need consistent user experience too.

Most projects that we work with are open source. I personally would want my identity information handled by open source software. I also think that open source development is particularly good at interoperable components of distributed systems — like identity systems.

.
Second, Bandit adds a layer of open source components for consistent authentication, authorization and audit capabilities.

You might say that accelerating convergence, contributing code to other projects, and some authentication code is necessary before we can build effective authorization and audit components. We need a cohesive, distributed identity system. But we also know that when we get such a system, some critical issues involving authentication, authorization, and audit will surface.

Bandit focuses on simple, reusable components for authentication, authorization, and audit. These capabilities are most recognized as needed in enterprise identity systems, but I think they will be needed in other places as well. The recent experiences of the Bandit team and others are confirming this. Once applications or services (web based or otherwise) start to actually be used by more than a few users and sources of identity, they immediately find they need a general, scalable solution for authorization and audit.

Authorization means determining whether a particular user can perform an operation. Most network services really support authorization based on something like a role. For example, a wiki may have a notion of an administrator, an editor, and a reader. The Bandit Role Engine will allow a sysadmin great power and flexibility in how to map security tokens, claims, and other information into the native roles of the system.

Auditing is needed to provide an record of who did what. In the case of most of the emerging Internet identity systems we are particularly interested in providing a record for the user of what a service has agreed to do for them. Think of it (in the insight of Bob Blakley) as the receipt from a Relying Party. Audit records are also needed (like a cash register receipt log) to help a service prove compliance with various accounting regulations.

Bandit is not limited to these components or use cases, but they illustrate the point. From the main project page:

Third, the Bandit Project is a conduit between developers and those who make these systems work in real deployments.

The Bandit Project works with Novell product teams, other vendors, current and future customers to determine what still needs to be done to make these identity systems work in real deployments. This will be an increasing emphasis of the Bandit Project this year.

More on this third point in the next post.

It as a great time at IIW last week. In the immortal words of Inigo Montoya: Let me explain… No. It is too much. Let me sum up.

1. The Higgins/Cardspace/Bandit demo worked.

It worked repeatedly in the speed geeking session on Tuesday, for impromptu performances, and in the “OSIS in Action” session on Wednesday. It was given by Mary Ruddy and me. In retrospect, my favorite part was getting a text message from Pat Felsted (demo coordinator and fellow Bandit) at exactly 2 minutes before the speed geeking demo session started that said something like “try it, it should work now”.

Thanks to everyone whose help and code was used, and to the bandits and rodents who set up the demo, especially because it involved collaboration with multiple companies, as well as wrestling code, machines, and corporate policy.

2. Some ad hoc identity project interaction occurred as well, and worked.

I couldn’t actually see it because the demos were shown simultaneously, but I have heard that Chuck showed his selector working with infocards generated from our Higgins IdP/STS site and used those and other cards with our relying party site.

3. I saw more of a focus on working systems and usability.

The focus of IIW seemed to have shifted — at least in my perception. Rather than just theory and concepts of Internet Identity, it was more about what currently works and what is proving to be most useful in practice. I found much more interest and discussion in capabilities and user experience above the basic interactions of Internet identity systems.

For example, the demo that Mary and I showed granted access to a mediawiki based on claims from an infocard that were fed to a Bandit authorization component configured with XACML. It also included pages that showed that all accesses of the Identity Provider, Security Token Server, and Relying Party were being audited via an open source framework. I got more requests for indepth information about those two components than I did for the basic open source infocard components.

Also, evolutionary adoption and consistent user experience at service sites (e.g. relying parties) got a lot of interest — at least the topic was interesting to me. In particular, a conversation with Pamela Dingle and a session by Joseph Smarr pointed this out. Maybe I just wasn’t listening, but at past IIWs I have not seen much emphasis on a consistent experience for users at service sites. Common issues for sites such as our demo MediaWiki are: 1) login with legacy username/password login vs. using a new internet identity, 2) claiming ownership of an existing account, 3) account merging, 4) removing old account information, etc. Perhaps I was just not sensitive to these issues until we put together the demo, but they will be very commonly needed capabilities. It would be much more effective if the community could promote common user experiences in those areas. I know that, since last week, the OpenID folks have been working on this for a login dialog box. That’s a start.

Overall, the informality combined with the intense passion of the event was very enjoyable. It even surprised me with some deeply meaningful moments. And it started productive conversations that I hope will continue for a long time.

Next week is the Internet Identity Workshop 2006B. I first went to an IIW in October 2005 as a result of some diplomatic coercion from Dr Nadalin. It’s been an amazing series of workshops. A small, almost-militantly-informal gathering of people that talk about abstract notions of “identity”, and how to make them real. I have heard them ridiculed as “grass roots” gatherings and indicative of the “bottom up” movements in Internet identity systems. That’s the best kind. I do believe these workshops have changed the direction of identity systems and how we will interact over the Internet.

Lots of very cool people will be there collaborating on lots of very cool projects and initiatives.

I will be attending and hope to help demo how an identity provided by an LDAP directory via Higgins (IdP and STS) can work through a Microsoft infocard client to access an open source MediaWiki — with authorization provided by a Bandit component. Multiple open source projects working together — surrounding Microsoft. Good stuff.

I hope it works.

Over the past few years I have read about and sometimes participated in many discussions about the One True Meaning of Identity and related concepts. One such concept I have not heard discussed much is the, um, relationship between Identity and Relationship. It seems to me that the very notion of Identity implies Relationship, and that this perspective is significant and useful.

I will attempt to explain in what follows.

I am well aware that there are many attempts to define “digital identity” for use in computer systems that the definitions are not necessarily indended to correspond to normal human usage. There is, of course, the Identity Gang Lexicon, and also this excellent set of definitions pointed out by Dave Kearns. However, for my purposes here I am referring to the meaning of Identity in everyday human usage. There are many aspects of Identity in the dictionaries I have consulted, but I will summarize a base meaning of Identity as “anything that can be identified.” To identify something means to distinguish it from something else.

So, on a human language level, there must be something different between things (identities) or we could not identify them. So the arguments about “what if two digital identities are the same” is not in view here. Of course two objects may be blue — the characteristic of blueness does not identify them in that context and two digital identities that consist of the statement “color = blue” would be the same. But for us to talk about the two blue objects, there must be something different about them or we couldn’t talk about them. We couldn’t identify them if we could not distinguish them — if something wasn’t different.

But the act of identifying something is a link between two things — two Identities. I identify you. In all of the discussion above I used terms like “we” and “us” — the identifying end of the identification link.

I know these notions may sound rather abstract and silly, but it seems to me that it follows that an Identity is something involved in a Relationship — the act of identifying is the beginning of a simple relationship.

In my day job I work more with code and processes than philosophy, so why does this matter to Bandit?  I think it matters because it follows that identity systems are for managing relationships. My relationship with my bank account, and with my employer, and my friends via email, etc.

Managing relationships with the largest number of identities in my networked world implies interoperability, and, in my opinion, necessarily involves heterogenous environments, open standard protocols, and open source implementations.  If all these things were not true for HTTP, WordPress, etc., we could not be sharing these thoughts. We could not be having this relationship. Of course, you must decide whether that’s a good thing or not for this post.