A single social network?

A while back, Phil Gyford lamented on the burden of his repeatedly having to

tell computers who my friends are

Amen to that.

Phil is somewhat equivocal on what he is looking for

I really, really want a single service where I can say “these people are my friends” and then when I sign up to any new website I can sync it with my previously-defined social network.

This is exactly what the Liberty Alliance People Service is designed to provide. In the People Service model, registration at the new social application would go something like this

1. Joe goes to SocialApp.com
2. SocialApp.com and Joe's IDP establish an identifier by which they will refer to Joe (in a B2C scenario, this identifier will likely be unique to these two providers)
3. Joe is SSOd into SocialApp.com as a result of authenticating too his IDP.
4. SocialApp.com discovers the location of Joe's People Service, namely FriendlyFolks.com
   
5. SocialApp.com, armed with necessary credentials, queries FriendlyFolks.com for the list of Joe's friends
6. FriendlyFolks.com checks its and Joe's policies and determines that it is authorized to respond with the list
7. SocialApp.com shows the list to Joe and says 'Who do you want to bring in?'.
8. Joe selects Alice and Bob from his list - presumably based on the nature of the community that SocialApp.com supports, e.g. stamp collecting etc
   
9. SocialApps.com sends another message to FriendlyFolks.com, this time asking for identifiers for Bob and Alice.
   
10. FriendlyFolks.com, works with the IDPs of Alice and Bob (they are likely different) and asks them for an appropriate identifiers to present back to SocialApps.com
11. Relavent IDPs either provide or create identifiers for Alice and Bob that will be unique to SocialApps.com
12. From here on, SocialApps will either map Alice and Bob into an existing account, if one exists, or create a new one (obviously maintaining the connection with Joe)

The multiple steps in the above come from Liberty's assumption that it should be possible for no two providers to share the same identifier for a given user - and so the complexity of the People Service mapping identities between the various actors.

If all providers share the same identifier for a user (as in default OpenID, and as Liberty People Service can support) , either for Joe or his friends, it becomes relatively simple, something like this

1. Joe goes to SocialApp.com
2. Joe provides SocialApp.com his global identifier.
   
3. Joe is SSOd into SocialApp.com as a result of authenticating too his IDP.
4. SocialApp.com discovers the location of Joe's People Service, namely FriendlyFolks.com
   
5. SocialApp.com, armed with necessary credentials, queries FriendlyFolks.com for the list of Joe's friends.
6. FriendlyFolks.com checks its and Joe's policies and determines that it is authorized to respond with the list
7. SocialApp.com shows the list to Joe and says 'Who do you want to bring in?'.
8. Joe selects Alice and Bob from his list - presumably based on the nature of the community that SocialApp.com supports, e.g. stamp collecting etc.
   
9. SocialApps.com indexes Alice and Bob against their global identifier.
   
10. From here on, SocialApps will either map Alice and Bob into an existing account, if one exists, or create a new one (obviously maintaining the connection with Joe).
    

Tags: Liberty Alliance, People Service, social networks, OpenID