| Re: [higgins-dev] Re: Original vs. Revised Access Control PolicyProposals |
I respond at the end to the last points in this Paul/Jim thread, but I’m leaving the full thread intact as the context is relevant.
Jim wrote:
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"
Paul wrote:
>> 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.
Jim wrote:
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.
Jim wrote:
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.
Paul wrote:
>> 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.
Jim wrote:
<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?
Paul wrote:
>> 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.
=Drummond writes:
There is a direct parallel to the XDI RDF graph model here. In the grammar of that model, one XRI -- $has – is used to express aggregation relationships, i.e, the XDI statement =a/$has/+b says that entity =a aggregates entity +b. The inverse predicate is $a$has, i.e., +b/$a$has/=a asserts that +b is aggregated by =a.
So even though there could be many arcs expressing different relationships between entities =a and +b, from the standpoint of hierarchical access control, an XDI agent enforcing link contract policies only has to look for a $has relationship.
This leads me to a suggestion: in the XDI RDF graph model, aggregation is aggregation no matter where it happens in the graph. In other words, aggregation relationships between people (such as the relationship between an entity representing a group and an entity representing a member of the group), and aggregation relationships between data (such as the relationship between an entity representing a business card and an entity representing a postal address on that business card) are both expressed using $has predicates.
To keep policy enforcement simple and universal, wouldn’t the Higgins model want to do the same thing, i.e., establish one Higgins predicate that – from the standpoint of policy enforcement -- means aggregation no matter what type of entity is being aggregated?
Here’s my rationale: take the same Higgins entity representing a group that is a _subject_ of a Policy in Paul’s example above, and therefore would have has “member/memberOf” relationships to the set of entities representing its members. Now turn it around and make that group the _object_ of another policy that permits access to the some of the contact data of the group’s members.
You wouldn’t want to have to suddenly create “part/partOf” relationships between the group and its members just because they are now the object of a policy when the “member/memberOf” relationships already express the same thing.
Net net: you can always add other arcs predicates to express specific types of relationships between entities. But having one predicate that expresses the pure concept of aggregation will simplify the job of policy enforcement everywhere.
=Drummond