how does one create an Access Control Resource?

[bblfish]

There is no mechanism for specifying how to create an Access Control Resource (ACR) attached to an ldp:Resource, in the WAC spec, as far as I can see.

acp:default allows one to state what a default ACR for a resource is, and the whole WAC inheritance algorithm says what one should do if a resource does not have an ACR: where to look for one. But it does not tell one how one creates an ACR for a resource.

One way to solve the problem is as ACP does: require that every resource has its own ACR. The acl:default can then be used to fill in the new ACR with the default access control rule. (And it would explain the old acl:defaultForNew name).

Without such a behavior the concept of acl:default does not quite make sense: for how would a client create an ACR to begin with, that could override the default? Link relations could only ever link to the ACR containing the default, and so one could not change the default.

One could perhaps think of allowing clients to POST content with a Link: ldp:AccessControl rel=type header to a resource to create one. Perhaps that is when default rules apply? Only users with control rights as default could create those resources?

[csarven]

Much of this is already in existing issues or made its way into the Protocol. For example, server associates an ACL resource to a resource, and the discovery is done by checking resource's Link header. The URI of the ACL resource is known. Only PUT or PATCH can be used to create an ACL resource. POST to a container entails that server allocates a URI to the created resource. ACL resources are not "contained" resources ie. they don't show up in containment listing. (That can be debated I suppose.. but not something I'm keen to pick up soon).

Once an ACL resource has a representation ie. a client creates the ACL resource at specified URI, it will be used. default is useful/looked for when a resource doesn't have its own ACL resource.

If you are curious about how a client can allocate the URI of the ACL resource instead of server (close to your example above with rel=type), see https://github.com/solid/specification/issues/131 .

[bblfish]

I had not thought of the possibility of a Link: <doc.acl>;rel=acl pointing to a non-existent resource. That would require the client though to know that it has access rights to edit that acl and so to know the default for it, bringing us back to the ACL Inheritance problem. This train of thought leads one to the conclusion of ACP: every resource should come with its own ACL. Then it is just a matter of copying the defaults to the newly created resource.

This problem arises as soon as one writes an ACL system, as I am doing right now.

Finding ways to hint or create new ACLs seems indeed like a complicated problem, better left for later.

[csarven]

URI reference does not entail that a resource has a representation. ACL resources may have a representation, created, deleted..

Clients can know via WAC-Allow.

[bblfish]

We agree agree that URIs don't entail that the referred to resource exists.
The problem is that a client that would want to create a resource whose URI is available in a Link header, would not know what credential to use to do that, if you keep the problematic statements discussed in Issue #257.
Neither isWAC-Allow defined in WAC Spec of much use here either. That tells you what modes a logged-in user has on a resource, and we are talking here about the problem of what identity to use before presenting a credential. The purpose of WAC-Allow - deducible from it's behavior - is quite different: it is to help guide a client on whether to show or not an edit button on a resource.

Now these two use cases may be indistinguishable if your only use case is that the owner of a POD has control over all resources. In that case the user will always be logged in to his POD, and have control access to all the resources. But it gets more problematic if one invites another user or groups to control subcollections too.

[bblfish]

There is another way to look at this. If the rules from Issue #257 hold about it being bad practice for a client to follow links up the container hierarchy, and since the client has to know how to authenticate, it follows that the server needs to copy the default rules to the ACR on creation (or potentially if it goes missing on the file-system).

Note that if things are specified that way, then the comment about the link following being bad practice become unnecessary, since the data is already available at the ACR.

[bblfish]

It may be on the other hand that the purpose of a default is to reduce the amount of places where edits need to be made to change access control rules. A POD owner wants to set her key on the root container but not on every subcontainer. Or the POD owner wants to give rights to another user for a container and its children. In that case copying the the rules to every Access Control Resource (ACR) would be problematic, because if the owner wanted to change keys, it would need to change keys in every resource.

As a result we need a link from the Resource to the default. But as we saw if we place the Link in the header to the original default, then it becomes tricky for the client to know what to edit. Instead we can use the :authorizes relation discussed in authorization panel issue 184: re-using policies and for which there is a similar construct acp:apply see the diff story.

The link to the default was done in rww-play 7 years ago by using acl:include relation from the Resources' ACR to the ACR containing the default. The default ACL would contain a rule with an acl:accessToClass using regexes. The new and more elegant trick, is to add an inferencing step that adds the accessTo relation if the correct links are followed.