Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Methods for ACL resource creation #42

Closed
acoburn opened this issue Sep 19, 2019 · 11 comments
Closed

Methods for ACL resource creation #42

acoburn opened this issue Sep 19, 2019 · 11 comments

Comments

@acoburn
Copy link
Member

acoburn commented Sep 19, 2019

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
Copy link

pmcb55 commented Sep 20, 2019

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
Copy link
Contributor

kjetilk commented Sep 23, 2019

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
Copy link
Member

csarven commented Dec 2, 2019

ACL resources are RDF Sources.

@csarven csarven modified the milestones: March 19th, December 19th Dec 2, 2019
@csarven csarven added this to Under discussion in Specification Dec 2, 2019
@kjetilk
Copy link
Contributor

kjetilk commented Dec 19, 2019

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
Copy link
Member

+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.

@Mitzi-Laszlo Mitzi-Laszlo modified the milestones: December 19th, February 19th Jan 14, 2020
@csarven csarven modified the milestones: February 19th, ~First Public Working Draft Jan 24, 2020
@csarven
Copy link
Member

csarven commented Apr 10, 2020

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
Copy link
Member

csarven commented Apr 20, 2020

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
Copy link
Member Author

acoburn commented Apr 21, 2020

👍 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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

csarven commented Jul 10, 2020

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.

@csarven csarven closed this as completed Aug 3, 2020
Specification automation moved this from Drafting to Done Aug 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Specification
  
Done
Development

No branches or pull requests

7 participants