1. CMIS ACL-PROPOSAL 26-28 Jan 2009

2.  Motivation: Scenarios  Policies: Recap  ACL Concept  Proposal: Discussion Topics

3. Scenarios Documents Development: No permissions used (might be passed through, but not interpreted) Runtime: Admin or enduser knows the permissions, assigned by a user to the documents End-User Collaboration Scenario CMIS Application CMIS Application permissions

4. Scenarios Documents Development: Usage of Permissions is being coded into the application Runtime: Application Background Tasks CMIS Application CMIS Application permissions mappings? permissions per- missions

5. Recap CMIS Objects

6. ACL Concept Policies

7. READ WRITE ALL Read All Delete FileWriteProperty ReadPolicy ReadContent UnfileWriteContent Write WritePolicy ReadProperty Version Permissions ACL Concept

8. Discussion Topics  Assumption: unified user base  no user discovery, no mapping (within the scope of CMIS) ok ?  Scenario: flexible mapping („level 1“) vs. known permissions („level 2“) ?  Permissions (Level 2): extended permissions required vs. Read/Write/All ?  Modelling of ACLs: Policies vs. Properties ? [if policies] entire ACL vs. individual ACEs as Policy ?  Format for ACLs: XACML vs. XML vs. other format ? format for principals (plain ID vs. type info + ID) ?  ACL Assignment: atomic action when creating an object vs. inheritance ?  ACL Inheritance: on create vs. create + lifetime ?

9. Revised proposal outline  GetACLs()  A collection of ACEs that are: (,, boolean isInherited)  DeleteACE() – or SET  MUST fail is ACE isInherited  AddACE() – or SET  MUST fail is object is not securable or repository does not support setting ACLs.  RepositoryInfo:  ACLSupportLevel: None, Get, Set  Object Type definition includes:  isSecurable  Note: This proposal models ACLs as separate from policies (likely as a service on objects)  Open questions:  Need to make sure that there’s a way to express that a system has ACLs per-container and not per-document.  Can we now delete Policies from the spec entirely?  Is the permission set extensible or fixed?  What rights do you need to get or set ACLs?  Can we leverage the XACML standard for this capability? (Seems like no, so far)  Need to make sure that we’re leveraging the knowledge/best practices?  Why do we think we’ll succeed with an ACL approach (vs. policies) when iECM/JCR have gone the other way?  Need to make sure that we’ve covered the basic collaborative cases (e.g. team sites, wikis, “my” content)…  Out-of-scope:  Repository offers no guarantee that the ACL list is complete (E.g. we won’t expose DENY rights, etc.)  There’s no explicit statement about how to compute effective permissions for a user from the ACL (e.g. how inheritance/precedence of ACLs works)