[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
On Jan 15, 2009, at 6:42 AM, Rich.Levinson wrote: > Hi Daniel, > > 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. > That is indeed an ambiguous usage of the term "forest", which is a disconnected acyclic graph. But I am not sure I understand your objection about the term "hierarhy". Definition of a hierarhy is " a graded or ranked series". So that implies that we introduce a partial order relation between resource nodes that implies inheritance of applicable policy statements. (if A => B, then rule applicable to A applies to B). This does not imply that we have to define this as a rooted tree. For example, we have three resources A, B, C and A=>C and B=>C, so C inherits policy from A and B. I think ambiguity may be corrected by removing reference to "forest" and changing "ordered set" to "partially ordered set" (as we do not require comparability for the inheritance relation). > 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? What I was trying to say is that we do express hierarchical relationship as an attribute on each resource X with value being a unordered set of nodes {Ai} for which Ai=>X is true. We suggest a way on how to write rule target so that it is applicable to a particular resource and its children. That does not mean that all rules in a a policy need to be written that way and it does not require that evaluation strategy be aware about any "hierarhies". Daniel
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]