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