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: decision combining algorithm: EntireHierarchy or arbitrary resource list


Can anyone produce a use case that requires the decision-combining
algorithm (and implied business scenario) described in MR profile
section 3?

By "implied business scenario" I mean something like this:
	1. Policy writer creates individual rules for resources without
any concern for the hierarchical context in which those resources might
appear.
	2. Client application sends a hierarchical resource and asks PDP
for a decision that boils down to "are all of these permitted", or "are
any of these denied".

The hierarchical nature of the resource is irrelevant in this
scenario--the "resource" could just as well be a bag of unrelated
resources.

Now, if the rules depend on the hierarchical relationships within the
resource, it is a different matter.  But in that case the ruleset itself
is able to issue a single decision based on hierarchical characteristics
of the resource, considered as a whole.  There is no need to break the
resource into individual pieces, make a decision on each one, and
combine them to issue a single decision.

I ask this because we should establish the need for this feature before
considering whether and how to extend it to include other groups of
individual resources (e.g., Children, or arbitrary xpath node
selections).

It is an interesting question, but in an abstract sense that is pretty
far removed from core XACML use cases.  In full generality, the proposal
is to enable the request context to ask that the PDP make a number of
individual decisions on a specified set of resources (why not actions,
subjects as well?), and then combine the decisions by some predictable
algorithm, and return a single decision.

But to address the practical use case that Jan is proposing, I do not
believe this is the right approach.

Regards,
--Paul


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