OpenID for social sharing

Brian Ellin posts about a script he created by which access to resources can be controlled in OpenID.

Brian wanted to share a playlist but didn't want to make it available to all and sundry. This scenario, of one user controlling which of their friends/family/colleagues can access some resource of theirs, was key for the development of Liberty's People Service.

This is the first time I've seen it explored in the context of a URI-based identity system like OpenID. I can see some differences (which may or may not reflect any real architectural differences between OpenID and Liberty):

1. Brian has the 'trust list' (i.e. the list of friends authorized to view the playlist) maintained and running at the service provider at which the resource is hosted. The implication is that he would need to duplicate the creation and management of this list (or some variation) at any other SP at which he has other resources for which this sort of access control would be desired (or even for some other playlist held at the same SP).
   
   The whole premise of the People Service was to pull the management and storage of this sort of 'friends list' away from particular SPs to a dedicated provider. SPs still own the access control policies, but the rules are defined in terms of identities and/or groups held at the dedicated People Service Provider. For the user, the value is maintaining their friends list in one place, but leveraging it all the various SPs that refer to it. Critically, in the People Service, access permissions can be defined against a group of users rather than individual identifiers.
   
   An OpenID-based system could presumably do something similar through retrieval of a centralized FOAF file.
   


2. Brian's model for getting people onto the list is

   Email me at brianellin at @@@@.com, and I’ll stick you in the trusted list.

   So, were you to send Brian a mail requesting access to the playlist, you would supply your Openid URI and Brian would add it to the approved list.
   
   In the People Service, we defined an invitation mechanism by which the resource owner would notify his/her friends of the possibility of being added to the list and the access to some resource that would be enabled, and be given the option of declining the privilege if desired.
   


3. The resource here (the playlist) would be accessed through a browser and then downloaded or played.
   
   In support of this sort of cross-principal resource sharing, we added new functionality to Liberty's Web Service Framework so that one user (or some provider acting on that user's behalf) is able to access the identity resources of another (user) through SOAP interfaces and not just the browser.
   
   So, for instance, my music player could retrieve the playlist directly from the hosting server, rather than reply on me to initiate things through the browser. Also possible would be for me to be given appropriate rights so that my client could post my own playlists to the server through the same APIs.

Differences aside, it's interesting to see different identity systems moving beyond SSO.