Time/Place
- Time: 3:00pm Eastern Daylight Time US (UTC-4)
- Call-in:
Attendees
Agenda
- Review WebAC fundamentals
- Establish minimum Phase1 scope/use-cases
- Allow admin agent to always have full access to resources and ACLs
- Allow admin agent to CRUD ACLs
- Allow admin agent to assign ACLs to resources
- Allow a specific agent to READ a resource
- Allow a specific agent to READ and WRITE a resource
- Allow a specific agent to CREATE a resource, but not update it
- Allow a specific agent to assign an ACL
- Allow a class of agent to do the above (d - g)
- Allow a specific agent to do the above over a class of resources (d - g)
- Allow a class of agent to do the above over a class of resources (d - g)
- When access is denied return a 403 and a body (or link header) with cause
- Reconfirm commitments
- Schedule initial two sprints
- Address questions (can also happen offline)
- ACL resource is its own ACL?
- What is the algorithm for finding an ACL on a resource?
- if is ACL (rdf:type Authorization), use itself
- if incoming reference from ACL, use it
- else traverse up ldp:contains or pcdm:hasMember or custom? relationships
- How should conflicting policies be handled? e.g...
- (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?
- Discuss Phase2 scope/use-cases
- 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)
- Enforce authorization policy on a resource (or class of resources) based on that resource's association to a licenses (or tag)
- Enforce datetime sensitive authorization polices (i.e. embargos / leases)
- Allow authorization decisions based on nested ACLs (i.e. acl:include)
- Demonstrate pattern for enforcing the same authorization decisions as found in the repository in the context of Solr queries
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 there is a default ACL 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)
- We will have another meeting at the same time next week