Liberty Alliance explains the need for a ‘People Service’

Late last year the Liberty Alliance announced the release of the latest version of ID-WSF 2.0, Liberty’s open framework for identity-based Web services. Part of the new 2.0 release is something called “The Liberty ID-WSF People Service,” a “service” which I questioned the need for in a newsletter last month (“Who needs specs from the Liberty Alliance?”).

In a recent e-mail exchange with Paul Madsen, co-chair of the Liberty Technology Expert Group, and author of the white paper “Liberty ID-WSF People Services – federated social identity” the questions of why Liberty is interested in people, and why this new service is needed drew a somewhat lengthy – but informative – response. The words in square brackets ([]) are my interpolations or explanations of things Paul says which might otherwise be obscure outside the entire discussion that was going on. According to Madsen:

“People Service is motivated by the current fragmentation of user’s social identity info. Lots of apps (e.g. LinkedIn, Flickr, Last.fm, etc) build on some subset of ‘who you know’ but they all capture their own slices. So, as for lots of other aspects of identity, the user bears the burden of maintaining the multiple silos across the various apps. One consequence of this is the requirement that both users have accounts at the same provider (think ‘If you wish to see Bob’s photos, please sign in or create an account’).

“People Service is designed to allow users (or providers on their behalf) to establish ‘person-to-person’ (and cross provider) connections with those friends, family, colleagues etc with which they expect/desire to interact with online. The various members of the list [that is, list of friends and family, etc.] can be categorized/tagged [e.g., Canadian] and grouped [Sun Employees].

“If Dick is in my People Service (PS), the PS and Dick’s IDP [Identity Provider] will have established an identifier for Dick (set up the first time Dick was invited to be added to my list). So, if and when I’m at a service provider and want to ‘interact’ with Dick (e.g. allow him to see my playlists, edit my calendar, etc) the existing identifier between my People Service and his IDP can be the starting point by which the service provider can discover and query relevant bits of Dick’s identity (assuming he consents to this).

“The basic premise is to extract social info from the apps (at least those for which the management of such info isn’t core to the value proposition) so that it can be reused across applications. The fact that I ‘know’ Dick could be relevant for IM [instant messaging], photo sharing, BTO [formerly Bachmann-Turner Overdrive, a rock group] Fan club, Canadian political discussions, etc so the basic connection can be leveraged across all these apps. If Vancouver falls into the Pacific, I can delete him in one move [references to Sxip founder Dick Hardt who lives in Vancouver].

“People Service builds on Liberty’s existing Web services framework so benefits from the privacy & security mechanisms defined there.

“So, (kinda) a SOAP [Simple Object Access Protocol] API into a FOAF [Friend Of A Friend] file with associated mechanisms to ensure privacy through generation & mapping of opaque identifiers.”

That does, to me, make the need clearer. But we’ll explore this a bit more in the next issue.