Lists of OpenIDs as Groups for Decentralized Services?

[Johannes Ernst]

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.

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)

> 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.

> (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.

> 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.

> (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).

> 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!


Johannes.


Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060830/30ed0068/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst