acp:Rule equivalent to foaf:Agent

[bblfish]

ACP defines a class of Rules, to describe types of agents. But what are those?
The current ontology defines it as:

acp:Rule a rdfs:Class ;
    rdfs:label "Rule"@en ;
    rdfs:comment "A Rule defines which agent(s), group(s) and client application(s) match a Policy filter"@en ;
    rdfs:isDefinedBy acp: .

But how is this different from just specifying a sublcass of agents? This is what OWL has been designed for. See the examples in issue 135 where we define:

<#Responsible> owl:equivalentClass [
      owl:intersectionOf  (  iso:Over18  [ owl:complementOf <g0#Trolls> ] ) 
]

As long as such classes are subclasses of foaf:Agent then these can be used to specify to what agents a policy applies with

<#p1> a acp:Policy ;
    acp:anyOf <#Responsible> ;
    acp:allow acp:Read, acp:Append .

An advantage is that we can then write a rule that is publicly readable like this:

<#p1> a acp:Policy;
    acp:anyOf foaf:Agent;
    acp:allow acp:Read .

It is also immediately clear what a rule is meant to be.

[bblfish]

So what would acp:agent then be? It is defined as

acp:agent a rdf:Property ;
    rdfs:label "agent"@en ;
    rdfs:comment "The agent property identifies the agent WebID(s) to which a Rule applies."@en ;
    rdfs:domain acp:Rule ;
    rdfs:isDefinedBy acp: .

This is a bit specialized of a relation: why should one only identify an agent by a WebID? Why not indirectly by an OpenID, or by proof of possession of a credential?

But nevertheless, if a acp:Rule is a subset of agents, then acp:agent can only really a relation like membership of the agent in the set. So we can deduce that

acp:agent owl:subPropertyOf [ owl:inverseOf rdf:type ] .

Why a sub property? Because we don't really want to claim the generality of rdf:type . For example we want to keep the domain of acp:agent to be a subset of foaf:Agent .

[emmettownsend]

The current implementation allows an acp:Rule to specify agents, groups and applications.
However the intent is to extend the implementation beyond that so that a Rule could specify conditions like:

• A time frame (rule would only be satisfied if the current time falls within the specified time)
• A credential (rule would only be satisfied if the agent possessed the type of credential specified)
• relation (rule would only be satisfied is the protected resource contained a triple with the specified relation)
  etc

Basically rules are the extension point that allow ACP to be flexible and implement more conditions over time.

[bblfish]

However the intent is to extend the implementation beyond that so that a Rule could specify conditions like:

Thanks that is a very important anchor point to understanding how you are seeing this develop, and is clearly very important to look at the different ways to think about this. We would need to look through the consequences of adding rules both for subjects and for resources in that location.

An interesting insight that comes out of the RelBAC model is that we really only have two types of things: Agents, Resources and Permissions. The last can just be modeled as subsets of the pairsAgents × Resources.

We can then use Description Logic to specify subsets of either via attributes. So let me illustrate with your examples above:

A Credential

A Credential is a statement about an agent that she has certain attributes, signed by a third party. There is a process that a Guard has to go through to decide whether it believes the issuer of the credential is entitled to make the claim. But once it has gone through the process the Guard would have a (verified) attribute of the subject seeking authentication. The guard would then need to check if agents with such attributes are permitted to access the resource in question. This is where the access control statements come into play.

Let us take the Age Based verifiable Credential use case, which is also illustrated in the Verifiable Claims Data Model. Let us say that a store is really only interested that those coming to it can prove they are over 21. Then it can create a subset of People as described in the OWL-2 spec like this:

<#PersonOver21> owl:equivalentClass [  a owl:Restriction;
      owl:onProperty :hasAge ;
      owl:someValuesFrom   
          [ rdf:type   rdfs:Datatype ;
            owl:onDatatype       xsd:integer ;
            owl:withRestrictions (  [ xsd:minExclusive     21 ]   [ xsd:maxInclusive    150 ] )
          ]
       ] .     

Obviously this will be so widely used that it could be standardized and defined in a well known ontology.
Now the interesting thing about this is that the restriction on the agents allowed is orthogonal to the types of claims that can be presented to prove the claim. Claims that would be acceptable would be:

• over 18 credential as they do in the uk,
• passports,
• birth certificates,
• drivers licenses, ...

Any of those could be a claim to prove the needed attribute. (Clearly some of them provide much too much information).

So here we can restrict the agents group allowed access to a resource via an attribute they need to satisfy.

Resource Metadata

To restrict resources so ones that contain certain info, or have certain metadata the same OWL tools can be used.
So media may be annotated with targetAudience attributes that may imply age restrictions.

<#AdultContent> owl:equivalentClass [  a owl:Restriction;
       owl:onProperty :targetAudience;
       owl:someValuesFrom :Adult 
] .

Meta-Data + Agent restriction

Both of the above can be brought together via the permission

<#adultPermission> 
          :accessToClass :AdultContent;
          :agentClass :PersonOver21 ;
          :mode :Read .

Time

To allow permissions to be active for a given time periods one could extend WAC with
an :activeDuring relation that would perhaps use the Time Ontology.
But one could also time slice the person or the resource, so so as to speak of objects during a time period.
Resource slices may be more appropriate for access control :-)