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

[Daniel Engovatov <daniel@streamdynamics.com>]

On Feb 19, 2009, at 8:03 PM, Rich.Levinson wrote:

> Hi Erik,
>
> A few points I'd like you to consider with respect to your first  
> point:
> I am not sure why you have chosen to refer the URI scheme as the  
> "limited URI scheme", because as I showed in previous emails, it  
> appears that the URI scheme is, in fact, more general than what you  
> refer to as the "more general approach advocated by Daniel". The  
> reasons for this are quite simple. First, the URI scheme is  
> functionally equivalent and more efficient as can be easily seen as  
> follows:

I do not think you have shown it.

>
> in the ancestor scheme, as I understand it, we might have a node,  
> "a", which is a normative identity for a particular node, and it  
> might have 2 ancestors, a parent, "b", and ancestor "c".
> Presumably, if a request to access "a" comes in, the CH will have  
> to gather the ancestors. This means the CH must have some means of  
> finding out that "b" and "c" are the ancestors of "a". Since this  
> information is not included in the node name of "a", the CH must  
> look elsewhere.

You do not need to gather ancestors.  They are included in the  
attribute.  You need to gather applicable rules.   Rules have a  
specified target.

> in the URI scheme, I would name my "a" node as "/c/b/a" using the  
> same strings as above. In the URI scheme, a request for "a" would  
> come in as "/c/b/a". In this case, the CH is done, it doesn't have  
> to go looking for ancestors for 2 reasons: 1. because it doesn't  
> need them, 2. even if it did need them, they are already there.

I do not understand what "looking up ancestor" you are talking  
about.    One need to look up rules.

>
>
> The reason why the URI scheme is more general is a bit subtle, but  
> still should be straight-forward to understand. The subtlety is  
> that when presented from an inverted perspective, it might at first  
> appear that the ancestor scheme is more general, but a few quick  
> points should explain why that is not the case:
> Sticking with the same use case as above as a starting point, let  
> us consider the case where "b" has 2 parent nodes "c" and "d". I  
> don't believe there are many people who would argue that this  
> structure is still a hierarchy, however a rational case could be  
> made that it is actually 2 hierarchies, one headed by "c" and one  
> headed by "d". In this case "b" would be a member of 2 hierarchies.

I do not see anything "rational" in this case, and I do not see any  
reason why it could be made.  The rest of the argument is based on  
this flawed straw-men assumption.

Daniel;