FAQ: what are the basic Assertion functions, and how are they provided?

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

An Assertion in a Boolean policy framework, regardless of the Assertion
language, must support 3 basic functions:

1) IDENTIFY: Provide the identity of the policy variable (policy
vocabulary item) that the Assertion covers.

2) TEST: When provided with a value for the policy variable it covers,
return a value of TRUE or FALSE depending on whether the value satisfies
the Assertion.

3) INTERSECT: Provide a way to compare two Assertions that cover the
same policy variable and return either an error indicating "Not
compatible" or return some representation of the one or more values that
are mutually compatible for the two Assertions (the values for which
both Assertions will return TRUE).

COMPARISON OF DOMAIN-SPECIFIC VS DOMAIN-INDEPENDENT APPROACHES
==============================================================

Let's compare how these functions are provided using domain-specific and
domain-independent policy Assertion languages.

  Example Consumer Service Assertion: the guaranteed bandwidth must be
at least 4800bps.
  Example Provider Service Assertion: the guaranteed bandwidth is 14400 bps.

A. DOMAIN-SPECIFIC
==================

  Consumer Service Assertion:
     <ns:GuaranteedBandwidth>4800</ns:GuaranteedBandwidth>

  Provider Service Assertion:
     <ns:GuaranteedBandwidth>14400</ns:GuaranteedBandwidth>

  1) IDENTIFY: The QName of the Assertion element: "ns:GuaranteedBandwidth".

  2) TEST: There is a problem here.  The consumer is happy with any
value greater than or equal to the GuaranteedBandwidth, whereas the
provider is happy only with the one value provided.  So the special code
module must know whether the input value is from a consumer policy or
from a provider policy in order to return the right answer.  For the
consumer, the special code module must implement a "greater than or
equal to" test, whereas for the provider, the special code module must
implement an "equal to" test.

     If the Assertion is to be used to test a policy value that occurs
in an actual message, then the special code module must know how to
locate the policy value in a message and use it as input.

  3) INTERSECT: A special code module must be written that can take two
ns:GuaranteedBandwidth Assertions and determine which values will result
in TRUE from both Assertions, or else return an error indicating
"Incompatible".  A way must be provided to represent that set of values
that will return TRUE.  Again, this special module must know which
Assertion comes from a consumer and which comes from a provider in order
to implement the correct computation.

B. DOMAIN-INDEPENDENT
=====================

  Consumer Service Assertion:

    <xacml:Apply FunctionId="integer-greater-than-or-equal">
        <xacml:AttributeSelector
            InputContextPath="//ns:GuaranteedBandwidth/text()"
            DataType="integer"/>
        <xacml:AttributeValue
            DataType="integer">4800</xacml:AttributeValue>
    </xacml:Apply>

    Think of this as the function:

           //ns:Bandwidth/text() >= 4800

  Provider Service Assertion:

    <xacml:Apply FunctionId="integer-equal">
        <xacml:AttributeSelector
            InputContextPath="//ns:GuaranteedBandwidth/text()"
            DataType="integer"/>
        <xacml:AttributeValue
            DataType="integer">14400</xacml:AttributeValue>
    </xacml:Apply>

    Think of this as the function:

           //ns:Bandwidth/text() == 14400

  1) IDENTIFY: The "InputContextPath" value of the AttributeSelector:
"//ns:GuaranteedBandwidth/text()".  If an XACML AttributeDesignator were
used instead, it would be the AttributeId value (perhaps
"...:GuaranteedBandwidth").

  2) TEST: There are standard functions for
"integer-greater-than-or-equal" and "integer-equal".  The input value
and the "AttributeValue" are passed to these standard functions as
parameters, and the answer is returned.

    If the input value occurs in a message, then the InputContextPath
would be an XPath expression that selects the policy value, so the
message can be supplied as input, and the TEST can be applied directly
to it, with the semantics "Does this message satisfy this Assertion?"

  3) INTERSECT: The standard function intersection table is consulted
for the entry that corresponds to ">=" and "==":

   First function   Second function   If        Result
   --------------   ---------------   ------    ------
   x >= y           x == z            z >= y    z
                                      z < y     INCOMPATIBLE

In this case "14400 >= 4800" is true, so the result is 14400.
Calculating this intersection is a simple integer test.  The other
function intersection functions are similar trivial to compute.

The result is either an error indicating "Incompatible", or can be
expressed using an Assertion that describes the mutually acceptable
values.  In this case, the resulting Assertion will be the same as the
provider's Assertion.  Computing a new mutually compatible Assertion
makes it easy to compare Assertions from multiple policies: two are
compared, the result is compared with the next policy's Assertion, that
result is compared with the next policy's Assertion, ....

For simplicity of presentation, the example above omits the function
that tests whether the policy variable has a single value or multiple
values.  Particularly when testing an Assertion directly against a
message, this function is very helpful, since there may be more than one
instance of a given element in the message.  That situation may either
be an error, or it may be the case that the policy writer is happy so
long as at least one of the values satisfies the function.

Regards,
Anne
-- 
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