Lists of OpenIDs as Groups for Decentralized Services?
Don Engel
donengel at techhouse.org
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
http://drupal.org/node/81716, 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