The History of Tomorrow’s Internet: Identity (iCards, pt 4)

I just finished up my three part series on Microsoft’s CardSpace implementation of iCards, but one of the most important things to understand is that CardSpace is just ONE implementation of iCards. The specifications are completely open and in fact, have been implemented in an open source project simultaneously. That project is Higgins and I recently had a chance to spend some time with Paul Trevethick, the project’s lead.

Paul, like most of the people in this space is an adult (which is one of the things I find most appealing about Identity). He’s been building software companies since he left MIT in 1982. When he left his last position as President of the publicly traded BitStream in 2000, he left with the express intent of building a BIG company–one that could fundamentally transform the internet and leave a lasting legacy. So in 2000, when he co-founded Pariity with John Clipinger, did he set out to build an Identity layer for the internet?

As is the case for most people in this space (and another reason I find it so appealing), the answer is no. Paul had a vision of an internet where trust between people and organizations could be automatically brokered, similar to that expressed in the Augmented Social Network paper I discussed in my first post in this series. He wanted to surround each individual with a reputation layer and then build the algorithms that would help efficiently establish trust between those individuals. The problem that he and so many others have run into when attempting to “thicken” the data that surrounds us on the internet so that it can be shared across sites is that WE don’t exist on the internet. In other words, like so many others, Paul stumbled into the problem of Identity.

In 2003, about the time Paul ran into this problem, he caught wind of what Microsoft was implementing on the Identity layer and realized both that it would be perfect for what he wanted to accomplish AND that there clearly needed to be an open source implementation of iCards. So Paul’s project took both a turn to Identity and to open source, and Higgins, which now is primarily thought of as the open source implementation of iCards, was born.

I don’t want to go over the details that distinguish the Higgins’ implementation of iCards from CardSpace because it has been designed (intentionally) much along the sames lines, so that it remains compatible with that emerging standard. One important point to note though, is that it suffers from the same schizophrenic nomenclature as CardSpace, in that the Higgins the project encompasses BOTH the iCard selector that lives locally AND the server based technology for brokering claims.

Besides this, it does have one additional layer that is extremely powerful that deserves some discussion: the rCard. As I discussed in my CardSpace series, CardSpace supports a pCard (a PERSONAL card that allows you to assert limited claims about yourself) and mCards (that organizations with information about you use to “officially” assert information about you). So what is this “Relationship Card” (rCard)?

Two things distinguish and rCard from an mCard: persistency and bi-directionality. What do I mean by these two things and why should you care? With an rCard that is persistent and bi-directional, YOU can provide constantly updated assertions about YOURSELF to a claim provider. How might this work? Well, think about the implicit attention data currently locked up on your computer. Might you want to allow a company that serves as your “movie preference” claim provider to have a persistently updated stream of your implicit movie data? For example, if you established such a relationship with Netflix, they would have a real-time stream of your movie searching, viewing, and purchasing activity that occurred OUTSIDE of their site, and could thereby provide you and other sites where you used their “Movie iCard” with better recommendations.

So the rCard puts YOU back in the loop of the iCard claim stream and allows you to automatically update that information on a POLICY basis. In other words, with an rCard, you can set a policy that defines WHO gets updates on WHAT data and WHEN at a granular level. If PERSISTENT, GRANULAR, BI-DIRECTIONAL data links sound familiar to those who’ve been reading this series, it should. Establishing those kind of data pipes are exactly what XRI/XDI are designed to do, and in fact Higgins uses XRI/XDI in the rCard layer.

So what are the most important things to remember about Higgins?

  1. The technology has been in development for FIVE years now, so you may want to think twice before duplicating it.
  2. It is MORE than just the open source iCard implementation. Identity is a MEANS to an end, not the end itself.
  3. With the rCard, YOU are back in the loop and can establish persistent and granular assertions about yourself.

Next up are the two final installments on iCards: a discussion of the Pamela Project and an interview with Kim Cameron of Microsoft’s Cardspace.

Be Sociable, Share!