Methods for ACL resource creation

[acoburn]

The Solid WAC specification defines a link header (currently: rel="acl") pointing to the location of an ACL resource. Because the resource at that location may not exist, what are the valid mechanisms for creating a resource at that location? In addition to PUT, is PATCH (with a SPARQL-Update body) allowed? My reading of the SPARQL-Update specification suggests that this is legitimate. Does the Solid specification need to explicitly refer to this pattern, either via normative or non-normative text?

[pmcb55]

I would think the main 'valid mechanism for creating [an ACL] resource at that location' is a transaction - i.e. either the resource and it's associated ACL are both created together, or neither are. I'd consider this an implementation detail though, i.e. some persistence implementations may have no transactional capability to enforce that (but it then becomes 'their problem' to deal with the consequences). Personally I'd suggest keeping the resource data and all it's metadata (including the ACL data) within the same physical store (e.g. a triplestore), and for NonRdfSource resources (e.g. that might make more sense to store on a SAN (e.g. huge video files)) I'd simply keep all the metadata (including the reference to the video 'file' on the SAN) transactionally together in that same triplestore (and have server-side error-handling logic to handle the video file being deleted without updating the meta-data pointing at that video file (i.e. rather than trying to guarantee distributed transactionality)).

[kjetilk]

I would think the main 'valid mechanism for creating [an ACL] resource at that location' is a transaction - i.e. either the resource and it's associated ACL are both created together, or neither are.

I interpreted @acoburn 's question differently, it was not about the relationship between the resource and its ACL, it was about the methods used to create the ACL.

I think the concern is a legitimate one. I think it is up to us to decide whether SPARQL Update could be used to do it, there is nothing I can think of in other specifications that would be inconsistent with this.

[csarven]

ACL resources are RDF Sources.

[kjetilk]

I've started to detail how ACL resources should be manipulated along with the discussion of each HTTP method, and so far I have agreed with @csarven , they can be manipulated as RDF Sources, only that acl:Control applies. I think this is generalizeable. Is there rough consensus on that?

[justinwb]

+1 that they can be manipulated as RDF sources, and acl:Control is the first constraint that will be evaluated. I do think that we'll look to stipulate some more constraints as part of #102, where we detail how solid servers handle certain types of metadata like acls. For example, the server might apply special handling to ensure that the content is valid WAC (perhaps through shape evaluation), to protect from malformed rules that could restrict access or (even worse) expose it.

[csarven]

It'd be useful to expand on the acl:Control requirement (and implying why). Straw man proposal/requirement:

Server MUST reject requests to create ACL resources of (existing or non-existing) associated resources from users without control access.

Aside: there may be other issues or comments stating something equivalent or hinting at it, but nothing jumped out at me. This issue was closest. Preferring to bring this up any way instead risking it from causing issues later on. nodeSolidServer/node-solid-server#1418 is an implementation issue backing up why we need this requirement.

[csarven]

This issue is specifically about the second premise below. To have rough consensus on this issue, we only need to respond to that. I'm further outlining the other requirements that all need to hold true in order for ACL resource creation to take place.

P1: An ACL resource is an RDF source (subject to resource lifecycle handling).
P2: An ACL resource can be created using HTTP methods pertaining to the write operation i.e PUT, PATCH [1].
P3: A resource advertises its associated ACL resource with a link relation.
P4: Server must implement the ACL inheritance algorithm to determine the applicable ACL resource and its authorization policies of a resource.
P5: An ACL resource can be created by agents with acl:Control access privilege on the resource to which access is being granted.

[1] PUT and PATCH are deterministic as the target resource name is fixed. While it is technically possible to create ACL resources with POST+Slug, it allows varying implementations due to its non-deterministic resource naming ie. each server ultimately names the resource as they prefer. This entails that a server may not actually end up creating an ACL resource but a generic RDF source with no association to client's original intention. The intention remains unclear without server validating the payload or client providing additional information in the headers (eg. Link rel=type for ACL, or profile parameter in Content-Type).

[acoburn]

👍 This seems like a very reasonable approach. Clarifying that ACLs can be created only via PUT and PATCH makes sense for the reasons outlined.

[jaxoncreed]

The intention remains unclear without server validating the payload or client providing additional information in the headers (eg. Link rel=type for ACL, or profile parameter in Content-Type).

I think this is the main thing to stress. We might want to consider, as you said, adding a header that allows the client to dictate their intention to create an ACL.

[justinwb]

This looks good. Agree with the points as stated by @csarven. Only suggest that we further clarify P4, which states:

P4: Server must implement the ACL inheritance algorithm to determine the applicable ACL resource and its authorization policies of a resource.

We should clarify to the reader that this is determining which existing ACL resource to apply when there is not one directly associated with the target resource in question, so that it is not confused with how the server determines the directly associated ACL resource to advertise in the link header.

[csarven]

I've captured the rough consensus on this issue with emphasis on P2 for auxiliary resources (which includes ACLs) in 41c8dc3 (PR'd). The reasoning is that the intent to create a resource that happens to have a reserved URI (server-determined identifier) and the affects are the same. Creating ACLs have additional concerns, as already discussed.