Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


print this article (opens in new window) view printer-friendly version (opens in new window)

OpenID group service proposal lacks key feature: OpenID

The methods offered are an Enumeration Query (give me the collection of members) and Membership Query (is URI a member?). There are quite a few well-defined methods you might use for collections (see, for example, the Java Collection interface), but these are two obvious ones. Iteration might have been nice as well as enumeration, for example.



Its an interesting proposal but there are a few loose ends I'd like to pick away at.



"Membership" can be defined by a pair of related assertions:





However, there is also another assertion we might typically make here:





Now, in some cases these relations are mutually asserted, in many others they can be unidirectional. For example, if I have a friends list in Facebook, then this is a unidirectional group. The assertion we can make then might be one of:





The former makes sense to assert under OpenID, as "Scott" can demonstrate ownership of the "Scott's Friends" group. So I could quite possibly use a protocol around this to share my group (and assert it really is mine) or even to add members to it. The latter doesn't make quite as much sense in this case, but more on this later.



Elgg, and some other social networks, also support the reverse relationship of "Friends Of". Which is an interesting one, as this is actually the collection of relations from multiple groups; for example, a "Friends of Scott" query is actually:






So this is not a request to a group for its members, but a rather different kind of query. If I have a group offered by my OpenID service that is a "Friends Of" group, then I can't really offer the same kind of assertion as a "Friends" group. Any system consuming this service could either take the assertion at face value, or iterate over the collection and go off and query the entries as to whether this inverse relation is true. I presume this is what the specification is getting at when it talks about computing queries using recursive calls, but it would be useful I think to explain this in terms of reverse membership as well as nesting. In fact, I see this as being the major case; look at these examples:






In each of these cases the membership assertion is made by another entity and not by the subject; the subject is collating a set of membership assertions that are made by other parties and exposing it at one endpoint. While the querying agent is asking for an enumeration of group memberships, what it is really asking for is an enumeration of membership assertions.



So how can this work using OpenID? Bear in mind that OpenID asserts a very simple statement: this is a URI I own. Now, this can work very well for the "my friends" case; but in each of the inverse relationship cases it breaks down. The specification as it stands is asking me to trust the group service to "do the right thing" and return only valid memberships. Well, thats fine, but what would it take to make a service that handled inverse group relations correctly?



Perhaps the service could offer me a MemberOf assertion rather than just Member. For example, an enumeration query of "http://www.cetis.ac.uk/members/scott/friends" could return:




<Members>
<Member uri="URL1"/>
<Member uri="URL2"/>
<MemberOf uri="URL3"/>
<MemberOf uri="URL4"/>
</Members>


In this case Member is an assertion from the subject, verified by OpenID. In the case of MemberOf, the agent is at liberty to inspect URL3 and URL4 for services to check that the subject is a member using a Membership Query.



OK, so far so good. However, looking a little deeper we can see that the proposed specification doesn't actually involve a subject at all: the group itself is the subject! For example,




  1. I login with OpenID into a social network service

  2. I choose the "import friends" option

  3. I put in the URL of my Friends OpenID group.

  4. The social network's agent then goes and issues an Enumeration Query and gets the friends list.



Wait, whose friends list is this? There is no relationship between the "me" and the group, so I could just stick someone else's friends list in instead if I felt like it and the agent would be none the wiser.



Now, maybe this isn't a real problem, but where is the "OpenID" part here? How hard would it be to instead:




  1. I login with OpenID into a social network service

  2. I choose the "import friends" option

  3. The social network's agent redirects me to my OpenID server with an Enumeration Query

  4. I log in to my OpenID server and choose the group I want to share with the service

  5. The OpenID server transmits the group enumeration response to the social network

  6. I'm redirected back to the site



In this case a Group is rather like a special version of the Simple Registration Extension in OpenID.



I can see the specification as it stands being useful in cases where the site itself is the subject, as in "Facebook, give me Scott's Friends list", or "MyOpenID.com, give me your whitelist". However, this (1) isn't a very user-centric approach to group services; the groups we are really interested in are the groups created by users of services, and in particular the assertions about membership made by group owners and group members, rather than solely that of a "group" entity; and (2) some of these cases can be already met using FOAF: for example, Elgg and Explode offer FOAF for user profiles that contain their friends lists.



See also commentary by Stephen and Andy. It may also be interesting to compare this to the IMS Enterprise Group Service spec, and my own RESTish take on it, plus of course FOAF and its grouping mechanism.



Related items: