Fellow Bandit Jim Sermersheim and I attended the Higgins developer face to face meeting in Raleigh, NC , last week. It was an enjoyable and productive time. The IdAS has been progressing nicely, and the overall architecture supporting the I-Card Selector Service (ISS) is now well underway.

Paul Trevithick  and Mary Ruddy ran a tight workshop and the IBM facility facilitated nicely. Local Higgins contributors Raj and Greg provided architecture (and restaurant) recommendations, and doubled as tour guides.

It seems to me that the Higgins project has really gained traction and the pace of development has taken off this summer — there are active discussions on the mailing lists, well attended face-to-face meetings, and (woohoo!) actual code getting checked in. We are on track to put the Higgins pieces together with parts from Bandit and other projects – and take this user centric identity space from the realm of concepts and terminology to the realm of working code.

After the Bandit press interviews and announcement on Monday, I spent most of this week at the Catalyst conference in San Francisco. The whole experience has been great validation and boost to the Bandit project. Some of the highlights of the last few weeks for me were to work with Sarah Mees — and to finally meet Bruce Lowry in person (both from Novell marketing). As a technical guy, I don’t get out much.

Now I’m sitting in the last session at Catalyst. The conference has strongly affirmed the need and opportunity for Bandit. Many of the companies and individuals that gave supportive quotes in the Bandit announcement are here this week. I participated on a panel discussion with representatives from Higgins, IBM, Microsoft and Bandit/Novell. Not only did no one get hurt, but there was progress and many significant points of collaboration. There is very deep consensus that identity services must be interoperable, and we need to work together to build them. Novell’s experience in identity systems such as eDirectory and Identity Manager, as well as our open source perspective and experience, give us a unique voice in the discussion. This has also been validated in hallway discussions, after hours, and in other presentations and panel discussions. We are seeing an explosion of interest in building a consistent set of identity services, and it is very clear that open source implementations such as Higgins and Bandit are key initiatives in this ecosystem.

Now I need to attend a few more sessions. Next week I will be on representing the Bandit project on a panel discussion at the Identity Mashup conference sponsored by the Berkman Center for Internet and Society at Harvard. And the Bandit project rolls on.

Wow. There are so many good lessons to be learned from the Hungry, Hungry HIPAA post over at the DailyWTF, an often hilarious site that posts, um, implementation flaws. Some lessons immediately come to mind:

• control and physical location of the data matters (physical entities must be part of the model).
• too much aggregation of user data makes for big mistakes
• access controls need to protect against incompetence of administrators as well as malicious intent

For the past few years I have been involved in many discussions that have started with the question “what is identity?” Or “what is a digital identity?” It reminds me of the debates we had around object-oriented programming. Programmers would ask “what is an object?” The answer was usually “everything is an object.” This answer sounds meaningless, but it actually accomplished something important – it allowed us to move on to other questions. Questions to which the answer was more meaningful — or at least more in our line of work. The question that really mattered to me in those discussions was “what type of objects do we define within a particular program?” Or “what objects are useful for me to instantiate?”

I have been thinking about the question “what is an identity” in the same way. I’m sure it is currently being debated yet again on a mailing list (and someone is probably adding more to it as I type this). Perhaps a useful answer is “anything that can be identified.” If nothing else, this answer allows us to move on and start work on other questions. Questions such as “why do I instantiate an identity?” This means moving beyond definitions of what identity ‘is’ to discussing ‘why’ an identity (or some aspect such as a digital subject) would actually exist within a running process. Of all the things that can be identified, why do we deal with attributes about some of them? Why are attributes of some identities communicated or stored, but not others?

There are probably many reasons, but one reason comes to my mind now: identity is the end point to which we attach policy. It is the connection between policy and technology — between policy and information.

I’m sure there are other uses for identity, such as ad hoc transactions in which identity information should be handled like a controlled substance, but right now I’m thinking of a fairly persistent set of identity information. It may be something like a user account which may support authentication. [By the way, I do think authentication can be a useful feature of identity systems, though apparently when I use it in a use-case discussion it can be construed as my view of the whole area. Sheesh. I’ve often said that most security is enforcement of policy we attach to an identity. How odd that I would be reputed to equate authentication with identity… anyway, back to identity as an end point for policy…]

Policy comes in many shapes and sizes. It may be user configuration policy (a.k.a. preferences or options), it may be data access policy (you can’t read my email), or it may be business policy (conference room B can only be scheduled by the engineering team), and it may be workflow policy (when the new hire gets here, give her a phone). File systems and directory services use an identity of some sort to implement access control or authorization policy. Each of these policies are links controlling the relationship between multiple identities (things that can be identified). So I instantiate an identity so that I can put it on the end of a policy.

Considering an identity as “something to attach to policy” helps move the discussion to what an identity can do, rather than what it is. For those who know me very well, this is a strange position for me to take. I’m usually more on the philosophical side of the importance of being more than the importance of doing. Nevertheless, I think that’s what’s needed now — not more definitions, protocols, and specifications — but more interoperable components and working code. It was the focus of my session at IIW. Also, the project I work on will be focusing on Open Source implementations of identity components.

Years ago I found this quote in a Fortune Cookie program. It seems appropriate here:

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

Just as the concept of an object is a useful organizational principle of programming, the concept of identity is a useful organizational principle of networked systems. What we are focusing on now is: what identities are useful to instantiate? I think it’s at least those on which we want to attach policy.