Time/Place
- Time: 2:00pm Eastern Daylight Time US (UTC-4)
- Call-in: DuraSpace conference line
Attendees
Agenda
Related documents:
- Introduction and topic summary
- Establish common understanding of function of WedAccessControl Authorization Delegate
- Use-cases
- Compile initial requirements
- Workplan and timelines
- Development, testing and validation
- Next steps
- Summarize and Post use-cases and requirements
- Iterative meetings, as required
- Set deadline for feedback
- Create strawman design
- Set deadline for feedback
- Confirm commitments
- developer and stakeholders (verification)
- Schedule sprints
Minutes
Intro and topic summary
- Use cases for WebAC
- University of Maryland
- Some resources are public and some are not
- For public resources, users should not be challenged for authentication
- Probably not related to authorization but this can be a requirement for WebACL implementation
- Art Institute of Chicago solves this problem by using a public mirror of the repository
- Use properties other than rdf:type to make assertions about authorization
- Multiple applications connecting to Fedora and one authorization layer
- External applications should be able to enforce Fedora WebACLs
- Why do people want WebACL vs. another authorization scheme?
- Simpler/cleaner than XACML but not as granular
- Are there use cases in XACML that need to be represented in WebACL?
- How are multiple multiple policies on the same resource interpreted?
- This would be a matter of implementation
- WebAC permissions
- Read, Write, Append, Control
- Append may be analogous to PATCH, no DELETE allowed
- Use case: Dropbox functionality for adding resources but not editing/deleting them
- Use case: Allow users to add new objects to a collection without being able to delete the collection
- Users can edit/delete their own objects but not the collection
- Granularity
- Both containers and binaries should support WebAC
- Should WebAC also support restrictions on properties?
- Not currently supported in other authorization schemes.
- Not a requirement for initial implementation
- Authentication
- Fedora assumes that incoming requests have already been authenticated.
- Web IDs
- Agents/principals have URIs
- Currently principals only need to be represented by a string
- Shibboleth with provide URIs, other authentication systems likely will as well
- We should support both URIs and strings
Next steps
Commitments
- Use cases
- Development
- Testing and verification
Actions
- Collect use cases
- Post to community and ask for feedback
- Schedule another call if required
- Check with Hydra community regarding requirements
- Schedule implementation meeting
- Schedule development sprints