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.

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.