"acl" should = Active Control List

[bblfish]

In the latest WAC spec the "acl" link relation points to the resources own ACR even when this does not exist. For Solid servers with simple defaults set at the root that means that most resources would point to ACLs that don't exist. One could imagine a horror situation with a Web Science server hosting billions of documents where each one points to an ACL that does not exist, requiring clients to search for the default making "2n+1" requests.

Instead the "acl" should point to the active acl (acl = active control list), as that is what authentication libraries have been following to find the access control rules for a resource. A new relation pointing to the Access Control Potential (ACP) resource could then be coined. Perhaps http://www.w3.org/ns/auth/acp#AccessControl?

A server could then return for the /2021/foo/bar/baz/2093supernovae resource a 401 with the headers

Link: </default.acl>; rel="acl"
Link: </2021/foo/bar/baz/2093supernovae.acl>; \     
      rel="http://www.w3.org/ns/auth/acp#AccessControl"

Possibly the server would not show the ACP link unless the user already has control mode, as that would be required to create it. Who has control mode could be available from the active ACL. The cost of making a second HTTP request on /2021/foo/bar/baz/2093supernovae after having submitted a proof of control mode will not be that problematic. This is in line with the thinking of issue 325/, but now taking the more pragmatic route of having acl point to the effective one.

[bblfish]

The nice thing is that for servers where all resources have their own Access Control Resource, as advocated currently by ACP, acl and acp:AccessControl will coincide. For servers like existing WAC based ones, where a few default rules exist the two will point to different resources. This will allow the WAC and the ACP systems to come together.

[bblfish]

So here is the definition from the ACP draft spec (pushed recently but not reviewed) for the URL http://www.w3.org/ns/solid/acp#accessControl

The ACP accessControl predicate defines the set of access controls that mandate access over a resource and its associated access control resource, it has a range of acp:AccessControl and a domain of acp:AccessControlResource.

I think we could adapt the language a bit here, so that it can point to non-existing resources allowing it to work with WAC default access control policy.
@timbl could then add that as a first relation to the acp ontology, since I don't see why we could not have consensus on both sides.

[acoburn]

This will allow the WAC and the ACP systems to come together.

I don't understand the motivation for this. WAC and ACP address different use cases.

[bblfish]

I don't understand the motivation for this. WAC and ACP address different use cases.

They are both addressing access control use cases. That is all the client at the stage discussed here is wanting to discover. It is asking: where is the access control resource?

Consider a hyper-App (such as @timbl's Tabulator) trying to find the access control rules governing a resource on the web. It might have arrived at this resource in any number of ways. So at this point it has no way of knowing if the ontology for describing the rules is WAC or ACP. And that is not yet the question. At this point the client wants to find the rules for access, either to read them and then the "active control list" is the one it is looking for, or to edit it, in which case it may want to edit the access control resource most closely tied to the given resource. (in WAC that resource may not yet exist, in ACP as currently specified, it always exists)

[bblfish]

I now think it should be the other way. We need a relation to the Active access control container. See
#325 (comment)

[TallTed]

So you want to further overload the already horrendously overloaded ACL TLA, differentiating by whether it's uppercase or lowercase? acl = Active [Access] Control List, while ACL = Access Control List? This needs a rethink, should it already have been revived or be revived in the future.

[bblfish]

Hi @TallTed, I agree that my thought was confused a bit at the time of writing the initial issue, which is why I closed the issue a couple of weeks ago. I have now got a better proposal: #531