Atomicity of creating a resource and its ACL about web-access-control-spec HOT 2 OPEN

I think we should consider the possibility of clients to suggest the URI of the ACL they want to assign to a resource when creating or updating the resource.

It makes it possible to create the ACL before or after creating the resource - depending on their level of comfort and tolerance.

Helps to address use cases requiring decentralised ACLs.

In the case where Link rel=acl isn't specified, the server can still assign one as per usual.

The LINK method can be optionally used by a client to establish the relationships in Link (eg. pertaining to rel=acl/meta). This is useful in and itself because the location of acl/meta doesn't need to be sticky. It should be mutable so that the reference can change without having to re-create the resource with a new reference.

Let's be careful to not lose sight of the target resource with URI/API tricks. Slashes in path segments is different - native to URI (RFC).

That leaves us with having either the client to be explicit that a resource is an ACL or server figuring it out. The options are not mutually exclusive:

1. Client: Content-Type - there isn't a mediatype for ACL (only existing RDF formats). Perhaps profile=solid:ACL can be used?
2. Client: Link rel=type solid:ACL - new reference.
3. Server: Processing the payload and checking against a data shape.
4. Server: URI Template for ACL resources.
5. ..

Option 1 - New media type for ACL is probably nonsensical (given that it is already in RDF... subtyping is meh). profile seems attractive eg. Content-Type: text/turtle; profile="http://www.w3.org/ns/solid/terms#AccessControl" (alternative: use acl ns and add class). Meaningful?

Option 2 - specifies "payload's abstract semantic type".

Option 3 - server probably should process the ACL shape any way.

Option 4 - server expects only ACL resources at designated URIs.

I think the following can work..

POST /foo/bar/
201
Location: baz
Link: <http://example.org/foo/bar/baz.acl>; rel="acl"

PATCH /foo/bar/baz.acl
Link: <http://www.w3.org/ns/solid/terms#AccessControl>; rel="type"

LINK /foo/bar/baz
Link: <http://example.net/.acl>; rel="acl"

from web-access-control-spec.

@csarven one possible issue with this proposal is whether a client suggests an ACL location or whether a client assigns an ACL location to a resource. And also whether a server implementation is free to ignore that.

Here are some issues that emerge if a client is able to assign an arbitrary ACL to a resource.

1. An ACL resource could be a regular resource. Does this mean that this "regular resource" now is accessible only by those with acl:Control privileges? What if that resource already has its own ACL resource?

2. What if the designated ACL resource is a child of the resource in question (in terms of LDP hierarchy)? How does that intersect with DELETE operations?

3. If an untrustworthy application can get a user to assign a remote ACL to a resource -- an ACL that the user does not control, then a series of potential "loss of control" scenarios become quite real.

4. How does a server enforce ACL restrictions in the case that an assigned ACL is temporarily inaccessible? (i.e. on a remote server that is under a DDoS attack?)

5. If a client assigns an arbitrary ACL (e.g. an ordinary LDP-RS within the same server), what makes that a legitimate ACL resource? The mere presence of ACL triples? What happens if a user with acl:Write access to that "acl resource" is able to remove those triples or otherwise render the ACL graph semantically meaningless? And what happens if ACL triples are added to an ordinary LDP-RS? Does that resource become an ACL resource?

I'm not against this feature, because it could be implemented in a way that these concerns are addressed. OTOH, I would be concerned if support for this was absolutely required, because it introduces some significant issues that a server implementation could easily fall into.

from web-access-control-spec.