3.1 Policy Assertion

[Definition: A policy assertion represents an individual requirement, capability, or other property of a behavior.] A policy assertion identifies a behavior that is a requirement or capability of a policy subject. [Definition: A policy subject is an entity (e.g., an endpoint, message, resource, operation) with which a policy can be associated. ] Assertions indicate domain-specific (e.g., security, transactions) semantics and are expected to be defined in separate, domain-specific specifications.

An assertion MAY indicate that it is an ignorable policy assertion (see 4.4 Ignorable Policy Assertions). An ignorable policy assertion is an assertion that may be ignored for policy intersection (as defined in Section 4.5 Policy Intersection). By default, an assertion is not ignorable for policy intersection.

Assertions are typed by the authors that define them. [Definition: A policy assertion type represents a class of policy assertions and implies a schema for the assertion and assertion-specific semantics.] The policy assertion type is identified only by the XML Infoset [namespace name] and [local name] properties (that is, the qualified name or QName) of the root Element Information Item representing the assertion. Assertions of a given type MUST be consistently interpreted independent of their policy subjects.

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 XML Infoset of a policy assertion MAY contain a non-empty [attributes] property and/or a non-empty [children] property. Such properties are policy assertion parameters and MAY be used to parameterize the behavior indicated by the assertion. [Definition: A policy assertion parameter qualifies the behavior indicated by a policy assertion.] For example, an assertion identifying support for a specific reliable messaging mechanism might include an attribute information item to indicate how long an endpoint will wait before sending an acknowledgement.

Authors should be cognizant of the processing requirements when defining complex assertions containing policy assertion parameters or nested policy expressions. Specifically, authors are encouraged to consider when the identity of the root Element Information Item alone is enough to convey the requirement or capability.

4.45  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. Intersection is a commutative, associative function that takes two policies and returns a policy. There are two modes for intersection: strict and lax. How the mode is 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 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:; specifically, for two policy alternatives to be compatible, they must at least have the same policy alternative vocabulary (see Section 3.2 Policy Alternative).

·         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 Ttwo policy alternatives are compatible if each assertion in one is compatible with an assertion in the other, and vice-versa. If the mode is lax, two policy alternatives are compatible if each assertion in one that is not an ignorable assertion is compatible with an assertion in the other, and vice-versa. 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.

…

Part 2 – XML Schema Declaration for the New Attribute