Clarify what happens with semantically invalid WebAC resources

[acoburn]

In the Web Access Control inheritance algorithm, there is an example describing how an implementation would enforce ACL rules. The key text appears not to be whether an ACL resource exists or not but whether there are any permissions to inherit. The example also states:

if any such authorizations are found, the process stops there and no other statements apply

This implies that some statements can be ignored. For example, it appears that an inherited Authorization lacking an acl:default should be ignored. What is the minimal RDF shape of a semantically valid, inheritable acl:Authorization? Would this qualify as an inheritable Authorization:

<#auth> acl:accessTo <./> ;
     acl:agentClass foaf:Agent;
     acl:default <./> .

(this would, effectively, revoke all access to all users).

What happens if the acl at https://example.com/pod/resource/.acl is:

<#auth> acl:accessTo <https://other1.example.com/> ;
    acl:agentClass foaf:Agent ;
    acl:default <https://other2.example.com/> .

Should that Authorization be ignored?

What about:

<#auth> acl:accessTo "Everything" ;
   acl:agentClass foaf:Agent ;
   acl:default "do what I mean" .

[kjetilk]

It seems this issue needs more attention going forward. In the current Editor's Draft, @csarven has tightened the language, saying

Access is granted when conforming Authorizations are matched, otherwise access is denied.

and there is a section detailing what an conforming Authorization is, so several of these examples would not match as they are not conforming.

However, as @RubenVerborgh notes in #57 , checking for the acl:Authorization class will essentially make the evaluation of an Authorization slower, which means that we should think through this more going forward.

[csarven]

Thanks for this issue and discussion. Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ . See #authorization-representation , #authorization-conformance , #authorization-matching . Please use https://github.com/solid/web-access-control-spec for future discussion.

---

Authorization needs to be subclassable so that eg. time-based authorization is possible (eg. solid/web-access-control-spec#37 + solid/web-access-control-spec#10 ), and server needs to be able to apply only the conforming authorizations for that. If an application includes eg. TimeLimitedAuthorization ( #57 (comment) ) but a server doesn't implement it, it must not match even if the rest of the statements are conforming. (Perhaps WAC ED can make this more clear without getting into the weeds, but that was the rationale for requiring a acl:Authorization.)

As for slow down (via SPARQL or other), certainly. That seems obvious? But how slow exactly? FWIW, the examples in WAC ED run ASK queries in context of specific GRAPH $aclResource