Lists of OpenIDs as Groups for Decentralized Services?

Don Engel donengel at techhouse.org
Wed Aug 30 22:55:45 UTC 2006


I think your (Johannes') post at
	http://netmesh.info/jernst/Technical/lid-and-groups-thoughts.html
addresses the core of what I have in mind, so I'd rather not do  
something incompatible.  The differences are, I think:

(1) I don't think your post includes the idea of grouping multiple  
OpenIDs under a single member identity.  I think this is important  
because a service on another site might need to recognize individuals  
within groups.  For example, remotely maintained mailing list systems  
or voting systems should treat returning users (with perhaps multiple  
OpenIDs) as the same person who visited previously.  Also, by  
grouping OpenIDs under some group-specific unique key-per-individual,  
someone on a remote site can specify that anyone-but-Joe can access  
some aspect of their profile, because they don't trust Joe but trust  
all other members of the group.  Joe should be able to add other  
OpenIDs to the group, but only if they are also under the umbrella of  
his membership.  Otherwise, he could get around the block against  
him.  Grouping OpenIDs under individuals does add complexity, though,  
so I'm torn.

(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?
(2b) The idea of only certain individuals being able to see the  
membership roster is very exciting to me, because it allows for  
friend-of-friend-of-friend searches that could help realize my  
biggest pipe dream for the internet - decentralized trust network  
searching.  That is, I'd like to know if a blogger or website or  
group or cooking recipe (any kind of URL) should be trusted by me,  
based on what my network thinks, but I don't want to require my  
network to make who they trust be public.  I'm new to OpenID, but  
I've so far seen it used only when a user is trying to access a  
single site manually.  What if I wanted to recursively spider a  
group?  Is there a way for me to have permissions managed with non- 
zero degrees of separation, without having to log into all the places  
that I might spider, but still having those places recognize me as  
myself?  Perhaps the query component of your proposal could be used  
to have my groups' sites make requests on my behalf, etc?

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

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!

Many Thanks,
Don


On Aug 30, 2006, at 12:41 AM, Johannes Ernst wrote:

> I blogged about something rather similar:
>     http://netmesh.info/jernst/Technical/lid-and-groups-thoughts.html
>
> Would that address some of what you have in mind?
>
>
> On Aug 29, 2006, at 11:00, Don Engel wrote:
>
>>
>> Hi all,
>>
>> I'd like to follow standards (or invent new ones if necessary) for  
>> the use of web resources by groups of people.
>>
>> Call the proposed system OpenGID.  The content at an OpenGID url  
>> would include a set of people and subgroups, where:
>>
>> 	A person is a prioritized list (possibly empty) of OpenIDs,  
>> possibly a name, and possibly a role with respect to the group
>>
>> 	A subgroup is another OpenGID, possibly with a role of the  
>> subgroup with respect to the group (membership is recursive, roles  
>> are not)
>>
>>
>> Take the example of a site that would offer a system for  
>> preferential voting.  Any visitor to the site could create a  
>> ballot, at which time they'd also list the OpenGIDs and OpenIDs of  
>> those allowed to access it.  When another user tries to access the  
>> ballot at the voting site, they'd have to log in, and the voting  
>> site would then spider to see if the person was in the set of  
>> allowed OpenGIDs and OpenIDs.
>>
>> This kind of permissions management could also be used to see  
>> aspects of a profile, control who can join a mailing list (log in  
>> with OpenID, then specify and verify e-mail), etc.
>>
>>
>> I'm currently thinking about rewriting a lot of group organization  
>> tools I've done for specific groups into an set of open source  
>> Drupal modules (unless someone here has a better idea - I'm new to  
>> Drupal), but if other people use the module elsewhere (which of  
>> course I hope they will), I'd like them to be able to recognize  
>> the existence of groups on other sites with the same module.
>>
>> Many Thanks,
>> Don
>
> Johannes Ernst
> NetMesh Inc.
>
> <lid.gif>
>  http://netmesh.info/jernst
>
>
>
>



More information about the yadis mailing list