This page will be used to design a WebAccessControl Authorization Delegate.

Guiding Principles

Any Fedora4 feature should be available through an API which is an implementation of LDP or an optional extension (ideally an existing standard)
Fedora4 features should favor existing tools over custom code
Fedora4 features should establish integration patterns where an implementation is not a part of the core code

Use Cases

Authorization enforced within F4 must also be enforceable by external services, such as Solr.
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

F4 MUST allow assertions about authorization to be modeled in RDF in accordance with the WebAccessControl specification
F4 MUST be able to enforce authorization based on WebAC when a resource is requested via the REST-API
F4 resources that are open for public read should not challenge the client to authenticate
F4 MUST allow authorization policies to apply to a group of resources
F4 MUST honor the most permissive authorization policy when multiple policies apply to a request

What are the exact behaviors associated with the following permissions?
1. READ
2. WRITE
3. Append
4. Control
Is there anything currently implemented within the Hydra WebAC implementation that strays from direct compatibility with the WebAC standard? In other words, are there currently barriers to the goal of cross-application compatibility?