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

[Daniel Engovatov <daniel@streamdynamics.com>]

>
> However, I do not understand precisely what you are recommending:
> I do not understand how {"PC", "DEPT", "FACILITIES"} relates to the  
> scenario I have described. I have specific PCs, in the example they  
> have serial numbers r5, r6. One of these PCs, r5, is identified in  
> the "dept" as /a1/b1/c1. In the facilities org the same pc is  
> identified as /a2/b2/c2.
No, PC is identified by "r5".   The fact that a PC is governed by a  
policy of the "dept" does not change that fact.   The only purpose of  
hierarchy is to determine an applicable set of rules for a particular  
evaluation.   That is it.  Constructing a hierarchical identifier is  
beyond the scope of that task.

So in my example access to a  "PC" is governed by rules applied to  
both "DEPT" and "FACILITIES".   Very simple.


>>> It is also uniquely defined by a URI if a URI scheme has been  
>>> applied to the same resources, since all the ance
> URIs do not represent bags of strings. Possibly one might choose to  
> represent a URI as a bag of strings, however, one loses the  
> ordering in the process. If one wants to identify the specific set  
> of nodes represented by a URI, it is a simple matter to  
> sequentially strip one component at a time off the URI, and at each  
> step one has the normative identity of the next node up the chain  
> until one reaches the root.
>>

For the purposes of defining a hierarchical policy in this model all  
you need is a bag of strings.   Using URI for that is not needed.    
Use cases that can be represented that way are a subset of use cases  
that can be represented wit "ancestors" approach.  Ordering is not  
important in this model, just like for the rest of our rules.


> At this point I fail to understand the purpose of specifically not  
> using a hierarchical naming scheme in order to identify a set of  
> resources that will be managed as a hierarchy. I understand that  
> there may be cases where for some reason it may not be possible or  
> practical to use such a naming scheme, but in those cases where it  
> is possible and practical, I do not understand why it would not be  
> a good idea to use it.
>

The purpose is that a hierarchical naming scheme is not generic  
enough.   For those cases when it is possible, it is still easier to  
use, as it does not require one to introduce a superfluous naming  
scheme and preserves the ability to change the structure of the  
inheritance graph if needed.


Daniel;