OpenID-style Group Proposal

Dick Hardt dick at
Tue Aug 1 05:00:26 UTC 2006

Great idea!

Another use case is that I want to prove that I am part of group X,  
without disclosing my specific identity.

I could provide the group URL to the RP which then send me to the IdP  
for that URL (Group IdP) where I then enter my OpenID URL which then  
acts as an RP to check if I am in the group. If I am in the group,  
then the Group IdP responds to the original RP.

An RP may not even know that it was a group URL that was used.

-- Dick

On 31-Jul-06, at 12:09 AM, Martin Atkins wrote:

> 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