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

[Daniel Engovatov <daniel@streamdynamics.com>]

> Hi Daniel,
>
> If you would care to elaborate on the use case of 'access to a   
> "PC" is governed by rules applied to both "DEPT" and "FACILITIES"  
> ', I would be interested, however, with the info you have given, I  
> simply do not see a hierarchy represented there. I am truly  
> interested, because when I do not understand something, I generally  
> assume that there is information of which I am not yet fully  
> cognizant, as was the case when Erik responded with his example  
> that showed usage of the ancestors capability.
>


This is the most basic example that is the whole idea of the  
profile.    What we are trying to achieve is to define a mechanism to  
write a rule that applies to a resource and all resources that are  
connected to it through "inheritance".

"PC" is a resource representing a PC.  "DEPT" is a resource  
representing a department.  "FACILITIES" is a resource representing  
facilities.    When I define an attribute of the "PC" resource that  
lists {"PC", "DEPT", "FACILITIES"} I implicitly define a hierarchy  
that make rule written on "DEPT" and "FACILITIES" to apply.   It does  
not matter what is the exact structure of that graph: "PC" may have  
two "parents", or "DEPT" may be part of "FACILITIES".   The only  
thing of concern is how to collect a bag of applicable rules.

The whole point here is that you do not want to and do not need to  
concoct any hierarchical naming scheme or to restrict it to any  
particular structure.

> My experience with hierarchies includes the following as a common  
> use case:
> A manager conceptualizes a project, large as a whole company or  
> govt or small as a simple team leader scoped project, and creates a  
> hierarchical structure within which resources: people, equipment,  
> facilities, etc. are deployed. As such, for one example, the  
> manager creates a hierarchical org chart of the people in the  
> project and defines responsibilities etc wrt to that org chart.  
> When the project commences, individuals are assigned their places  
> within the hierarchy and they have the hierarchical identifier  
> added to their identity properties. Such is the case with the /a*/ 
> b*/c* that I used in my example. "r5" was the serial number on the  
> PC that doesn't change, however, the hierarchies that PC  
> participates in will generally vary over time, which is reflected  
> by the identifiers from the various org structures that it is  
> assigned.
> One additional realization that has occurred to me after last  
> night's email is that when resources are assigned URIs for the  
> purpose of being within a particular organization, that set of URIs  
> satisfies the requirements of the algorithms ("corrected" or not)  
> in section 3.2. This is because, as I pointed out, without being  
> fully cognizant of the implications at that point, the URI, itself,  
> implicitly contains the normative identity of "self", "parent", and  
> all "ancestors" by nature of its construction.
>


Yes, but such a scheme is a subset of the profile, and there is no  
need to add it.   It will only confuse the users.      We do not want  
to imply that there is any tree behind it, so even using the "/"  
notation to represent a hierarchy is confusing.

We are not in the business of defining enterprise resource  
ontologies.   We are just providing a generic mechanism to map them  
into access control policy inheritance.

Current "ancestors" profile is definitely not the only possible  
approach.   We may want to add a different profile, but I do not  
think we should overload the current one with unrelated concepts.

Daniel