Does the acl:Authorization need to be materialized in an ACL resource

[acoburn]

Via simple RDFS entailment, one can infer the presence of acl:Authorization in a valid ACL document:

acl:mode rdfs:domain acl:Authorization .
acl:agent rdfs:domain acl:Authorization .
acl:accessTo rdfs:domain acl:Authorization .

And from the implementation of ACL-Check it appears that the materialized presence of <...> a acl:Authorization is not necessary. It would be helpful if the WebAC specification clarified whether an implementation really needs to materialize that triple.

[RubenVerborgh]

I would say it does not; and we probably want to spec a minimal shape (cfr. #56).

[pmcb55]

I think I must be missing something here, but basically I don't like relying on entailment (even simple RDFS entailment), and in fact I also have concerns about even using rdfs:range and rdfs:domain (I'm sure they might be fine here in the ACL vocab, but for example, Schema.org doesn't use them (instead using the much looser schema:rangeIncludes and schema:domainIncludes), and professor Robert Stevens from Manchester University recommended against overusing range and domain in an OWL course I attended years ago!)).
So I'd just ask why would the spec not mandate materializing the <...> a acl:Authorization triple? Are we just trying to save a triple? Personally I prefer being as explicit (and readable) as possible.

[RubenVerborgh]

I don't like relying on entailment

We should not.
It's just that clients can be designed for this specific case such that they don't need the type triple to be present.

[pmcb55]

Sorry @RubenVerborgh, but I don't follow what you mean. Are you saying it might be good if we make it just a little bit easier for clients if they don't need to provide this simple type triple (or parse it from server responses)? I really don't like that idea (since behaviour is then implicit, or is relying on inference), so I'm guessing you mean something else...

[RubenVerborgh]

Consumers of an ACL should not need the type triple to function properly. They don’t even need to infer it. They should just look for the relevant predicates.

[pmcb55]

Ah Ok, sure, no argument there at all. But I think it's Ok (in general, not just in relation to ACLs) for the spec to expect consumers to ignore triples they're not interested in. So I'm still thinking making the <...> a acl:Authorization triple a MUST is a good idea.

[acoburn]

The reason I raised this issue is that Trellis, for example, does not require the acl:Authorization type in order to process an Authorization rule. Fedora, in its WebACL implementation, does require that triple to be present. Given that diversity, I thought it would be helpful to clarify expectations.

[pmcb55]

Yep, I totally agree - which is why I suggest that the type triple being a MUST in the spec is the only way to get simple and clear interoperability. Clients are free to ignore that triple (as they are free to ignore anything of course!).

[acoburn]

I actually come to the opposite conclusion, that the triple MAY be materialized. But either way, the important part is to be explicit about expectations.

The LDP spec takes a similar approach to LDP type triples in LDP-RSs: e.g. that a container MAY materialize the rdf:type ldp:Container triple. The question isn't about whether the triple is present in the graph or not (it is via rdfs entailment), it is a question of whether a server must rely on a materialized triple before enforcing a particular Authorization rule. Similarly, for a client is it necessary to explicitly write that triple in a serialization in order to generate a valid ACL rule.

[RubenVerborgh]

I also don’t follow here. Why a MUST for something that is not needed to algorithmically decide access control? It is not the “only way” clearly, since Trellis does without it. Fedora is just being overly strict.

The ignoring part is important for when the triple is present, which is allowed, but not needed.

We should make the shapes as minimal as possible (but not more minimal). For instance, also no need to mandate an owl:Thing or rdfs:Resource triple. Following the predicates is enough.

[pmcb55]

Ok, so yeah, I'd agree that enforcing a Shape might be another way of 'simply and clearly' indicating that a request (or response) is intended to be an ACL (but it's still not as simple, or as clear as providing an explicit <...> a acl:Authorization triple!).

That was my major concern - i.e. without an explicit type or somehow providing an explicit Shape, then the logic to determine a request/response is an ACL needs to either rely on inference (i.e. not simple or clear), or else it has to 'follow the predicates' by doing something like:

if RDF contains(<acl:accessTo>) or contains(<acl:agentClass>) or contains(<acl:default>)
  then processAsACL()

...which is less simple and less clear than...

if RDF type(<acl:Authorization>)
  then processAsACL()

It's just been a convention I've followed for a while now to use explicit types whenever they seem to make sense, and it always seems to keep things simple and clear (i.e. and I can always immediately see in RDF payloads 'what' things are without needing to mentally follow predicates). But I agree, maybe I'm just being 'overly strict', like Fedora!

[acoburn]

@pmcb55 an implementation is actually considerably simpler, even without checking for the type: in fact, a fully functional implementation doesn't require any of those clauses mentioned above (I can show you how this works off-list, if you are interested). In my experience, I have found that, on the server side, it is entirely unnecessary to do any rdf:type checking at all.

[RubenVerborgh]

Security remark: I think we should specify that clients MUST NOT use inferencing to determine access rights from an ACL document. Otherwise, some might define subproperties of acl:accessTo etc., that only are interpreted by those that use inferencing, leading to different interpretations.

Also, going on a bit of a tangent here, but I will describe a useful strategy for dealing with any RDF documents we encounter, such as these.

Basically, I suggest that the first strategy is always querying. So if you want to find who has access, you execute a SPARQL query. Then it is up to the query engine to find the most optimal way for a given piece of information to be located in a document. Because, depending on the structure of the document, one way might be faster than another (whereas, if you hardcode, you typically only hardcode one way). And in this case, if we were to write such a query, I don't see a reason for it to contain a type clause, as that is redundant information.

Now of course, one might say that it is overkill to always to SPARQL queries. My answer there is that it is overkill to always re-write a query engine—because that it actually what we're doing if we write code to look for specific triples in a document. I see such engines being written again and again.

Only if it turns out to be detrimental to performance in specific cases (and ACL might or might not be one of them, given the typically low number of triples), then it would be okay to write custom code that achieves the same thing faster. But starting out with custom code is basically premature optimization.