search

solid / authorization-panel

Github repository for the Solid Authorization Panel
MIT License
19 stars 20 forks source link

Empower rather than diminish acl:accessTo and acl:default #191

Open woutermont opened 3 years ago

woutermont commented 3 years ago

Please note that I am aware of solid/specification#55 and all similar issues mentioning it. However, these issues all seem to halt at a clarification of the (back then more confusing version of) the current WAC draft, without considering possible changes and their impact. I am also aware of the existing proposed changes to WAC, and come back to them below.

The current WAC draft seems to limit the use of the acl:accessTo and acl:default predicates severely:

This forces us to either [A] stick to some default inherited permissions with as few direct permissions as possible, or [B] handle some cumbersome construction of ACL resources when we want to get a more fine-grained control. Moreover, since the inheritance algorithm stops at the first existing ACL resource in the resource hierarchy, and defaults to zero permissions, adding an ACL resource low in the hierarchy often means copying a lot of permissions from higher up, which would be redundant if not for the (often small) change one wants to make, and which increase with the number of agent classes employed higher up the hierarchy.

[ Informative but already in proposed changes | Note that, while substituting an incorrect object for the (only) correct one has a significant effect, the semantic value of the correct object does not really contribute any information apart from "being the only object actually supported by the specification". Indeed, since the only significant effect of an incorrect object is the exact same behavior as leaving the triple out entirely, a semantically more informative choice would be to specify these two predicates with a boolean range: <#auth> acl:accessTo true would then be equivalent to the current use with the correct uri object, while <#auth> acl:accessTo false would equal both the current use with an incorrect object and the current absence of the triple (and similar for acl:default), of course also still allowing the absence of such a boolean triple. Even more, since acl:default is only applicable to containers, and its default value would be false, from an information theoretic perspective the entire current workings could even be replicated with a single boolean predicate. ]

This limited expressive power and cumbersome practical use have already been the grounds for at least two proposed changes to WAC: making acl:accessTo obsolete in favor of acl:accessToClass and changing the acl:default range to boolean. However, both these changes are backwards incompatible, and still fail to take full advantage of the expressive power of having separate, uri-specific predicates for direct access and inherited defaults. While doing away with some semantic redundancy of the existing specification, they do therefore not fully solve the practical issues sketched above (in particular having fine-grained control without cumbersome ACL constructions).

I would therefore like to propose an alternative solution which a.f.a.i.k. would have the same advantages as the two mentioned proposals, but is backward compatible and allows for a more free, practical ACL resource hierarchy. My proposal consist merely of the following two additions to the existing WAC draft:

These triples can then be taken into account by the inheritance algorithm just like the currently supported ones, i.e. only when a more direct ACL resource is not present. This would enable us to maintain permissions at the hierarchical level that is optimal for each use case: the current pattern would still be possible; more fine-grained approaches would not necessarily clutter the resource hierarchy anymore; and redundant copying would be avoidable by changing permissions in an existing ACL resource higher up rather than having to create a whole new ACL resource. Moreover, nothing seems to prevent this to be combined with the addition of (but not replacement by) an acl:accessToClass predicate, given some additional priority rule.

Importantly — and contrary to the obsoletion of acl:accessTo or the range change of acl:default — since the proposed use of the predicates is currently not supported, introducing them (and changing the interpreting code of existing implementations) would be backwards compatible, up to the exception of existing ACL files that currently already contain such a (up till now useless) triple.

bblfish commented 3 years ago

I implemented WAC 5 or more years ago as it was only an ontology. I need to re-implement this now so will look in more detail at the inheritance algorithm.

But since you are speaking of acl:accessTo have you looked at https://github.com/solid/authorization-panel/issues/184 on re-using policies? There are more examples of this in the ACLs on ACLs issue https://github.com/solid/authorization-panel/issues/189

woutermont commented 3 years ago

I hadn't, but now I have. I believe this issue and #184 address different problems, however, and the proposals should therefore probably be used alongside each other (if possible).

An :authorizes predicate might enable us to split the assignment of a policy from the description of it, but it does not solve issues around the organization of the assignments itself, which are at the core of this issue. Even if an access control resource only has to contain an :authorizes reference, having a lot of small overrides will still require a bunch of access control resources with many copied triples. My proposal simply wants to make sure the inheritance algorithm gives authorization controllers as much freedom as possible in specifying the assignments, while still remaining compatible with current access control resources.

bblfish commented 3 years ago

Issue #184 also shows why deprecation of :accessTo is not needed. In situations where it can be inferred it allows the statement of what has access to be open ended.

  • Allow the ACL resource of any ancestor container of a resource to also specify (effective) <#auth> acl:accessTo <./some/resource> triples about resources in their subhierarchy.
  • Allow the ACL resource of any ancestor container of a subcontainer to also specify (effective) <#auth> acl:default <./some/sub/container/> triples about containers in their subhierarchy.

That generalises to specifying things like [] acl:accessToClass [ childrenOf <> ] for giving default access to all children of a container.

I tend to look at things from the client side: the client needs to know what the rules for access are before attempting access. See for example How does one create an Access Control Resource?. From that perspective an obvious answer I came up with 5-7 years ago was to include an :include relation in the newly created Access Control Resource (ACR) to the parent ACR. That automatically brings default behavior in, and a controller that wishes to break the inheritance, can just remove the acl:include relation.