Re: [dipal-discuss] FAQ: what are the basic Assertion functions, and how are they provided?

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

I think that you are missing some key aspects of policies
Notably the subject of the policy (the owner of the policy if
you will) and who is the subject of the policy.

In our discussions, we distilled policy into "a constraint on the
behavior of some owned resource from the perspective of a stakeholder"
This conceptualization seems completely missing below.

Frank McCabe

On Dec 15, 2005, at 9:05 AM, Anne Anderson wrote:

> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dipal-discuss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dipal-discuss-help@lists.oasis- 
> open.org
>