I still think that there is no compelling reason to redesign existing algorithms and that we should rather design a normative way to extend them in an interoperable way.
Daniel.
-----Original Message-----
From: "Rich.Levinson" <>
Date: Tue, 11 Nov 2008 19:27:54
To: Erik Rissanen<>
Cc: <>
Subject: Re: [xacml] Combining algorithms
Hi Erik,
Nice job putting together the combining algorithm sections. I agree with
most everything you supplied although I have not yet looked at all the
explicit details of each algorithm, but for the sake of discussion will
assume that they are correct and just focus on the details of the
extended algorithms.
First, the things I agree on are:
* Agree that we don't need to define biased algorithms. Might want
to comment on that and indicate that recommendation is to build
any bias directly into the policies, if needed.
* Might also want to mention that PEP bias is possible, but that it
can be removed by defining appropriate policies, especially at top
level. For example, if you want a Deny for all cases of errors and
indeterminate, a top level PolicySet w permit-overrides can
contain one policyset for all other policies which collectively
can return Permit, Deny, Indeterminate, NotApplicable, plus a
second policyset that has an automatic Deny Rule if the first
PolicySet did not return a Permit.
* Agree on change deny-overrides policy combining to unbiased as you
have included.
* Agree on change permit-overrides policy combining to unbiased, as
well, also, it is symmetric w deny-overrides.
On the extended algorithms, I think we have a disagreement as to the
potential value, and therefore I will try to point out the value that I
see there as the basis of why I think they should be included.
I'd like to initially point out that what we are dealing with here is a
pre-existing condition in the current set of combining algorithms that
neither Erik nor I were a party to creating in the first place. Erik's
proposal is to "fix" some aspects of the existing algorithms, and I
agree that those fixes are improvements to the current state. My
proposal has been to revisit whether, in fact, that separate policy and
rule combining algorithms actually add value or subtract value, when
compared to a single combining algorithm that applies to both
policy(set)s and rules.
First, I agree that the extended algorithms Erik has written appear to
be functionally equivalent to what I was recommending in the earlier
discussion on this topic:
http://lists.oasis-open.org/archives/xacml/200810/msg00053.html
(Note: I recommend changing the Indeterminate(DP) defn to be: "an
Indeterminate from a policy which could have evaluated to a Deny or
Permit." i.e. remove the "or rule" because a rule can either be a "D" or
a "P" but not both. This has no algorithmic impact but might be
conceptually useful when examining the algorithms, i.e. to know DP
applies to policies only. (In fact this brings out a key concept, namely
that policies, while inherently can be DP, depending on the contained
rules and their evaluations, can effectively be constrained to only "D"
or "P", which carries the character of the collection of applicable
rules that it contains.)
In particular, the 3 flavors of Indeterminate preserve the results as to
whether there was a possible override or not, which is lost in the
current "base" permit/deny-overrides algorithms that simply return
Indeterminate in the case where there is a potentialDeny or
potentialPermit flagged and do not distinguish the cases where those
potentials are not present.
In other words, it is obvious by inspection of the base
permit/deny-overrides algorithms, that Indeterminate in both algorithms
can be returned in 2 distinct cases, which causes you to lose track of
whether there was a potential deny in the deny-overrides case or a
potential permit in the permit-overrides case.
In fact, one could take the point of view that we are effectively
introducing the complexity of having two classes of combining algorithm
(policy and rule) in order to remove information that we are
presupposing will be of no value to any customer. i.e. the reason that
the policy-combining algorithms are simpler than the rule-combining is
that potentially useful decision making information is removed by the
rule combining algorithms after using only a portion of the information
that they have gone to the trouble to collect.
The net result is that there is a non-uniformity of containers for Rules
that adds conceptual complexity to the strategy of building PolicySets
with no obvious added value, but with subtracted decision-making
information.
For example, consider a deny-overrides Policy with 2 Permit Rules, RP1
and RP2, and 1 Deny Rule, RD3. If the Deny Rule, RD3, is NotApplicable
and one Permit Rule, RP2 is Indeterminate then if the remaining Rule,
RP1, evaluates to Permit, then the Policy evaluates to Permit.
Now split the Rules into 2 Policies, one with a Permit, RP2, and Deny,
RD3, and the other with one Permit RP1, and put the Policies in a
deny-overrides PolicySet. If the Deny Rule, RD3, again is NotApplicable
and the companion Permit Rule, RP2, is again Indeterminate then that
Policy will return Indeterminate. If the remaining Rule, RP1, in the
other Policy, again evaluates to Permit, then that Policy will evaluate
to Permit. Now the PolicySet, which contains the two Policies which
together contain the same three rules as the case above, and all the
Rules evaluate the same as above, then now this combined PolicySet
evaluates to Indeterminate, even though there was a valid Permit and no
applicable Deny.
Interesting, if you switch RP2 to be NotApplicable, and RD3 to be
Indeterminate, then both cases evaluate to Indeterminate.
The point is that by introducing a distinction between rule and policy
combining we end up with a non-intuitive structure where sometimes
behavior is consistent and sometimes not depending on the subtleties of
the whether the container is a container of Rules directly or a
container of containers of Rules.
Now my proposal is not to take away any of the above-mentioned behavior
from those who choose to use it, but to offer an alternative behavior
which is container-consistent, which will enable one to focus on
managing collections of Rules without worrying about whether the
structure of the containers might contain unexpected side-effects such
as described above.
The extended algorithms provide this container uniformity, while at the
same time not introducing new complexity, but simply by avoiding
removing potentially useful decision making information. With the
combined algorithms, for example, a top level deny-overrides PolicySet
will always know when it receives an Indeterminate, whether that
Indeterminate was a potential deny or not.
I believe the combination of retaining information that is lost from the
existing algorithms plus the conceptual improvement of having uniform
container algorithms is sufficient justification to include these
extended algorithms as valuable options that one can choose. No one will
have to use them under any circumstances, but I believe that there are
organizations that would value the conceptual simplification that the
extended algorithms offer from the perspective of getting consistent
behavior from the container structures.
Thanks,
Rich
Erik Rissanen wrote:
