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.