solid / solid/specification

Coin and document effective ACL URI

Open
#325 15 comments 0 reactions 1 assignee View on GitHub

@csarven is already working on this.

Since Oct 19, 2022.

Dominant language
HTML
Stars
563
Forks
108
Avg merge
4d 13h
Merged PRs (30d)
3

Description

There are some very good reasons to have default ACLs (WAC). There are also very good reason for each resource to have its own ACL (ACP). How can these two points of views come together?
Simply by allowing LDPRs to distinguish between two ACL resources

  1. A link to the effective Access Control Resource
  2. A link to the resource's potential Access Control Resource

Indeed the current WAC spec states that

a separate link relation type targeting the effective ACL resource is allowed, but no behaviour is defined by this specification.

Please specify this officially!

Trellis has defined http://www.trellisldp.org/ns/trellis#effectiveAcl. It should be possible to have one that we all agree on in a solid namespace.

Problems solved

The problems are:

  • If only 1) is given then there is no way to create subspaces on a server with different access control rules, as there is no way to work out where the resource's acl will be
  • if only 2) is given but the default acl needs to be discovered (as per current WAC) then the cost of finding the effective ACL is 2n+1 where n is the number of folders between the resource and the effective one. This is unworkable.
  • If every resource has 2 be the effective resource - as ACP does - then we have a problem of wastage and maintenance. This creates duplication of information as per issue 206 of the authorization panel. For all those cases where a default set of rules would do for most content, one ends up with a duplication of rules. Every resource will end up with the same copy of pretty much the same ACL. This creates problems for updating them, and also would slow down requests, fill up intermediate caches with duplicate information, etc... So it can be pretty wasteful. It slows down requests that are access controlled, by requiring essentially 1 more request than needed.

The answer to both these problems, is just to coin a new Link relation as discussed in last weeks authorization panel meeting
https://github.com/solid/authorization-panel/blob/draft-minutes/meetings/2021-10-13.md

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.