Re: [xacml] [model] Issues PM-2-02,PM-2-04: Applicability

[Polar Humenn <polar@syr.edu>]

Anne,

I think a similar solution can be done by merely including explicit truth
values in the policy.  And that apporach will certainly make the policy
less complex in syntax and evaluation, yet also allow for flexibility in
expressing when a policy does not apply.

You hit on an important point. There is no EXPLICT "implication"
operator, I think. We basically have one operator (which I've been
labeling as "->")  for reasoning about the applicability target predicate
of a policy, but none within the policy itself.

We still need such things like:

<TRUE/>
<FALSE/>
<INAPPLICABLE>  or <NOT-APPLICABLE>

(Error will be an artifact of evaluation)

Because there would not be a way to merely state that a policy is True or
False all on its own (without any predicates).

But didn't we have some operator like "IF-THEN"

<IF-THEN>
  <...>
     a complex predicate that SHOULD NOT evaluate to n/a
  </...>
  <INAPPLICABLE/>
</IF-THEN>

It would have the same semantics as our applicability predicate.
With added semantics if the premise evaluated to INAPPLICABLE then the
entire expression is in Error.

NOTE: With our current 3 valued logic, "p implies q" would not be
equivalent to "(NOT p) OR q", which is true in classical 2 valued logic.

Cheers,
-Polar

On Mon, 11 Feb 2002, Anne Anderson wrote:

> [This note has to do with the syntax for expressing
> "applicability" of a single policy, and not with the logical
> rules for combining an inapplicable policy with other policies!!]
>
> We currently allow a <target> element predicate in
> <applicablePolicy> element.  The purpose of this element is to
> allow a PDP (or its agent, a PRP) to eliminate policies
> efficiently if they do not apply to the current
> authorizationDecisionQuery.  Such an element can be used to index
> policies by Subject or Resource/Action (where some policies will
> need to be indexed under both Subject and Resource/Action, and
> some policies will apply to all Subjects and/or
> Resource/Actions).  The idea is that the <target> element
> predicate is simple to compute, and allows the PDP (or PRP) to
> narrow down the field of potentially applicable policies
> efficiently.  The PDP (or PRP) can then perform more complex
> evaluations on the smaller remaining set of policies.
>
> Since the <target> element needs to be a simple predicate that is
> efficient to compute, it is not sufficiently expressive to rule
> out all cases where the <policy> may not apply.  For example, if
> the policy applies only to employees who are over 55 years of
> age, then there is no syntax currently for expressing this in the
> <target> element.
>
> POTENTIAL RESOLUTION:
>
> We need two levels of applicability predicate: one used for fast
> narrowing down of the set of potentially applicable policies (and
> used for indexing), and the second for fully expressing the
> conditions under which this policy is applicable.
>
> The first level applicability predicate is our current syntax: a
> regular expression match on a Resource/Action and Subject.  It is
> very simple to compute, and MUST return TRUE for every
> authorizationDecisionQuery to which the corresponding policy
> applies.  It MAY return TRUE for an authorizationDecisionQuery to
> which it does not apply.  This predicate might be called
> "indexApplicability" or "basicApplicability" or something
> similar.
>
> The second level applicability predicate is an optional new
> element in the <applicablePolicy>.  It may use any comparison of
> attributes and values that could be used in the policy itself.
> This predicate might be called "fullApplicability" or something
> similar.  This second level predicate is optional because for
> many policies, only the first level predicate may be required to
> fully capture the exact set of conditions under which the policy
> applies.
>
> A policy evaluation returns "NOT-APPLICABLE" if either the first
> level applicability predicate OR the second level applicability
> predicate evaluates to FALSE.  The second level predicate need be
> computed ONLY IF the first level predicate evaluates to TRUE.
>
> The <policy> element may assume that the first and second level
> applicability predicates have been evaluated to TRUE.  This may
> save some duplicate predicates.
>
> --
> 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>