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

[Daniel Engovatov <daniel@streamdynamics.com>]

> For example, all the PCs in a company have serial numbers. When  
> managers create policies, they have the physical resources in mind  
> and may organize them hierarchically for various purposes. A  
> department manager may label the PCs in his/her dept according to  
> some hierarchical structure in the dept organization and assign  
> policies accordingly. At the same time these PCs are company  
> property and may be labeled independently by the IT dept in terms  
> of who is responsible for maintenance on them.
>
> If someone wants to take one of these PCs out of the building,  
> maybe there is a policy that says even if the employee's manager  
> says it is ok, the facilities manager must also approve before  
> permission is granted. This can be modeled with a dept hierarchy  
> and a facilities hierarchy, and there are rules within the  
> hierarchy producing a result and policy combining between the 2  
> hierarchies that can resolve conflicts such as described above.
>
> In the above example the /a1/b1/c1 might be the dept hierarchy and / 
> a2/b2/c2 might be the facilities hierarchy.

There is no need for separate hierarchies here if the "remove from  
building" is a single access decision.  In your example, let's "PC"  
be a resource, "DEPT" be a department, and "FACILITIES" be  
facilities.     In this case resource-ancestors will be {"PC",  
"DEPT", "FACILITIES"}    (or {"a1", "a2", "b1", "b2", "c"} )  There  
is no need for two hierarchies.   That is the advantage of not being  
pidgeonholed into a single inheritance URI-like scheme.

> It is also uniquely defined by a URI if a URI scheme has been  
> applied to the same resources, since all the ancestors are readily  
> identifiable within the URI.

That's a bit of a contorted way to represent a simple bag of strings.

>  Within the policies themselves, there would generally be no need  
> to include this attribute except possibly for reporting purposes.

Then what exactly is the problem?   Policy, as specified, can be  
evaluated deterministically.   The mapping of physical entities into  
policy resources is outside of the scope of this profile.   I do not  
see anything broken here.

Daniel;