| [higgins-dev] Re: Original vs. Revised Access Control Policy Proposals |
<snip>
Paul,
In the old model, we probably could have said that the <operation> was a multi-valued attribute such that one could express: "john has read and modify access to mary's hatsize attribute" We can still do that with the new proposal, but there will be a bit more data "john has read access to mary's hatsize attribute and modify access to mary's hatsize attribute". Also note that the new proposal could (if operation is indeed multi-valued) allow a statement like: "john has read access to mary's hatsize attribute and write access to bill's phoneNumber attribute"
>> All true. I’m still provisionally thinking the revised proposal is better. We’ll see how it fares after we apply it to the use cases.
For a given policy statement, what should the cardinality of the subject, and resource (or now operation) parts be?
>> I’d say 1..N for both.
A lot of the systems I'm used to present access control statements in terms of: 1 subject, 1 resource, and N operations. Not saying that's the best or right way to do it, it's just what I'm used to seeing.
>> My reasoning behind allowing N>1 on both the resource and the subject sides was to simply limit the number of Policy Entities. The idea of lots of “subjects” being parties to a single Policy instance makes sense to me. And the idea of a single policy applying potentially to lots of “resource” Entities also makes sense.
<probably an aside> Sometimes the resource implies a collection of sub-resources when there is some kind of explicit hierarchy in the system (which there is in the HDM, what with contexts holding entities, entities holding attrs, attrs holding vals holding perhaps more attrs, etc.) Will we say that "joe has read access to mary's entity" implies read access to all of mary's attributes?
>> I need to publish the HOWL 1.1.103 that I’ve already created. In the “comments” for each new attribute (e.g. higgins:read, etc.) I’ve started to flesh this out. If the higgins:read attribute’s value is the UDI of an Entity, then ALL attributes of the Entity are readable by the subject. If the higgins:read attribute’s value is an Attribute UDI, then it applies only to this attribute.
>> On the call today, David suggested that we could/should also transitively apply the same policy to what you’re calling above “sub-resources”. I’m thinking that we should create a “higgins:part” (and its inverse “higgins:partOf”) attribute and that Policies should apply to all Entities reached following higgins:part links. This is analogous to the transitivity of the “higgins:member” and “higgins:memberOf” attributes on the “subject” side of the fence that we talked about today.
Jim