W3C标准：Web服务策略框架新版草案

Web 服务策略框架定义了普通目的的模型和相应的语法，以描述和交流 Web 服务策略，以便服务消费者能够发现他们需要知道的信息从而能够访问服务供应商的服务。

　　Web Services Policy 1.5 - Framework新版本草案已经发布。 

以下是草案原文

---

Web Services Policy 1.5 - Framework

W3C Candidate Recommendation 30 March 2007

This version:

http://www.w3.org/TR/2007/CR-ws-policy-20070330

Latest version:

http://www.w3.org/TR/ws-policy

Previous version:

http://www.w3.org/TR/2007/CR-ws-policy-20070228

Editors:

Asir S Vedamuthu, Microsoft Corporation

David Orchard, BEA Systems, Inc.

Frederick Hirsch, Nokia

Maryann Hondo, IBM Corporation

Prasad Yendluri, webMethods, Inc.

Toufic Boubez, Layer 7 Technologies

Ümit Yalçinalp, SAP AG.

This document is also available in these non-normative formats: PDF, PostScript, XML, and plain text.

Copyright © 2007 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

---

Abstract

The Web Services Policy 1.5 - Framework provides a general purpose model and corresponding syntax to describe the policies of entities in a Web services-based system.

Web Services Policy Framework defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements and capabilities.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

On 28 February 2007, this specification was published as a Candidate Recommendation, and a Call for Implementations was announced. This revision is published in order to give visibility to the technical decisions that have been made so far during this phase of the process and to allow review by W3C Members and other interested parties. The maturity level of the specification remains unchanged, and the work is on track to move forward to the Proposed Recommendation stage when the exit criteria for the current phase have been met. No features have been identified as "features at risk" by the Web Services Policy Working Group. The Working Group will maintain an implementation report.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This specification will remain a Candidate Recommendation until at least 30 June 2007.

This Working Draft was produced by the members of the Web Services Policy Working Group, which is part of the W3C Web Services Activity. The Working Group expects to advance this Working Draft to Recommendation Status.

A list of changes in this version of the document and a diff-marked version against the previous version of this document are available. There are no major changes in this version of the document. It is being republished to be in sync with the Web Services Policy 1.5 - Attachment specification.

The Working Group is tracking all comments via Bugzilla and highly prefers to receive comments via this system. If access to Bugzilla is not feasible, you may send your comments to the mailing list public-ws-policy-comments@w3.org mailing list (public archive). Each Bugzilla entry and email message should contain only one comment. All comments on this specification should be made following the Description for Issues of the Working Group.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

---

1. Introduction

Web Services Policy 1.5 - Framework defines a framework and a model for expressing policies that refer to domain-specific capabilities, requirements, and general characteristics of entities in a Web services-based system.

A policy is a collection of policy alternatives. A policy alternative is a collection of policy assertions. A policy assertion represents a requirement, capability, or other property of a behavior. A policy expression is an XML Infoset representation of its policy, either in a normal form or in its equivalent compact form. Some policy assertions specify traditional requirements and capabilities that will manifest themselves in the messages exchanged(e.g., authentication scheme, transport protocol selection). Other policy assertions have no wire manifestation in the messages exchanged, yet are relevant to service selection and usage (e.g., privacy policy, QoS characteristics). Web Services Policy 1.5 - Framework provides a single policy language to allow both kinds of assertions to be expressed and evaluated in a consistent manner.

Web Services Policy 1.5 - Framework does not cover discovery of policy, policy scopes and subjects, or their respective attachment mechanisms. A policy attachment is a mechanism for associating policy with one or more policy scopes. A policy scope is a collection of policy subjects to which a policy applies. A policy subject is an entity (e.g., an endpoint, message, resource, interaction) with which a policy can be associated. Web Services Policy 1.5 - Attachment [Web Services Policy Attachment] defines such policy attachment mechanisms, especially for associating policy with arbitrary XML elements [XML 1.0], WSDL artifacts [WSDL 1.1, WSDL 2.0 Core Language], and UDDI elements [UDDI API 2.0, UDDI Data Structure 2.0, UDDI 3.0]. Other specifications are free to define either extensions to the mechanisms defined in Web Services Policy 1.5 - Attachment [Web Services Policy Attachment], or additional mechanisms not covered by Web Services Policy 1.5 - Attachment [Web Services Policy Attachment], for purposes of associating policy with policy scopes and subjects.

1.1 Example

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

Example 1-1. Use of Web Services Policy with security policy assertions.

                
(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        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-06) represent one policy alternative for signing a message body.

Lines (08-11) 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. Notations and Terminology

This section specifies the notations, namespaces, and terminology used in this specification.

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

Table 2-1. Prefixes and Namespaces used in this specification

Prefix	Namespace	Specification
sp	http://schemas.xmlsoap.org/ws/2005/07/securitypolicy	[WS-SecurityPolicy]
wsp	http://www.w3.org/ns/ws-policy	This specification
wsu	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd	[WS-Security 2004]
xs	http://www.w3.org/2001/XMLSchema	[XML Schema Structures]

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:

ignorable policy assertion

An ignorable policy assertion is an assertion that may be ignored for policy intersection (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 alternative vocabulary

A policy alternative vocabulary is the set of all policy assertion types within the policy alternative.

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.

policy vocabulary

A policy vocabulary is the set of all policy assertion types used in a policy.

3. Policy Model

This section defines an abstract model for policies and for operations upon policies.

The descriptions below use XML Infoset terminology for convenience of description. However, this abstract model itself is independent of how it is represented as an XML Infoset.

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 policy intersection (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 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, 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.] An alternative with zero assertions indicates no behaviors. An alternative with one or more assertions indicates behaviors implied by those, and only those assertions. [Definition: A policy vocabulary is the set of all policy assertion types used in a policy.] [Definition: A policy alternative vocabulary is the set of all policy assertion types within the policy alternative.] When an assertion whose type is part of the policy's vocabulary is not included in a policy alternative, the policy alternative without the assertion type indicates that the assertion will not be applied in the context of the attached policy subject. See the example in Section 4.3.1 Optional Policy 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 behaviours 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.

Note: Depending on the semantics of the domain specific policy assertions a combination of the policy assertions can be required to specify a particular behavior.

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 vocabulary of the policy; the entity only has to understand the type of each assertion in the vocabulary of a policy alternative 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. Policy Expression

This section describes how to convey policy in an interoperable form, using the XML Infoset representation of 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.]

The normal form (see Section 4.1 Normal Form Policy Expression) of a policy expression is the most straightforward XML Infoset representation of the policy data model. Equivalent, alternative representations allow policy authors to compactly express a policy (see Section 4.3 Compact Policy Expression). Policy authors might be more interested in the compact form (see Section 4.3 Compact Policy Expression), where the outlines and definitions describe what is valid with regards to the policy language XML Schema.

While the policy language XML Schema is a representation of the compact form, the normal form is more restrictive as outlined in Section 4.1 Normal Form Policy Expression.

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:

(01) <wsp:Policy … >
(02)   <wsp:ExactlyOne>
(03)     ( <wsp:All> ( <Assertion …> … </Assertion> )* </wsp:All> )*
(04)   </wsp:ExactlyOne>
(05) </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://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        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-11) 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:

(01) <wsp:Policy ( Name="xs:anyURI" )?
(02)                 ( wsu:Id="xs:ID" | xml:id="xs:ID" )?
(03)             … >
(04)   …
(05) </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.

4.3.1 Optional Policy Assertions

To indicate that a policy assertion is optional, this specification defines an attribute that is a compact authoring style for expressing a pair of alternatives, one with and one without that assertion. The schema outline for this attribute is as follows:

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

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

/Assertion/@wsp:Optional

If the actual value (See XML Schema Part 1 [XML Schema Structures]) is true, the expression of the assertion is semantically equivalent to the following:

(01) <wsp:ExactlyOne>
(02)   <wsp:All> <Assertion …> … </Assertion> </wsp:All>
(03)   <wsp:All />
(04) </wsp:ExactlyOne>

If the actual value (See XML Schema Part 1 [XML Schema Structures]) is false, the expression of the assertion is semantically equivalent to the following:

(01) <wsp:ExactlyOne>
(02)   <wsp:All> <Assertion …> … </Assertion> </wsp:All>
(03) </wsp:ExactlyOne>

Omitting this attribute is semantically equivalent to including it with a value of false. Policy expressions should not include this attribute with a value of false, but policy parsers must accept this attribute with a value of false.

For example, the following compact policy expression:

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

is equivalent to the following normal form policy expression:

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        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>

The @wsp:Optional attribute in Line (02) of the first policy expression indicates that the assertion in Line (02) is to be included in a policy alternative whilst excluded from another; it is included in Lines (03-05) and excluded in Line (06). Note that @wsp:Optional does not appear in the normal form of a policy expression.

4.3.2 Policy Assertion Nesting

Any policy assertion MAY contain a policy expression. [Definition: A nested policy expression is a policy expression that is an Element Information Item in the [children] property of a policy assertion.] The schema outline for a nested policy expression is:

(01) <Assertion …>
(02)   …
(03)   ( <wsp:Policy …> … </wsp:Policy> )?
(04)   …
(05) </Assertion>

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

Note: This specification does not define processing for arbitrary wsp:Policy Element Information Items in the descendants of an assertion parameter, e.g., in the [children] property of one of the [children] as in:

(01)<wsp:Policy>
(02)   <Lorem>
(03)       <Ipsum>
(04)           <wsp:Policy> 
(05)           …
(06)           </wsp:Policy>
(07)       </Ipsum>
(08)   </Lorem>
(09)</wsp:Policy>

Policy assertions containing a nested policy expression are normalized recursively. The nesting of a policy expression (and a wsp:Policy child) is retained in the normal form, but in the normal form, each nested policy expression contains at most one policy alternative. If an assertion A contains a nested policy expression E, and if E contains more than one policy alternative, A is duplicated such that there are as many instances of A as choices in E, and the nested policy expression of a duplicate A contains a single choice. This process is applied recursively to the assertions within those choices and to their nested policy expression, if any. Intuitively, if a compact policy is thought of as a tree whose branches have branches etc, in the normal form, a policy is a stump with straight vines.

For example, consider the following policy expression with nested policy expressions in a compact form:

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        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>
(14)           <sp:HttpsToken RequireClientCertificate="false" />
(15)         </wsp:Policy>
(16)       </sp:TransportToken>
           <!-- Details omitted for readability -->
(17)      </wsp:Policy>
(18)    </sp:TransportBinding>
(19) </wsp:Policy>

Lines (02-18) in this policy expression contain a single transport binding security policy assertion; within its nested policy expression (Lines 03-17), is an algorithm suite assertion (Lines 04-11) whose nested policy expression (Lines 05-10) contains two policy alternatives (Lines 07-08). Generally, a nested policy expression implies recursive processing; in the example above, the behavior indicated by the transport binding assertion requires the behavior indicated by one of the assertions within the algorithm suite assertion.

The example above is equivalent to the following:

(01) <wsp:Policy
        xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
        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>
(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>

In the listing above, the transport binding and its nested policy expression have been duplicated once for each of the nested alternatives in Lines (07-08) of the compact policy. The first alternative (Lines 03-18) contains a single nested algorithm suite alternative (Line 08) as does the second alternative (Lines 19-34 and 24).

4.3.3 Policy Operators

Policies are used to convey a set of capabilities, requirements, and general characteristics of entities (see 1. Introduction). These are generally expressible as a set of policy alternatives. Policy operators (wsp:Policy, wsp:All and wsp:ExactlyOne elements) are used to group policy assertions into policy alternatives. To compactly express complex policies, policy operators MAY be recursively nested; that is, one or more instances of wsp:Policy, wsp:All, and/or wsp:ExactlyOne MAY be nested within wsp:Policy, wsp:All, and/or wsp:ExactlyOne.

The schema outline for the wsp:Policy element in the compact form is as follows:

(01) <wsp:Policy … >
(02)   ( <wsp:Policy …>…</wsp:Policy> |
(03)     <wsp:ExactlyOne>…</wsp:ExactlyOne> |         
(04)     <wsp:All>…</wsp:All> |
(05)     <wsp:PolicyReference … >…</wsp:PolicyReference> |
(06)     …
(07)   )* 
(08) </wsp:Policy>

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

/wsp:Policy

This element is the wsp:Policy operator.

/wsp:Policy/wsp:Policy

This element is a nested wsp:Policy operator.

/wsp:Policy/wsp:ExactlyOne

This element is a nested wsp:ExactlyOne operator.

/wsp:Policy/wsp:All

This element is a nested wsp:All operator.

/wsp:Policy/wsp:PolicyReference

This element references a policy expression to be included per Section 4.3.5 Policy Inclusion.

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

/wsp:Policy/{any}

Additional elements MAY be specified. Such elements MUST NOT use the Web Services Policy language XML namespace name and MUST NOT contradict the semantics of the [parent element].

The schema outline for the wsp:ExactlyOne element in the compact form is as follows:

(01) <wsp:ExactlyOne>
(02)   ( <wsp:Policy … >…</wsp:Policy> |
(03)     <wsp:ExactlyOne>…</wsp:ExactlyOne> |
(04)     <wsp:All>…</wsp:All> |
(05)     <wsp:PolicyReference … >…</wsp:PolicyReference> |
(06)     …
(07)   )* 
(08) </wsp:ExactlyOne>

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

/wsp:ExactlyOne

This element is the wsp:ExactlyOne operator.

/wsp:ExactlyOne/wsp:Policy

This element is a nested wsp:Policy operator.

/wsp:ExactlyOne/wsp:ExactlyOne

This element is a nested wsp:ExactlyOne operator.

/wsp:ExactlyOne/wsp:All

This element is a nested wsp:All operator.

/wsp:ExactlyOne/wsp:PolicyReference

This element references a policy expression to be included per Section 4.3.5 Policy Inclusion.

/wsp:ExactlyOne/{any}

Additional elements MAY be specified. Such elements MUST NOT use the Web Services Policy language XML namespace name and MUST NOT contradict the semantics of the [parent element].

The schema outline for the wsp:All element in the compact form is as follows:

(01) <wsp:All>
(02)   ( <wsp:Policy … >…</wsp:Policy> |
(03)     <wsp:ExactlyOne>…</wsp:ExactlyOne> |
(04)     <wsp:All>…</wsp:All> |
(05)     <wsp:PolicyReference … >…</wsp:PolicyReference> |
(06)     …
(07)   )* 
(08) </wsp:All>

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

/wsp:All

This element is the wsp:All operator.

/wsp:All/wsp:Policy

This element is a nested wsp:Policy operator.

/wsp:All/wsp:ExactlyOne

This element is a nested wsp:ExactlyOne operator.

/wsp:All/wsp:All

This element is a nested wsp:All operator.

/wsp:All/wsp:PolicyReference

This element references a policy expression to be included per Section 4.3.5 Policy Inclusion