Time/Place

  • Time: 3:00pm Eastern Daylight Time US (UTC-4)
  • Call-in: 

Attendees

Agenda

  1. Review WebAC fundamentals
  2. 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. 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
  3. Reconfirm commitments
  4. Schedule initial two sprints
  5. Address questions (can also happen offline)
    1. ACL resource is its own ACL?
    2. 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
    3. How should conflicting policies be handled? e.g...
      1. (userA=WRITE, public=READ) => result of WRITE request from userA?
      2. (userA=READ, groupB=WRITE) => result of WRITE request from userA, assuming userA is member of groupB?
  6. 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

Related Documents

Minutes

  • WebAC Spec
    • What is the agent/agent class being authorized?
    • What is that agent being authorized against?
      • Specific resource or class of resources
      • RDF type
    • What mode is the agent in with respect to the resource
      • Read, Write, Append, Control
    • Web IDs
      • Not going to implement this
      • Probably not using URIs for agents at least at first
    • W3C LDP working group is working on access control requirements
      • Nothing here looks very divergent from what we’re talking about
  • MVP
    • Minimum set of initial requirements
    • Question: How can we allow a user to have read/write access to anything they themselves create
      • By default, after creating a resource, its creator has read/write access to that resource
      • This might not be desirable in all cases
    • Does every resource get a default ACL on creation?
      • Or should the resource inherit whatever ACL is determined by the algorithm?
      • General agreement that a default ACL can be created that defines owners permissions for objects they create
    • How do we define an owner?
      • Ontology includes namespace acl:owner
      • The owner may or may not be the creator
      • Do all resources have an owner? Do we need a default owner?
      • The concept of an owner is not necessary for the MVP (based on feedback from those on the call - please let us know if you disagree)
    • Do we need a separate permission for deleting a resource?
      • Currently this falls under Write permission
      • There is a use case for allowing a user to edit a resource without deleting it
        • Islandora and Hydra have these use cases
      • This would be a divergence from the spec
        • Delete and Update would be subclasses of Write
    • What is the class of an agent?
      • Does this map to a group?
      • For Islandora: Drupal role
      • URI to a list of agents in a particular class
        • Appealing but may not be practical initially
  • Scheduling sprints (tentative)
    • Aug. 24
    • Sept. 28
  • We will have another meeting at the same time next week
  • No labels