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

[Daniel Engovatov <daniel@streamdynamics.com>]

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