[OpenID] openid and acl's

[Andrew Tomlinson]

Not sure why your scheme leads to multiple passwords. Each group
authorisation server could proxy OpenID authentication through them out to
your personal  OpenID to check that you are you before giving access to the
group.

On this subject this draft proposal was mentioned a bit back on the list:

http://openid.net/wiki/index.php/Group_Membership_Protocol

May be worth a look to prevent duplication of effort. 

For a simpler method of group membership you could use a combination of url
prefix and delegation:

E.g. http://openid.sun.com/engineer/bblfish -> http://openid.sun.com/bblfish

The prefix match on the first url proves you are an engineer. The delegation
of authentication means you only have to prove control of the second url to
authenticate (i.e. only 1 password).

This grouping scheme requires you as a user to know which group name gives
you access to which site. For the simple yes/no acl case this should need
very little work to implement. Can't think of any major drawbacks - please
feel free to pick holes :)

Another alternative is to have a group url (e.g.
http://openidgroup.sun.com/engineer) which the RP requires you to prove
control over. This is just another OpenID whose OP could authenticate you in
a number of ways including starting up another OpenID authentication for
your personal OpenID.

It would be nice to standardise (or best practice) distributed group
membership as it is a common requirement. I guess that is why it is on
http://openid.net/wiki/index.php/Potential_Future_Projects ;)

Andrew

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Story Henry
Sent: 07 August 2007 10:47
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] openid and acl's


On 4 Aug 2007, at 19:30, Peter Williams wrote:

>
>
> 		In "A Foaf File for Sun" [1] I argue that the Authorization
service
> 		can be thought of as a group identifier. The Authorization  
> service is
> 		a group membership verifier.
> 		
> 		This can be used to give people access to different parts of
the web
> 		using RDF. An example I give is how this could be used to
make  
> access
> 		to the W3C just a question sending someone Sun's foaf file.
> 		
> 		
> 		Henry
> 		
> 		[1] http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun  
> <http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun>

Just to be critical of my own proposal first.

Whilst using the Authorization service as a group identifier makes  
sense, it can be criticized for not scaling in the right way. If  
every group tried to have an authorization server then one would be  
back to square one, namely having to remember one password per group.  
Well at least one would only need to remember on openid, this openid  
pointing to each of the authorisation servers.

Perhaps the idea of having a number of authorization servers can be  
made to make sense. If the OpenId had a foaf representation then it  
could express which authorisation servers  we linked to which groups.  
My foaf file could be written like this:

@prefix oid: <http://openid.org/tmp/ont#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<me> a foaf:Person;
      foaf:firstName "Henry";
      foaf:family_name "Story";
      foaf:mbox <mailto:henry.story at bblfish.net>;
      foaf:openid [ = <http://openid.sun.com/bblfish>;
                    oid:service [ = <https://openid.sun.com/openid/ 
service>;
                                   is oid:memberIdService of <http:// 
sun.com/data#sunw> ],
                                [ = <https://openid.sun.com/openid/ 
engineer/Service;
                                   is oid:memberIdService of <http:// 
sun.com/data#engineer> ] .


This is saying in short that my openid has two services, one of them  
shows that I am a member  of Sun Microsystems, the other that I am  
member of the sun engineering team. One could imagine that both of  
those use the same authentication password, so as not to be so  
troublesome.

As the above is a little complex, (I am using the inverse relation of  
oid:memberIdService for example), here is the same thing  illustrated  
graphically: