Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Daniel,

Thanks for the feedback. Let me try to clarify a bit.
My first objective is to understand what the spec currently says, and I am finding that the terminology is inherently ambiguous, and as a result, to me at least, that makes the details of the spec impossible to understand. So, what I did was try to disambiguate by defining "hierarchy". Let me be more explicit:

Lines 73-77 state the following:

In this Profile, a resource organized as a hierarchy may be a “tree” (a hierarchy with a single root) or a “forest” (a hierarchy with multiple roots), but the hierarchy may not have cycles. Another term for these two types of hierarchy is “Directed Acyclic Graph” or “DAG”. All such resources are called hierarchical resources in this Profile. An XML document is always structured as a “tree”. Other types of hierarchical resources, such as files in a file system that supports links, may be structured as “forests”.

This is an inherently self-contradictory definition. A hierarchy has a single root. It is an "ordered set", where each entity in the set has a defined relationship to every other entity. A "forest" is not a hierarchy. It is multiple hierarchies. The "definition" above is not meaningful because it equates the singular and plural.

As a result of this self-contradiction, the spec then goes to introduce what, to me are meaningless concepts, such as lines 315-316:

Note that a node in a hierarchical resource that is not represented as an XML document MAY have multiple parents.

Therefore, in order to understand what the spec says, I first found it necessary to come up with an unambiguous term for "hierarchy", which allows sentences such as the above to be restated in a "meaningful" way, such as:

Note that a node in a hierarchical resource that is not represented as an XML document MAY belong to multiple hierarchies and have a parent associated with each one.

I am not saying anything so far is "wrong", simply that it is not understandable without firming up the definitions.

wrt to the "somehow identify all the hierarchies a node belongs to" comment, I was not saying it was a problem, but simply observing that that was what the spec was saying in terms of specific defn of the term "hierarchy".

Finally, I do not understand your comment that says:

Policy evaluation does not need to know anything about hierarchies that are represented with an "ancestor" attribute.

I am trying to understand what policies are supposed to do with the definitions in the spec. i.e. it is the spec that says in section 3.2 that all the parent and ancestor nodes need to be assembled in the request context. What "policy evaluation" are you referring to? Are you saying what I indicated in original email that a policy does not need to know anything about hierarchies that the resource-id node does not belong to?

    Thanks,
    Rich



Daniel Engovatov wrote:

1448A6CC-1532-40B4-BFC0-DC9D0413097E@streamdynamics.com" type="cite">
On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:

   * There needs to be a definition of "hierarchy". In particular, a
     "hierarchy" defn should state that the fundamental properties are
     that there must be a single root node with no parent, and that
     every other node in the hierarchy must have one and only one
     parent, and can have zero, one, or more children.

I am not sure why do you think this is a requirement.   It is a normal use case to inherit policy from more then one parent, and "ancestors" attribute approach allows such models without undue restrictions.

   in order to submit a request  one has to somehow identify all the hierarchies the given node
     belongs to, all the hierarchies the node's parent(s) and ancestors to, and include an Attribute element for each.

And why is that a problem?   Yes, if one wants "inheritance", graph needs to be defined, and attributes is a natural way to define it.

 I suspect that at most one would need to collect all the normative representations of only the resource-id node (i.e. identify all the hierarchies it belongs to), then for each hierarchy, one would evaluate the policies that apply to that hierarchy.

Policy evaluation does not need to know anything about hierarchies that are represented with an "ancestor" attribute.

Daniel;

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php