Stream of Consciousness

Drummond Reed offers some practical answers to dizzy who asked some reasonable questions about i-names. I’d like to add a couple small points.

First, I’d like to stress that I agree with dizzy that i-names need services to become useful. Besides the three that Drummond mentioned, we have plans - limited only by our resources - for many more, including:

• event registration, currently in beta that includes social networking capabilities
• membership management for organizations, made easier when the member maintains e.g. their contact information
• disposable email addresses that protect privacy and offer a spam-free email address for the user
• reputation-based and/or community-driven vetting of i-names to set access permissions, etc.
• permission based matching services (useful for everything from dating to traditional marketing)
• inter-social networking — networks without lock-in
• persistent avatars for on-line gaming
• and more…

The second point I’d like to make is that the global namespace is only the first one being built, primarily because it’s a simple and straightforward mechanism to bootstrap i-names into general use. But i-names are not centralized by nature, a key requirement towards supporting a world of ends. Other global roots as well as an unlimited number of distributed community roots can and will exist, some perhaps initially with mapping relays between the namespaces, much as the initial relay machines helped connect the arpanet, bitnet, usenet and others into what we now know as the internet.

And along these lines, though dizzy got a free global i-name for attending Digital ID World, IMO the majority of i-names will be free which coincides with our (2idi’s) open source business model with no governance required, though I believe that a membership-based federation of communities ala that proposed by Identity Commons is a good middle ground.

=Fen.Labalme

At a gathering after yesterday’s events of Digital ID World, Peter Davis suggested I do a Google search for “XML-dev Monty Python”. I was ROTFL while reading the thread of Monty Python-inspired commentary on semantic web goodliness starting here.

Ni!

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.

I’ve recently returned to the study of design patterns, originally stemming from Christopher Alexander’s book, A Pattern Language. While the book concerns itself with patterns in physical architecture, software architects embraced the concept as they saw patterns in the design of software systems. The state of the art in Computer Science has, in only a few short years, embraced the concept of patterns, and with many tools, languages and conferences devoted to software design patterns and languages. But I digress…

In my research, I discovered a set of patterns designed for developing a community (in this particular case, the Jini community) and I found many of the patterns to be remarkable and particularly apropos to what Identity Commons is striving to create. When I noticed that one of the authors as Richard Gabriel, I got even more excited, as Dick is sort of a hero of mine, as he was a primary architect of the Common Lisp Object System (CLOS) in the 80’s (did I mention that Lisp is my favorite language?). He’s also the author of Worse Is Better that I received on a MIT mailing list in 1991. (I’m still digressing!)

So I’ll get to the point: here’s a link to the Jini Community Pattern Language (which could easily be renamed the Identity Commons Community Pattern Language!). But first, a note on the terminology of pattern definitions: These patterns have four parts:

1. Context sets the stage
2. Problem defines the problem
3. Force (this one can be confusing) it is a noun, a “force” that exerts pressures on the Problem within the Context
4. Therefore is the conclusion (or strategy to find one)

There’s a lot there, so let me whet your appetite with a few teasers:

• A Dangerous Waterhole occurs when competitors come to “drink” from the same (possible non-existent) resource…
• …so the first thing you need the community needs to do is Grow the Market.
• Of course, you need a Safe Place to Share,
• and it really helps to have a strong Compatibility Logo.
• In the end, it’s Survival of the Fittest.

I leave the rest to you, dear reader. May we all thrive!

The following is a rant on Open Source vs. Free Software, with Java as the protagonist. While I am pragmatic and appreciate what Java offers (fast development, powerful tools, strong support) I have also voiced at times my concerns over its use, particularly within the non-profit and NGO markets that we have been looking at pursuing.

There are many sides to the issue, and I don’t really want this to become a long thread with arguments and counter-arguments - find those on any open source and/or free software developers forum. But as it is a difficult topic to understand, I found this article [Newsforge] provides a fair overview of a particular scenario, and decided to share it with the goal of shedding some more light upon a subtle yet important issue.

OpenOffice is the premier open source alternative to Microsoft Office - it’s what I use to open and read the .doc and .ppt files that occasionally flow through the IdCommons mailing lists. The much anticipated version 2.0 is nearing, but not without controversy, as the new version has certain dependencies on Java, a non-free language.

The well-balanced article more or less concludes that the choice to use Java is largely a matter or pragmatism (the open source advocates) vs. philosophy (the free software supporters). But as some of the comments suggest - and I must say I agree with - it’s important to stick to your philosophy if you want to create a superior product.

An example in the XDI world might be if we made an architectural decision that, while you have total control over your own data, so does XDI.org, and you can trust XDI.org, right? Today, the answer might be yes, but over time and political pressures, the once pragmatic architectural decision may lead to the destruction of the trust that Identity Commons depends upon. That’s why we are committed to the philosophy that you own your own data.

To date, my company, 2idi, has used only free and open source software (LAMP) for its i-broker development. (There is an exception: our connection to the global registry currently uses a Java library, but only a tiny percentage of i-brokers will be global registrars and need this code, and there is a C++ library available, too.) Nonetheless, I’m comfortable that several XRI and XDI developers are currently using Java, as they are doing great work that is portable, has language-independent APIs, and is extending the state of the art. I look forward to incorporating these new code contributions, no matter what language they are written in, as long as the copyright is given to Identity Commons so that they can license is as GPL/BSD, or in some cases Apache 2.0. This will support the growing community and enable us, should the time come that such is necessary, to rewrite the code in a free language. In the mean time, we will be able to enjoy the benefits of a rapidly expanding code base.

If you’d like some more points of view, here’s the Slashdot commentary.

=Fen

I haven’t blogged for over a month, so here’s a random rant to try to kick start this for me again…

Since the Xerox machine, people have been able to make easy copies of “the news,” but forgery was tough as (say) the New York Times had a distinctive type face and “feel” to it.

Now with the Internet, it’s trivial to make forgeries. (Phishing attacks work by creating convincing forgeries of trusted web sites.) It’s deep within my philosophy that anything that can be reduced to bits (what I generically call “software”) should be free. (Why should we pay lawyers try to make a plentiful resource scarce?) IMO, the real value comes with software’s timely production, searching, indexing, matching, storage, maintenance, support, additional commentary, etc. In this vision (of utopia?) authentication is supreme. Anything that wasn’t authenticated would be generally ignored.

XDI helps raise authentication to a new level, as access to arbitrary data can be mediated by arbitrary contracts and policies. It’s turtles all the way down. And the danger of “tunnel vision” — seeing only what you pre-define that you want to see — is only real if that’s what you want. Through authenticated, constantly evolving relationships and communities, and perhaps even subscription to special (open source or for-profit) “serendipity” editors, a sound and well-rounded view (you pick the subject(s)) is readily available.

Problem is, it puts responsibility back on the person. But then, by joining a community that will assume certain responsibilities for you, you can offload that, too.

Sort of like the “real” world.

Just came across Chis Ceppi’s blog posts on more Less Databases. He suggests that:

…some aggregation of identity information into centralized systems would be a big step in the right direction. Each aggregation point will be held to higher benchmarks for trust, security, privacy, and open standards than any completely decentralized system can ever attain.

I disagree on (at least) two accounts: first, he’s still talking about multiple aggregation points, so by definition (and being admittedly nitpicky) we’re still talking decentralized. But the major issue is: who controls the identity information?

Chis seems to think that we can and should trust a very few, highly secure, semi-centralized databases. Perhaps we should trust the government to hold all our personal information? Or maybe Microsoft? (As I used to say, ‘the only good thing about Passport is at least Microsoft won’t buy their database.’) Personally, I would rather trust who I want to trust, whether it’s my bank or a personal identity broker (like 2idi) or my own home server running a hardened personal copy of the open source i-broker software on an encrypted file system.

Such an i-broker can provide other sites with the ability to access and potentially even cache portions of my personal information, assuming they sign and abide by the specifics of the appropriate data sharing contracts. Adherence to these social contracts is governed by a mixture of technology and community reputation metrics that each community can define and manage as they see fit. Such social mechanisms simplify usability and puts the privacy burden on policies and trust federations (which I believe can become very powerful force indeed).

In this way, the number of databases truly drops to one, and as there is just one me - and I am the best authority for any information related to me - it seems natural and normal that I would be in control over my personal information.

Joi Ito wrote today about Global Voices (blog, wiki) which is “a name, an identity, a watchword to ward away the chills of restricted expression. A place for coordinating ideas; a source for inspiration; an optimistic, collaborative manifesto“. This is a very cool project and about the best thing I can think of to blog about on a holiday honoring the birth of a person who loved and respected all human beings.

And at the same time, I see many challenges. One of which is creating technologies that will enable people to read what they want and to publish their ideas - and maintain control over them - without fear of retribution. (This is also a primary goal of 2idi and the Identity Commons.) There is a project just underway aimed at giving all the people of Costa Rica a virtual identity (perhaps using i-names) with emphasis on the poor so as to help the distribution of aid and supplies where needed the most.

Let’s all get together and make the better world we envision real.

Stephen Downes makes some observations that are indicative of some of the misunderstandings that surround i-name technology. I will briefly address two issues in particular:

I-names can be free

While so-called “global” i-names cost money, there are at least two type of free i-names, and I expect the large majority of i-names issued will be free. First, “community” i-names, which are delegated from a globally rooted organizational i-name, will, in most cases, be free. (Of course, it’s up to the delegating community to charge for them if they wish to.) Then there’s the wide open frontier of i-names that use a cross reference as a root, which enables a fully distributed P2P and/or DNS-based community root system. (This may also give you an idea of how completely open-ended the protocols are.) All that said, the current (limited time fund raiser) offering of 50 year global i-names for $25 is, IMO, a very good deal.

No governance required

But most civil society finds a certain amount of governance to be useful. It’s a good thing that people in this country drive on the right side of the road and that murder is illegal. In the online world, mailing lists like to limit posts from trolls or advertisers and K-12 forums like to limit (e.g.) sexual language. The Identity Commons is proposing an identity-based governance framework that enables member communities to decide for themselves what rules they will allow for inter-member and inter-community communications. For example, while a community may limit unrequested outside advertising (spam), it may allow - and even encourage - intra-community advertising. XDI-based negotiation mechanisms will enable communities to define their rules (XDI contracts) and their i-broker (such as 2idi) will enforce these contracts.

Our open APIs and open source vision are aimed at giving people 100% control over their personal identity information. It distresses me that there’s so much misunderstanding out there. At the same time, it’s understandable, given the identity systems proposed so far (e.g., Passport). The bottom line (IMO) is that we’re really on track to creating the identity services framework that will enable anyone to use it however they want to use it. That’s simply the way it should be.

Olivier Travers writes of the need for open APIs. We at Identity Commons consider open APIs to be crucial (as well as open governance, open privacy and security mechanisms, etc.). Not only are the technologies used by 2idi to implement the IC platform based upon open standards and code (LAMP, XRI, XDI and SAML/Lasso), but all 2idi core software will be dual (BSD/GPL) licensed. In addition, we will be explicitly working with service providers of all types to create more and better open APIs so that they can more easily use the open authentication model. It may sound counterintuitive, but not only do we want to have as many people and applications connecting to us as possible, but we also want to encourage a multitude of providers offering services compatible with ours - all part of our open source plan for success.

As there will be other identity models in existence for a while (after all, we’re coming in rather late to the game) we will work to create interoperability where possible. Of course, since 2idi/Identity Commons is the only initiative that I know of that is aimed at a fully open system giving its users total control over their identity - including where their information is stored - some of the other identity providers that we interface with may have less than the desired level of compatibility.