[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
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. 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. Therefore the augmentation of section 3.2 need be little more than to emphasize this now obvious fact. More specifically, in the case of multiple URIs as a result of belonging to multiple hierarchies, this fully models the general DAG case as well. i.e. given a single hierarchy (one root), it is obvious that a URI scheme can be used to apply identifiers to the members of that hierarchy. Furthermore, given a DAG, because the DAG can be transformed into a set of independent hierarchies, a separate URI scheme can be applied to each hierarchy there, and when transformed back into the DAG, the nodes that appear in multiple hierarchies will simply have multiple URIs and the problem is fully defined. Thanks, Rich Daniel Engovatov wrote: 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]