Authors MAY define that an assertion contains a policy expression (as
defined in 4. Policy Expression) as
one of its [children]. Nested policy
expression(s) are used by authors to further qualify one or more specific
aspects of the
original assertion. For
example, security policy authors may define an
assertion describing a set of security algorithms to qualify the specific
behavior of a security binding assertion.
…The following describes additional processing constraints on the outline listed above:
indicates that the assertion contains a nested policy expression. If there is
wsp:Policy Element Information Item in the [children] property, the assertion
has no nested policy expression.
If the schema outline for an assertion type requires a
nested policy expression but the assertion does not further qualify one or more
aspects of the behavior indicated by the assertion type (i.e., no assertions
are needed in the nested policy expression), the assertion MUST include an empty
<wsp:Policy/> Element Information Item in its [children] property
; as explained in Section 4.3.3
Policy Operators, this is
equivalent to a nested policy expression with a single alternative that has zero assertions.
Policy intersection is useful when two or more parties express policy and want to limit the policy alternatives to those that are mutually compatible. For example, when a requester and a provider express requirements on a message exchange, intersection identifies compatible policy alternatives (if any) included in both requester and provider policies. Policy intersection is commutative operation performed on two policies that yields a policy that contains a collection of the compatible policy alternatives. (Note: while policy intersection at times is analogous with set intersection, it does not imply formal set intersection semantics).
There are two modes for intersection: strict and lax. How the mode is selected or indicated for the policy intersection is outside the scope of this specification.
Because the set of behaviors indicated by a policy alternative depends on the domain-specific semantics of the collected assertions, determining whether two policy alternatives are compatible generally involves domain-specific processing. If a domain-specific intersection processing algorithm is required this will be known from the QNames of the specific assertion types involved in the policy alternatives.
As a first approximation, an algorithm is defined herein that approximates compatibility in a domain-independent manner:
· If either assertion contains a nested policy expression, the two assertions are compatible if they both have a nested policy expression and the alternative in the nested policy expression of one is compatible with the alternative in the nested policy expression of the other.
If the mode is strict, two policy alternatives A and B are compatible:
o if each assertion in A is compatible with an assertion in B, and
o if each assertion in B is compatible with an assertion in A.
If the mode is lax, two policy alternatives A and B are compatible:
o if each assertion in A that is not an ignorable policy assertion is compatible with an assertion in B, and
o if each assertion in B that is not an ignorable policy assertion is compatible with an assertion in A.
If two alternatives are compatible, their intersection is an alternative containing all of the assertions in both alternatives.
· Two policies are compatible if an alternative in one is compatible with an alternative in the other. If two policies are compatible, their intersection is the set of the intersections between all pairs of compatible alternatives, choosing one alternative from each policy. If two policies are not compatible, their intersection has no policy alternatives.