1.1 Example

Example 1-1 illustrates a security policy expression using assertions defined in WS-SecurityPolicy [[WS-SecurityPolicy]]:

                
(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)        <sp:SignedParts>
(05)           <sp:Body/>
(06)        </sp:SignedParts>
(07)     </wsp:All>
(08)     <wsp:All>
(09)        <sp:EncryptedParts>
(10)           <sp:Body/>
(11)        </sp:EncryptedParts>
(12)     </wsp:All>
(13)   </wsp:ExactlyOne>
(14) </wsp:Policy>

Lines (03-07) represent one policy alternative for signing a message body.

Lines (08-12) represent a second policy alternative for encrypting a message body.

Lines (02-13) 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 will either sign or encrypt the message body.

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 an exclusive 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 item 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.

Elements and Attributes defined by this specification are referred to in the text of this document using XPath 1.0 [XPATH 1.0] expressions. Extensibility points are referred to using an extended version of this syntax:

• An element extensibility point is referred to using {any} in place of the element name. This indicates that any element name can be used, from any namespace, unless specified otherwise such as in Section 4.3.3 Policy Operators.

• An attribute extensibility point is referred to using @{any} in place of the attribute name. This indicates that any attribute name can be used, from any namespace.

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

Within normative outlines, in this specification, 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. In this context, if an Attribute Information Item is not recognized, it SHOULD be ignored. If an Element Information Item is not recognized, it MUST be treated as a policy assertion, unless specified otherwise such as in Section 4.3.4 Policy References.

2.3 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/ns/ws-policy. A normative XML Schema [[XML Schema Structures], [XML Schema Datatypes]] document can be obtained indirectly by dereferencing the namespace document at the WS-Policy 1.5 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 as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and 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, the namespace URI will be changed accordingly.

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 vast majority of instances would remain valid.

• Modifications to the cardinality of elements (i.e. modifications to minOccurs or maxOccurs attribute value of an element declaration) 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.4 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:

collection

The items in a collection in this specification are unordered and may contain duplicates.

ignorable policy assertion

An ignorable policy assertion is an assertion that may be ignored for purposes of determining the compatibility of alternatives in policy intersection in a lax mode (as defined in 4.5 Policy Intersection).

nested policy expression

A nested policy expression is a policy expression that is an Element Information Item in the children property of a policy assertion.

policy

A policy is a potentially empty collection of policy alternatives.

policy alternative

A policy alternative is a potentially empty collection of policy assertions.

policy assertion

A policy assertion represents a requirement, a capability, or other property of a behavior.

policy assertion parameter

A policy assertion parameter qualifies the behavior indicated by a policy assertion.

policy assertion type

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

policy attachment

A policy attachment is a mechanism for associating policy with one or more policy scopes.

policy expression

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

policy scope

A policy scope is a collection of policy subjects to which a policy may apply.

policy subject

A policy subject is an entity (e.g., an endpoint, message, resource, operation) with which a policy can be associated.

3.1 Policy Assertion

[Definition: A policy assertion represents a requirement, a 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). [Definition: An ignorable policy assertion is an assertion that may be ignored for purposes of determining the compatibility of alternatives in policy intersection in a lax mode (as defined in 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 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.

The XML Infoset of a policy assertion MAY contain a non-empty attributes property and/or a non-empty children property. Such properties, excluding the Attribute and Element Information Items from the WS-Policy language XML namespace name 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.

3.2 Policy Alternative

[Definition: A policy alternative is a potentially empty collection of policy assertions.] [Definition: The items in a collection in this specification are unordered and may contain duplicates. ] An alternative with zero assertions indicates no behaviors. An alternative with one or more assertions indicates behaviors implied by those, and only those assertions.

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. However, authors can write assertions that control the order in which behaviors are applied.

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) (See XML Schema Part 1 [[XML Schema Structures]]) content, if any) are specific to the assertion type and are outside the scope of this document. If policy assertion authors did not specify the semantics of repetition of policy assertions of a type that allows neither parameters nor nested policy expressions within a policy alternative, then repetition is simply redundancy, and multiple assertions of the assertion type within a policy alternative have the same meaning as a single assertion of the type within the 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. For example, a combination of two or three assertions from the WS-SecurityPolicy [[WS-SecurityPolicy]] specification is used to indicate message-level security for protecting messages - that is, the sp:AsymmetricBinding assertion is used to indicate message-level security, the sp:SignedParts assertion is used to indicate the parts of a message to be protected and the sp:EncryptedParts assertion is used to indicate the parts of a message that require confidentiality.

3.3 Policy

[Definition: 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 Policies of Entities in a Web Services Based System

Applied to a Web services based system, policy is used to convey conditions on an interaction between entities (requester application, provider service, Web infrastructure component, etc). An interaction involves one or more message exchanges between two entities. It is the responsibility of assertion authors to define the interaction scope of an assertion including any constraints on the policy subjects to which the assertion may be attached and a clear specification of the message (s) within that interaction scope to which the assertion applies.

Any entity in a Web services based system may expose a policy to convey conditions under which it functions. Satisfying assertions in the policy usually results in behavior that reflects these conditions. For example, if two entities - requester and provider - expose their policies, a requester might use the policy of the provider 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 an entity in the web services based system if and only if the entity satisfies the requirement (or accommodates the capability) corresponding to the assertion. A policy alternative is supported by an entity if and only if the entity supports all the assertions in the alternative. And, a policy is supported by an entity if and only if the entity 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 an entity may be able to support a policy even if the entity does not understand the type of each assertion in the policy; the entity only has to understand the type of each assertion in a policy alternative that the entity 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 entities 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.

/wsp:Policy/@{any}

Additional attributes MAY be specified but MUST NOT contradict the semantics of the owner element; if an attribute is not recognized, it SHOULD be ignored.

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 (see 4.3.2 Policy Assertion Nesting).

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 a policy expression.

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)        <sp:SignedParts>
(05)           <sp:Body/>
(06)        </sp:SignedParts>
(07)     </wsp:All>
(08)     <wsp:All>
(09)        <sp:EncryptedParts>
(10)           <sp:Body/>
(11)        </sp:EncryptedParts>
(12)     </wsp:All>
(13)   </wsp:ExactlyOne>
(14) </wsp:Policy>

Lines (03-07) and Lines (08-12) express the two alternatives in the policy. If the first alternative is selected, the message body needs to be signed [[WS-SecurityPolicy]] is supported; conversely, if the second alternative is selected, the message body needs to be encrypted.

4.2 Policy Identification

A policy expression MAY be associated with an IRI [[IETF RFC 3987]]. The schema outline for attributes to associate an IRI is as follows:

<wsp:Policy ( Name="xs:anyURI" )?
                ( wsu:Id="xs:ID" | xml: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 IRI [[IETF RFC 3987]]. If omitted, there is no implied value. This IRI 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]]. [Definition: A policy attachment is a mechanism for associating policy with one or more policy scopes.] [Definition: A policy scope is a collection of policy subjects to which a policy may apply.]

/wsp:Policy/(@wsu:Id | @xml:id)

The identity of the policy expression as an ID within the enclosing XML document. If omitted, there is no implied value. The constraints of the XML 1.0 [[XML 1.0]] ID type MUST be met. To refer to this policy expression, an IRI-reference MAY be formed using this value per Section 4.2 of WS-Security [[WS-Security 2004]] when @wsu:Id is used.

Note:

The use of xml:id attribute in conjunction with Canonical XML 1.0 is inappropriate as described in Appendix C of xml:id Version 1.0 [[XML ID]] and thus this combination must be avoided (see [[C14N 1.0 Note]]). For example, a policy expression identified using xml:id attribute should not be signed using XML Digital Signature when Canonical XML 1.0 is being used as the canonicalization method.

Note:

Canonical XML 1.1 [[XMLID11]] is intended to address the issues that occur with Canonical XML 1.0 with regards to xml:id. The W3C XML Security Specifications Maintenance WG has been chartered to address how to integrate Canonical XML 1.1 with XML Security, including XML Signature [[SecSpecMaintWG]] (See http://www.w3.org/2007/xmlsec/.)

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

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

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

(01) <wsp:Policy
        wsu:Id="P1"
        xmlns:wsp="http://www.w3.org/ns/ws-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 sub section below describes a construct and its equivalent normal form. To interpret a compact expression in an interoperable form, a policy expression in the compact form can be converted (see Section 4.3.6 Normalization) to the normal form (see Section 4.1 Normal Form Policy Expression).

A policy expression consists of a wsp:Policy wrapper element and zero or more child and descendent elements.

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

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <sp:IncludeTimestamp wsp:Optional="true" />
(03) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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>
               <sp:HttpsToken>
                 <wsp:Policy/>
               </sp:HttpsToken>
(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://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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>
                   <sp:HttpsToken>
                     <wsp:Policy/>
                   </sp:HttpsToken>
(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>
                   <sp:HttpsToken>
                     <wsp:Policy/>
                   </sp:HttpsToken>
(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>

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

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

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

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <sp:RequireDerivedKeys wsp:Optional="true" />
(03)   <wsp:ExactlyOne>
(04)     <sp:WssUsernameToken10 />
(05)     <sp:WssUsernameToken11 />
(06)   </wsp:ExactlyOne>
(07) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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>

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <sp:RequireDerivedKeys />
(03)   <wsp:ExactlyOne>
(04)     <sp:WssUsernameToken10 />
(05)     <sp:WssUsernameToken11 />
(06)   </wsp:ExactlyOne>
(07) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>
(04)       <sp:RequireDerivedKeys />
(05)     </wsp:All>
(06)   </wsp:ExactlyOne>
(07)   <wsp:ExactlyOne>
(08)     <wsp:All>
(09)       <sp:WssUsernameToken10 />
(10)     </wsp:All>
(11)     <wsp:All>
(12)       <sp:WssUsernameToken11 />
(13)     </wsp:All>
(14)   </wsp:ExactlyOne>
(15) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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:ExactlyOne>
(12) </wsp:Policy>

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

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <wsp:PolicyReference URI="#Protection" />
(03)   <sp:OnlySignEntireHeadersAndBody />
(04) </wsp:Policy>

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <sp:IncludeTimestamp />
(03)   <wsp:PolicyReference URI="#Protection" />
(04)   <sp:OnlySignEntireHeadersAndBody />
(05) </wsp:Policy>

4.4 Ignorable Policy Assertions

The wsp:Ignorable attribute indicates if a policy assertion is an ignorable policy assertion. The behavior implied by an ignorable assertion is expected to be a behavior that need not be engaged for successful interoperation with the entity that includes such ignorable assertions in its policy.

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

The following describes the Attribute Information Item defined in the schema outline above:

/Assertion/@wsp:Ignorable

This attribute is of type xs:boolean. If the actual value (See XML Schema Part 1 [[XML Schema Structures]]) is true, the assertion is an ignorable policy assertion. If the actual value is false, the assertion is not an ignorable policy assertion. Omitting this attribute is semantically equivalent to including it with a value of false.

4.5 Policy Intersection

Policy intersection is OPTIONAL but, a useful tool 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 a 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.

AsBecause a first approximation, an intersection algorithm is defined below that approximates compatibility of policy assertions inalternative a domain-independent manner. Mechanisms for determining assertion parameter compatibility are not partsemantics of the this domain-independent policyassertions, intersection. Determiningdetermining whether two policy assertions of the same typealternatives are compatible may involve domain-specific processing for purposes of determining assertion parameter compatibility. Domain-independent policy intersection may be extended toinclude domain-specific processing. If a domain-specific intersection processing algorithm is required this will be known from the QName of the specific assertion type involved in the policy alternative. However,alternatives. regardless of whether an assertion's QName indicates domain-specificapproximation, processing, an implementation ofis defined the domain-independentherein intersection need not apply the domain-specific processing.

• 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 domain-independent compatibility determination defined herein but this domain-independent policy intersection may be extended to include domain-specific processing for purposesprocessing. of determining Assertion parameter compatibility.

• If the mode is strict, two policy alternatives A and B are compatible:

  • if each assertion in A is compatible with an assertion in B, and

  • 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:

  • if each assertion in A that is not an ignorable policy assertion is compatible with an assertion in B, and

  • 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 occurrences of all of the assertions from botheach of the alternatives (i.e., the bag union of the two), regardless of whether or not they are marked with the wsp:Ignorable='true' attribute.two).

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

The result of policy intersection can be zero or more alternatives. Each alternative may contain more than one assertion of the same type which may come from different input policies. See Section 3.2 Policy Alternative for mechanisms for determining the aggregate behavior indicated by multiple assertions of the same policy assertion type. If policy assertion authors did not specify the semantics of multiple assertions of the same assertion type within a policy alternative and the type and its descendant assertion types (within a nested policy expression outline, if any) do not allow any parameters, then multiple assertions of the type within a policy alternative in the intersection result have the same meaning as a single assertion of the type within the policy alternative.

An entity applies all the behaviors implied by a policy alternative when that policy alternative is chosen from the intersection result (see 3.4 Policies of Entities in a Web Services Based System). If an entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected result, then that entity SHOULD not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the input policies being intersected then the intersection result is silent about the behavior implied by the assertion type Z.

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

(01) <wsp:Policy
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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 assertion 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://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://www.w3.org/ns/ws-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 two> 1 assertions of the type sp:SignedParts; when and two assertionsbehavior of the typewith sp:EncryptedParts, one from eachis of the contents input Policies.both In general, whetherare two assertionsto of the same typebehavior. are compatible or repetition is redundancy depends on the domain-specific semantics of the assertionsp:SignedParts type. Asassertion. mentioned above, if theassertion authors assertions haveare no parametersto and the assertions in nestedsuch policiy expressions have no parameters, thentwo multiple assertions of the type within a policy alternative in the intersection result have the same meaning as a single assertion of the type within the policy alternative.

As another example of intersection of WS-Addressing assertions that utilize the framework intersection algorithm, consider two input policies:

<wsp:Policy
      xmlns:wsp="http://www.w3.org/ns/ws-policy"
      xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" >
  <wsp:ExactlyOne>
    <wsp:All>        <!-- Alternative A5 -->
      <wsam:Addressing>
        <wsp:Policy/>
      </wsam:Addressing>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Lines (04)-(06) in the above policy expression contain an addressing policy assertion with the empty <wsp:Policy/> in line (05). The empty <wsp:Policy/> is a nested policy expression with an alternative that has zero assertions. In the example above, the addressing assertion indicates the use of addressing without any restriction.

<wsp:Policy
      xmlns:wsp="http://www.w3.org/ns/ws-policy"
      xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" >
  <wsp:ExactlyOne>
    <wsp:All>       <!-- Alternative A6 -->
      <wsam:Addressing>
        <wsp:Policy>
          <wsam:AnonymousResponses/>
        </wsp:Policy>
      </wsam:Addressing>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Lines (04)-(08) in the above policy expression contain an addressing policy assertion with a nested policy expression in lines (05)-(06). The nested policy expression indicates that the provider requires request messages to use response endpoint EPRs that contain the anonymous URI. The nested policy expression contains an alternative that has one assertion, wsam:AnonymousResponses.

The two assertions in alternatives A5 and A6 have the same assertion type and have nested policy expressions. The nested policy expression within the addressing assertion in the alternative A5 contains an alternative that has zero assertions. The nested policy expression within the addressing assertion in the alternative A6 contains an alternative that has one assertion. The nested policy expressions within these two assertions are incompatible because the alternative in one is incompatible with the alternative in the other.

Therefore, the two assertions are incompatible and hence the two alternatives are incompatible.

4.6 Use of IRIs in Policy Expressions

Policy expressions use IRIs for some identifiers. This document does not define a base URI but relies on the mechanisms defined in XML Base [[XML BASE]] and RFCs 3023 [[IETF RFC 3023]], 3986 [[IETF RFC 3986]] and 3987 [[IETF RFC 3987]] for establishing a base URI against which relative IRIs can be made absolute.

5.1 Information Disclosure Threats

A policy is used to represent the capabilities and requirements of a Web Service. Policies may include sensitive information. Malicious consumers may acquire sensitive information, fingerprint the service and infer service vulnerabilities. These threats can be mitigated by requiring authentication for sensitive information, by omitting sensitive information from the policy or by securing access to the policy. For securing access to policy metadata, policy providers can use mechanisms from other Web Services specifications such as WS-Security [[WS-Security 2004]] and WS-MetadataExchange [[WS-MetadataExchange]] .

5.2 Spoofing and Tampering Threats

If a policy expression is unsigned it could be easily tampered with or replaced. To prevent tampering or spoofing of policy, requestors should discard a policy unless it is signed by the provider and presented with sufficient credentials. Requestors should also check that the signer is actually authorized to express policies for the given policy subject.

5.3 Downgrade Threats

A policy may offer several alternatives that vary from weak to strong set of requirements. An adversary may interfere and remove all the alternatives except the weakest one (say no security requirements). Or, an adversary may interfere and discard this policy and insert a weaker policy previously issued by the same provider. Policy authors or providers can mitigate these threats by sun-setting older or weaker policy alternatives. Requestors can mitigate these threats by discarding policies unless they are signed by the provider.

5.4 Repudiation Threats

Malicious providers may include policy assertions in its policy whose behavior cannot be verified by examining the wire message from the provider to requestor. In general, requestors have no guarantee that a provider will behave as described in the provider’s policy expression. The provider may not and perform a malicious activity. For example, say the policy assertion is privacy notice information and the provider violates the semantics by disclosing private information. Requestors can mitigate this threat by discarding policy alternatives which include assertions whose behavior cannot be verified by examining the wire message from the provider to requestor. Assertion authors can mitigate this threat by not designing assertions whose behavior cannot be verified using wire messages.

5.5 Denial of Service Threats

Malicious providers may provide a policy expression with a large number of alternatives, a large number of assertions in alternatives, deeply nested policy expressions or chains of PolicyReference elements that expand exponentially (see the chained sample below; this is similar to the well-known DTD entity expansion attack). Policy implementers need to anticipate these rogue providers and use a configurable bound with defaults on number of policy alternatives, number of assertions in an alternative, depth of nested policy expressions, etc.

<wsp:Policy wsu:Id="p1">
  <wsp:PolicyReference URI="#p2"/ >
  <wsp:PolicyReference URI="#p2"/>
</wsp:Policy>
                
<wsp:Policy wsu:Id="p2" >
  <wsp:PolicyReference URI="#p3"/>
  <wsp:PolicyReference URI="#p3"/>
</wsp:Policy>
                
<wsp:Policy wsu:Id="p3" >
  <wsp:PolicyReference URI="#p4"/>
  <wsp:PolicyReference URI="#p4"/>
</wsp:Policy>
                
<!-- Policy/@wsu:Id p4 through p99 -->
                
<wsp:Policy wsu:Id="p100" >
  <wsp:PolicyReference URI="#p101"/>
  <wsp:PolicyReference URI="#p101"/>
</wsp:Policy>
                
<wsp:Policy wsu:Id="p101" >
  <mtom:OptimizedMimeSerialization />
</wsp:Policy>

Malicious providers may provide a policy expression that includes multiple PolicyReference elements that use a large number of different internet addresses. These may require the consumers to establish a large number of TCP connections. Policy implementers need to anticipate such rogue providers and use a configurable bound with defaults on number of PolicyReference elements per policy expression.

5.6 General XML Considerations

Implementers of Web Services policy language should be careful to protect their software against general XML threats like deeply nested XML or XML that contains malicious content.