I disagree with this assessment. I think it was important to separate the ability to explicitly handle errors from results. So effect and decision are distinct on purpose.
What we really need is a normative and portable way to define and exchange combining policies.
Daniel.
-----Original Message-----
From: "Rich.Levinson" <>
Date: Sun, 26 Oct 2008 04:25:31
To: Erik Rissanen<>
Cc: XACML TC<>
Subject: Re: [xacml] Combining algorithm combining orders
Hi All,
While there are probably some details in the previous email that need to
be cleaned up, I think that it identifies a basic problem that needs to
be addressed.
As indicated, Erik came up with a single rule policy where the rule had
an effect of permit, and yet the policy that wrapped it effectively
produced a deny at a higher level.
I believe the root cause of this problem is that the concept of
"Effect", and its implementation in the current XACML specs is
fundamentally flawed and needs to be addressed.
Again, with Erik's use case, the flaw is obvious: a Rule with an Effect
of Permit results in a Policy that causes a Deny. The flaw is that the
concept of Effect is not handled properly. "Effect" effectively means
that the block of logic contained within this element can ONLY produce
either a Deny or a Permit, but not both. On the other hand, because a
Policy does not have an Effect, it implicitly can produce either a Deny
or a Permit. Therefore, to preserve the notion of "Effect", we have to
include it also at the Policy level, with the following constraints: The
Effect of a Policy must equal the "AND" of the Effects of all of its
Rules. Therefore if a Policy has only Rules that are Permits, then the
Effect of the Policy is Permit. If the Policy has Rules with both a
Permit and Deny, then the Policy effectively has no "Effect" because the
meaning of "Effect" is that only one type of decision is possible, and
now the Policy can produce two types of decisions.
Therefore, I think my basic conclusions in prev email are correct about
converging Policy and Rule into a single element - i.e. the only thing
that distinguishes the Rule and single Rule Policy is the fact that the
Rule has an Effect and the Policy doesn't, which has been shown above to
be wrong and correctable by giving the Policy an Effect attribute, which
effectively removes the distinction between Policy and Rule.
Comments and suggestions will be much appreciated.
Thanks,
Rich
Rich.Levinson wrote:
