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.