KEY:

Yellow highlight: CONTEXT ISSUE

3.1 Policy Assertion

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 parent policy assertion. The qualification may indicate a relationship or context between the parent policy assertion and a nested policy expression. For example within a security domain, security policy authors may define an assertion describing a set of security algorithms to qualify the specific behavior of a security binding assertion. A parent policy assertion of one domain may also serve as a container for the nested policy expression from another domain.

 

 

3.2 Policy Alternative

…Note: Depending on the semantics of the domain specific policy assertions regardless if they are qualified by nested policy expressions, a combination of the policy assertions can be required to specify a particular behavior.

…4.3.2 Policy Assertion Nesting

…The following describes additional processing constraints on the outline listed above:

/Assertion/wsp:Policy

This indicates that the assertion contains a nested policy expression. If there is no 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; . Aas explained in Section 4.3.3 Policy Operators, this is equivalent to a nested policy expression with a single alternative that has zero assertions.

…4.5 Policy Intersection

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:

·         Two policy assertions are compatible if they have the same type and

·         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.

Assertion parameters are not part of the compatibility determination defined herein but may be part of other, domain-specific compatibility processing.

·        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.

See Section 3.2 Policy Alternative for mechanisms for determining the aggregate behavior indicated by multiple assertions of the same policy assertion type.