Limitations: re-using policies

(Is this requirement allready listed?) In @ericprud's PR 178 ACP Compared to Web Access Control a limitation of WAC (as deployed) is explained to be that Access Control Rules cannot be generalized easily over a number of resources.

Indeed if we want to restrict the application of a rule by extending WAC slightly using regexes to restrict acl:accessToClass as I did in rww-play one could get something like this

_:bart-copies-my-assignments
  acl:agent <http://solid.example/users/bart#id> ;
  acl:mode acl:Read ;
  acl:accessToClass [ acl:regex ".*/courses/8.04/assignment-.*" ] .

The problem is that this is fragile and requires one to decide a-priori which resource belongs to a class.

ACP can be understood to allow a partial WAC rule to be effective, by having a policy state a group of agents that have an access in a mode, but allow the resources to add themselves to the policy: In ACP the resources for which a rule applies, are those that link to it.

But that is also the case in WAC: since the link from the resource to the ACL is the one that client and server Guards MUST follow.

WAC+ answer

We can therefore also express this pattern by extending the ACL ontology used by WAC, as I discussed in Issue 128 in November 2020. Extending WAC while keeping its semantics, means we are in the space of a WAC+ answer.

All we need to do, is to extend WAC with a new relation :authorizes that relates an ACR to a rule. We can then see that wac:accessTo should be defined as:

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

With this we can now have an ACR that can refer to a rule by containing the following statement

<> :authorizes </myAccessPolicies#bart-copies-my-homework>

where we have in </myAccessPolicies> the following

<#bart-copies-my-homework> a acl:Authorization;
   acl:agent <http://solid.example/users/bart#id> ;
   acl:mode acl:Read .

To adapt the example slightly, let us look at the following layout for @timbl's WebID Profile expressed in WAC+. Consider the diagram below, where card.acl contains exactly the following graph:

<> :authorizes [ a acl:Authorization;
          acl:agentClass acl:Agent ;
          acl:mode acl:Read  ];
    :authorizes <personal#Rule1> .

First we have the acl:accessControl link header from <card> to <card.acl> as usual. From there we now have an :authorizes relation from <card.acl> to the blank node identified acl:Authorization. These two relation together imply the acl:accessTo relation (used in current wac deployments) and hence it is shown with dotted lines. The acl:accessTo relation is not in the ACR as we can see above, but it can be logically deduced by any agent coming from the original resource.

WAC Mapping

The nice thing is that this also allows us to have Authorizations described outside of the document, possibly in different containers. Indeed in the above diagram we show a second :authorizes relation pointing from <card.acl> to <personal#Rule1>. Again the :accessControl Link header followed by the :authorizes relation implies

<personal#Rule1> acl:accessTo <card> .

Since this is implied, it does not need to be written out.

Conclusion

By Adding one simple relation :authorizes to WAC we get the major new feature described in the ACP Compared to Web Access Control story. Furthermore this does not change much to the way current implementations are working since following the process as they are the :accessTo verification can be argued to be redundant, as it is implied once the :authorizes relation is added.

Todo

Is the above correct? If so:

We should make this answer clear in the "ACP Compared to WAC" PR linked to above
What are the advantages and disadvantages of doing this?
What is the next use case or "limitation" we can look at? Perhaps something using one of the "apply" relations? Perhaps one of those brings out another interesting feature of ACP.

Is the requirement already listed in the UCR? If not it should be.

solid / authorization-panel