Re: [xacml] wd-19 indeterminate policy target handling

[rich levinson <rich.levinson@oracle.com>]

Hi Erik,

The algorithm w proposed changes in my earlier email in "first draft form" was this:

Decision denyOverridesRuleCombiningAlgorithm(Node[] nodes) {  // see 1 below
    Boolean atLeastOneError = false;
    Boolean atLeastOneErrorD = false;
    Boolean atLeastOneErrorP = false;
    Boolean atLeastOneErrorDP = false;
    Boolean atLeastOnePermit = false;
    for ( i=0; i<lengthOf(nodes); i++  ) {
        Decision decision = evaluate(nodes[i]);   // see #2 below
        if (decision==Deny) {
            return Deny;        // loop breakout (#2 below)
        }
        // the next two "if"s are the same as C.10:
        if (decision==Permit) {
            atLeastOnePermit = true;
            continue; // i.e. skip the rest of the logic current iteration of loop
                              // and start next iteration
        }
        if (decision==NotApplicable) {
            continue;
        }
        // see #3 below
        if (decision==Indeterminate) { // this can only be returned for rules
            if ( effect((Rule)nodes[i])==Deny) ) { // cast to Rule to get effect
                atLeastOneErrorD = true;
            }
            else {
                atLeastOneErrorP = true;
            }
            continue;
        }
        // the following is same as C.2 and will evaluate the 3 types
        // of Indeterminate, which can only be returned for Policy and PolicySet
        ... same as lines 5762->5776 (not repeated here)
    } // end for loop
    if (atLeastOneErrorD==true &&
          (atLeastOneErrorP==true || atLeastOnePermit==true) {
        atLeastOneErrorDP = true;
    }
    if (atLeastOneErrorDP==true) {
        return Indeterminate(DP);
    if (atLeastOneErrorD==true) {
        return Indeterminate(D);
    }
    if (atLeastOnePermit==true) {
        return Permit;
    }
    if (atLeastOneErrorP == true) {
        return Indeterminate(P);
    }
    return NotApplicable;
} // end algorithm

It is intended to produce the same results in every case as the current algorithm.
The differences that it embodies (that do not impact the final results) are:

1. it uses "nodes" as input rather than decisions, where a "node" can be
   any of: {Rule, Policy, PolicySet}
2. it preserves the original logic from 2.0 that shows the evaluate done in each
   iteration, which enables the loop breakout as soon as a certain final result
   is obtained (i.e. the explicit "biased" decision type of the algorithm
3. it preserves(and makes explicit) the logic whereby the D or P status of
   Indeterminate is established
4. It should reduce to the 2.0 algorithms when the "constraints" that were
   implicit in 2.0 are applied (i.e. that the property does not apply to policy)
   

I think it needs one more pass to get the syntax of the Indeterminates consistent
w the current defns in the doc, but otherwise I am pretty sure it does the same
as the current. (I will try to clean it up a bit, later today  but I am bust until then)

    Thanks,
    Rich


On 5/18/2011 4:01 AM, Erik Rissanen wrote:

4DD37CEB.9000706@axiomatics.com" type="cite">Rich,

Does the algorithm with your proposed changes lead to a different result in any case than the algorithm which is in WD-19?

Best regards,
Erik


On 2011-05-17 15:36, rich levinson wrote:

This is not a performance issue. It is a change from XACML 2.0 that implies
that the combining algorithm has as input a set of decisions as opposed to 2.0
where the combining algorithm had as input a set of Rules, Policies, or PolicySets,
that had yet to be evaluated.

The change implies that the algorithm is working on a different state, which is not
the case.

    Thanks,
    Rich


On 5/17/2011 5:07 AM, remon.sinnema@emc.com wrote:

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Tuesday, May 17, 2011 9:35 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] wd-19 indeterminate policy target handling

The spec should strive for the simplest possible explanation of the behavior, not the most efficient implementation.

+1 We can leave it up to vendors to come up with some nice performance tricks.

Thanks,
Ray



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php