Prioritize formalization of WebACL specification

[pmcb55]

Of course we'd like a complete formalization of the current WebACL specification (https://github.com/solid/web-access-control-spec), but very specifically we need practical answers for the following questions:

• - A formal description of the inheritance algorithm with respect to acl:default, and whether permissions are cumulative or not.
• - Whether acl:origin is even effective at addressing the security concerns that it is designed to address (and how it is actually supposed to be implemented).
• - What to do with ACL documents that are semantically ambiguous (i.e. is there a shape for Authorization statements?)
• - What to do with incomplete ACL statements? i.e. Default=DENY or Default=Skip?

If these areas are not sufficiently important for others on this panel, then we'll just suggest answers ourselves (to have them at least recorded), and then implement our system accordingly.

[zenomt]

i implemented an authorization server based on https://github.com/solid/web-access-control-spec . based on that experience, i believe:

A formal description of the inheritance algorithm with respect to acl:default, and whether permissions are cumulative or not.

the inheritance algorithm is clearly specified (there is exactly one ACL file that applies to a resource, and how acl:default works). permissions are not cumulative -- only the permissions in the in-force selected ACL matter.

Whether acl:origin is even effective at addressing the security concerns that it is designed to address (and how it is actually supposed to be implemented).

acl:origin does what it was designed to do. i don't think it is sufficient for the "per-app-per-user" use case though, nor is it consistent with the reality that users can lie to a resource server about what app/origin is being used.

What to do with ACL documents that are semantically ambiguous

i don't think WAC documents are ambiguous. either the in-force ACL file has an acl:Authorization that grants the desired access, or it doesn't.

What to do with incomplete ACL statements? i.e. Default=DENY or Default=Skip?

there is no such thing as an incomplete ACL statement. if there is no acl:Authorization that grants an access, then access is denied.

"Access Control List" is a misnomer for WAC, because the acl:Authorizations aren't ordered (that is, there is no "access control list"). a WAC file comprises an unordered set of authorizations, any of which could permit an attempted access. there's no such thing as "deny" in WAC, so order wouldn't matter anyway. in other words, WAC works by "access is permitted if any authorization rule permits the access".

also, having implemented an authorization server based on WAC, i believe that WAC in its current form is insufficient. see for example gitter conversations at

• https://gitter.im/solid/app-authorization-panel?at=5d584d5ebfd2887f53093ba7
• https://gitter.im/solid/app-authorization-panel?at=5d5d9b3c8e8dde63d8138398
• https://gitter.im/solid/app-authorization-panel?at=5d684659bee75051a41c2d7f

TL;DR: WAC, while good, is not good enough.

[acoburn]

I have also implemented WAC-based authorization for two completely different servers.

Is the specification implementable, as currently written? Yes, certainly

Will all implementations enforce WebAC authorization the same way, based on the text of the specification? That is considerably less certain.

The point @pmcb55 is making is that there is ambiguity in the language of the current specification that makes it difficult to build independent WebAC implementations that are compatible. Here are some specific examples that build on what @pmcb55 stated above.

1. Is it necessary to materialize the <> a acl:Authorization triple? A server could, legitimately, use simple RDFS entailment to infer the presence of that triple, though some implementations require this. It would be helpful if the specification used normative language such as one finds in the LDP Specification:

WAC implementations may infer the following triple: one whose subject is the WAC Authorization, whose predicate is rdf:type, and whose object is acl:Authorization, but there is no requirement to materialize this triple in the resource representation.

2. The definition of acl:default is ambiguous. Here is the comment from the ACL vocabulary:

If a resource has no ACL file (it is 404), then access to the resource if given by the ACL of the immediately containing directory, or failing that (404) the ACL of the recursively next containing directory which has an ACL file. Within that ACL file, any Authentication which has that directory as its acl:default applies to the resource. (The highest directory must have an ACL file.)

Given that description, what is the use of acl:default at all if the next highest container contains any ACL resource (whether that resource has an acl:default statement or not)? What happens if a resource has no defined ACL document, but its direct parent does contain an ACL document (but that ACL document has no acl:default statement). And the first ACL document with an acl:default statement is in the "grand parent" container ACL? Does the inheritance algorithm skip the ACL document in the parent container and only apply the one from the grand parent container? There is ambiguity here.

Furthermore, what happens with an ACL such as:

<#authorization> a acl:Authorization ;
    acl:mode acl:Read, acl:Write ;
    acl:agent <https://example.com/webid#me> ;
    acl:accessTo <.> ;
    acl:default <./some-child-resource> .

Would that mean that the Authorization statement is only applied to ./some-child-resource but not to ./some-other-child-resource (assuming both lack their own ACL resource)?

3. acl:origin may do what it was designed to do (modulo the security concerns about spoofing Origin headers), but its definition is ambiguous. It is defined in the section about trusted apps, though that section is clearly marked with this warning:

NB: this feature was only added recently and is still considered experimental. It's likely to change in the near future.

Furthermore, the ACL vocabulary defines acl:origin as having an rdfs:domain of acl:Authorization -- does that mean that the subject of the acl:origin triple needs to be the same as the one that grants access to the webID at hand? Or would it have a distinct subject: the specification is silent on this and provides no guidance. The specification also shows examples of using acl:origin with two properties that are entirely absent from the ACL vocabulary: acl:trustedApp and acl:trustsForUse. These examples also do not align with the formal definition of acl:origin (c.f. acl:origin rdfs:domain acl:Authorization). Without any definition of those properties, this feature is basically unimplementable, at least not in a way that is guaranteed to work the same as other implementations.

4. regarding semantically ambiguous ACL documents, what if an implementation supports acl:accessToClass? This is defined in the ACL vocabulary but "not supported by design" by the specification. Does that mean servers "SHOULD NOT implement this feature" or "MUST NOT implement this feature" or does the specification take no stance on that? And in that case, how does this affect portability? Furthermore, what if the acl:accessTo triple points to a resource in a completely different location? or (as hinted above) what if the acl:default triple points to a child resource? From the examples, it is clear what a "proper" ACL document could look like, but one needs to assume that a client application (provided it has acl:mode acl:Control may put all manner of RDF in those resources? And is it legit to put arbitrary RDF in those resources?

[RubenVerborgh]

Will all implementations enforce WebAC authorization the same way, based on the text of the specification? That is considerably less certain.

This confirms earlier observations that the existing draft specs are insufficient. Hence the undertaking of https://github.com/solid/specification/

However, this also brings me to a larger issue: perhaps this panel focused on app authorization is premature, since authorization itself has not been fully fleshed out.

I think we should consider either broadening the scope of this panel, or to at least create another panel and acknowledge the dependency. Will create issues.

[RubenVerborgh]

Created #36 and solid/process#135 to track.

[kjetilk]

@timbl 's interpretation of this is embodied in his implementation, which can be reviewed for some answers.

[bblfish]

I doing a PhD on fomalizing Solid and Access control. I gave in my 2nd year report on April 1st 2019.
There I located the logics to use, how these need to be tied to the web, and where one can go from there to make a potentially much more flexible system.
The remaining year was to be dedicated to using these logics and describe what is happening formally in Solid, as well as potentially go beyond what is currently possible.

(Sadly my funding is running very short and so instead of doing this I am spending most of my time looking for programming work. That is helping me get back to programming and tie theory to practice again, but it is not helping me get the thesis finished.)

[dmitrizagidulin]

I'd like to add to @pmcb55's list, as far as formalizing the WebACL spec, and add the issue of:

• Decide which vocab/ontology Solid's WebACL terms live in, as discussed over at Add preamble explaining that this spec is only one of four existing flavours of WAC web-access-control-spec#51.