[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
> > 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;
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]