Page History

...

1. As a user from the Registrar office creates an Asset with a loan agreement document, the user assigns a property to the asset indicating that the asset is restricted to the Registrar staff, the user (a member of the Registrar group) should not be locked out of viewing/editing the resource.
2. A user wishes to create multiple resources that all share access restrictions. The user is able to create a single access control list that is used by that group of resources. In addition, they do not have to explicitly link to the ACL from every resource; the appropriate ACL is inferred from the collection a resource is a member of (collection defined by as a resource that ldp:contains the target resource) , or the class(es) it is an instance of. 
3. There is a collection that is by default restricted access. However, there are a selection of resources within that collection that are publicly available. These public resources are not necessarily grouped together in a single hierarchy within the collection.
4. An unauthenticated user requests a protected resource. The system presents them with an authentication challenge. The user successfully authenticates, and it is determined that they have read access to the requested resource. The system retrieves and presents the resource to the user.
5. An authorized user must be able to change which ACL applies to a given resource or group of resources without moving those resources.
6. An authorized user must be able to edit an ACL in place in order to update the policy that applies to all resources governed by that ACL.

...

1. F4 MUST allow assertions about authorization to be modeled in RDF in accordance with the WebAccessControl specification.
   1. Access assertions to be implemented are 
      1. READ -> GET a resource
      2. WRITE -> PUT/POST/PATCH/DELETE a resource
      3. APPEND -> PATCH a resource, restricted to Insert statements only.
   2. as well as extending for:
      1. DELETE -> DELETE a resource
      2. UPDATE -> PUT/POST a resource
   3. The implementation assumes an ACL is it's own ACL, therefore CONTROL will not be implemented at this time.
   4. Optional extensions (ie. regex matching) will not be implemented in Phase 1.
2. F4 MUST be able to enforce authorization based on WebAC when a resource is requested via the REST-API
3. F4 MUST allow authorization policies to apply to a group of resources which consists of:
   1. Resources sharing a rdf:type attribute matching an acl:accessToClass rule in an ACL in the preconfigured location.
   2. Resources (without their own specific policy) share the policy of their container (defined by as the resource which ldp:contains the target).
4. F4 MUST honor the most permissive authorization policy when multiple policies apply to a request.
   1. See the section Finding the effective policy set, for more clarity.
5. F4 MUST provide a way for external services such as Solr to enforce the authorization rules defined in the repository.
   
   1. Would one method of achieving this be to create separate solr cores for public users vs. admin users and publish only the public resources to the former and everything to the latter, or does the use case dictate more granular distinctions?

...