web-access-control-spec
web-access-control-spec copied to clipboard
Questions about "document's container" and "container's parents container"
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":
- Use the document's own ACL resource if it exists (in which case, stop here).
- Otherwise, look for authorizations to inherit from the ACL of the document's container. If those are found, stop here.
- 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.
- Failing that, move up the container hierarchy until you find a container with an existing ACL file, which has some permissions to inherit.
- 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:
- 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:
- Are WebAC ACLs compatible with the concept of a resource having multiple parent containers?
- If so, how should the inheritance be resolved?
- 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.
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.