Questions about "document's container" and "container's parents container"

[dbernstein]

Hello!

I'm writing on behalf of the Fedora Repository project (https://github.com/fcrepo4) regarding an issue that was raised last week on our weekly tech call. We are in the process of aligning our reference implementation with the SOLID/WAC spec. In recent discussions questions have surfaced around the relationship between "container" in the SOLID/WAC vs LDP specs.

The SOLID WebAC spec describes the ACL inheritance algorithm in terms of a
"document's container" and the "container's parent container":

1. Use the document's own ACL resource if it exists (in which case, stop here).
2. Otherwise, look for authorizations to inherit from the ACL of the document's
   container. If those are found, stop here.
3. Failing that, check the container's parent container to see if that has its
   own ACL file, and see if there are any permissions to inherit.
4. Failing that, move up the container hierarchy until you find a container with
   an existing ACL file, which has some permissions to inherit.
5. The root container of a user's account MUST have an ACL resource specified.
   (If all else fails, the search stops there.)

[https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm]

For the purposes of implementing this algorithm in the context of LDP, we are
making the following assumption:

1. The terms "container" and "parent container" refer to LDP containment.

Given that assumption, in the case of basic containers the implementation is
straightforward. However, there appear to be complications in the case of
indirect containers, because of cases where a resource may have multiple parent
containers (by the definition of LDP containment).

Thus, we have the following questions about the ACL inheritance algorithm:

1. Are WebAC ACLs compatible with the concept of a resource having multiple
   parent containers?
2. If so, how should the inheritance be resolved?
3. If not, should the ACL inheritance algorithm be interpeted as referring to
   path-based containment? That is, is it operating solely on the level of URI
   syntax, and not any semantics of the resource?

Your feedback/guidance on the issue would be most appreciated.

[timbl]

Good question. At the moment the solid code does just use a simple tree of basic containers (folders, directories) in the style of a very traditional unix file system. My gut feeling is that keep that as the only way in which authorization defaults can flow gives us invariants which we would lose if a subfolder were put in some random container and that container given different default ACLs.