Clarify where new acl files should be created

[Otto-AA]

The spec states where one can find acl files, but as far as I've seen it never says how the client could know where to create new acl files.

As mentioned in #8 it could be interpreted that the server also returns the acl link even if no acl file exists yet. If this behaviour is mandatory it could be used for deciding where to PUT new acl files.

But I wonder how this would work if I wanted to create a new acl file with multiple accessTo values. Just choosing one file at random and then pick its proposed acl link?

[dmitrizagidulin]

The spec states where one can find acl files, but as far as I've seen it never says how the client could know where to create new acl files.

Yeah, it's like you suspected in PR #8, the implied recommended procedure is:

• Perform an OPTIONS or a HEAD request on the intended file URL (it's fine if the file does not exist yet, the resulting .acl link header is required to be returned).
• Create that .acl file via a PUT
• Create the corresponding file (note that the .acl should be created before the file)

Keep in mind though, that the most common use case is to have an .acl at the container level, which all the files in the container will re-use. While it's possible that every single file will have its own individual .acl, that is a rare use case.

But I wonder how this would work if I wanted to create a new acl file with multiple accessTo values. Just choosing one file at random and then pick its proposed acl link?

Right, so... (And this should probably be clarified in the spec) Solid currently assumes that an individual .acl resource only specifies access to a single file or container.

[kjetilk]

Indeed, that's how I'm writing tests for it right now. But I'm not sure it makes sense to me, since that as you say, the .acl may reside further up the container hierarchy. The correct thing may be to make changes there rather than PUT a new one. Something also tells me that this is something a footprint should decide.

[Otto-AA]

Thanks for your thoughts on it, as I'm currently writing an acl js library these are very useful to me.

I will go with checking the link header to know where it should put the new acl resource. I would appreciate it if this is clarified in the spec.

While it's possible that every single file will have its own individual .acl, that is a rare use case.

I think it is really common for file sharing and collaborating. For instance if I want to give user A write permissions on a doc, but the Public should only have read permissions. Or if I want to share a file like one can do in dropbox and co. Maybe there are not many other use cases, but here it seems essential to me.

Right, so... (And this should probably be clarified in the spec) Solid currently assumes that an individual .acl resource only specifies access to a single file or container.

From my point of view this is contrary to what the spec is currently saying: "The acl:accessTo predicate specifies which resources you're giving access to, using their exact URLs as the objects.". The plural of resource here makes me think that multiple accessTo predicates are also valid in the same acl file.

And what do you mean with footprint, @kjetilk ?

[kjetilk]

And what do you mean with footprint, @kjetilk ?

Ruben has blogged about shapes and stuff, including footprints: https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/#top-dt-3

[Otto-AA]

Right, so... (And this should probably be clarified in the spec) Solid currently assumes that an individual .acl resource only specifies access to a single file or container.

Is this something that is commonly agreed upon to be part of the spec (but not clearly phrased imo), or do you mean that it is commonly implemented that way, but it is not sure if it will be part of the spec or not?
(I can also move this to another issue, so we have one issue per clarification request)

[kjetilk]

I think that the general footprints mechanism will become a part of Solid at some point, and that it is where such things will be described. As the discussion is relatively new, I'm not sure exactly where it will fit, but I think the general idea is that it will be there.

[csarven]

Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ .
See See #acl-resource-discovery #authorization-matching #reading-writing-resources .