...

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

Minutes

• Agent class
  • What makes sense for phase 1?
  • In spec, class of agent is a URL that points to a listing of user IDs
    • ACL has an agent class that points to this list of user IDs
    • Can this be any arbitrary URL that resolves to a list of users?
      • Must have a number of FOAF members (i.e. it returns a graph)
    • Lots of upsides to following the spec, but many existing services may not be able to use this functionality without some kind of middleware to translate the output to an RDF graph with appropriate properties
      • This could be a maintenance issue. We would probably need an API capable of translating between a variety of services
    • In order to constrain the scope of phase 1, this could be a stretch goal
      • If we go this route, we probably won’t support any notion of groups until we implement this as per the spec
      • It would not be good to implement a fall-back if we are only going to rip it out when we implement the agent class functionality as people may write code around it and come to rely on it
  • Could fall back to group notion
    • If a user belongs to a particular group, the ACL will permit access
• Class of resource
  • An agent can have permission to act on a class of resources
  • Any agent with the ability to update a particular resource will have the right to add that resource to a class or remove it from a class
  • This may need some clarification and further discussion but we can likely implement as per spec without significant risk
• Providing information to users
  • The spec recommends providing information to users when they are denied access that explains why they were denied and how they can gain access
  • We already have some examples of this in the existing authorization delegates
    • We can just return a 403
• Developer commitments
  • Peter, Mohamed, Jared, Aaron (?)
• Stakeholders
  • Josh, Stefano, Nick
• Sprints
  • Aug. 24
  • Sept. 28
• Protecting ACLs themselves
  • ACL resources are their own ACL (e.g. they do not reference another ACL for access control)
• Algorithm for finding ACLs on a resource
  • If resource isn’t an ACL or does not have an inbound reference from an ACL, traverse up the graph to find an ACL
    • In this case do we use the first ACL found or continue traversing until all relevant ACLs are found?
      • Continuing to traverse after the first ACL has performance implications
      • There is an acl:include extension that would allow admins to explicitly include more than one ACL
  • Proposal: Stop at first ACL in phase 1, support acl:includes in phase 2
• How to resolve conflicts
  • For a given user, first check to see if there is an ACL that references that user specifically. If there is, stop. If not, go to the policy that references the group the user belongs to
    • If the user has no specific policy and the user belongs to two groups with different policies, the most permissive combination of permissions should apply