Dependent resources / explicit inheritance across containers

[dmitrizagidulin]

The discussion about Auxiliary resources (and how they are tied to the life cycle of their primary resource) reminds me -- I'd love to see an addition to the Web Access Control spec that denotes "The ACL policies for this resource are fully dependent on the ACL policies of that parent resource."

Classic example: Blog posts and comments. The ACL of a blog post determines who can view the post. The post has a list of comments on it. And the access policy for the comments is determined solely by the access policy for the post. (Unless overridden/customized, dependent on the use case.)

So, something like:

• /posts/blog-postA.ttl -- has a comment on it, represented by resource /comments/commentB.ttl
• /posts/blog-postA.ttl.acl -- contains the usual ACL statements controlling access to the post
• /comments/commentB.ttl -- contains the comment, the author, etc.
• /comments/commentB.ttl.acl -- just has a statement like <wac:dependentOn> </posts/blog-PostA.ttl> (which denotes that it explicitly inherits the permissions of the blog post, but outside the usual container hierarchy).

[bblfish]

If I read it correctly this seems to follow from https://github.com/solid/authorization-panel/issues/73 "Client-Server symmetry" and also from follow your nose principles.

[elf-pavlik]

I would find it interesting to consider how much of the plumbing user gets exposed to. To my understanding shape trees attempt to create intuitive data boundaries. As general requirement I think we should have something in lines. "User should be able to assign existing access rules to a resource without need to change URL of that resource".

Another case that comes to my mind relates to few presets that networks like facebook offer:

In that case each preset would need to stay immutable to avoid changing rules to all posts that preset applies by modifying the preset.

[csarven]

Before going further with the need, can we be clear on the use case or scenario?

The post has a list of comments on it.

I think the expectation in the Solid ecosystem is that content creator decides where to store the resource and the applicable authorization policy (whether they actively set that or not). With the commenter example, they'd normally be expected to store their comment in their own storage. In that case, article's ACLs and the comments in response to the article and other comments' ACL are potentially on different systems. Currently the resource and its ACL are expected to be under the same origin server or URI space.

Would it make sense to reframe the use case or raise a different one?

I would also add that regarding the inheritance as you describe, there may be some discrepancy between server's HTTP header referring to an ACL resource it manages meanwhile allowing clients to effectively bypass the authorization policy that would normally be assigned to it in the associated ACL resource. Related issue: inherited ACL gets deleted.

[bblfish]

@csarven

I think the expectation in the Solid ecosystem is that content creator decides where to store the resource and the applicable authorization policy (whether they actively set that or not). With the commenter example, they'd normally be expected to store their comment in their own storage. In that case, article's ACLs and the comments in response to the article and other comments' ACL are potentially on different systems. Currently the resource and its ACL are expected to be under the same origin server or URI space.

Both use cases make sense. It makes sense to allow posting content to a container on the same server just at it make sense to post it on one's own. In the latter case though one needs a way after posting the comment to one's own server to notify the original content of the comment. This process requires again a post (probably to a container linked to by the original post). And this notification post may well need restrictions on access to avoid spam.

Come to think of it, those two ways of doing things could make for separate and interlinked use cases. cc @justinwb

[bblfish]

Your point @dmitrizagidulin goes in the same direction as the high confidentiality use case I put forward https://github.com/solid/authorization-panel/pull/96

[csarven]

In the latter case though one needs a way after posting the comment to one's own server to notify the original content of the comment. This process requires again a post (probably to a container linked to by the original post). And this notification post may well need restrictions on access to avoid spam.

That equally applies to posting a comment about an article on the same server. To be clear, in order for an application to discover an article's comment, one of these common patterns needs to happen:

• discover relevant relations between an article and for example its ldp:inbox or oa:annotationService, and eventually find way to the comments collection. Implementation: dokieli

• article links to comment collection and/or each comment. This actually requires the commenter to have Append (or Write) access on the article - I don't think that's a realistic or safe build from. In the classic Web via HTML form/POST, server processes the comment, and then makes the article representation include the new comment or at least makes a reference to it. This is not the approach we are taking in Solid.

• there are other ways of making the connection between an article and comments (via pim:storage, as:outbox, or possibly even some hops through solid:public/privateTypeIndex or other random hops) depending on context and the discovery starting point.

See also https://csarven.ca/linked-research-decentralised-web#linking-the-decentralised-information-space for an overview on key components and how they can be connected.

[bblfish]

@dmitrizagidulin wrote

I'd love to see an addition to the Web Access Control spec that denotes "The ACL policies for this resource are fully dependent on the ACL policies of that parent resource."

There are some proposals now in this direction.

1. add :imports relation which allows an acl to import other acls. By default the acl for a resource created in a container would import the acl of the container .
2. There is also the proposal on re-using policies that can go in that direction, but is finer grained. one way is described in issue 184. I am not yet that clear how that should work together with the imports proposal.