...

1. A resource can be related to tags. Each tag is contained in a tag category: Conservation, Imaging, Licensing, etc. For tags related to a certain resource:
   1. Imaging users can read, create and delete tags in Imaging category 
   2. Imaging users can read tags in Conservation category
   3. Conservation users can read, create and delete tags in Conservation and Imaging categories
   • Note: F4 does not have "tags" per se. Are you envisioning a "tag" as a resource? or a property?
   • See comment below
2. Enforce ACLs on binary resources
3. Add support for external ACL resources (resources that point to an ACL that is outside the Fedora domain)
4. Add support for external agentClass graphs
5. Enforce ACLs on ACL resources with a filesystem-based backstop (at present, only the admin user can add/edit ACLs)
6. Verify header-based (delegated) authentication use cases
7. Add ACL URIs to response headers as Link: <acl-uri>; rel=meta
8. Implement acl:Control and acl:Append modes
9. Add support for inclusion of other acls via acl:include

Removed/Amended Use Cases

...

Proposed Requirements (Phase 1)

Sprint 1 (Phase I) Requirements

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.
      1. Note: sprint-1 implementation does not confine ACLs to reside in a "preconfigured location", but they can instead exist anywhere within the repository.
   2.  Resources (without their own specific policy) share the policy of their container (defined 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?
6.  Each request for a Web Resource returns an HTTP document containing a Link header (Link: <>; rel=acl) to an ACL resource which describes access to the given resource and potentially others.
7.  Servers are required to recognize the class foaf:Agent as the class of all agents (i.e. foaf:Agent is synonymous with "everyone")

Sprint 2 (Phase I) Requirements 

Must have

1. Enforce ACLs on ACL resources with filesystem-based backstop:

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1792

2. Implement acl:Control, acl:Append, acl:Update and acl:Delete modes: 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1794

3. F4 MUST provide a way for external services such as Solr to enforce the authorization rules defined in the repository: 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1795

       and 

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1802

4. Enforce ACLs on binary files: 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1791

5. More documentation: 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1239

   2. Jira
      server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1806

   3. Jira
      server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1791

6. Add support for agentClass graphs defined within F4: 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1793

7. Verify header-based (delegated) authentication is supported (where headers are used to define the effective agent, independent of any container-based AuthN): 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1790

8. Fix bug with versioned resources: 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1760

9. Make webac and audit default configuration in fcrepo-webapp-plus: 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1773

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1821

10. Bug fixes

    1. Jira
       server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1809

Nice to have

1. Add ACL uris to response headers as "Link: <acl-uri>; rel=acl": 

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1795

2. Support external ACLs (ACLs not managed by fedora)
3. Add support for agentClass graphs defined external to F4
4. Minor code cleanup: 

   1. Jira
      server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1807

Likely not

1. Support for inclusion of other ACLs via acl:include

Removed requirements

1. F4 resources that are open for public read should not challenge the client to authenticate
   1. What if a resource has no ACL? Should there be a default behavior? (for example allow all to admin user; deny all to non-admin?)
   2. This requirement specifies public *read*. Do we also want to allow a public write? While use cases for the latter are admittedly going to be rare, it would seem better not to be opinionated here if public write is what an implementer wants.

...