OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Based on this situation, my proposal is to enhance the existing Hierarchical spec using the URI representation in section 3.2 and indicating that this approach can be used instead of resource-parent and ancestor when the hierarchies are represented by nodes with URI resource-ids.

Using URI is a very limited approach, and it can be trivially mapped into "ancestor" approach.    Requiring a unique URI for resources is often not feasible

The following example will show why this is doubly and actually triply specified and also why it is essential that the changes described in 1-3 above are needed.

Consider 3 hierarchies:
  • /a1/b1/c1
  • /a2/b2/c2
  • /a3/b3/c3
Let's say that a1, a2, and a3 are distinct roots and represent 3 separate nodes (or resources) in the overall collection.

I think you are confusing physical resources and policy resources.    Such mapping is outside of XACML.    There is no real hierarchy in XACML, we just provide a convenient normative way to represent them - only for the purpose of using it in a policy target.

For the purpose of a single policy evaluation hierarchy that is used is uniquely defined by the provided "resource-ancestors" attribute.   The fact that there is some persistent identity that may participate in different hierarchies should be outside of the scope of this profile.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]