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

Store WAC permissions in their own named graph #1270

Open
srosset81 opened this issue May 30, 2024 · 0 comments
Open

Store WAC permissions in their own named graph #1270

srosset81 opened this issue May 30, 2024 · 0 comments

Comments

@srosset81
Copy link
Contributor

In the current implementation, WAC permissions are all saved in a custom SemApps-specific named graph. While it would be technically possible to keep this with NextGraph, the standard-compliant way to do this would be to store WAC permissions as regular resources, in their own document (and thus their own named graph)

This will require quite a lot of refactoring. It should probably be done closely with #1189

  • Automatically create a WAC permission every time a new LDP resource or container is created.
    • Put it on the same container as the resource ?
  • Automatically link it to the LDP resource with the acl:accessControl predicate
    • This is the one used by StartinBlox
    • This predicate is described like this in the ACL ontology: "The Access Control file for this information resource. This may of course be a virtual resource implemented by the access control system."
  • When a LDP resource or container is deleted, also delete the WAC permissions
    • If ActivityPub Tombstones are activated, the WAC permissions should be erased and we should only keep a public read permission.
  • Migration tool
    • Go through all LDP resources and containers, create a Document with a WAC permissions. Look at the existing permissions of the resource or container. Add a acl:accessControl link from the resource.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant