CMIS access control: some ideas on how to move forward

[David Pitfield <david.pitfield@oracle.com>]

On today's CMIS TC call, I suggested a tiered scoping for access 
control.  I wanted to re-state the idea (for those not on the call) and 
explain how this might help move the discussion forward.

The basic idea is to provide the TC some options for trimming the scope 
of access control in CMIS v1.  We could either specify:

(a) just enough to satisfy the unified search use case ("who can read 
what?"),
(b) access control reporting ("who can do what?"), or
(c) access control management

So far, we've been tackling all three.  Perhaps, for CMIS v1, we should 
focus on (a) and (b), or even just (a).  If we trimmed scope, we might 
be able to defer to CMIS v2 some of the tricky issues we've been 
discussing (for example, policies versus dependent objects, ACL sharing 
and inheritance).

If we tackled just (a), we could take a "one-of" approach for unified 
search.  We wouldn't need to specify a complete privilege model, and 
could just focus on *whether* a user could read a document (versus *how* 
they obtained that privilege, avoiding issues like ACL 
sharing/inheritance, "standard" versus "custom" privileges, and 
groups/roles).

If we tackled (a) and (b), we'd need a privilege model and ACEs, but 
still wouldn't need to specify ACL sharing/inheritance.  (For reporting 
purposes, it might be sufficient to report *which* privileges a user 
has, and not report *how* they obtained those privileges.)  Since we 
wouldn't be tackling access control management, we wouldn't need to 
decide whether this would happen through policies, and could therefore 
remove policies for now.

Going from (b) to (c) is difficult.  For access control management, we 
need to address not only *whether* a user has certain privileges (or 
*which* privileges they have), but also *how* they got those 
privileges.  This forces us to resolve whether ACLs can be shared or 
inherited, and whether access control is managed through policies.

(A consequence of deferring (c) is that, ultimately, ACL-based access 
control management may use different interfaces than general access 
control reporting.  That's ok with me.  For managing access control, we 
may ultimately need multiple mechanisms, such as non-shared ACLs, policy 
based ACLs, RBAC, and named policies.  Regardless of which management 
model a repository supports, there would be a common reporting model.)

Based on the discussions to date, my sense is considerable dialog and 
iteration remains before reaching consensus on (c) access control 
management.  So I suggest CMIS v1 focus only on (a), or possibly (a) and 
(b).

Regards.
dbp