acp/wac diff: the ACR Document

[bblfish]

In the spirit of finding the diffs between ACP and WAC (Web Access Control), and the issue on formalization I thought I'd start with the one that struck me first.

Summary

WAC Authorization statements link to the resource. ACP is linked to from the protected resource.
Here I show the change by looking at how a similar idea would be implemented in WAC.

Details

The WAC ontology is very simple. It consists of an wac:Authorization class each of which states

• what class of agents
• can get access to which class of resources
• in what mode (read, write, append, control)

ACLs have thus been written out as documents listing all three properties
as follows:

@prefix wac: <http://www.w3.org/ns/auth/acl> .
[]    a wac:Authorization; 
     wac:accessTo <card>, <card.ttl> ;
     wac:agentClass </personal/friends#grp> ;
     wac:mode acl:Read .

Note that anyone can write up such statements. But the server Guard is only bound by those statements located in documents referenced by the acl rel HTTP header of the protected resource. This relations is named wac:accessControl in the current wac ontology (after renaming "acl"prefix with "wac").

As a result there is duplication in the usage of the current wac ontology. The wac:accessTo and the wac:accessControl (aka rel="acl" http link relation) seem to be stating something close to the same thing in an inverse way:

• wac:accessControl relates a resource to a resource containing wac:Authorizations.
• wac:accessTo relates an Authorization to a resource for which it is an authorization.

We can formalise this as follows. Create a type :ACR (for access control resource) and relation :authorizes

:authorizes a rdf:Property;
   rdfs:domain :ACR;
   rdfs:range wac:Authorization;
   rdfs:comment "relates an ACR to Authorizations found in that document" . 

Then we can have the following: wac:accessTo is the inverse of the relation that consists of the path wac:accessControl followed by :authorizes defined above. I think in OWL2 this can be expressed as

wac:accessTo owl:inverseOf [ 
        owl:propertyChainAxiom ( wac:accessControl :authorizes )
      ] .

ACP can be thought of as following the second pattern: an acp:AccessControl element does not link to the resource it is protecting, but is linked to from the protected resource.

Advantages

1. This removes duplication of relations, and so removes a source of false statements (wac documents that point to resources that don't point back)
2. The resource linking to the ACR is authoritative over what WAC Document needs to be considered and the "acl" link header must be present. It makes sense therefore to only keep that relation. The other relation can be inferred.
3. It builds in the requirement from ACP that every Solid resource must have an associated ACR resource.
4. It makes it easy to have a shared authorization as ACP does, since there is no need to update the document where the Authorization is located when linking to it. For example a newly created resource can re-use an Authorization in another document just by having their Acess Control Resource (ACR) link to them, as shown here:

<> :authorizes 
        </personal#foaf_read>,
        </personal#commentsOnly> .

Where /personal can then contain Authorizations such as:

<#foaf_read> a wac:Authorization;
    wac:agentClass </personal/friends#grp> ;
    wac:mode acl:Read .

[namedgraph]

There's no wac:accessControl

[bblfish]

$ curl -s http://www.w3.org/ns/auth/acl | grep accessControl --after-context=8
    acl:accessControl     a rdf:Property;
         :comment """The Access Control file for this information resource.
        This may of course be a virtual resource implemented by the access control system.
        Note also HTTP's header  Link:  foo.meta ;rel=meta can be used for this.""";
         :domain gen:InformationResource;
         :label "access control";
         :range gen:InformationResource;
         :subPropertyOf :seeAlso .

[TallTed]

@bblfish - It's important to include prefix definitions when using prefixed names in TTL, SPARQL, and the like, especially when the cited ontology does not use the prefix you've chosen (wac:) (and it's also unknown by prefix.cc), here using instead acl: (which prefix.cc does know).

$ curl -s http://www.w3.org/ns/auth/acl | grep -i "prefix" | grep "<http://www.w3.org/ns/auth/acl#>"
    @prefix acl: <http://www.w3.org/ns/auth/acl#> .

Without that @prefix definition, @namedgraph is correct -- there is no wac:accessControl, though there is an acl:accessControl (as your curl output demonstrates). Heck, even your own initial posting above started out talking about acl:Authorization and then the TTL says a wac:Authorization!

[namedgraph]

@TallTed good point, but I was referring to acl:accessControl and it indeed exists - my bad

[bblfish]

I made a few clarifying changes @TallTed . There is indeed a legacy issue with naming these ACL's for Access Control Lists, as 1) there are no lists and 2) ACL technology is much more limiting that what the ontology allows: namely potentially Role Based Access Control (using credentials and OWL descriptions as the range of wac:agentClass, and perhaps even capability based Auth). But that last point should be discussed in a separate issue when we are further along.

[bblfish]

Am I right to think @emmettownsend that the wac:authorizes I defined above is the same as acp:access, ie. the following holds:

wac:authorizes owl:equivalentProperty acp:access .

If that is the case the ontology could be improved by specifying the domain like this:

acp:access a rdf:Property ;
    rdfs:label "access"@en ;
    rdfs:comment """
     The access property identifies the access policies that apply to the resource that links 
     to it via the acp:accessControl link header."""@en ;
    rdfs:domain acp:AccessControlResource:
    rdfs:range acp:Policy ;
    rdfs:isDefinedBy acp: .

And come to it, it would perhaps be useful to make clear than an AccessControlResource is one that is linked to from a resource via the acp:accessControl Link relation, ie one that is active.

acp:AccessControlResource a rdfs:Class ;
    rdfs:label "Access Control Resource"@en ;
    rdfs:comment """
         An RDF resource that includes acp:access statements. 
        An acp:AccessControlResource is linked to via acp:accessControl  HTTP Link header."""@en ;
    rdfs:isDefinedBy acp: .

[bblfish]

@emmettownsend I just answered my question above in a comment on acp:apply* relations.
wac:authorizes is not the same as acp:access.

Instead

acp:access owl:inverseOf wac:accessTo .