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] Groups - xacml-3.0-combalgs-v1.0-wd02.doc uploaded



Hi Erik,

I have some comments on the Additional Combining Algorithms draft.

In the pseudo-code in section 2.1, the last four "if" statements, i.e.:

  if (decision1 == Indeterminate{P}) {
    // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
    return Indeterminate{P};
  }
  if (decision1 == Indeterminate{D}) {
    // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
    return Indeterminate{D};
  }
  if (decision1 == Indeterminate{DP}) {
    // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
    return Indeterminate{DP};
  }
  if (decision1 == NotApplicable) {
    return NotApplicable;
  }

can be simplified to this:

  if (decision1 == NotApplicable) {
    return NotApplicable;
  }
  // Use status code urn:oasis:names:tc:xacml:1.0:status:processing-error
  return decision1;

I'm not so sure the pseudo-code should be specifying the status code to return.
If the first policy evaluates to indeterminate because of a missing attribute,
then it would be very useful for that to carry through rather than being
overturned by this combining rule.

As currently specified, the on-permit-apply-second combining rule is treating
a Deny decision from the first policy as equivalent to Indeterminate. Policy
writers would have more flexibility in how they structure the first policy if
Deny (and Indeterminate{D}) were treated the same as NotApplicable, i.e., that
the "condition" is not satisfied. For example, the first policy could contain
a Deny rule with a positive target instead of an equivalent "not" expression
in a condition in a Permit rule.

Section 2.2 describes this refactored policy:

    PolicySet X [on-permit-apply-second]
      Policy Y
        Rule Z [Permit]
          Condition A
      Policy A:
        Target A
        Rules of A...

which is not equivalent to the ideal policy because it puts the condition
evaluation before the target evaluation. It should be this:

    PolicySet X [on-permit-apply-second]
      Target A
      Policy Y
        Rule Z [Permit]
          Condition A
      Policy A:
        Rules of A...

This arrangement is more faithful to the ideal, as well as being more efficient,
and more appropriate if, for example, PolicySet X were contained in a policy set
using the only-one-applicable combining rule.

By the way, I won't be on the conference call to discuss this because it starts
at 3:00 AM my time.

Regards,
Steven


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