OpenID-style Group Proposal

Martin Atkins mart at
Mon Jul 31 07:09:51 UTC 2006

Lukas Rosenstock wrote:
> Hm, good idea!
>> The GroupID concept would be that a site supporting OpenID could extend
>> it by publishing a URL as a GroupID url.  So, they could publish a URL
>> (e.g. http;// ) which they say "we will
>> verify your assertion that your OpenID is a member of the group
>> identified at that URL".
> I'd suggest using that the GroupID in fact is an RDF file with FOAF 
> elements because there a data format for describing a group of people 
> already exists.

I think Rob's intention was to avoid enumerating all of the group 
members. Whether that was what Rob meant or not, there are three main 
situations where this is useful:

* Where the set as a whole is a secret, but you are happy to give a YES 
or a NO to specific identities.
* Where the set is too large to enumerate, such as with the set of all 
LiveJournal users.
* Where set membership is computed on request rather than there actually 
being a physical list stored behind the scenes.

The latter two are related and are, I think, the most important:

* Currently several sites identify LiveJournal users by doing 
pattern-matching on the URL. While in most cases this would be the only 
efficient approach, it'd be nice to have a URL where you can say "does 
this URL represent a LiveJournal user?", and perhaps in future have it 
take into account the "custom domain" feature that LJ offers, or other 
situations where the URL doesn't match http://(\w)

* Imagine the set of all OpenID identities. Every single one of them. 
This wouldn't actually be *stored* anywhere, but instead the software 
that answers for it could just go and fetch the URL and see if it has an 
openid.server link or a Yadis link with an OpenID entry and make up the 
answer based on what it finds.

If you take it down to the bare guts of the idea, it's really just a 
question about whether a particular entity is part of some set.

The protocol could be as simple as this:
* GET[...]/
* Server says "YES" or "NO" in the body of the response.

I think it's important to keep this one simple, since if it's going to 
be used for trust applications a caller may want to check a few dozen 
different trust services in one go. From a pie-in-the-sky point of view 
it'd be nice to use Yadis discovery for this, but my view is that the 
overhead would be too large for something so simple.

Someone can define some custom elements for FOAF so that foaf:Group 
entities can say "My set-discovery URL is ...", or whatever.

The only thing I really see wanting here is the ability to return some 
kind of score for "how much" you are in the set, but that's a can of 
worms that I'm happy to leave closed for someone else to open with a 
different proposal. :)

More information about the yadis mailing list