There is nothing social in default SSO. There is a single user and he/she, based on an authentication performed at some identity provider, is granted appropriate access for their own resources at some service provider. There would seem to be some unexplored social (i.e. more than a single user involved) aspects of SSO.
For instance, a user may be SSOing in to access resources belonging to another user. If I define the permissions at some online photo site such that certain friends can see my recent photos; if and when those friends log-in to that photo site they will be granted those privileges. If they log-in with an account local to the photo site then its very straightforward for me to define privileges against the corresponding identifier and for the site itself to enforce them. This is how sharing currently works at such sites.
However, if they don't have such an account nor desire to create one, they will want to access my photos based on an authentication performed elsewhere, e.g. SSO in to the photo site. The challenge now becomes how the photo site gets an identifier for the friend to which the privileges can be assigned and how users can track and manage the social relationships relevant to their online interactions. The Liberty Alliance People Service is designed to facilitate this.
Another social angle comes from the fact that, in many situations, the nature of the credential by which a user authenticates to an IDP is such that the IDP can't unambiguously identify them as individuals. For instance, when I access the Net from my home PC, my ISP knows only that I am one of the family members with access to that PC. Based on that shared credential I should be able to SSO to some SP and be granted permissions appropriate to mmy family, but not to any particular member. So, I might be able to see the family's calendar but not my personal one (at least not until I re-authenticated with a credential that did allow the IDP to unambiguously identify me and make an assertion to this effect to the SP).