OK, I see the point of skipping ACL docs that contain no acl:default statements, but I think there would be some downsides. It seems a bit arbitrary, especially if different (groups of) people have different access rights to different (sub-)folders.

Suppose there is a server that has two main user groups, for instance musicians and music lovers. By default, at the root of the server, all musicians can read+append, and all music lovers can read. Then say someone updates the settings for the /jazz/ container to change the default for musicians from read+append to read+write.

Sounds like a change that would only increase the rights a musician has on the /jazz/ folder, right? Well no. It would instantly make all Jazz music unreadable to music lovers. Ouch.

IIRC, in NSS, the search for an applicable .acl and the use of that .acl are two different processes, but I could be wrong.

I fear that I missed something, so please correct me if I have a mistake in my thoughts. So assume we have following setup:

• /public/folder/file.ext
• /public/folder/.acl (without acl:default)

If we use the Algorithm which does not check for the presence of acl:default:

1. file.ext has no acl file to it, so it searches the parents
2. /folder/.acl exists, so it uses this acl file
3. The acl file has no acl:default, so no permissions are supplied to file.ext

Would this mean, that file.ext is not read/write/append/control-able by anyone? If this is the case, adding an acl file to /public/folder/ would overwrite the /public/ rules in both scenarios. Therefore we would need to copy them anyway. (This is also what I intended to add to my solid-acl-utils library: To copy the default permissions of the corresponding parent when creating a new acl file)

@Otto-AA - You're understanding it correctly.

Would this mean, that file.ext is not read/write/append/control-able by anyone?

Yep, that's it. (That's the current spec's behavior, anyway. Whether we want that to continue or something different is the point of this issue / discussion.)

Therefore we would need to copy them anyway.

Yeah, I think that's what some existing libraries do as well (the data browser I think).

In the triple <#auth> acl:default , does the value of the object node matter?

Yes

Must the object node point to the URL of the resource for which this ACL is defined? What is the implication of that object node pointing to some other URL?
Yes
In that case, would that acl:Authorization statement be ignored?

Yes

Is an acl:Authorization inherited only if acl:default is present?

Yes

The vocabulary document suggests the answer is yes; the Solid WebAC spec document also suggests the answer is yes (but only in an example); discussion on the issue referenced above suggests that the answer is no. That is, if a resource lacks its own ACL resource and the WebAC algorithm checks the parent container, does the algorithm stop at the parent container if that parent ACL contains any acl:Authorization statements or only if it contains any statements that also include acl:default? There appear to be conflicting ideas about this.

It stops at the first file which exists, irrelevant of its content. If it find a file which exists and is empty, then there is no access for anyone to anything below it. There is a huge difference here between an empty file and a nonexistent file.

This is how this works in any code I have written about this.

Can we close this?

Ok, great to get clarity on this. But just before closing, I'd like to invite @d-a-v-i-- to review this conclusion from a security perspective...

Before closing, it may also be helpful to have corresponding normative language added to the WAC portion of the Solid specification, clearly articulating what is described above. In the meantime, perhaps a label can be added to this issue, indicating its status.

Yes, I think these issues need to be open until they are merged into the specification through the process.

@acoburn , have your questions been answered to your satisfaction? If yes, I think we can move this to "Rough consensus" based on @timbl's statements.

Yes, this has been thoroughly clarified. Thanks so much.
Feel free to move into "rough consensus"

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 , #authorization-evaluation , #authorization-matching . Please use https://github.com/solid/web-access-control-spec for future discussion.