Web Services Policy 1.5 - Framework (DIFF from the Working-Draft-31-July-2006)

1.1 Goals

The goal of Web Services Policy 1.5 - Framework is to provide the mechanisms needed to enable Web services applications to specify policy information. Specifically, this specification defines the following:

• An XML Infoset called a policy expression that contains domain-specific, Web Service policy information. [Definition: A policy expression that contains domain-specific, Web Service policy information. is an XML Infoset representation of a policy, either in a normal form or in an equivalent compact form. ]
• A core set of constructs to indicate how choices and/or combinations of domain-specific policy assertions apply in a Web services environment.

Web Services Policy 1.5 - Framework is designed to work with the general Web services framework, including WSDL service descriptions [ WSDL 1.1 , WSDL 2.0 Core Language ] and UDDI service registrations [ UDDI API 2.0 , UDDI Data Structure 2.0 , UDDI 3.0 ].

1.2 Example

The following example illustrates a security policy using assertions defined in WS-SecurityPolicy [ WS-SecurityPolicy ]:

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <wsp:ExactlyOne>
(03)     <sp:Basic256Rsa15 />
(04)     <sp:TripleDesRsa15 />
(05)   </wsp:ExactlyOne>
(06) </wsp:Policy>

Lines (01-06) represent a policy for the algorithm suite required for performing cryptographic operations with symmetric or asymmetric key-based security tokens.

Lines (02-05) illustrate the ExactlyOne policy operator. Policy operators group policy assertions into policy alternatives. A valid interpretation of the policy above would be that an invocation of a Web service uses one of the algorithm suite assertions (Lines 03-04) specified.

2.1 Notational Conventions

This specification uses the following syntax within normative outlines:

• The syntax appears as an XML instance, but values in italics indicate data types instead of literal values.
• Characters are appended to elements and attributes to indicate cardinality:
  • "?" (0 or 1)
  • "*" (0 or more)
  • "+" (1 or more)
• The character "|" is used to indicate a choice between alternatives.
• The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
• This document relies on the XML Information Set [ XML Information Set ]. Information items properties are indicated by the style [infoset property] .
• XML namespace prefixes (see Table 2-1) are used to indicate the namespace of the element or attribute being defined.
• The ellipses characters "…" are used to indicate a point of extensibility that allows other Element or Attribute Information Items.

Normative text within this specification takes precedence over normative outlines, which in turn take precedence over the XML Schema [ XML Schema Structures ] descriptions.

2.2 Extensibility

The ellipses characters "…" are used to Within normative outlines, ellipses (i.e., "…") indicate a point of extensibility that allows other Element or Attribute Information Items. Information Items MAY be added at the indicated extension points but MUST NOT contradict the semantics of the element information item indicated by the [parent] or [owner] property of the extension. If a processor does n Attribute Information Item is not recognize an Attribute Information Item, the processord, it SHOULD ignore it; if a processor does be ignored; if an Element Information Item is not recognize an Element Information Item, the processord, it SHOULD treat it be treated as an assertion.

Normative text within this specification takes precedence over normative outlines, which in turn take precedence over the XML Schema [ XML Schema Structures ] descriptions.

2.23 XML Namespaces

This specification uses a number of namespace prefixes throughout; they are listed in Table 2-1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [ XML Namespaces ]).

All information items defined by this specification are identified by the XML namespace URI [ XML Namespaces ] http://www.w3.org/@@@@/@@/policy . A normative XML Schema [ XML Schema Structures , XML Schema Datatypes ] document can be obtained by dereferencing the XML namespace URI.

It is the intent of the W3C Web Services Policy Working Group that the Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment XML namespace URI will not change arbitrarily with each subsequent revision of the corresponding XML Schema documents but rather change only when a subsequent revision, published as a WD, CR or PR draft results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification.

Under this policy, the following are examples of backwards compatible changes that would not result in assignment of a new XML namespace URI:

• Addition of new global element, attribute, complexType and simpleType definitions.
• Addition of new elements or attributes in locations covered by a previously specified wildcard.
• Modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid.
• Modifications to the cardinality of elements for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule.

2.34 Terminology

The keywords " MUST ", " MUST NOT ", " REQUIRED ", " SHALL ", " SHALL NOT ", " SHOULD ", " SHOULD NOT ", " RECOMMENDED ", " MAY ", and " OPTIONAL " in this document are to be interpreted as described in RFC 2119 [ IETF RFC 2119 ].

We introduce the following terms that are used throughout this document:

[Definition: A policy is a collection of policy alternatives.]

[Definition: A policy alternative is a collection of policy assertions.]

[Definition: A policy assertion represents an individual requirement, capability, or other property of a behavior.]

[Definition: A policy assertion type represents a class of policy assertions and implies a schema for the assertion and assertion-specific semantics.]

[Definition: A policy assertion parameter qualifies the behavior indicated by a policy assertion.]

[Definition: A policy vocabulary of a policy is the set of all policy assertion types used in a policy.]

[Definition: A policy expression is an XML Infoset representation of a policy, either in a normal form or in an equivalent compact form. ]

[Definition: A policy subject is an entity (e.g., an endpoint, message, resource, interaction) with which a policy can be associated. ]

[Definition: A policy scope is a collection of policy subjects to which a policy may apply.]

[Definition: A policy attachment is a mechanism for associating policy with one or more policy scopes.] EdNote: script will insert termdefs here

3.1 Policy Assertion

A policy assertion identifies a behavior that is a requirement (or capability) of a policy subject. Assertions indicate domain-specific (e.g., security, transactions) semantics and are expected to be defined in separate, domain-specific specifications.

Assertions are strongly typed by the domain authors that define them. 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 [Definition: A policy assertion type represents a class of policy assertions and implies a schema for the assertion and assertion-specific semantics.] Assertions of a given type MUST be consistently interpreted independent of their policy subjects.

Domain authors MAY define that an assertion contains a policy expression as one of its [children] . Policy expression nesting is used by domain authors to further qualify one or more specific aspects of the original assertion. For example, security policy domain 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 an assertiona policy assertion MAY contain a non-empty [attributes] contain a non-empty [attributes] property and/or a non-empty [children] property. Such content MAY be used to parameterize the behavior indicated by the assertion. [Definition: A policy assertion parameter be used to parameterize the qualifies the behavior indicated by the assertion.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.

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

3.2 Policy Alternative

A policy alternative is a logical construct which represents a potentially empty collection of policy assertions. An alternative with zero assertions indicates no behaviors. An alternative with one or more assertions indicates behaviors implied by those, and only those assertions.

The vocabulary of a policy alternative is the set of all policy assertion types within the alternative. The < [Definition is the set of all assertion types used in all the policy alternatives in the policy. An assertion whose type is part of the policy's vocabulary but is not included in an alternative is explicitly prohibited by the alternative.: A policy vocabulary is the set of all policy assertion types used in a policy.] An assertion whose type is part of the policy's vocabulary but is not included in an alternative is explicitly prohibited by the alternative.

Assertions within an alternative are not ordered, and thus aspects such as the order in which behaviors (indicated by assertions) are applied to a subject are beyond the scope of this specification.

A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) content, if any) are specific to the assertion type and are outside the scope of this document.

3.3 Policy

At the abstract level a policy is a potentially empty collection of policy alternatives. A policy with zero alternatives contains no choices; a policy with one or more alternatives indicates choice in requirements (or capabilities) within the policy.

Alternatives are not ordered, and thus aspects such as preferences between alternatives in a given context are beyond the scope of this specification.

Alternatives within a policy may differ significantly in terms of the behaviors they indicate. Conversely, alternatives within a policy may be very similar. In either case, the value or suitability of an alternative is generally a function of the semantics of assertions within the alternative and is therefore beyond the scope of this specification.

3.4 Web services

Applied in the Web services model, policy is used to convey conditions on an interaction between two Web service endpoints. Satisfying assertions in the policy usually results in behavior that reflects these conditions. Typically, the provider of a Web service exposes a policy to convey conditions under which it provides the service. A requester might use this policy to decide whether or not to use the service. A requester may choose any alternative since each is a valid configuration for interaction with the service, but a requester MUST choose only a single alternative for an interaction with a service since each represents an alternative configuration.

A policy assertion is supported by a requester if and only if the requester satisfies the requirement (or accommodates the capability) corresponding to the assertion. A policy alternative is supported by a requester if and only if the requester supports all the assertions in the alternative. And, a policy is supported A policy assertion is supported by a requester if and only if the requester satisfies the requirement (or accommodates the capability) corresponding to the assertion. A policy alternative is supported by a requester if and only if the requester supports all the assertions in the alternative. And, a policy is supported by a requester if and only if the requester supports at least one of the alternatives in the policy. Note that although policy alternatives are meant to be mutually exclusive, it cannot be decided in general whether or not more than one alternative can be supported at the same time.

Note that a requester may be able to support a policy even if the requester does not understand the type of each assertion in the vocabulary of the policy; the requester only has to understand the type of each assertion in the vocabulary of a policy alternative the requester supports. This characteristic is crucial to versioning and incremental deployment of new assertions because this allows a provider's policy to include new assertions in new alternatives while allowing requesters to continue to use old alternatives in a backward-compatible manner.

4.1 Normal Form Policy Expression

To facilitate interoperability, this specification defines a normal form for policy expressions that is a straightforward XML Infoset representation of a policy, enumerating each of its alternatives that in turn enumerate each of their assertions. The schema outline for the normal form of a policy expression is as follows:

<wsp:Policy … >
  <wsp:ExactlyOne>
    ( <wsp:All> ( <Assertion …> ……> … </Assertion> )* </wsp:All> )*
  </wsp:ExactlyOne>
</wsp:Policy> 

The following describes the Element Information Items defined in the schema outline above:

/wsp:Policy

A policy expression.

/wsp:Policy/wsp:ExactlyOne

A collection of policy alternatives. If there are no Element Information Items in the [children] property, there are no admissible policy alternatives, i.e., no behavior is admissible.

/wsp:Policy/wsp:ExactlyOne/wsp:All

A policy alternative; a collection of policy assertions. If there are no Element Information Items in the [children] property, this is an admissible policy alternative that is empty, i.e., no behavior is specified.

/wsp:Policy/wsp:ExactlyOne/wsp:All/*

XML Infoset representation of a policy assertion.

If an assertion in the normal form of a policy expression contains a nested policy expression, the nested policy expression MUST contain at most one policy alternative.

To simplify processing and improve interoperability, the normal form of a policy expression should be used where practical.

For example, the following is the normal form of the policy expression example introduced earlier.

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)       <sp:Basic256Rsa15 />
(05)     </wsp:All>
(06)     <wsp:All>
(07)       <sp:TripleDesRsa15 />
(08)     </wsp:All>
(09)   </wsp:ExactlyOne>
(10) </wsp:Policy>

Lines (023-05) and Lines (06-08) express the two alternatives in the policy. If the first alternative is selected, only the Basic 256 RSA 15 algorithm suite [ WS-SecurityPolicy ] is supported; conversely, if the second alternative is selected, only the 3DES RSA 15 algorithm suite is supported.

4.2 Policy Identification

A policy expression MAY be associated with a URI [ IETF RFC 3986 ]. The schema outline for attributes to associate a URI is as follows:

<wsp:Policy ( Name="xs:anyURI" )?
            ( wsu:Id="xs:ID" )?
            …… >
  ……
</wsp:Policy>

The following describes the Attribute Information Items listed and defined in the schema outline above:

/wsp:Policy/@Name

The identity of the policy expression as an absolute URI [ IETF RFC 3986 ]. If omitted, there is no implied value. This URI MAY be used to refer to a policy from other XML documents using a policy attachment mechanism such as those defined in WS-PolicyAttachment [ Web Services Policy Attachment ].

/wsp:Policy/@wsu:Id

The identity of the policy expression as an ID within the enclosing XML document. If omitted, there is no implied value. To refer to this policy expression, a URI-reference   MAY be formed using this value per Section 4.2 of WS-Security [ WS-Security 2004 ].

The following example illustrates how to associate a policy expression with the absolute URI "http://www.example.com/policies/P1" :

(01) <wsp:Policy
        Name="http://www.example.com/policies/P1"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <!-- Details omitted for readability -->
(03) </wsp:Policy>

The following example illustrates how to associate a policy expression with the URI-reference "#P1" :

(01) <wsp:Policy
        wsu:Id="P1"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
(02)   <!-- Details omitted for readability -->
(03) </wsp:Policy>

4.3 Compact Policy Expression

To express a policy in a more compact form while still using the XML Infoset, this specification defines three constructs: an attribute to decorate an assertion, semantics for recursively nested policy operators, and a policy reference/inclusion mechanism. Each is described in the subsections below.

To interpret a compact policy expression in an interoperable form, a compact expression may be converted to the corresponding normal form expression by the following procedure:

1. Start with the [document element] property D of the Document Information Item of the policy expression. The [namespace name] of D is always "http://www.w3.org/@@@@/@@/policy" . In the base case, the [local name] property of D is "Policy" ; in the recursive case, the [local name] property of D is "Policy" , "ExactlyOne" , or "All" .
2. Expand Element Information Items in the [children] property of D that are policy references per Section 4.3.4 Policy Inclusion .
3. Convert each Element Information Item C in the [children] property of D into normal form.
   1. If the [namespace name] property of C is "http://www.w3.org/@@@@/@@/policy" and the [local name] property of C is "Policy" , "ExactlyOne" , or "All" , C is an expression of a policy operator; normalize C by recursively applying this procedure.
   2. Otherwise the Element Information Item C is an assertion; normalize C per Sections 4.3.1 Optional Policy Assertions and 4.3.2 Policy Assertion Nesting .
4. Apply the policy operator indicated by D to the normalized Element Information Items in its [children] property and construct a normal form per Section 4.3.3 Policy Operators .

Note that an implementation may use a more efficient procedure and is not required to explicitly convert a compact expression into the normal form as long as the processing results are indistinguishable from doing so.

<Assertion ( wsp:Optional="xs:boolean" )? …> … </Assertion>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <sp:IncludeTimestamp wsp:Optional="true" />
(03) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)       <sp:IncludeTimestamp />
(05)     </wsp:All>
(06)     <wsp:All />
(07)   </wsp:ExactlyOne>
(08) </wsp:Policy>

<Assertion ……>
  ……
  ( <wsp:Policy …> ……> … </wsp:Policy> )?
  ……
</Assertion>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <sp:TransportBinding>
(03)     <wsp:Policy>
(04)       <sp:AlgorithmSuite>
(05)         <wsp:Policy>
(06)           <wsp:ExactlyOne>
(07)             <sp:Basic256Rsa15 />
(08)             <sp:TripleDesRsa15 />
(09)           </wsp:ExactlyOne>
(10)         </wsp:Policy>
(11)       </sp:AlgorithmSuite>
(12)       <sp:TransportToken>
(13)         <wsp:Policy>
(14)           <sp:HttpsToken RequireClientCertificate="false" />
(15)         </wsp:Policy>
(16)       </sp:TransportToken>
           <!-- Details omitted for readability -->
(17)      </wsp:Policy>
(18)    </sp:TransportBinding>
(19) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)       <sp:TransportBinding>
(05)         <wsp:Policy>
(06)           <sp:AlgorithmSuite>
(07)             <wsp:Policy>
(08)               <sp:Basic256Rsa15 />
(09)             </wsp:Policy>
(10)           </sp:AlgorithmSuite>
(11)           <sp:TransportToken>
(12)             <wsp:Policy>
(13)               <sp:HttpsToken RequireClientCertificate="false" />
(14)             </wsp:Policy>
(15)           </sp:TransportToken>
               <!-- Details omitted for readability -->
(16)         </wsp:Policy>
(17)       </sp:TransportBinding>
(18)     </wsp:All>
(19)     <wsp:All>
(20)       <sp:TransportBinding>
(21)         <wsp:Policy>
(22)           <sp:AlgorithmSuite>
(23)             <wsp:Policy>
(24)               <sp:TripleDesRsa15 />
(25)             </wsp:Policy>
(26)           </sp:AlgorithmSuite>
(27)           <sp:TransportToken>
(28)             <wsp:Policy>
(29)               <sp:HttpsToken RequireClientCertificate="false" />
(30)             </wsp:Policy>
(31)           </sp:TransportToken>
               <!-- Details omitted for readability -->
(32)         </wsp:Policy>
(33)       </sp:TransportBinding>
(34)     </wsp:All>
(35)   </wsp:ExactlyOne>
(36) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All> <!-- @wsp:Optional alternative with assertion -->
(04)       <sp:RequireDerivedKeys />
(05)     </wsp:All>
(06)     <wsp:All /> <!-- @wsp:Optional alternative without -->
(07)   </wsp:ExactlyOne>
(08)   <wsp:ExactlyOne>
(09)     <wsp:All>
(10)       <sp:WssUsernameToken10 />
(11)     </wsp:All>
(12)     <wsp:All>
(13)       <sp:WssUsernameToken11 />
(14)     </wsp:All>
(15)   </wsp:ExactlyOne>
(16) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)       <sp:RequireDerivedKeys />
(05)       <sp:WssUsernameToken10 />
(06)     </wsp:All>
(07)     <wsp:All>
(08)       <sp:RequireDerivedKeys />
(09)       <sp:WssUsernameToken11 />
(10)     </wsp:All>
(11)     <wsp:All>
(12)       <sp:WssUsernameToken10 />
(13)     </wsp:All>
(14)     <wsp:All>
(15)       <sp:WssUsernameToken11 />
(16)     </wsp:All>
(17)   </wsp:ExactlyOne>
(18) </wsp:Policy>

<wsp:Policy>
  ……
  <wsp:PolicyReference
      URI="xs:anyURI"
    ( Digest="xs:base64Binary" ( DigestAlgorithm="xs:anyURI" )? )?
      …… />
  ……
</wsp:Policy> 

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
        wsu:Id="Protection" >
(02)   <sp:EncryptSignature wsp:Optional="true" />
(03)   <sp:ProtectTokens wsp:Optional="true" />
(04) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <wsp:PolicyReference URI="#Protection" />
(03)   <sp:OnlySignEntireHeadersAndBody />
(04) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
(02)   <sp:IncludeTimestamp />
(03)   <wsp:PolicyReference URI="#Protection" />
(04)   <sp:OnlySignEntireHeadersAndBody />
(05) </wsp:Policy>

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

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

• Two policy alternatives are compatible if each assertion in one 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.

As an example of intersection, consider two input policies in normal form:

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
       <!-- Policy P1 -->
(02)   <wsp:ExactlyOne>
(03)     <wsp:All> <!-- Alternative A1 -->
(04)       <sp:SignedElements>
(05)         <sp:XPath>/S:Envelope/S:Body</sp:XPath>
(06)       </sp:SignedElements>
(07)       <sp:EncryptedElements>
(08)         <sp:XPath>/S:Envelope/S:Body</sp:XPath>
(09)       </sp:EncryptedElements>
(10)     </wsp:All>
(11)     <wsp:All> <!-- Alternative A2 -->
(12)       <sp:SignedParts>
(13)         <sp:Body />
(14)         <sp:Header
                Namespace="http://www.w3.org/2005/08/addressing" />
(15)       </sp:SignedParts>
(16)       <sp:EncryptedParts>
(17)         <sp:Body />
(18)       </sp:EncryptedParts>
(19)     </wsp:All>
(20)   </wsp:ExactlyOne>
(21) </wsp:Policy>

The listing above contains two policy alternatives. The first alternative, (Lines 03-10) contains two policy assertions. One indicates which elements should be signed (Lines 04-06); its type is sp:SignedElements (Line 04), and its parameters include an XPath expression for the content to be signed (Line 05). The other assertion (Lines 07-09) has a similar structure: type (Line 07) and parameters (Line 08).

The second alternative (Lines 11-19) also contains two assertions, each with type (Line 12 and Line 16) and parameters (Lines 13-14 and Line 17).

As this example illustrates, compatibility between two policy assertions is based on assertion type and delegates parameter processing to domain-specific processing.

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
       <!-- Policy P2 -->
(02)   <wsp:ExactlyOne>
(03)     <wsp:All> <!-- Alternative A3 -->
(04)       <sp:SignedParts />
(05)       <sp:EncryptedParts>
(06)         <sp:Body />
(07)       </sp:EncryptedParts>
(08)     </wsp:All>
(09)     <wsp:All> <!-- Alternative A4 -->
(10)       <sp:SignedElements>
(11)         <sp:XPath>/S:Envelope/S:Body</sp:XPath>
(12)       </sp:SignedElements>
(13)     </wsp:All>
(14)   </wsp:ExactlyOne>
(15) </wsp:Policy>

Because there is only one alternative (A2) in policy P1 with the same vocabulary — — the assertions have the same type —— as another alternative (A3) in policy P2, the intersection is a policy with a single alternative that contains all of the assertions in A2 and in A3.

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        xmlns:wsp="http://www.w3.org/@@@@/@@/policy" >
       <!-- Intersection of P1 and P2 -->
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)       <sp:SignedParts >
(05)         <sp:Body />
(06)         <sp:Header
                Namespace="http://www.w3.org/2005/08/addressing" />
(07)       </sp:SignedParts>
(08)       <sp:EncryptedParts>
(09)         <sp:Body />
(10)       </sp:EncryptedParts>
(11)       <sp:SignedParts />
(12)       <sp:EncryptedParts>
(13)         <sp:Body />
(14)       </sp:EncryptedParts>
(15)     </wsp:All>
(16)   </wsp:ExactlyOne>
(17) </wsp:Policy>

Note that there are > 1 assertions of the type sp:SignedParts ; when the behavior associated with sp:SignedParts is invoked, the contents of both assertions are used to indicate the correct behavior. Whether these two assertions are compatible depends on the domain-specific semantics of the sp:SignedParts assertion. To leverage intersection, assertion authors are encouraged to factor assertions such that two assertions of the same assertion type are always (or at least typically) compatible.