I can completely understand the natural human tendency to want to claim
ownership of our identity.  I constantly see the statements “It’s mine!  I want to control it!  I want to determine who can see it!”

After years of looking at this space, however, I have become convinced
that our identity, as we know it, is already spread across the
communities that gave us that identity.  That the basis of the First and Second Axioms that I posited.  I see identity as an accumulated thing … and it only exists with language.  It is language that allows us to distinguish identity.

It is this train of thought that takes me to the Fourth Axiom of Identity:

I posit that for an
effective community to exist there must be verified agreement, which
requires a minimum of three community members.

As I stated above, I believe it is language that allows us to
distinguish identity.  Language requires agreement on the meaning
of words.  The only way to have verified agreement is to have a
third party as a “tiebreaker.”  This does not prevent
disagreement, however it allows for the verification of a previous
agreement.

Where I see this relating to identity is in the area of verification, or authentication
of identity attributes.  Here, I mean authentication as in
“verifying the authenticity of.”  I can always choose to accept
the identity information that I receive from another entity, however
the value and accuracy of that identity information is always in
question until I am able to verify it.  How I verify identity
information will always occur using some other member of a common
community that is able to provide the verification.

When applying for a financial loan, I can tell a bank about my employer
and salary information, however they are probably going to verify the
information with my employer.  All three of us exist within a
common community that enables this, and this community has defined the
language and protocols to enable this verification process to
occur.  There is the ability to generate a verified agreement.

Even in a conversation with my employer, we could potentially disagree
about my salary.  So what do we do?  We get lawyers involved
– the third party – to examine the contracts and employment agreement
to verify the information.  This can only occur within a community
that has the same language and contract law.  Verified agreement.

In the digital identity world, this quickly becomes an important aspect
of  any system that is going to replace our paper-based
systems.  Often, just as in paper-based systems, it is not enough
to communicate only the identity information.  It is often
critical to also communicate the sources of verification … some third
party that can provide verified agreement.  This, in most cases,
is also the source of that identity attribute.

I saw that Mark Wahl and Kim Cameron have been talking
a while back, and I like to see that. With Mark’s background in
LDAP directory technologies, I know that he has been thinking about
this space for a long time.

When working on digitalMe at Novell, I really wanted to see directory
technologies extended to become a primary platform for Identity.
When I say “extended” it was because there are a lot of issues that we
found when attempting to store identity in a directory.

There are numerous reasons that a directory is a logical place to store identity:

• fully extensible schema for objects and attributes
• authentication for verifying the user
• access control down to the attribute level
• flexible multi-protocol access

An extensible schema gave us
the ability to quickly create a core identity representation. A
“user” object with a list of attributes. What was powerful here
was when a user interacted with a new entity and was prompted for some
previously “unknown” attribute. This would be some attribute that
might be common, but had not been pre-defined in our list of user
attributes. With a directory we were able to ask the user for the
value of that attribute, extend the schema, and populate the
value. In a later iteration, we also looked for a way to allow
the user to “alias” the new attribute to simply point at an existing
attribute. This is the case where some attribute is called
different things by different communities.

With directory authentication, we are able to verify who is talking to the directory and then enforce access control on that connection.

Access control, down to the
attribute level, was one of the most powerful features that a directory
provides. With this, we were able to determine the “visibility”
of any particular identity attribute to any requestor. With most
directories there is even the concept of a “public” or “anonymous” user
making requests, and so we were able to expose those attributes that
are considered “public.” This is also what allows me to expose
more information to people that I want to. These access controls
could also determine who was able to modify any attribute of any
object. So, for example, I might have an object that represents you in my directory, and I might choose to allow you to update and maintain some of your own attributes. It is important to see that I might choose to
… because I also might choose not to allow you to update your
object. After all … it’s my directory. However if I trust
you, why not allow you to keep me up to date on your identity if you
want to?

Lastly, it is multi-protocol
access that offered the ability to integrate with a wide range of
identity solutions. At Novell we had internal proprietary
protocols, LDAP, and even some HTTP/HTML/XML methods of access. I
worked on a protocol that I called XDAP just before we announced
digitalMe. It is almost a LID/FOAF parallel. What I did was to have XML data returned – in DSML format – when a request was received in the IETF RFC 2255
format. Even after leaving Novell I had a lot of fun
experimenting with this further and using CSS and XSL to then directly
render identity information as “documents” in the browser that looked
just like the “real” documents in the paper world.

Over all … I believe that directories could be one of the possible
stores for identity information. There are, however, some
limitations in their implementations that don’t allow for many of the
common identity request patterns … like versioning and timestamping
of attributes. Directories are not very well designed to account
for how our identities evolve and change over time. I believe
this is necessary to have effective identity management.