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.

[timbl]

((Yes, @RubenVerborgh you have stated your preference for using queries rather than graph navigation many times. But which one you use is just a coding choice where people will be doing both. It should not have a bearing on this))

The code I have written does not IIRC check for the type triple. Most code RDF my systems produce tend to not use explicit typing. It makes the turtle files easier to read, and shorter. Often data is converted from XML or JSON where there are arcs but no types. So according to that pattern, an ACL would not need the type triple.
Let's make it optional.

The only logical reason I can think of for adding it as a MUST is as follows.
We change the ontology tomorrow removing those domain and range statements. so that that any shape without the type triple is not an Authorization. We then next year can add a new class, TimeLimitedAuthorization. That has the same shape but also has a start and end times on it. The existing code must test that the thing is an Authorization, or it will mistakenly also match a TimeLimitedAuthorization which it in fact doesn't know about. That is a reason for making the triple explicit. (You can't just add a triple "Expires 2019-06-56" to it, as that breaks the rule of monotonicity. Anyone can ignore it and would learn something not true)

[RubenVerborgh]

Yes, @RubenVerborgh you have stated your preference for using queries rather than graph navigation many times.

I have—but don't take it as an argument of preference here. The point is rather that, conceptually, we are always executing a query over a graph, whether we implement it manually or through an actual query.

As a consequence, in order to determine whether or not the triple should be there, it suffices to check the impact on a query, instead of having to reason over all possible implementations, since the result will be the same.

Concretely, we are talking about the difference between

SELECT * {
    ?auth acl:agent ?agent;
      acl:accessTo ?target;
      acl:mode ?mode.
}

and

SELECT * {
    ?auth a acl:Authorization;  # <== is this one needed?
      acl:agent ?agent;
      acl:accessTo ?target;
      acl:mode ?mode.
}

Is there any benefit in having the extra triple?

The answer would be yes if the extra triple makes the query more selective (which would also improve performance). However, in case of a MUST, the cardinality of that triple will not be lower than that of the acl:agent, acl:accesTo, or acl:mode triple patterns; hence, it slows down query execution rather than speeding it up. Regardless of whether you manually implement this or use a query engine.

---

We then next year can add a new class, TimeLimitedAuthorization.

But that would in practice (regardless of whether it is explicitly stated or not) be a subclass of Authorization?

[Otto-AA]

(Note: I'm not very familiar with RDF and WAC, so following may be far fetched. I hope it is of value nonetheless)

A generalization of the point @timbl made: If there are other expressions* which also use acl:agent, acl:mode and co, but should not be treated as acl:Authorization or are in an inactive state, then I think explicitly stating it would be necessary.

Reasons for that could be a time based authorization, template authorizations, toggle-able authorizations, single-use authorizations, conditional authorizations etc. If we want to use them in acl files, I think it is necessary to have a way to distinguish between them. Hence using acl:Authorization seems like a good way to me.

*sorry, I lack the appropriate vocabulary here

[kjetilk]

I'll note that the current Editor's Draft mandates the use of an acl:Authorization. Rereading the discussion here, I agree with @RubenVerborgh that if you have to check for it, it does slow down the process (I am more inclined to write a custom evaluator than @RubenVerborgh though, even though I'm very fond of SPARQL).

What I think this boils down to is the solution to #56 , as you do not necessarily have to check for acl:Authorization when computing the access given by a certain authorization. Currently, it seems that you do have to check, but we could discuss that in more detail (possibly over in #56).

[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-conformance . Please use https://github.com/solid/web-access-control-spec for future discussion.

---

#56 (comment)