As I’ve explained more than once in this blog, a greater problem than finding reliable Identity Providers is getting the websites we know and love to become Relying Parties. That is exactly the problem that Pamela has deemed to attack with her eponymous project. As the project’s mission statement says, “The Pamela Project is a grassroots organization dedicated to providing community support for both technical and non-technical web users and administrators who wish to use or deploy information card technologies.” Given the difficulties I experienced even USING iCards as a non-technical web user, this seems like a pretty ambitious task, and as part of this post, I’m going to try to get my blog up and running. First, a few words about Pamela and the history of the project.

Pamela first ran into the issues surrounding Identity in her role as a technology consultant in Calgary in 1999. Anyone who’s done any large-scale enterprise software installation has likely had a similar experience–try to do anything and you’ll run into a myriad of (often semi-functional) authentication and directory services before you can even get off the ground. She’d been working at a company that does Peoplesoft installations and with Oblix (an enterprise self-service password management tool later acquired by Oracle), when she attended her first Burton Identity conference in 2001. It was here she first began to think of Identity as a (the?) core technology problem, as opposed to something peripheral to what she wanted to get done. It’s a realization that, once had, can become a little consuming (trust me, I spend WAY too much time building software to be blogging about anything–especially, SOFTWARE).

Her second “ah-ha” moment came when, if my notes serve me correctly, she was “hit on the head with a brick” by Kim Cameron at the 2002 Catalyst conference. There he drew her a brief sketch on a napkin where he showed the three party system (Subject, Relying Party, Identity Provider) that is at the core of most of the emerging identity systems. She was hooked, but it wasn’t until in 2005, when Kim added some sample PHP Relying Party code to his blog that she saw a place where she could contribute. As a sometimes PHP hacker, she took the simple code, and began to port it over to some of her favorite PHP frameworks (WordPress, Joomla, and MediaWiki). Since that time, she and about 10 other contributers have been working to get a 1.0 version of the product out, which, given Pamela’s commitment, I suspect will be about like most other project’s 2.0 release.

Before writing about my experience installing the WordPress v0.9 plugin, a word about the seemingly self-promulgatory name of the project because I think it says a lot about Pamela as a person and the Identity movement she’s part of. According to Pamela it’s the last name she would have thought of as a woman working as a technologist. As she explains, it’s hard enough as a woman to get recognized as a serious technologist without drawing unnecessary attention to yourself. Having a wife who is one the best Java engineers in NYC, but who also is regularly asked if she REALLY wrote the stunning code she produces, I can attest this is true. It’s because of this stereotype though that Pamela chose the name. She was tired, as someone who is self-admittedly “vocal”, of this kind of self-inflicted sheepishness. So in “defiance to self-regulation”, and at Craig Burton‘s urging, she chose The Pamela Project.

This is indicative of Pamela and many others I’ve met in the Identity movement not only because it demonstrates the self-reflection surprisingly consistent in this crowd. It is indicative because it shows a willingness to take a risk and do something insanely difficult in order to do something you believe in. I finished my talk with Pamela asking her why she does it. Why leave a long day of fighting with technology to spend the evening coding on something that she can never hope to gain from financially? Her answer was that it is BECAUSE Identity is still too early for many to make a living at it that she participates. It ensures that the many technologists looking to make a quick buck are nowhere to be found. It ensures that Pamela can spend time with people who do what they do, because like her, they care.

I’ll let you know how my experience actually USING the Pamela project goes in my next post. In the mean time, as you wait in breathless anticipation, why not go over to the project’s site and ask Pamela how you can be of use. This is a big project and they’re going to need all the help they can get.

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.