Lists of OpenIDs as Groups for Decentralized Services?

Don Engel donengel at
Thu Aug 31 17:03:08 UTC 2006

On Aug 30, 2006, at 11:32 PM, Johannes Ernst wrote:

> On Aug 30, 2006, at 15:55, Don Engel wrote:
>> (1) I don't think your post includes the idea of grouping multiple  
>> OpenIDs under a single member identity...
> You are right, and that is intentional. The trouble with solving  
> this is that if I own URL1, URL2 and URL3, and I'd like to create a  
> group that expresses that, this group will likely have to reside at  
> URL4. So an attacker could create the same group at URL5 and  
> include their own, hostile URL in the group. This problem can  
> really only be avoided if the group URL is somehow proven to be  
> under my control as opposed to somebody else's.

Disclaimer: I'm new to all this, so my questions are genuinely  
uninformed and not meant as strong arguments.

I'm either missing some knowledge or imagination here - I follow you  
up until the point where it's a problem.  I'm not sure why a hostile  
copy of the group at a different URL is a big problem, any more than  
a hostile URL that looks like my personal ID URL but has some  
character flipped.  I presume there's more to it than that, though?

> In LID, so far, we said -- mostly because the vCard vocabulary  
> already has an entry for that -- that
>     URL1?lid-xpath=/VCARD/URL
> returns a list of synonym URLs for URL1 (i.e. URL2 and URL3).  
> There's no trust problem here because URL1 is, by definition, under  
> my control. (And URL URL1?lid-xpath=/VCARD/URL itself can be  
> considered a group according to my proposal) (And in case you ask,  
> if Yadis is present, then it is URLX?lid-xpath=/VCARD/URL if URLX  
> is the service endpoint for this service)

I want to learn more about LID and vCard, but haven't so far...

>> Grouping OpenIDs under individuals does add complexity, though, so  
>> I'm torn.
> Yes, and there is also the information leakage problem. One of the  
> reasons we use multiple identifiers in the first place is that  
> people *cannot* correlate us -- gambling club vs. the church being  
> the standard example.

Presumably, though, a group member wouldn't share the OpenIDs they  
want to keep uncorrelated, but might have redundant OpenIDs like some  
people end up with multiple e-mail addresses?

>> (2) Your post includes the idea of sending commands to the group's  
>> URL.
>> (2a) I don't yet fully understand the benefit in decentralized  
>> maintenance of a group that has a fixed home location?
> Say you have a group of people who have sysadmin privileges at some  
> site. And you have four people (somewhere) who are allowed to  
> promote and demote people to sysadmin status.

I'd been thinking any of those four people would log into the server  
that hosts the group URL and promote/demote through a web GUI there  
which could take arbitrary form.  The fixed query format you offer  
seems different from this, perhaps letting them administer a group  
from an arbitrary site?  I'm confused.

>> Perhaps the query component of your proposal could be used to have  
>> my groups' sites make requests on my behalf, etc?
> Again there are a bunch of pitfalls here. It should be your site  
> that makes requests on your behalf, because once you have empowered  
> another site to impersonate you, it's difficult to put that cat  
> back into the bag.

Oh - I think I was unclear, or using words reserved for meanings  
other than what I intended.  I meant "on my behalf" as asking a query  
as themselves, then reporting back.  So, person A wants to know who's  
in their social network up to five degrees of separation - rather  
than person A doing the crawling to all the nodes in the tree, I'd  
think it could maybe be a recursive process, where A asks B and C up  
to five degrees (as A), B asks D and E up to four degrees (as B), C  
asks F up to four degrees (as C), and so on, with each node reporting  
to the level above it in the tree.

>> (3) Your post doesn't include the idea of roles (text) in a  
>> group.  I'm not sure if this is useful to remote services, though,  
>> and I'm thinking maybe to keep things simple, all that should be  
>> communicated is who's in the group (sets of OpenIDs) and what  
>> subgroups also are in the group.
> My thought on that one is that one can build roles from many  
> groups. Potentially we have to have the construct of having a group  
> id as a member in a group, but even that I'm not convinced is  
> necessary if we allow groups to calculate their membership (rather  
> just having a passive data store).

Again I'm probably using the wrong words.  By "role" I mean something  
like "Secretary" or "Treasurer" - in that context, I'm not sure what  
it means to build roles from many groups.

>> I'm eager to start coding a set of Drupal modules that will manage  
>> groups (defined as having members and recursive subgroups) within  
>> a single site. Ultimately I'd like to support these groups being  
>> able to use remote services.  Anyone's thoughts on all this are  
>> greatly appreciated!
> Cool!

Thanks!  I've posted my preliminary thoughts on the Drupal module at, for whoever's interested.  Much of the  
above (especially the social network crawling) is not immediately  
relevant to a recursive groups module, which in its first  
incarnations probably will only be internal to a given site.  In  
latter incarnations, though, I definitely don't want to hold group  
definitions hostage, any more than I'd want to hold login/password  
data hostage.

More information about the yadis mailing list