< Return to Ballot details

Vote Details

Ballot: Access control proposal (summarized June 19th)
Company:
Microsoft
Vote:
Yes
Comment:
I approve, with the following comments:

1) We should really rationalize the terminology for the "controllabe" vs. "ACLControllable" properties on Object-Types. (E.g. I'd love to see us move to more descriptive terms like "securable" for ACLs).

2) I don't like the term "set type" as proposed here. I'm OK with the concept, but the term should describe what the effect of it is (as opposed to "set type", which is kind of meaningless). I'd suggest something like "inheritance".

3) How are we expecting repositories to indicate what "set types" they support? Minimally, a repository must be able to say they support only "repository-determined".

4) Why are we adding a new "getACLCapabilities" service, as opposed to just adding 2 enums to the existing repository capabilities? One for the enum for "none/discover/manage", and one for "SupportedSetTypes" (or whatever we rename it to).

5) Why does a "Principal" include a key-value pair property bag? I would think that all of these "principals" as used in this proposal are basically just references to the actual principals stored elesewhere in the system anyway. So I think it would just be simpler to say the following:
- ACEs, when set, include a PrincipalId, a Permission, and a Direct Flag.
- ACEs, when retrieved, will include a PrincipalId, a "Display Name" for the Principal, a Permission, and a Direct Flag... and the "Display Name" is returned purely for application convenience. (Or we could just omit it entirely).