Directory technolgies and Identity Management

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.

It's not just Bluetooth ...

I have been reviewing Kim's posts about the issues with Bluetooth and privacy/private identity. I have been meaning to comment about the fact "It's not just Bluetooth!"

My deep networking experience from my time at Novell taught me a lot about the inner workings of networking hardware and protocols. Anyone familiar with how networks work knows that the first 'key' to communications on Ethernet (actually any of the IEEE 802 standard networks) is the MAC address. MAC addresses are assigned to every networking adapter ... and they are globally unique by default. Each vendor who is manufacturing networking hardware is assigned a 3-octet IEEE assigned Organizationally Unique Identifier (OUI). This OUI is then used by that vendor as the first 6 hex digits of every networking adapter that they create. During manufacturing, most vendors then simply tack on 3 more octets (6 more hex digits) and increment the value for each board or device they manufacture. What you end up with is a 12 hex digit number that is globally unique - the first 6 identify the manufacturer, and the second 6 identify the unique adapter.

You can actually go and search the OUI database here. A sample of this would be to search for '00022d' - the first 6 digits from my Orinoco wireless card. The point is ... these MAC addresses are globally unique and can identify your specific machine.

Now, one of my other occupations is being the founder of a wireless Internet company. We operate a series of Internet Cafes, and also offer some residential wireless. Using MAC addresses, we are able to determine how many repeat customers we have. This MAC address is what is used at the lowest levels of networking to obtain an IP address. When you use DHCP, you are assigned an IP address that is then associated with your MAC address. All DHCP servers remember your MAC address to renew your DHCP lease.

Wireless is really where this becomes an issue with identity. When you turn on your 802.11a/b/g wireless, you are now exposing yourself to be tracked via the MAC address of your wireless card. Now for those of you paying attention, you would realize that this goes for wired Ethernet as well ... when you plug into any Ethernet network, you are leaving traces of your visit. In our wireless network, we could easily have a script that would notify us of any particular MAC address when it was detected at any of our Internet access locations. In the case of 802.11 wireless, you don't even have to be assigned an IP address or use DHCP ... if your card simply 'associates' to our access point we know you are there. This is equivalent to the 'Bluetooth bomb' that was talked about.

Now there are some ways around this. With more modern Ethernet and wireless adapters, you are able to 'override' the default MAC address that is provided by the vendor, but I have found very few software packages or operating systems that take advantage of this. I saw a "security tool" for Windows a few weeks ago that picks a random MAC address each time you boot, and assigns it to your networking card ... but this is not a standard feature.

There are several identity issues that arise with wireless devices and identity. This first one is a big issue since it is a globally unique ID that the average person is not aware of. There are others that can also be trouble ... I'll write more in another post ...