Four More "Laws of Identity"

I (along with most if not all of the digital identity crowd) have been following the development (as well as, it appears, the general acceptance) of Kim Cameron's seven Laws of Identity with great interest. Kim seems to "get it," despite the fact that he works for Microsoft, the company that wanted to take total control over your identity to ease your online life - and to have full visibility into all of your online transactions - with Passport. (Needless to say, that didn't go over very well.) While reviewing Kim's Laws, it occurred to me that there are some missing points and/or areas that could use some additional clarification, perhaps even to the extent that several new laws need to be drafted. I take the latter approach here. Though some of the "laws" presented below may be alluded to in Kim's original seven, or given their obvious nature it could be considered overkill (or redundant) to explicitly state them as "laws," I believe that the area we are exploring is so vital to the future of the Internet that no such assumptions should be made. Kim is interested in creating an open platform (or "backplane") that will interoperate with all (or at leas most) of the various identity systems under development (Liberty/PingID, SAML/Shibboleth, LID, Sxip, FOAF and my favorite, XRI/i-names). Further, he has mentioned that he might use the excellent (though still nascent) WS-Trust specification to provide trust credentials across domains. I've looked at WS-Trust as a mechanism to support inter-community and inter-federation trust credential negotiation within the Identity Commons, but I've also had some concerns...

Intellectual Property

I'm no expert on IP issues, but my understanding is that the WS-* suite has IP restrictions, since the license is Royalty Free (RF) - which according to Microsoft's Glossary "says nothing about other terms and restrictions within a particular license, or whether a license may be refused to certain licensees" - but not RAND (Reasonable And Non-discriminatory), the combination of which makes for a "GPL-compatible" (but still capable of proprietary use and extensions) license that paves the way for widespread adoption. I'm particularly interested in using the the WS-Trust specification, as it could become a key component of the structure of XDI federations, but I'm concerned that it may impose restrictions that prevent its free and open use in the wider (dare I say, non-corporate) community. This brings me to my first law, which I will audaciously number "8" as an addendum to Kim's seven:

8. Freedom

The entity (often a person) using an online digital identity system must be in total control of their information. This implies that not only the data but also the access protocols and authorization mechanisms must not be encumbered by someone else's (IP) rights, unless such restrictions were previously - and explicitly - agreed to.

Particular implementations or jurisdictions may impose restrictions, but the underlying identity management architecture and reference implementations must themselves impose none. Further, many may wish to cede certain control over their information to third parties for reasons ranging from security to convenience but again, this should be by choice, not by design. As we in the "digital identity community" are breaking ground by creating an interoperable set of identity standards, let us require that all reference implementations be 100% free and open source. Anything less leads us down the slippery slope of customer lock-in that should be avoided, having learned our lessons from earlier proprietary, closed and centralized solutions. As Microsoft is a primary author of the WS-* specifications, I believe that if they put their weight behind the freeing of these currently encumbered specifications, they would not only gain positive press but would also see these specifications embraced by the open source community, thus moving the whole process a step closer to global acceptance. That brings us to another proposed "Law" that has been much discussed but has not been explicitly stated, and which I believe merits being put forward:

9. Decentralization

An identity system should be decentralized.

I would like to say "must" rather than "should" but this is a very hard problem to tackle (see, e.g., Zooko's Triangle). We need to aim for as close as we can get, as centralized identity systems are too easily co-opted by the dreaded spectre of Big Brother. Note that for the hard core among us (particularly the capability security gang), even systems based on DNS are centralized in that the DNS space itself is centralized at the so-called dot authority (the implied "." at the end of every domain name). For example, while the only currently implemented XRI/i-name namespace is rooted at a centralized authority, that is not a requirement of the technology and one can even run their own root(s) or distribute the roots across the internet, perhaps using a technology such as distributed hash tables. In the meantime, there is a suggested worse-is-better approach to solving Zooko's Triangle (PDF) that i-name technology, for one, supports. The reference to i-names, one of many identity architectures in a sea of evolving identity systems and standards, brings to the fore the requirement for the next law:

10. Portability

Bridges must exist - or be straightforward to create - between identity systems so that users are not locked into a single provider.

This relates to the "Freedom" and "Decentralization" laws above, adding an explicit call for some sort of ontological translation or taxonomy-sharing mechanism that allows concepts in one data space (as defined by a particular instance/combination of user and identity system) to be translated into another. This may not always be possible (as the Sapir-Whorf hypothesis suggests) but it is a goal of the Semantic Web activity and as such must also be a goal of an Identity Infrastructure (or Dataweb). "Portability" (of both data and identity) is another way saying that the technology itself must be free from customer lock-in. In essence, a customer using services provided by one set of vendors should be able to move to a completely different set of vendors and retain (at minimum) the great majority of their services. Some vendors, of course, will continue to build in lock-in, but providers that offer open systems will (in my crystal ball) gain greater customer loyalty. Note that there is a tremendous opportunity here for Microsoft to build and embrace a truly open system. With their talented developer pool, they can provide the best user interfaces, system integration and overall user experience on an open system. If the system is truly open, this alone will be a huge selling point and provide maximal customer loyalty, something I believe Microsoft would like to maintain. However, if the system is closed and locks users into a Microsoft-only system... well, we're already beginning to see backlash in that sphere, what with Firefox and various open document standards. Finally, we come to a law directly related to the user experience. Users report a positive experience with a system when it clearly serves a perceived need, puts them in command of the user interface, makes it safe to explore its features, and empowers them with its capabilities. It is the word "safe" that I would like to call attention to here with the next Law:

11. Transparency

There should be a clear and (if desired) visible cause and effect relationship in all identity related transactions.

(I have a slightly different take on the term "transparency" than, say, Wikipedia, likely as a result of my previous work on OpenPrivacy.) While in a typical deployed system there may be a lot going on "under the covers," the relevant details of interactions must be available to the specific parties involved. If an old high school buddy finds me through the system, I'd like to be able to query the system to find out how this happened (in reality, this form of backtracking may not be initially feasible but it is a worthy goal). If my (personal) data is shared, I should be able to determine exactly under what conditions this occurs, and further, exactly how the data will be used by the obtaining entity. Ultimately, I would like to see legislation that requires companies to make the data they maintain on their customers available to those customers (not dissimilar to current EU privacy regulations). Not only will this contribute to the enforcement of transparency, but it will also allow users to manage their own SuperProfile, yet another "holy grail" of the digital identity world.