I’m now a proud member of LinkedIn – entirely due to conversations I was part of during the Identity Open Space in Vancouver last week. This particular site seemed to be the poster child for cases involving portability & accessibility of relationship data. The question on everybody’s mind seemed to be: Assuming that protocols exist to make relationships portable, what possible reason could there be for a site such as LinkedIn to adopt such protocols? Isn’t their identity silo a corporate asset? Technically, you can export your LinkedIn contacts – but the trick is, without some kind of common identifier to re-link your list into other social networks, your list is nothing but a bunch of text strings. Really it isn’t the data itself that is valuable – it is the method by which the data is indexed.

Enter Liberty “PeopleService”. The idea is for users to create & manage relationship lists which are made available & indexed in such a way that they can be leveraged in many places. Every person in the relationship cloud would have an IdP account that is (a) used to authenticate to the PeopleService, and (b) is used as part of the “handle” that would be used to uniquely identify this person within a relationship list that might span multiple PeopleServices. This is a woefully simplistic summary of the service, based on a talk given at IOSVan by Paul Madsen, hopefully I’ve got the essence.

The advantages to this plan are straightforward. Users would see the same relationship data at multiple sites, and would only have to maintain those relationships in one place. Sites leveraging this information could gain access to a fully fleshed out network of people without having to persuade their users to input everything from scratch. Best of all, everyone’s computer-unsavvy aunt doesn’t have to be walked through a whole new account creation step every time you want to share something with her on a different site – just get her an IdP account and refer to it forever more.

The problem is, entities who have worked to build their own “zoo” (to use the slashdot term) will need a good solid profitable reason to switch from a successful silo mentality to a federated method, which in their case would seem to be more about giving than taking. The idea that everyone will just suddenly see the light and ‘heed the lessons of Microsoft’ makes me laugh. Not even I’m that optimistic :-)

The way I see it, the only way the plumbing is going to change is if the decision is a business decision and not a technical decision. And the only way I can see that decision-makers who don’t happen to be visionaries in this space will come to understand the benefits, is to be outplayed. In a rosy perfect world, the right startup company will adopt Liberty’s PeopleService (& therefore the rest of the stack) from inception, and build their zoo from scratch. They will sign everyone up to what I predict would be their own ‘locally owned & operated’ IdP & PeopleService, and the resulting zoo + service will be adopted gladly by other sites. At some point the advantage of a wholly owned relationship cloud would consequently dwindle. The advantage will fall to those with valuable meta-data, as Bob Blakley so eloquently pointed out at Catalyst this year.

Can I pause to ask a dumb question? Is it really a given that moving ownership of the zoo from application silos to IdPs gives more power and/or convenience to the user? Pete Rowley asked at IOS Van whether the Liberty folks were just architecting yet another identity silo. His comment started me down the path of pondering what happens when you distribute ownership of the zoo, but merge usage from an RP perspective. Seems to me that vertical silos will be replaced by horizontal silos. Sure, in theory no one IdP would control all the users – but they will control all the sites that their own local userbase can access, through negotiation of trust relationships and/or contractual red tape, however that works. This seems to me to potentially be much more powerful than the clout wielded today by a Yahoo! or a LinkedIn. Are we leaping from the frying pan into the fire, trading application lock-in for IdP lock-in, or is the portability built into the protocol enough to make sure that a user can dodge that kind of pitfall with their relationship lists intact?

Either way — wanna connect?

— Pam