Make explicit in spec that when a default resource is served for a container, server should check ACL for that resource

[megoth]

As a continuation of https://github.com/solid/solid-spec/issues/134, we might want to make it explicit in this spec that the server should check the default resource's ACL.

Examples:

1. If serving index.html for a container, check index.html.acl (and traverse container ACLs as usual)
2. If serving index.ttl for a container, check index.ttl.acl (and traverse container ACLs as usual)
3. If serving the virtual resource for a container, there's no specific resource ACL to check, but traverse container ACLs as usual

[megoth]

The way I understand it this level of detail shouldn't be in the spec (as discussed in https://github.com/solid/solid-spec/issues/134). So I'll close this issue as well.

[RubenVerborgh]

I do not think the solid spec should govern what is on disk; there might even be no disk or no filesystem.

However, we what we should be concerned about is that, if representations of a resource have their own URL, that they are protected by the same ACLs. Access control should protected resources, not representations.

For example, /foo/ is the main resource, with /foo/index.html or /foo/index.ttl are representations; ACL should be set on /foo/, but also cover representations. However, in this spec, no assumptions regarding representation URLs should be made.

Hence, I think it is important to reopen. Cross-post of https://github.com/solid/solid-spec/issues/134#issuecomment-457554116.

[kjetilk]

Indeed, and there is already mention of possible antipatterns in this spec, so there is precedent for pointing out what shouldn't be done.

[csarven]

The authority of a resource determines what the resource refers to - generic or specific. The server manages the association of an ACL resource to a resource, sets any constraints on authorization rules, and determines the requirements of an operation on a resource (which may be conforming to a specific protocol). WAC describes the authorization process, does not restrict, distinguish or relate #access-object resources that is of the kind generic or specific.

---

I suggest that whether a server associates the same ACL resource to both resource and representation URLs, and whether an ACL resource's Authorization can be checked to match a resource or a representation URL is specified elsewhere (e.g. the Solid Protocol) or deemed to be implementation specific.