...

• David Wilcox
• Andrew Woods
• Nick Ruest
• Joshua Westgard
• Stefano Cossu
• Ben Wallberg
• Peter Eichman
• Karen Estlund

Agenda

• Unknown User (acoburn)
• Jared Whiklo

Agenda

1. Collect stakeholder feedback on Sprint 1
2. Review
3. Review WebAC fundamentals
4. Establish minimum Phase1 scope/use-cases
   1. Allow admin agent to always have full access to resources and ACLs
   2. Allow admin agent to CRUD ACLs
   3. Allow admin agent to assign ACLs to resources
   4. Allow a specific agent to READ a resource
   5. Allow a specific agent to READ and WRITE a resource
   6. Allow a specific agent to CREATE a resource, but not update it
   7. Allow a specific agent to assign an ACL
   8. START HERE — Allow a class of agent to do the above (d - g)
   9. Allow a specific agent to do the above over a class of resources (d - g)
   10. Allow a class of agent to do the above over a class of resources (d - g)
   11. When access is denied return a 403 and a body (or link header) with cause
5. Reconfirm commitments
6. Schedule initial two sprints
8. What Phase1 requirements must be addressed in Sprint2?
   1. Link header
   2. Remote ACLs
   3. ...
9. Schedule second sprintAddress questions (can also happen offline)
10. ACL resource is its own ACL?
11. What is the algorithm for finding an ACL on a resource?
    1. if is ACL (rdf:type Authorization), use itself
    2. if incoming reference from ACL, use it
    3. else traverse up ldp:contains or pcdm:hasMember or custom? relationships
How should conflicting policies be handled? e.g...
12. (userA=WRITE, public=READ) => result of WRITE request from userA?
(userA=READ, groupB=WRITE) => result of WRITE request from userA, assuming userA is member of groupB?
13. Discuss Phase2 scope/use-cases
    1. Allow a request from a specific I.P. address (or range?) to do the above for a resource and a class of resources (2.d - g)
    2. Enforce authorization policy on a resource (or class of resources) based on that resource's association to a licenses (or tag)
    3. Enforce datetime sensitive authorization polices (i.e. embargos / leases)
    4. Allow authorization decisions based on nested ACLs (i.e. acl:include)
    5. Demonstrate pattern for enforcing the same authorization decisions as found in the repository in the context of Solr queries

...

• https://www.w3.org/wiki/WebAccessControl
• https://github.com/duraspace/pcdm/wiki#webacl
• Authorization Delegates
• http://www.w3.org/ns/auth/acl

Minutes

Facilitate Stakeholder Verification

• Enable WebAC feature in fcrepo4-vagrant
• Script the creation of resources and ACLs that correspond to stakeholder use cases
  • Stakeholders should provide additional use cases/scenarios as needed to help round out the verification

Sprint 2 Items to address

1. Allow a specific agent to CREATE a resource, but not update it
2. Currently, ACL resources are protected like other repository resources. Add special protection for ACL resources
3. Implement "agent class" support:
   1. For agent classes that are found within the repository
   2. For agent classes that are found external to the repository (stretch, do stakeholders want this?)
   3. Allow repository admins to turn of "agent class" capability
4. Implement "remote ACLs", if stakeholders view it as a priority
5. Stretch goal: acl:include

Note: Since the WebAC "specification" does not have provisions for time-based authorization, the proposal is to move logic for policies such as leases or embargoes up into the application layer. Question for stakeholders, Is that reasonable?