Re: ACL Ontology and Discussion

On 20 Apr 2010, at 15:52, Nathan wrote:

> Hi All,
> 
> I'd like to propose a few new additions to the ACL Ontology, I won't be
> specific on names but will describe each one and the associated need.
> 
> The addition of "groups" - personally I see no need to define a set
> ontology for what constitutes a group when dealing with ACL, however it
> would be fantastic to be able to point to the URI of a "Group of WebIDs"
> and the relation, or predicate, that should be used. For example:
> 
> [] a acl:Authorization ;
>  acl:accessTo </pictures-of-me> ;
>  acl:mode acl:Read ;
>  acl:agentGroupSource <http://webr3.org/nathan#me> ;
>  acl:agentGroupLink foaf:knows .

I think you can get what you want by using owl reasoning

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix acl: <http://www.w3.org/ns/auth/acl#> .

[] a acl:Authorization ;
 acl:accessTo </pictures-of-me> ;
 acl:mode acl:Read ;
 acl:agentClass :myfriends .

:myfriends owl:equivalentClass [ 
      a owl:Restriction;
      owl:onProperty [ owl:inverseOf foaf:knows ];
      owl:hasValue <http://webr3.org/nathan#me> 
] .

> 
> in this scenario the agentGroupSource is a foaf:Person (me) and the
> relation to be used as members who have acl:Read access is everybody i
> foaf:knows.
> 
> [] a acl:Authorization ;
>  acl:accessTo </working-group> ;
>  acl:mode acl:Read , acl:Write ;
>  acl:agentGroupSource </groups#working-group-members> ;

you probably want a 

   acl:agentGroupSource </groups/#userGroup1> ;

>  acl:agentGroupLink sioc:has_member .


[] a acl:Authorization ;
 acl:accessTo </working-group> ;
 acl:mode acl:Read , acl:Write ;
 acl:agentClass :wkgrp.

:wkgrp owl:equivalentClass [
    a owl:restriction;
    owl:onProperty sioc:member_of;
    owl:hasValue </groups/#userGroup1> .   

> 
> in this scenario the agentGroupSource is a sioc:Usergroup and the
> relation to be used as members who can Read,Write is sioc:has_member.
> 
> I'm very aware that there are inverse relations here (sioc:member_of),
> but strongly feel that we can't be trusting anything in somebodies foaf
> profile document for ACL, so thus have negated entirely :)

That is not a question of the direction of the realtion, but a question 
of which information you take as reliable. If you don't trust the information
from the user's profile, don't merge it into the graph you use to decide 
who get access to some resource.

> 
> I've also given the above pretty poor names of agentGroup* in the
> examples, purposefully to get some input on better names!



> Next up is acl:agentClass, I'm actually going to suggest deprecation or
> reserving it for future use, because afaict everything which is
> requesting access to a resource must be an agent of some kind,

Not sure why you think so. The point of agentClass is to link to the set
of agents that have access. Seems pretty reasonable to me.

> and if we were to distinguish between Classes of Agent then the only place
> we can find out what Class an Agent has, is in their foaf profile - which they
> control.

The agent class is not a way of defining the type of the agent, it is a way to
define the type of people who will be given access. 

agentClass   a rdf:Property;
        rdfs:label "agent";
        rdfs:comment "A class of persons or social entities to being given the right";
        rdfs:domain     Authorization;
        rdfs:range      rdfs:Class.  # Must be subclass of foaf:Agent. 



> So for example you can say that access can only be granted to
> ex:Admin and I can say I am a foaf:Person, ex:Admin and gain access.

That is why one would not use information from your foaf file to decide
what class you are in. Presumably the class could be one defined either directly
by a URL, which could list all its members, and presumably would be access 
controlled by someone reliable, or as above indirectly as your friends.

> 
> In addition access control is a pretty critical issue, and adding in
> things which bring up many design issues about inference etc when they
> aren't strictly needed (as in groups and lists of WebIds suit the
> purpose and always have - imo) may not be the best course of action.
> (You've no idea how humbly I say that, but figure it best to bring it up).
> 
> This does however bring up the issue of how to say "read access for
> anybody with a webid" - is there any wild card syntax that could be used
> for acl:agent or suchlike?

If you want that you would do as the note in the acl ontology points out, you
would use the class of foaf:Agent 

> 
> 
> And finally, some form of "doesn't have access" - in many cases and on
> many systems I've implemented there has been very strong, non-optional,
> requirements to effectively "ban" or restrict access to certain people.

You can use set operators defined here 

http://www.w3.org/TR/2004/REC-owl-guide-20040210/#SetOperators

to define sets of people who are not allowed access.

> Often access is granted to everybody who is logged in but not to
> person-x and person-y. It seems that some for of acl:Unauthorisation is
> needed - but I'll leave it there for those more intelligent than me to
> pick up :)
> 
> /end-of-list
> 
> Out of all the above, the first issue group access is the one I'd most
> like to get out of the way asap, or even ideas on a temporary work
> around as keen to be progressing with the acl implementation.
> 
> Best Regards,
> 
> Nathan
>

Received on Tuesday, 20 April 2010 18:50:23 UTC