1.1 Work Item: Ordered versions of combining algorithms

[Anne Anderson <Anne.Anderson@Sun.com>]

Submitted by Anne Anderson and Seth Proctor.

The TC voted this week to drop the XACML 1.1 Work Item titled
"Deterministic algorithm for combining obligations" because the
original sponsor did not submit a proposal.  There has been
interest in deterministic algorithms for reasons going beyond
obligations, so we are now submitting a new proposal.  The TC
suggested that such a proposal would not be considered "too late"
if submitted prior to the 12 June 2003 TC meeting.

Problem
=======

Often policy writers do not care in which order policies and
rules are evaluated, and so may be willing to allow a PDP to
perform optimizations that require out-of-order evaluation (based
on cached evaluations, network reachability, etc.).  A compelling
use case is where a hospital emergency room references two
policies, either of which is sufficient to return "permit".  The
first policy says use defibrilator if next-of-kin has authorized;
the second policy says use defibrilator if this is
life-threatening heart attack.  If the next-of-kin policy is
unavailable for some reason, do we want to return "Indeterminate"
or see if the second policy is available?  Our current combining
algorithms are appropriate for this set of expectations.

In most cases, however, policy writers will assume their policies
are being evaluated in order, especially since existing
implementations that we know of do so.  If an implementation is
later optimized to use cached policy evaluations (for example),
the policy writer will wonder why their policies are now working
differently.  Policy writers may also care strongly about order.
There may be side effects of policy evaluation (such as
obligations).  There may be Policies or Rules that the
administrator knows are better to evaluate first that the PDP
might otherwise try to optimize around.  There may be reasons why
an unavailable policy should force an "Indeterminate" result.
Policy writers may want to be able to test their policies and
know they will be evaluated in the same way they were tested.  We
do not have combining algorithms to meet these requirements.

The solution is to define ordered versions of our existing
combining algorithms.  Since existing implementations probably do
not optimize order anyway, the new algorithms can probably be
implemented using existing code.  Note that several users of
Sun's Open Source XACML implementation have requested ordered
evaluation of rules and policies, so this is not a theoretical
use case.

Detailed Proposal
=================

Section 2.3: non-normative change

line 403: change to

  Deny-overrides (Ordered and Unordered),

line 404: change to

  Permit-overrides (Ordered and Unordered),


Section 10.2.3: add four Mandatory URNs to the Algorithm table

  urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-deny-overrides
  urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-deny-overrides
  urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-permit-overrides
  urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-permit-overrides


Section B.10: add four algorithm descriptions

  The ordered-deny-overrides rule-combining algorithm has the following
  value for ruleCombiningAlgId:

    urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-deny-overrides

  The ordered-deny-overrides policy-combining algorithm has the following
  value for policyCombiningAlgId:

    urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-deny-overrides

  The ordered-permit-overrides rule-combining algorithm has the following
  value for ruleCombiningAlgId:

    urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-permit-overrides

  The ordered-permit-overrides policy-combining algorithm has the following
  value for policyCombiningAlgId:

    urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-permit-overrides


Section C: add two new sub-sections to define the new algorithms

After section C.1 add a new section called "Ordered-deny-overrides" with
the following text

  The Following specification defines the "Ordered-deny-overrides"
  rule-combining algorithm of a policy.

    The behavior of this algorithm is identical to that of the
    Deny-overrides rule-combining algorithm with one exception. The
    order in which the collection of rules is evaluated SHALL match
    the order as listed in the policy.
  
  The Following specification defines the "Ordered-deny-overrides"
  policy-combining algorithm of a policy set.

    The behavior of this algorithm is identical to that of the
    Deny-overrides policy-combining algorithm with one exception. The
    order in which the collection of policies is evaluated SHALL match
    the order as listed in the policy set.

After section C.2 add a new section called "Ordered-permit-overrides"
with the following text

  The Following specification defines the "Ordered-permit-overrides"
  rule-combining algorithm of a policy.

    The behavior of this algorithm is identical to that of the
    Permit-overrides rule-combining algorithm with one exception. The
    order in which the collection of rules is evaluated SHALL match
    the order as listed in the policy.
  
  The Following specification defines the "Ordered-permit-overrides"
  policy-combining algorithm of a policy set.

    The behavior of this algorithm is identical to that of the
    Permit-overrides policy-combining algorithm with one exception. The
    order in which the collection of policies is evaluated SHALL match
    the order as listed in the policy set.

Seth Proctor <Seth.Proctor@sun.com>

Anne Anderson
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692