I also indicated that whereas the lavender roles receive a lot of attention in the community, the other colors do not. In this post, I’d like to take a look at what I’m calling a “Claim Broker” by outlining what a Claim Broker might do, why it is necessary, and some of the challenges a business like this might face.

As I wrote in part 1 of this series, much of this thinking was spurred by a talk Bob Blakley gave on the role of Relationships in the Identity industry at Burton’s Catalyst this summer. In that talk, he focussed on the need of what I’m calling a “Claim Holder” to develop a strong relationship with the Subject whose claims they are responsible for. This, of course, makes sense, because the stronger the relationship, the better the claims will be. When I began to think about this, however, I began to wonder if the MAJOR barrier to a broader adoption of Identity technologies was the weakness of THIS relationship.

To give an example of this, I have a pretty strong relationship with Netflix as my “movie” Claim Holder. I also have a strong relationship with Fandango. Now the question is, do these organizations really need to improve their relationships with me? They could (and probably should–particularly Fandango), but my relationship with THEM isn’t what’s preventing me from sharing the claims they have about me with other organizations. The relationship that is missing, is the relationship between THEM and OTHER ORGANIZATIONS.

Now there are good reasons these sites don’t have relationships with other websites (or each other as far as I can tell):

1. It’s not their core business. Their core business is and SHOULD BE fostering a relationship with ME.
2. The other organizations that would be interested in their data are likely competitors.
3. Establishing these relationships is expensive and doesn’t scale for a single Claim Holder.
4. There is no obvious financial incentive for establishing these relationships.

The point being, if the Identity industry waits around for Claim Holders to rise up and become Identity Providers, the Identity industry will be waiting for an amount of time approaching never. It makes no sense for a Claim Holders to enter into this business. The above conditions are PERFECT, however, for a Claim Broker:

1. A Claim Broker’s core business IS to establish relationships between Claim Holders and Claim Consumers.
2. A Claim Broker can act as a NEUTRAL broker of trust between competitors.
3. The economies of scale work for a Claim Broker by multiplying the value of each relationship they create.
4. Part of a Claim Broker’s job is to assess supply and demand and to set prices.

Let me unpack these points above beginning with the idea that this industry needs a strong sales organization DEDICATED to building relationships between Claim Holders and Claim Consumers. I see a real gap between these two kinds of organizations that is going to take a TON a sales work to close. Claim Holders often view their customer data as the core of their business that provides them with a competitive advantage against existing businesses and a barrier to entry for new ones.

Claim Consumers, on the other hand, are ill-equipped to make use of these claims and don’t fully-understand the value of the data they would receive. Not only that, but this is all a very new and weird idea for both of these businesses, and any time you have to explain a NEW business model, you are facing an uphill sales challenge. The point being, this is an entirely non-trivial sales challenge that will need to be handled by a large and sophisticated sales organization.

The second point is that this sales organization can’t be an existing Claim Holder. There is no way that Netflix is going to convince Blockbuster that they, as Netflix, could act as a fair and neutral broker for Movie Claims. Google won’t convince Microsoft. Facebook won’t convince MySpace. If there is any hope of these organizations forming relationships, it will have to be through a neutral third party whose ONLY job is to maintain those relationships.

The third point is just a classic example of Network dynamics. If I’m Netflix, and I go out and establish a relationships with every website that could consume my Movie Claims, there is no way I can justify the cost. If, as a Claim Broker, however, I represent Netflix, Fandango, Moviefone, Blockbuster and every other movie Claim Holder, each Claim Consumer relationship I establish is MULTIPLIED in value by the number of Claim Holder relationships I have.

The fourth and final point is that before any Claim Holder will ever pay attention to this industry, someone will have to take the risk to develop relationship with Claim Consumers and establish a market price for the data the Claim Holders have. This, I believe, is the most pressing issue facing the Identity industry and one that is receiving WAY too little attention.

The industry continues to gloss over this fundamental question with the same tired examples of Credit Scores, Age Verification, and Address Verification. Certainly there are businesses here, but the one (Credit Scores) is already established and at best subject to slightly better margins using Identity 2.0 technologies and the other two (Age and Address Verification), in spite of reassurances that regulation will drive adoption, have been functioning across the entire spectrum (youth social sites, porn, and liquor for Age and e-commerce for Address) for a decade now without strong verification.

I am NOT arguing that these industries wouldn’t benefit from stronger claim validation, I’m simply saying that I haven’t seen enough leg work done on the sales side to give me any comfort about how MANY interested Claim Consumers there are or how MUCH these organizations would pay for stronger claim verification. And this is the state for the OBVIOUSLY valuable claims. What about the more esoteric visions that are driving much of the energy around Identity technologies?

How many Claim Consumers are there for Movie Claims and how much would they pay? What about for my music preferences? Or my Social Graph? I’ve seen virtually no work done on this and the little I’ve done hasn’t been encouraging. The basic idea, is that the Claim Consumers could use these claims to provide a more tailored experience to their visitors. To do this, they would need to incorporate this into some sort of recommendation engine technology. I’ve spoken to some of the recommendation engine companies and their customers. The picture I get is this:

1. Explaining the value of this technology even to large sophisticated Claim Consumers is VERY challenging.
2. The technology is non-trivial to implement and a major integration headache for Claim Consumers.
3. The QUALITY of the recommendations mean very little in terms of lift (the increase in sales post implementation).

In fact, if I were a recommendation engine company, I’d build a simple web service that was easy to implement that recommended socks and underwear at the end of each purchase. The point being, that for these more general “customized web” use-cases for Identity Claims, there is little indication that ANYONE is willing to pay ANYTHING for the data.

So what are some of the tough questions facing a fledgling Identity Claims Broker:

1. How much value can Idenity 2.0 technologies provide to the more mature Claim Holder/Consumer relationships?
2. Will the gap between the value of the Claims to the Holders and the value to the Consumers ever narrow sufficiently?
3. When will the adoption of recommendation engine technology be widespread enough to provide a large and ready market of Claim Consumers.
4. How expensive will it be to sell Claim Holders/Consumers on a novel business that they both have reason to be skeptical of?

As I hope the above makes clear, there is a LOT of work to be done on the relationship between Claim Holders and Consumers. Furthermore, it is my opinion that this work should be done PRIOR to building a ton of great technology to enable it. I’ve built revolutionary technology before assessing the need for it WAY too many times before to do it again. Nothing is more depressing than spending the inordinate amount of care that it takes to build quality software only to discover that there isn’t enough pain to justify the expense of convincing entrenched industries to use it.

What do you think? Does anyone have a better sense of how many Claim Consumers are eagerly awaiting validated claims? Does anyone know how much they will pay? Drop me a note or a comment if you do.

1. What other relationships are missing from the Identity scene that might be inhibiting its development?
2. What other information would be valuable in Bob’s “Relationship Data Object” besides the nature of the relationship between the Subject and the IP?

In other words, Bob spent a lot of time talking about the relationship between the IP and the Subject, but I want to know if there are some other relationships, the neglect of which, might be a greater inhibitor to this industry moving forward. Also, if we do find some other relationships that need to be accounted for, what implications does that have for the “Relationship Data Object” Bob sees as the tradeable asset in the industry?

Now since my thoughts about this have been in some way inspired by an analysis of Bob’s talk, I want to keep with that theme and AVOID doing something with this series that both Bob and I have a tendency to do, and that is to “bury the lead”. In other words, Bob and I both like to keep the “cool” idea that we think we have until the end of a paper. This is a lot of fun as an author because it let’s us build up some suspense. The problem with this is that the subject matter of Identity is obscure enough on its own, and by trying to be clever, we can very easily lose our audience. It’s kind of akin to trying to build tension when writing an API–it may be the wrong literary device for the subject.

Having said that, let me introduce the diagram below:

This diagram outlines what I see as a more fully fleshed out Identity “stack”. The roles in carnation (OminGraffle’s term, not mine) show the roles that the Identity community spends a lot of time talking about. The roles in other colors are the roles that get less attention. Now before I go on, let me make clear that I’m not really introducing anything novel here. I’ve heard all these other roles discussed before (and I’m sure that upon publishing this, I’ll learn there are entire projects dedicated to them!). Nonetheless, for all the talk and work going on around the carnation roles, these equally important roles seem to get short shrift (for reasons that are not too surprising and that I shall endeavor to explain).

More importantly, I believe that each of these roles is a NECESSARY component of the Identity stack, if Burton’s vision of an “Identity Oracle” or Microsoft’s vision of “Minimal Disclosure” is going to be realized. Further, I also believe that each of these roles is probably better handled by DIFFERENT kinds of organizations. The good news if this is indeed a more accurate picture of the IP is that there are a NUMBER of potential business opportunities surrounding the Identity space. The bad news is, I don’t think the industry has done enough legwork to determine if there is enough DEMAND at all for claim-based Identity to justify the incredible resources necessary to create any one of these businesses.

In my next post, I’m going to take a look at the business in the exploded Identity stack whose role it is to DETERMINE the supply and demand of claims, namely the baby blue (or Sky in OG speak) “Claim Broker”.

Which brings me to the point of this piece: Relationships and Identity. I heard Bob Blakley give his talk on needing to introduce a Relationship entity into the identity discussion for a second time (see my brief summary of the first time here). As I listened to the talk, I noticed that Bob was subtly equivocating between two definitions of the word relationship as the talk progressed. It was interesting because Bob’s typically very precise with his language. When someone like him begins to equivocate, it’s typically because there’s some unconscious energy surrounding the word that’s trying express itself, but because it isn’t fully conscious, it sort of slides out at the seams.

These unintentional expressions are the stomping grounds for Freudian analysis because usually what’s seeping out is repressed and in the highly repressive Victorian era in which Freud lived, these energies were often repressed to the point of disease. The trick for the analyst has always been (at least) two-fold: to notice these moments of seeping intent AND to allow the PATIENT to interpret that intent without introducing too much of the analyst’s own perspective into the interpretive process (this is called projection and a BIG no-no).

The second trick is often much harder than the first. Fortunately for me, however, I’m less interested in analyzing why Bob’s leaking “Relationship” energy (though that would no doubt be great fun!), as I am in riffing on the energy in a more jazz-like way by letting it combine with my own thoughts about building a business in this space. In other words, I’m going to EXPLICITLY project.

To understand Bob’s first use of the word “Relationship”, let’s go back to the simplified diagram of the identity provider I’ve used ad nauseum in this blog:

Here we see a person (Subject) trying to get some information to a website (Relying Party) that they currently have entrusted to a third party (the Identity Provider). Bob starts his talk addressing the relationship between the Subject and the Identity Provider. His first point is that Identity Providers need to focus on building QUALITY relationships between them and their subjects, since, as he’ll claim, that’s ultimately what they are selling.

This makes complete sense and is an important point. Who we are is always defined in context. My relationship with my wife is entirely different than the one I have with my coworkers. Because of this, in a very real sense, I am a DIFFERENT person with them than I am with my wife (though I try to be less bifurcated than most, which has some interesting ramifications for both my work AND my marriage!). Regardless, the point is, the context of your relationship with your IP will DEFINE what KIND of identity about you that they possess and that relationship should be made explicit when they share that identity with a Relying Party.

The confusing equivocation comes when Bob explains his “Relationship” data object, which I have reproduced below:

This is a fictional example Bob envisions coming from Facebook. Confusingly, the example is of a claim that Facebook has between him and a coworker, namely that they are friends. Now this is a NEW kind of relationship (between two people), which I would argue is actually the CLAIM of this relationship data object (namely that Bob and Lori are friends). So Facebook is claiming that Bob and Lori are friends, but for this to be a true RELATIONSHIP data object in the sense Bob was talking about in the beginning of his presentation, the top of the card should read “Relationship: Three year member of our casual social network” rather than “friendship”, which is really part of the claim an only coincidentally a “relationship”.

In other words, the thing that makes a data object a “Relationship” data object, is not if the claim is about two people, but rather that in addition to any claims, it ALSO contains details about the context between the IP and the subject within the data object itself–in this example this could include the duration of the relationship (three years), how frequent it is (every day!), and how serious it is (just for fun). Now this is in some ways just a case of a bad example on Bob’s part that probably confused his audience, but I bring it up because incongruities like this get me actually THINKING, and as I thought, two important questions came to mind:

1. What other relationships are missing from the Identity scene that might be inhibiting its development?
2. What other information would be valuable in Bob’s “Relationship Data Object” besides the nature of the relationship between the Subject and the IP?

These questions are, of course, only tangentially related to Bob’s original discussion, but like I said, exegesis is just a path to interesting thinking rather than an end in itself for me. In my next post, I want to begin to unpack some of that thinking, because I think it’s important for the business of Identity (Relationship?) moving forward.

1. International Regulations:  Hearing from George Sherman about the constraints put on Morgan Stanley’s efforts to build an Identity system, given that they have to comply with dozens of regulatory jurisdictions, clearly demonstrates the hazards we are likely to face as we grapple with the widely divergent privacy legislation emerging throughout the world.
2. Revocation: Employees move on (often not by their own choice).  Enterprises understand all the complexities of revoking access to multiple systems.
3. Federation: Companies need to work with partners, suppliers, consultants and a multitude of other organizations.  They’ve dealt with the issues required to enable people from other organizations to access to their secure systems.
4. Usability: The enterprise has experimented with hundreds of Identity Management products and has an extremely tight feedback loop with their users.  We can learn from their UI sucesses and failures.
5. Roles: Enterprises have had to deal with fine-grained permissioning for decades.  What kind of employees should have access to which details of a customer isn’t too far from wanting to let your mom see your baby’s first step, but not your drunken exploits from the weekend that’s all the rage with your friends.
6. Monitoring: Enterprises need to know when someone’s credentials have been compromised so they can take immediate action.  What happens when someone’s internet ID has been compromised?  How do we even know and what do we do?
7. Concensus Building:  Getting different business units to agree on a framework is no less easy than getting Google and Microsoft to agree (okay… maybe a LITTLE easier).  Regardless, spend a half-hour speaking with a CIO who’s implemented a company-wide identity management project, and you will quickly learn how expert they are at building concensus around a project.

These are just a few examples, but it’s clear the enterprise has dealt with identity issues for a long time and solved use-cases many in the internet identity community have yet to consider.  We need to learn from them, so we don’t make the same mistakes or repeat work that’s already been done.  I don’t know exactly how to start this dialog, but it’s one that needs to begin.  Any suggestions?  That’s what Comments are for.

For those of you unfamiliar with the (un)conference format, it bears going over. At 8:45 am all the attendees circle up and people go the center to fill out notebook-sized cards with discussions, presentations, or demonstrations that they’d like to lead. They then each give a brief overview and post the cards on a giant wall schedule. Some of the sessions have been planned long ago, others are inspired by the day, but everyone has equal access to time slots. Only two rules prevail: sessions should go on only as long as they still have energy (this could mean a session ends early or takes all day) and individuals should remain in a session only as long as it is the most valuable place for them to be (in other words, getting up and leaving for whatever reason is encouraged).

With spontaneous session selection, indeterminate times, and roaming participants, it may seem that such a conference would quickly degrade into chaos, but I experienced just the opposite at IIW. Some highlights from the sessions I attended:

A session led by Dick Hardt on bi-directional validation of blog comments made by a single user across sites to help establish reputation. Conclusion: interesting but probably not worth the complex technology necessary to make it work for now.

A session led by Johannes Earnst on creating a community to ensure people are properly represented in the “Digital Deal” emerging between them and the sites they go to. Conclusion: a working group has been formed and a community site broad enough to embrace the multitude of perspectives is forthcoming.

Two sessions led by Joseph Smarr on the emerging social stack and a proposed consolidation of the major players’ various contact portability apis. Conclusion: the best description of the tools now available for social data export (posted on his blog) and a specification that is likely to be implemented by most of the major internet players over the next year.

A demonstration by Andy Dale of Ootao’s new iPage product. Conclusion: a VERY powerful backend that masks the complexity of the various claims sharing protocols and the first implementation I’ve seen that allows you to consolidate claims from various iCards into a single managed card.

A description by Drummond Reed of the XRDS-Simple, a discovery service being adapted by OpenID and Oath for service discovery. Conclusion: a light-weight alternative to XRDS that is likely to become the standard for these lighter protocols.

A demonstration of relationship cards (rCards) by the Higgins team. Conclusion: Cardspace makes a strong distinction between Self-Issued iCards (where you control the claims) and Managed iCards (where the vendor controls the claims). Since in most cases, you should control some of the claims (contact info) and the vendor should control some (like an airline with frequent flier miles), segmenting control over claims in a single card makes a TON of sense.

A preview of a paper by Bob Blakley that argued that the true value of an Identity Provider was not the DATA they have about the person, but rather the RELATIONSHIP they have with the person. In doing this, he proposed that the IP actually needs to provide much more than just the Identity information–they need to establish the terms under which the Identity can be used by the Relying party as well provisions for damages should the Relying Party abuse the Identity data or should the IP provide untrue Identity Data. Conclusion: This helps clarify what organizations would make good identity providers and moves the discussion from IP vs User vs RP rights into a discussion of mutual agreement of usage through contracts.

Now how many conferences have you been to where you can recall by memory every session you attended after a red-eye home? I’m lucky if I can remember what most sessions at a typical conference are about half way through the session itself! This just goes to prove the real quality of IIW. Much of the credit for this goes to the high-caliber of the attendees, but much credit also deserves to go to the day-to-day leader of the conference and one of the truly great connectors in the Identity space, the Identity Woman, Kaliya Hamlin.

Kaliya doesn’t get nearly as much credit as she deserves. Leading a conference and a movement that’s composed of SO many smart and opinionated people is a real trick. There are a lot of egos, careers, and hard work at stake in these emerging standards and people fight hard for what they believe in. Kaliya doesn’t assert herself into the middle of these necessary conflicts. Don’t get me wrong–Kaliya takes great glee is stirring the pot, but a community of technologist NEEDS this kind of communication and she never comes across as mean-spirited or controlling. Kaliya understands two of the most important aspects of leadership–a willingness to serve and a willingness to facilitate without domination. There are many communities that would be lucky to have leaders who understand these things, and IIW is lucky to have Kaliya.

Many people know (of) Kim from his Seven Laws of Identity, but Kim’s story (like most of the participants in the community) starts much earlier. Kim began his career in academia teaching Sociology (he had concentrated in both Sociology and Math/Physics), an occupation that he loved (teaching), but a subject that he soon became disillusioned with (as he said, “There was never any way to prove who was right”). Like any disillusioned sociology professor, he did the natural thing and started a Reggae band (no, I’m NOT making this up), called the Limbo Springs and proceeded to tour the East coast of Canada and the US for the next 7 years.

Having come off his 1981 sold-out stadium tour promoting the multi-platinum “MetaLimbo” (okay, THAT I made up, but JUST that), he returned to Canada to teach Assembly at George Brown University, Canada’s largest community college (as he explains, technology was always his fall-back when he needed money—sounds familiar!). It wasn’t long, however, until he realized that teaching technology wasn’t what he wanted to do long-term, so he and the head of the IT department decided to start a technology business. As he explains, they were dead-broke at the time (as btw it seems everyone in this space is broke at some time or another—I, myself, like to go broke about once every four years), so they did what any broke technologist would do and started consulting.

Kim and his partner were obviously quite good at what they did because they built this nascent technology company into a 40 person strong outfit by 1992, which was when Kim first encountered the problem of Identity (How many of YOU can say THAT?!). The issue of Identity arose when he was trying to build an email directory for Sprint’s 60,000 employees. The problem was that those 60,000 employees had 150,000 email addresses (it was common to have an email for every ISP at the time). The question was, how do you find a way to associate each of those email addresses with the correct person in the directory?

If you know anything about Kim or his company, you will recognize this was his first foray into the technology that would put Zoomit on the map (and eventually in Redmond as part of Microsoft)—the metadirectory. Metadirectory technology arose out of the need to simplify the management of people and software in the enterprise. Anytime someone joins a company, they have to be given permission to use any of a number of pieces of software and other digital assets. The larger the corporation and the more wired it is, the larger this problem becomes. How can an administrator setup 25 accounts for every person for a company that hires 10,000 employees a year? Better yet, how can an administrator ensure that access has been properly removed for a company that fires that many people in a year?

To solve this problem, Kim and the Zoomit team came up with the concept of a “metatdirectory”. Metadirectory software essentially tries to find correlation handles (like a name or email) across the many heterogeneous software environments in an enterprise, so network admins can determine who has access to what. Once this is done, it then takes the heterogeneous claims and transforms them into a kind of claim the metadirectory can understand. The network admin can then use the metadirectory to assign and remove access from a single place.

Zoomit released their commercial metadirectory software (called “Via) in 1996 and proceeded to clean the clock of larger competitors like IBM for the next few years until Microsoft acquired the company in the summer of 1999. Now anyone who is currently involved in the modern identity movement and the issues of “data portability” that surround it has to be feeling a sense of deja vu because these are EXACTLY the same problems that we are now trying to solve on the internet—only THIS time we are trying to take control of our OWN claims that are spread across innumerable heterogeneous systems that have no way to communicate with each other. Kim’s been working on this problem for SIXTEEN years—take note!

When I asked Kim what his single biggest realization about Identity in the 16 years since he started working on it was, he was slow to answer, but definitive when he did—privacy. You see, Kim is a philosopher as well as a technologist. He sees information technology (and the internet in particular) as a social extension of the human mind. He also understands that the decisions we make as technologists have unintended as well as intended consequences. Now creating technology that enables a network administrator to understand who we are across all of a company’s systems is one thing, but creating technology that allows someone to understand who we are across the internet, particularly as more and more of who we are as humans is stored there, and particularly if that someone isn’t US or someone we WANT to have that complete view, is an entirely other problem.

Kim has consistently been one the strongest advocates for obscuring ANY correlation handles that would allow ANY Identity Provider or Relying Party to have a more complete view of us than we explicitly give them. Some have criticized his concerns as overly cautious in a world where “privacy is dead”. When you think of your virtual self as an extension of your personal self though, and you realize that the line between the two is becoming increasingly obscured, you realize that if we lose privacy on the internet, we, in a very real sense, lose something that is essentially human. I’m not talking about the ability to hide our pasts or to pretend to be something we’re not (though we certainly will lose that). What we lose is that private space that makes each of us unique. It’s the space where we create. It’s the space that continues to ensure that we don’t all collapse into one.

Well on that rather heady note, I’ll end this look into the history of iCards. I for one, however, am glad that as we explore this space and redefine what it is to be a person, that we have someone like Kim deeply involved. I want to move forward as much as anyone, but I also understand that we are touching on what it means to be a person in the 21st century, and when dealing with the core of humanity, we ought be most careful about any unintended consequences we may produce. Next up, the “original” identity metasystem, the Liberty Project, and the lightweight alternative that is taking the internet by storm, OpenID.

Having my brand new certificate installed, I was anxious to take it out for a spin. I went to the SSL manager in my Bluehost control panel, and low and behold, they were NOT lying… there was my certificate. I clicked on the link to view my private key. This is what I saw in my Bluehost panel (I’ve change two characters in the image below so it’s STILL private!):

And this is what the fields I need to copy SOMETHING into look like in the Plugin options:

Okay… three fields need to be filled in. I guessed the secure site URL was just “https://drstarcat.com”, and when I clicked saved, the plugin gave me a green arrow next to the URL so I was on the right track. Now the tough part… what part of the above information about my SSL certificate is the Private Key? I’d installed these things before, but I couldn’t remember. It DEFINITELY seemed like the information in the top box, but what piece of it? Do I include the “—–BEGIN RSA PRIVATE KEY—–” part or just the stuff between it and the “—–END RSA PRIVATE KEY—–”? I tried BOTH of course and I STILL couldn’t get that last red “X” to turn into a green check mark.

I then begin to fixate on the “SSL Passphrase” piece. Do I have one of those? And if so, where is it? I write back to Bluehost. They reply almost immediately (Nice!). I DO have a pass phrase, but they hadn’t told me this. Now with my pass phrase in hand I am SURE I am nearing success. I try the pass phrase with just the stuff between the begin and end statements. No green arrow. I try it with the begin and end statement included–STILL no green arrow. NOW I’m in that very bad place where I have three variables, none of which I’m sure about, and no combination that seems to work. What do I do?–the manly thing of course. I write Pamela and ask her for help (yes, I was whining in the email).

I wait for a couple of hours for Pamela to respond. Given the fact, however, that this is NOT her job, she does not respond to me like my new pals at Bluehost. I start to tinker again. As I mess around I notice that my SSL certificate is ACTUALLY for “www.drstarcat.com”, not “drstarcat.com”. Now I had already tried switching the URL field to “https://www.drstarcat.com”, but I still hadn’t gotten the green arrow. Regardless, I was sure this would be a problem in the future, so I went ahead and wrote Bluehost to tell them to give me a new one with just “drstarcat.com”. They tell me that they stopped issuing certs for the base URL because “Cpanel would randomly uninstall the SSL”. I tell them I’ll take my chances and to get me the new one.

Two hours later (and just a little while ago), I’m done with dinner and I stumble back over here to my computer to see what new information I might have. Still no Pamela, Mike’s enjoying my pain, BUT the guys at Bluehost have given me the new cert. I’m pretty skeptical that it’s going to work, but since I don’t have anything better to try, I begin trying all the possible combinations in the three fields, and BAMN, like a sore-luck loser in Vegas who finally sees lucky 7s across the slot machine window, I get it… SIX green arrows! The winning combination:

Secure Site URL: https://drstarcat.com

SSL Private Key: Include the “Begin” and “End” statements

SSL Pass phrase: Required (at least for me).

Nice… my wife appreciates how I have to prove that I actually got it to work with an image. Too bad! I EARNED those six green arrows! Now the funny part is that I still don’t know what to do with my now functioning iCard enabled blog. I don’t require people to sign in to post (in fact, I can’t figure out HOW to require people to sign in, even for fun!). Regardless, if you’d like to sign into my blog using your iCard, you now can at this link. I’ll make sure that I learn how to require signing in to comment on my MOST important posts and enable LOTS of other really cool exclusive stuff for people who can figure out how to use an iCard, so I’m SURE it will be worth your while.

So what’s the final word on the Pamela Project? Well, clearly, I don’t have it, as this project (along with the rest of the Identity space) is JUST beginning in spite of how much work has already gone into it. Obviously any sane person isn’t going to go through what I did, but I also found out in my struggles that Pamela is about to release a version of the plugin that does NOT require SSL (talk about timing!) So really if you think about it, with just a little better instruction (put the dumb dumb download up front, and show exactly what needs to go into each blank), I probably could have installed the plugin (without SSL) in about 5 minutes (instead of 7 hours). If EVERY website in the world could become a relying party in 5 minutes, and that meant NO one EVER had to enter a password again… well, I’ll leave the math to you, but I think they might just be onto something.

Just to give some background, I’m attempting to install the Pamela Project Wordpress plugin v0.9 on my drstarcat.com blog that is hosted at Bluehost. The first step is to find the Wordpress plugin page on the Pamela Project site. Normally I’d go to the Wordpress plugin directory, but I believe Pamela doesn’t want to post it there until v1.0. The first thing I notice when coming to this page (because it is so well laid out) are the requirements:

This already puts me in a bit of bad mood because I don’t know if I have ANY of these things besides a “Wordpress blogging environment” and it pretty much looks like I’m here for the afternoon. The next thing I do is go to the link that provides installation instructions. The first thing they ask me to do is to get the plugin (seems like a good idea).

At first I panic because the instructions tell me to go to some directory on my server and then checkout the code from Subversion followed by some Unix commands. This sounds like something my development team asks me to do while looking at me as if they just asked me to grab a quart of milk from the fridge. As a non-Unix person, I can attest that it is more akin to doing some quick calculus to figure out how to put someone on the moon.

Fortunately, my panic subsides as I realize they have dumb-dumb instructions below this with a link to download the plugin. I can then just use Cyberduck to upload it to my plugins directory (yes, I like my technology masked by familiar childhood playthings). Wow… I actually have it on my server already, maybe today isn’t going to be so bad after all! Now I just go to my Wordpress admin page and go to the Plugins tab, and cool… there is the Pamela Project!

After I click the “activate” link on the plugin, I go to my “Options” tab to see if I can actually get this thing to work. As I look at the page, I’m both happy and sad:

I’m THRILLED that it looks like I have PHP 5 and these mysterious “Crypto Libraries” already installed (I probably would have had to quit otherwise!). I’m mildly sad to see that I need to get an SSL cert. Now, given that I understand iCards at a low enough level to know they use SSL, and given the fact that Pamela warned me on the instructions page that I would need this, I shouldn’t be disappointed, but I was REALLY hoping I could get away without it.

After sulking a bit, I give Bluehost a call. They make me feel better by making it seem like it’s not going to be such a big deal. At first I hope I’m going to be able to use the “shared” certificate that Bluehost let’s anyone use, but once I explain that I need the “Private Key” they tell me I’ve got to get my own. This also requires that I get a static IP (I KNOW, I was already warned in the requirements!)–total price: $90. Pamela will owe me a drink at IIW! Since it’s going to take a few hours to get my SSL cert issued and installed, I think I’ll post this and go outside for a break!

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.