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] | [Elist Home]

Subject: [xacml] Reviewed os 1.0 Draft 3

I reviewed the os 1.0 Draft 3 against the errata, and everything
looks fine except that [XF] and [XQO] are inconsistent.  I just
submitted a proposal for merging those.

I have also looked more closely into Satoshi's questions about
which obligations should be returned.  Here is how I would

2.1 Deny-overrides
  Q2.1.1 Deny-overrides does not specify order of evaluation.  If
         P1 is evaluated first, then P2 must be evaluated only if
         it contains any "Deny" rules.  Only if P2 is evaluated
         must the obligations associated with P2 be returned.
         Likewise, if P2 is evaluated first, then P1 might not be
         evaluated, and its obligations might not be returned.

  Q2.1.2 If P1 is evaluated first, then P2 need not be
         evaluated.  Likewise, if P2 is evaluated first, then P1
         need not be evaluated.  A policy's obligations are
         returned only if it is evaluated.

2.2 Permit-overrides
  Same answers

2.3 First-applicable
  Q2.3.1 If P1 is the first applicable, then P2 will not be
         evaluated and the obligations associated with P2 will
         not be returned.  First-applicable specifes order of
  Q2.3.2 Same answer.

I think the general answer is:

  We had to make trade-offs between efficient evaluation of
  policies and determinate results.  We defined "Deny-overrides"
  in such a way that it returns a determinate :-)
  "Permit/Deny/Indeterminate" result, since that was the combiner
  where users are most likely to insist on a determinate result.
  Note that this can require at least searching all rules in all
  policies just in case one of them has an effect of "Deny".  We
  also defined "First-applicable" such that it specifies an order
  of evaluation.  That order does not apply to inner combining
  algorithms, so there could still be some variation in order and
  completeness of evaluation.

  In general we let efficiency of evaluation be the primary goal.
  One evaluation order might return "Indeterminate" while another
  evaluation order might return a non-Indeterminate value, but if
  a non-Indeterminate value is returned, it will always be the
  same one.  If a PDP can evaluate P2 more easily than P1, then
  (for most algorithms) the PDP can evaluate P2 before evaluating
  P1.  We do not insist that the complete tree of policies and
  rules be evaluated.

  Obligations are returned only for policy sets, policies, and
  rules that are actually evaluated.

  We explicitly decided that returning a determinate set of
  Obligations was a secondary consideration to efficiency of
  evaluation for the standard combining algorithms.  Our
  combining algorithms do not force complete evaluation of all
  policy sets, policies, and rules, and they do not force a
  particular order of evaluation (except for the top-level

  If a user of XACML wants to return a consistent set of
  Obligations, then the user must define a new combining
  algorithm that specifies the order of evaluation or requires
  that all components of the policy must be fully evaluated.

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

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

Powered by eList eXpress LLC