W3C

Web Services Policy 1.5 - Attachment

W3C Recommendation 04 September 2007

This version:
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904
Latest version:
http://www.w3.org/TR/ws-policy-attach
Previous version:
http://www.w3.org/TR/2007/PR-ws-policy-attach-20070706/
Editors:
Asir S Vedamuthu, Microsoft Corporation
David Orchard, BEA Systems, Inc.
Frederick Hirsch, Nokia
Maryann Hondo, IBM Corporation
Prasad Yendluri, webMethods (A subsidiary of Software AG)
Toufic Boubez, Layer 7 Technologies
Ümit Yalçinalp, SAP AG.

Please refer to the errata for this document, which may include some normative corrections.

See also translations.

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


Abstract

This specification, Web Services Policy 1.5 - Attachment, defines two general-purpose mechanisms for associating policies, as defined in Web Services Policy 1.5 - Framework, with the subjects to which they apply. This specification also defines how these general-purpose mechanisms may be used to associate policies with WSDL and UDDI descriptions.

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

This is the W3C Recommendation of the Web Services Policy 1.5 - Attachment specification. It has been produced by the Web Services Policy Working Group, which is part of the W3C Web Services Activity.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

The Working Group released a test suite along with an implementation report. A diff-marked version against the previous version of this document is available.

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.

Table of Contents

1. Introduction
2. Notations and Terminology
    2.1 Notational Conventions
    2.2 XML Namespaces
    2.3 Terminology
    2.4 Example
3. Policy Attachment
    3.1 Effective Policy
    3.2 Policy Attachment Mechanisms
    3.3 XML Element Attachment
    3.4 External Policy Attachment
        3.4.1 URI Domain Expression
    3.5 Use of IRIs in Policy Attachment
4. Attaching Policies Using WSDL 1.1
    4.1 Calculating Effective Policy in WSDL 1.1
        4.1.1 Service Policy Subject
        4.1.2 Endpoint Policy Subject
        4.1.3 Operation Policy Subject
        4.1.4 Message Policy Subject
        4.1.5 Example
5. WS-Policy Attachment for WSDL 2.0
    5.1 Example
    5.2 Attaching Policy Expressions
    5.3 Extension to WSDL Component Model
    5.4 Effective Policy
        5.4.1 Service Policy Subject
        5.4.2 Endpoint Policy Subject
        5.4.3 Operation Policy Subject
        5.4.4 Message Policy Subject (input message)
        5.4.5 Message Policy Subject (output message)
        5.4.6 Message Policy Subject (input fault message)
        5.4.7 Message Policy Subject (output fault message)
6. Attaching Policies Using UDDI
    6.1 Calculating Effective Policy and Element Policy in UDDI
        6.1.1 Service Provider Policy Subject
        6.1.2 Service Policy Subject
        6.1.3 Endpoint Policy Subject
    6.2 Referencing Remote Policy Expressions
    6.3 Registering Reusable Policy Expressions
    6.4 Registering Policies in UDDI Version 3
7. Security Considerations
8. Conformance
    8.1 External Policy Attachment Conformance
    8.2 WSDL 1.1 Attachment Conformance
    8.3 WSDL 2.0 Attachment Conformance

Appendices

A. References
    A.1 Normative References
    A.2 Other References
B. UDDI tModel Definitions
    B.1 Remote Policy Reference Category System
        B.1.1 Design Goals
        B.1.2 tModel Definition
        B.1.3 tModel Structure
    B.2 Web Services Policy Types Category System
        B.2.1 Design Goals
        B.2.2 tModel Definition
        B.2.3 tModel Structure
    B.3 Local Policy Reference Category System
        B.3.1 Design Goals
        B.3.2 tModel Definition
        B.3.3 tModel Structure
C. Acknowledgements (Non-Normative)


1. Introduction

The Web Services Policy 1.5 - Framework [Web Services Policy Framework] specification defines an abstract model and an XML-based language for expressing policies of entities in a Web services-based system. This specification, Web Services Policy 1.5 - Attachment, defines two general-purpose mechanisms for associating policies with the subjects to which they apply; the policies may be defined as part of existing metadata about the subject or the policies may be defined independently and associated through an external binding to the subject.

To enable Web Services Policy to be used with existing Web service technologies, this specification describes the use of these general-purpose mechanisms with WSDL [WSDL 1.1, WSDL 2.0 Core Language] definitions and UDDI [UDDI API 2.0, UDDI Data Structure 2.0, UDDI 3.0].

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

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 other than the http://www.w3.org/ns/ws-policy namespace.

  • 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. 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 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 XML Namespace Specification
mtom http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization [WS-MTOMPolicy]
rmp http://docs.oasis-open.org/ws-rx/wsrmp/200702 [WS-RM Policy]
sp http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 [WS-SecurityPolicy]
wsa http://www.w3.org/2005/08/addressing [WS-Addressing Core]
wsam http://www.w3.org/2007/05/addressing/metadata [WS-Addressing Metadata]
wsdl11 http://schemas.xmlsoap.org/wsdl/ [WSDL 1.1]
wsdl20 http://www.w3.org/ns/wsdl [WSDL 2.0 Core Language]
wsoap12 http://schemas.xmlsoap.org/wsdl/soap12/ [WSDL 1.1 Binding for SOAP 1.2]
(none), wsp http://www.w3.org/ns/ws-policy This specification
wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd [WS-Security 2004]
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.

In this document reference is made to the wsu:Id attribute in a utility schema (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd). The wsu:Id attribute was added to the utility schema with the intent that other specifications requiring such an Id could reference it (as is done here).

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

effective policy

The effective policy, for a given policy subject, is the combination of relevant policies. The relevant policies are those attached to policy scopes that contain the policy subject.

element policy

The element policy is the policy attached to the policy subjects associated with the element information item that contains it.

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

merge

A merge consists of serializing each policy as a policy expression, replacing their wsp:Policy element with a wsp:All element, and placing each as children of a wrapper wsp:Policy element.

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

2.4 Example

This specification defines several mechanisms for associating policies (Web Services Policy 1.5 - Framework, [Web Services Policy Framework]) with various XML Web service entities. For brevity, we define two sample policy expressions that the remainder of this document references.

Example 2-1 indicates a policy for reliable messaging [WS-RM Policy]. Example 2-2 is a policy for securing messages using X509 certificates [WS-SecurityPolicy].

Example 2-1. Example RM Policy Expression.

(01) <wsp:Policy
        xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/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="RmPolicy" >
(02)   <rmp:RMAssertion>
(03)    <wsp:Policy/>
(04)   </rmp:RMAssertion>
(05) </wsp:Policy>

Example 2-2. Example X509 Security 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"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
        wsu:Id="X509EndpointPolicy" >
(02)   <sp:AsymmetricBinding>
(03)     <wsp:Policy>
(04)       <sp:RecipientToken>
(05)         <wsp:Policy>
(06)           <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
(07)             <wsp:Policy>
(08)               <sp:WssX509V3Token10 />
(09)             </wsp:Policy>
(10)           </sp:X509Token>
(11)         </wsp:Policy>
(12)       </sp:RecipientToken>
(13)       <sp:InitiatorToken>
(14)         <wsp:Policy>
(15)           <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient" >
(16)             <wsp:Policy>
(17)               <sp:WssX509V3Token10 />
(18)             </wsp:Policy>
(19)           </sp:X509Token>
(20)         </wsp:Policy>
(21)       </sp:InitiatorToken>
(22)       <sp:AlgorithmSuite>
(23)         <wsp:Policy>
(24)           <sp:Basic256Rsa15 />
(25)         </wsp:Policy>
(26)       </sp:AlgorithmSuite>
(27)       <sp:Layout>
(28)         <wsp:Policy>
(29)           <sp:Lax />
(30)         </wsp:Policy>
(31)       </sp:Layout>
(32)       <sp:IncludeTimestamp />
(33)       <sp:OnlySignEntireHeadersAndBody />
(34)     </wsp:Policy>
(35)   </sp:AsymmetricBinding>
(36) </wsp:Policy>

The document containing both of these policy expressions is assumed to be located at http://www.example.com/policies.  Per Section 3.2 Policy Identification of Web Services Policy 1.5 - Framework [Web Services Policy Framework], the IRIs used for these policy expressions in the remainder of this document are http://www.example.com/policies#RmPolicy and http://www.example.com/policies#X509EndpointPolicy, for the examples in Example 2-1 and Example 2-2, respectively.

3. Policy Attachment

This section defines two general-purpose mechanisms for associating policies with one or more policy subjects. The first allows XML-based descriptions of resources (represented as XML elements) to associate policy as part of their intrinsic definition. The second allows policies to be associated with arbitrary policy subjects independently from their definition.

In addition it defines the processing rules for scenarios where multiple policies are attached to a policy subject.

3.1 Effective Policy

Policies will often be associated with a particular policy subject using multiple policy attachments. For example, there may be attachments at different points in a WSDL description that apply to one policy subject, and other attachments may be made by UDDI and other mechanisms.

When multiple attachments are made, their relevent policies can be combined. [Definition: The effective policy, for a given policy subject, is the combination of relevant policies. The relevant policies are those attached to policy scopes that contain the policy subject.]

This combination can be achieved through a merge. [Definition: A merge consists of serializing each policy as a policy expression, replacing their wsp:Policy element with a wsp:All element, and placing each as children of a wrapper wsp:Policy element.] The resulting policy expression is considered to represent the combined policy of all of the attachments to that policy subject.

Such calculated policy expressions have no meaningful IRI of their own.

3.2 Policy Attachment Mechanisms

This section defines two general-purpose mechanisms for associating policies [Web Services Policy Framework] with one or more policy subjects. The first allows XML-based descriptions of resources to associate policy as part of their intrinsic definition. The second allows policies to be associated with arbitrary policy subjects independently from their definition.

The policy scope of an attachment is specific to the policy attachment Mechanism using it. Accordingly, any policy attachment mechanism MUST define the policy scope of the attachment.

3.3 XML Element Attachment

It is often desirable to associate policies with Web services policy subjects represented as XML elements (i.e., WSDL 1.1 elements - Section 4. Attaching Policies Using WSDL 1.1 for the specific details of WSDL attachment).

Since policy assertions are strongly typed by the authors, the precise semantics of how element policy is to be processed once discovered is domain-specific; however, implementations are likely to follow the precedent specified in the section below on WSDL [WSDL 1.1] and Policy.

This specification defines a global attribute that allows policy expressions to be attached to an arbitrary XML element. The following is the schema definition for the wsp:PolicyURIs attribute:

(01) <xs:schema>
(02)   <xs:attribute name="PolicyURIs">
(03)     <xs:simpleType>
(04)    <xs:list itemType="xs:anyURI" />
(05)     </xs:simpleType>
(06)   </xs:attribute>
(07) </xs:schema>

The namespace URI [XML Namespaces] for this attribute is http://www.w3.org/ns/ws-policy.

The wsp:PolicyURIs attribute contains a white space-separated list of one or more IRIs [IETF RFC 3987]. When this attribute is used, each of the values identifies a policy expression as defined by [Web Services Policy Framework]. If more than one IRI is specified, the individual referenced policies need to be merged together to form a single element policy expression. The resultant policy is then associated with the element information item's element policy property. [Definition: The element policy is the policy attached to the policy subjects associated with the element information item that contains it.]

An example of element policy through the use of this global attribute is given below using the sample policies stated in Section 2.4 Example.

If the policies referenced by the following XML element

(01) <MyElement wsp:PolicyURIs="
(02)    http://www.example.com/policies#RmPolicy
(03)    http://www.example.com/policies#X509EndpointPolicy" />

have been processed and merged, it would result in an element policy whose XML 1.0 representation is listed in Example 3-1:

Example 3-1. Example Merged Policy Expression.

(01) <wsp:Policy
            xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"
            xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
            xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02)   <wsp:All>
(03)     <rmp:RMAssertion>
(04)        <wsp:Policy/>
(05)     </rmp:RMAssertion>
(06)   </wsp:All>
(07)   <wsp:All>
(08)     <sp:AsymmetricBinding>
(09)       <wsp:Policy>
(10)         <!-- Details omitted for readability -->
(11)         <sp:IncludeTimestamp />
(12)         <sp:OnlySignEntireHeadersAndBody />
(13)       </wsp:Policy>
(14)     </sp:AsymmetricBinding>
(15)   </wsp:All>
(16) </wsp:Policy>

Note that this element policy has no meaningful IRI.

The presence of the wsp:PolicyURIs attribute does not prohibit implementations from using additional mechanisms for associating policy expressions with XML-based constructs.

Alternatively, rather than using the global attribute, XML elements MAY use the wsp:Policy or wsp:PolicyReference elements directly as children, in order to support element policy (Per Section 4.3.4 Policy References of Web Services Policy 1.5 - Framework [Web Services Policy Framework]), and the semantics for this are the same as for the use of the global attribute. For example, an alternative way of attaching the policies in the above example, using child elements, would be as follows: 

(01) <MyElement>
(02)   <wsp:PolicyReference
(03)      URI="http://www.example.com/policies#RmPolicy" />
(04)   <wsp:PolicyReference
(05)      URI="http://www.example.com/policies#X509EndpointPolicy" />
(06) <MyElement/>

3.4 External Policy Attachment

This mechanism allows policies to be associated with a policy subject independent of that subject's definition and/or representation through the use of a wsp:PolicyAttachment element.

This element has three components: the policy scope of the attachment, the policy expressions being bound, and optional security information. The policy scope of the attachment is defined using one or more extensible domain expressions that identify policy subjects, typically using IRIs.

Domain expressions identify the domain of the association. That is, the set of policy subjects that will be considered for inclusion in the scope using an extensible domain expression model. Domain expressions identify policy subjects to be included within the policy scope. Domain expressions yield an unordered set of policy subjects for consideration.

For the purposes of attaching policy to a policy subject through this mechanism, any policy expression contained inside of the wsp:AppliesTo element MUST NOT be considered in scope. For example, an Endpoint Reference may be used as a domain expression, and it may contain policy expressions within it, but this policy expressions are not considered in scope with respect to the wsp:PolicyAttachment element using it.

The following is the pseudo-schema for the wsp:PolicyAttachment element:

(01) <wsp:PolicyAttachment … >
(02)   <wsp:AppliesTo>
(03)     <x:DomainExpression/> +
(04)   </wsp:AppliesTo>
(05)   ( <wsp:Policy>…</wsp:Policy> |
(06)     <wsp:PolicyReference>…</wsp:PolicyReference> ) +
(07)   <wsse:Security>…</wsse:Security> ?
(08)   …
(09) </wsp:PolicyAttachment>

The following describes the attributes and elements listed in the pseudo-schema outlined above:

/wsp:PolicyAttachment

This describes an external policy attachment.

/wsp:PolicyAttachment/wsp:AppliesTo

This required element's children describe the policy scope.

/wsp:PolicyAttachment/wsp:AppliesTo/{any}

These child elements MUST specify and/or refine the domain expression(s) that define the policy scope. They MUST NOT contradict the semantics of their root element; if an element is not recognized, it SHOULD be ignored. Domain expressions are XML elements that describe policy subjects within a policy scope. When more than one domain expression is present, the policy scope contains the union of the policy subjects identified by each expression.

/wsp:PolicyAttachment/wsp:Policy

This element is a policy expression representing a policy that is attached to the policy subjects within the policy scope.

/wsp:PolicyAttachment/wsp:PolicyReference

This element references a policy expression to be attached to the policy subjects that are in the policy scope. Refer to Web Services Policy 1.5 - Framework [Web Services Policy Framework] for additional details.

/wsp:PolicyAttachment/wsse:Security

This element is of type wsse:Security and allows security information such as signatures to be included. The syntax of this element is described in WS-Security [WS-Security 2004].

/wsp:PolicyAttachment/@{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:PolicyAttachment/{any}

Other child elements for binding constructs MAY be specified but MUST NOT contradict the semantics of the parent element; if an element is not recognized, it SHOULD be ignored.

Domain expressions are used to identify entities such as endpoints, messages or resources with which a policy can be associated. For example, domain expressions may be used to refer to WSDL 1.1 definitions, WSDL 2.0 components, endpoint references, etc.

The following example illustrates the use of this mechanism with an EndpointReference domain expression for a deployed endpoint as defined in Web Services Addressing [WS-Addressing Core]:

(01) <wsp:PolicyAttachment>
(02)   <wsp:AppliesTo>
(03)     <wsa:EndpointReference>
(04)       <wsa:Address>http://www.example.com/acct</wsa:Address>
(05)     </wsa:EndpointReference>
(06)   </wsp:AppliesTo>
(07)   <wsp:PolicyReference
(08)      URI="http://www.example.com/policies#RmPolicy" />
(09) </wsp:PolicyAttachment>

In this example, the policy expression at http://www.example.com/policies#RmPolicy applies to all interactions with the endpoint at http://www.example.com/acct.

3.4.1 URI Domain Expression

This section defines a domain expression for identifying resources as policy subjects for the external attachment mechanism. The following is a pseudo-schema for the URI domain expression:

(01) <wsp:PolicyAttachment … >
(02)   <wsp:AppliesTo>
(03)     <wsp:URI … >xs:anyURI</wsp:URI> *
(04)   </wsp:AppliesTo>
(05)   …
(06) </wsp:PolicyAttachment>

The following describes the URI domain expression element listed in the pseudo-schema outlined above:

/wsp:PolicyAttachment/wsp:AppliesTo/wsp:URI

This element is an IRI that references a resource as a policy subject. There is no requirement that the IRI be resolvable; retrieval mechanisms are beyond the scope of this specification.

/wsp:PolicyReference/wsp:AppliesTo/wsp:URI/@{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.

URI domain expressions are used to identify resources that are identified using IRI or IRI References (such as endpoint, message or operation definitions) with which policies can be associated. For example, URI domain expressions can be used to identify WSDL 1.1 definitions, WSDL 2.0 components, etc. When a URI domain expression identifies multiple resources, i.e. WSDL 1.1 supports multiple operations with the same name (sometimes called operation name overloading), the Policy applies to all the resources that are identified.

IRI References for WSDL 2.0 components are defined in Appendix C of the Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language [WSDL 2.0 Core Language]. The following example illustrates the use of URI domain expression with a WSDL 2.0 IRI Reference:

(01) <wsp:PolicyAttachment>
(02)   <wsp:AppliesTo>
(03)     <wsp:URI>http://example.org/TicketAgent.wsdl20#wsdl.endpoint(TicketAgentService/Endpoint)</wsp:URI>
(04)   </wsp:AppliesTo>
(05)   <wsp:PolicyReference URI="http://www.example.com/policies#RmPolicy" />
(06)  </wsp:PolicyAttachment>

In this example, the policy expression at http://www.example.com/policies#RmPolicy applies to all interactions with the endpoint at http://example.org/TicketAgent.wsdl20#wsdl.endpoint(TicketAgentService/Endpoint).

IRI References for WSDL 1.1 elements are defined in WSDL 1.1 Element Identifiers [WSDL11 ElementIds].

The scope of URI domain expressions for WSDL 2.0 components or WSDL 1.1 elements is limited to the subjects defined in Section 5. WS-Policy Attachment for WSDL 2.0 and 4. Attaching Policies Using WSDL 1.1.

3.5 Use of IRIs in Policy Attachment

Policy attachment mechanisms 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.

4. Attaching Policies Using WSDL 1.1

This section describes a mechanism for associating policy expressions with Web service constructs in WSDL 1.1 [WSDL 1.1]. The mechanism consists of:

WSDL 1.1 disallows the use of extensibility elements on certain elements and the use of extensibility attributes on others. However, the WS-I Basic Profile 1.1 [BP 1.1] overrules this restriction and allows element extensibility everywhere. Therefore, when attaching a reference directly to the WSDL element the policy reference SHOULD be attached using wsp:PolicyReference as child element unless it is absolutely necessary to maintain the original WSDL 1.1 restriction, in which case the @wsp:PolicyURIs attribute MAY be used for the following WSDL elements:

If it is necessary to include the actual policy expressions within the WSDL description itself, it is RECOMMENDED that their wsp:Policy elements be included as children of the wsdl11:definition element, and referenced using the mechanisms just described. Alternatively, the policy expressions MAY be made available through some other means, such as WS-MetadataExchange [WS-MetadataExchange].

To ensure that consumers of policy-annotated WSDL elements are capable of processing such policy attachments, attachments using wsp:PolicyReference SHOULD be marked as a mandatory extension (e.g., with a @wsdl11:required="true" attribute).

The rest of this section defines how to interpret the policy attachments when they appear within a WSDL description.

4.1 Calculating Effective Policy in WSDL 1.1

Policy attachments in WSDL 1.1 can be used to associate policies with four different types of policy subject, identified as the service policy subject, the endpoint policy subject, the operation policy subject, and the message policy subject. These policy subjects should be considered as nested, due to the hierarchical nature of WSDL.

When attaching a policy to a WSDL element, a policy scope is implied for that attachment. The policy scope only contains the policy subject associated with that element and not those associated with the children of that element. Therefore, it is RECOMMENDED that each policy assertion contained within a WSDL element's element policy should have the correct semantic such that the policy subject for that assertion is that WSDL element. For example, assertions that describe behaviours regarding the manipulation of messages should only be contained within policies attached to WSDL message elements.

Figure 1 represents how the effective policies, with regard to WSDL, are calculated for each of these policy subjects. In the diagram, the dashed boxes represent policy scopes implied by WSDL elements. For a particular policy subject, the effective policy MUST merge the element policy of each element with a policy scope that contains the policy subject.

For abstract WSDL definitions, the element policy is considered an intrinsic part of the definition and applies to all uses of that definition. In particular, it MUST be merged into the effective policy of every implementation of that abstract WSDL definition.

Policies that are attached to a deployed resource (e.g., services or ports) are only considered in the effective policy of that deployed resource itself.


Effective Policy and Policy Scopes in WSDL

Figure 4-1. Effective Policy and Policy Scopes in WSDL


(This graphic is also available in SVG format here.)

When attaching policies at different levels of the WSDL hierarchy, care must be taken. A message exchange with an endpoint MAY be described by the effective policies in all four subject types simultaneously.

For example, in Figure 4-1, for a particular input message to a deployed endpoint, there are four policy subjects involved, each with their own effective policy. There is an effective policy for the message, as well as an effective policy for the parent operation of that message, an effective policy for the deployed endpoint, and the effective policy for the service as a whole. All four effective policies are applicable in relation to that specific input message.

It is RECOMMENDED that, where specific policy assertions associated with one policy subject are only compatible with specific policy assertions on another policy subject in the same hierarchical chain, the policies containing these assertions should be attached within a single WSDL binding hierarchy.

For any given port, the policy alternatives for each policy subject type SHOULD be compatible with each of the policy alternatives at each of the policy subjects parent and child policy subjects, such that choices between policy alternatives at each level are independent of each other.

The rest of this section describes these policy subject types, and how the effective policy for each policy subject is calculated.

4.1.1 Service Policy Subject

The following WSDL 1.1 element is considered as the service policy subject:

  • wsdl11:service

This element MAY have element policy as per Section 3. Policy Attachment, and if present MUST be merged into the effective policy of the WSDL service policy subject.

A policy associated with a service policy subject applies to any message exchange using any of the endpoints offered by that service.

4.1.2 Endpoint Policy Subject

The following WSDL 1.1 elements collectively describe an endpoint:

  • wsdl11:port

  • wsdl11:portType

  • wsdl11:binding

These elements MAY have element policy as per Section 3. Policy Attachment. The policy scope implied by each of these elements contains the endpoint policy subject representing the deployed endpoint.

Since the wsdl11:portType may be used by more than one binding, it is RECOMMENDED that only policies containing abstract (i.e., binding independent) assertions should be attached to this type of element.

Policies associated with an endpoint policy subject apply to any message exchange made using that endpoint.

The effective policy for a WSDL endpoint policy subject includes the element policy of the wsdl11:port element that defines the endpoint merged with the element policy of the referenced wsdl11:binding element and the element policy of the referenced wsdl11:portType element that defines the interface of the endpoint.

4.1.3 Operation Policy Subject

The following WSDL 1.1 elements collectively describe an operation:

  • wsdl11:portType/wsdl11:operation

  • wsdl11:binding/wsdl11:operation

These elements MAY have element policy as per Section 3. Policy Attachment.

The policy scope implied by each of these elements contains the operation policy subject representing the specific operation of the endpoint policy subject.

Since the wsdl11:portType/wsdl11:operation may be used by more than one binding, it is RECOMMENDED that only policies containing abstract (i.e., binding independent) assertions should be attached to this type of element.

Policies associated with an operation policy subject apply to the message exchange described by that operation.

The effective policy for a WSDL operation policy subject is calculated in relation to a specific port, and includes the element policy of the wsdl11:portType/wsdl11:operation element that defines the operation merged with that of the corresponding wsdl11:binding/wsdl11:operation element.

4.1.4 Message Policy Subject

The following WSDL 1.1 elements are used to describe messages:

  • wsdl11:message

  • wsdl11:portType/wsdl11:operation/wsdl11:input

  • wsdl11:portType/wsdl11:operation/wsdl11:output

  • wsdl11:portType/wsdl11:operation/wsdl11:fault

  • wsdl11:binding/wsdl11:operation/wsdl11:input

  • wsdl11:binding/wsdl11:operation/wsdl11:output

  • wsdl11:binding/wsdl11:operation/wsdl11:fault

These elements MAY have element policy as per Section 3. Policy Attachment.

The policy scope implied by these elements contains the message policy subject representing the specific input, output, or fault message in relation to the operation policy subject.

Policies associated with a message policy subject apply to that message (i.e. input, output or fault message).

The effective policy for a specific WSDL message (i.e., input, output, or fault message) is calculated in relation to a specific port, and includes the element policy of the wsdl11:message element that defines the message's type merged with the element policy of the wsdl11:binding and wsdl11:portType message definitions that describe that message.

For example, the effective policy of a specific input message for a specific port would be the merge of the wsdl11:message element defining the message type, the wsdl11:portType/wsdl11:operation/wsdl11:input element, and the corresponding wsdl11:binding/wsdl11:operation/wsdl11:input element for that message.

Since a wsdl11:message may be used by more than one wsdl11:portType, it is RECOMMENDED that only policies containing abstract (i.e., binding independent) assertions should be attached to this type of element.

Since wsdl11:input, wsdl11:output, and wsdl11:fault elements in a  wsdl11:portType/wsdl11:operation may be used by more than one binding, it is RECOMMENDED that only policies containing abstract (i.e., binding independent) assertions should be attached to these types of elements.

Care should be taken when attaching policies to outbound messages as the result may not be what is expected. For example, expressing a choice on a service's outbound message without a mechanism for a requester of that service to communicate its choice to the service before the outbound message is sent may not result in the desired behaviours. It is therefore RECOMMENDED that policy alternatives on outbound messages SHOULD be avoided without the use of some form of mutual policy exchange between the parties involved.

4.1.5 Example

As an example of the combination of these policy subjects and effective policy calculation, consider the WSDL type definition in Example 4-1 that references policies.

Example 4-1. Example Policy Attached to WSDL.

(01) <wsdl11:definitions name="StockQuote"
        targetNamespace="http://www.example.com/stock/binding"
        xmlns:tns="http://www.example.com/stock/binding"
        xmlns:fab="http://www.example.com/stock"
        xmlns:rmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702"
        xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
        xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
        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)   <wsp:Policy wsu:Id="RmPolicy" >
(03)     <rmp:RMAssertion>
(04)       <wsp:Policy/>
(05)     </rmp:RMAssertion>
(06)   </wsp:Policy>
(07)     <wsp:Policy wsu:Id="X509EndpointPolicy" >
(08)       <sp:AsymmetricBinding>
(09)         <wsp:Policy>
               <!-- Details omitted for readability -->
(10)           <sp:IncludeTimestamp />
(11)           <sp:OnlySignEntireHeadersAndBody />
(12)         </wsp:Policy>
(13)       </sp:AsymmetricBinding>
(14)     </wsp:Policy>
(15)     <wsp:Policy wsu:Id="SecureMessagePolicy" >
(16)       <sp:SignedParts>
(17)         <sp:Body />
(18)       </sp:SignedParts>
(19)       <sp:EncryptedParts>
(20)         <sp:Body />
(21)       </sp:EncryptedParts>
(22)     </wsp:Policy>
(23)     <wsdl11:import namespace="http://www.example.com/stock"
            location="http://www.example.com/stock/stock.wsdl" />
(24)     <wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
(25)       <wsoap12:binding style="document"
(26)          transport="http://schemas.xmlsoap.org/soap/http" />
(27)       <wsp:PolicyReference URI="#RmPolicy" wsdl11:required="true" />
(28)       <wsp:PolicyReference URI="#X509EndpointPolicy" wsdl11:required="true" />
(29)       <wsdl11:operation name="GetLastTradePrice" >
(30)         <wsoap12:operation soapAction="http://www.example.com/stock/Quote/GetLastTradePriceRequest" />
(31)           <wsdl11:input>
(32)             <wsoap12:body use="literal" />
(33)             <wsp:PolicyReference URI="#SecureMessagePolicy"
                                      wsdl11:required="true" />
(34)           </wsdl11:input>
(35)           <wsdl11:output>
(36)             <wsoap12:body use="literal" />
(37)             <wsp:PolicyReference URI="#SecureMessagePolicy"
(38)                                  wsdl11:required="true" />
(39)           </wsdl11:output>
(40)       </wsdl11:operation>
(41)     </wsdl11:binding>
(42) </wsdl11:definitions>

For endpoints bound to StockQuoteSoapBinding, the effective policy of the endpoint is listed in Example 3-1 (above). For the GetLastTradePrice operation, an additional message-level effective policy is in effect for the input message, whose XML 1.0 representation is listed in Example 4-2.

Example 4-2. Example Message Security 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"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
        wsu:Id="SecureMessagePolicy" >
(02)   <sp:SignedParts>
(03)     <sp:Body />
(04)   </sp:SignedParts>
(05)   <sp:EncryptedParts>
(06)     <sp:Body />
(07)   </sp:EncryptedParts>
(08) </wsp:Policy>

5. WS-Policy Attachment for WSDL 2.0

This section describes a mechanism for associating policy expressions with Web service constructs in WSDL 2.0. The mechanism consists of:

2.2 XML Namespaces lists all the XML Namespaces that are used in this section. (XML elements without a namespace prefix are from the Web Services Policy XML Namespace.)

5.1 Example

The example below illustrates the use of WS-Policy Attachment for WSDL 2.0:

Example 5-1. Example Policy Attached to WSDL 2.0

(01) <wsdl20:description>
(02) …
(03)   <wsp:Policy wsu:Id="common">
(04)     <mtom:OptimizedMimeSerialization wsp:Optional="true"/>
(05)     <wsam:Addressing>…</wsam:Addressing>
(06)   </wsp:Policy>

(07)   <wsp:Policy wsu:Id="secure">
(08)     <wsp:ExactlyOne>
(09)       <sp:TransportBinding>…</sp:TransportBinding>
(10)       <sp:AsymmetricBinding>…</sp:AsymmetricBinding >
(11)     </wsp:ExactlyOne>
(12)   </wsp:Policy>

(13)   <wsdl20:binding name="SecureBinding"
(14)       interface="tns:RealTimeDataInterface" >
(15)     <wsp:PolicyReference URI="#secure" />
(16)     <wsdl20:operation name="GetRealQuote" >…</wsdl20:operation>
(17)     …
(18)   </wsdl20:binding>

(19)   <wsdl20:service name="RealTimeDataService"
(20)        interface="tns:RealTimeDataInterface" >
(21)     <wsdl20:endpoint name="RealTimeDataPort" 
(22)          binding="tns:SecureBinding">
(23)       <wsp:PolicyReference URI="#common" />
(24)       …
(25)     </wsdl20:endpoint>
(26)   </wsdl20:service>
(27) …
(28) </wsdl20:description>

The SecureBinding WSDL binding description describes a binding for an interface that provides real-time quotes and book information on securities. (The prefixes wsdl20 and tns are used here to denote the Web Services Description Language 2.0 XML Namespace and the target namespace of this WSDL document respectively.) To require the use of security for these offerings, a policy expression that requires the use of either transport-level or message-level security is attached to the binding description. The policy expression applies to any message exchange associated with any endpoint that supports this binding description.

The RealTimeDataPort WSDL endpoint description describes an endpoint that supports the SecureBinding WSDL binding description. To require the use of addressing and allow the use of optimization (Optimized MIME Serialization as defined in the MTOM specification [MTOM]), a policy expression that represents the addressing requirement and optimization capability is attached to the endpoint description. The policy expression applies to any message exchange associated with the RealTimeDataPort endpoint.

In the above example, the #secure and #common policy expressions attached to the SecureBinding WSDL binding and RealTimeDataPort WSDL endpoint descriptions collectively apply to any message exchange associated with the RealTimeDataPort endpoint. The example below represents the combination of these two policies, that is, the effective policy for the RealTimeDataPort endpoint.

Example 5-2. Effective Policy for the RealTimeDataPort endpoint

(01) <wsp:Policy>
(02)   <wsp:All>
(03)     <wsp:Policy>
(04)       <mtom:OptimizedMimeSerialization wsp:Optional="true"/>
(05)       <wsam:Addressing>…</wsam:Addressing>
(06)     </wsp:Policy>
(07)     <wsp:Policy>
(08)       <wsp:ExactlyOne>
(09)         <sp:TransportBinding>…</sp:TransportBinding>
(10)         <sp:AsymmetricBinding>…</sp:AsymmetricBinding >
(11)       </wsp:ExactlyOne>
(12)     </wsp:Policy>
(13)   </wsp:All>
(14) </wsp:Policy>

5.2 Attaching Policy Expressions

Policy attachment points in a WSDL 2.0 document are:

  • wsdl20:service

  • wsdl20:endpoint

  • wsdl20:binding

  • wsdl20:binding/wsdl20:operation

  • wsdl20:binding/wsdl20:fault

  • wsdl20:binding/wsdl20:operation/wsdl20:input

  • wsdl20:binding/wsdl20:operation/wsdl20:output

  • wsdl20:binding/wsdl20:operation/wsdl20:infault

  • wsdl20:binding/wsdl20:operation/wsdl20:outfault

  • wsdl20:interface

  • wsdl20:interface/wsdl20:operation

  • wsdl20:interface/wsdl20:fault

  • wsdl20:interface/wsdl20:operation/wsdl20:input

  • wsdl20:interface/wsdl20:operation/wsdl20:output

  • wsdl20:interface/wsdl20:operation/wsdl20:infault and

  • wsdl20:interface/wsdl20:operation/wsdl20:outfault.

Any of these elements MAY have one or more wsp:Policy or wsp:PolicyReference child elements.

Policy attachment points in a WSDL document are associated with specific policy subjects as described in the table below. There are four policy subjects in WSDL: the service policy subject, the endpoint policy subject, the operation policy subject and the message policy subject. When a policy expression is attached to a policy subject in a WSDL document, capabilities and requirements represented by the policy expression apply to any message exchange or message associated with (or described by) the policy subject.

Table 5-1. Association of Policy Attachment Points with Policy Subjects
Policy Attachment Point in a WSDL document WSDL Component Policy Subject
wsdl20:service Service Service
wsdl20:endpoint Endpoint Endpoint
wsdl20:binding Binding
wsdl20:interface Interface
wsdl20:binding/wsdl20:operation Binding Operation Operation
wsdl20:interface/wsdl20:operation Interface Operation
wsdl20:binding/wsdl20:operation/ wsdl20:input Binding Message Reference Message for an input message
wsdl20:interface/wsdl20:operation/wsdl20:input Interface Message Reference whose {direction} property is ‘in’
wsdl20:binding/wsdl20:operation/ wsdl20:output Binding Message Reference Message for an output message
wsdl20:interface/wsdl20:operation/ wsdl20:output Interface Message Reference whose {direction} property is ‘out’
wsdl20:binding/wsdl20:fault Binding Fault Message for an input fault message
wsdl20:binding/wsdl20:operation/ wsdl20:infault Binding Fault Reference
wsdl20:interface/wsdl20:fault Interface Fault
wsdl20:interface/wsdl20:operation/wsdl20:infault Interface Fault Reference whose {direction} property is ‘in’
wsdl20:binding/wsdl20:fault Binding Fault Message for an output fault message
wsdl20:binding/wsdl20:operation/wsdl20:outfault Binding Fault Reference
wsdl20:interface/wsdl20:fault Interface Fault
wsdl20:interface/wsdl20:operation/wsdl20:outfault Interface Fault Reference whose {direction} property is ‘out’

For a WSDL component, the attached policy (extension to the WSDL component model is described in 5.3 Extension to WSDL Component Model) is considered an intrinsic part of the WSDL component definition and applies to all uses of that definition. For example, when attached to a WSDL Interface component, capabilities and requirements represented by a policy apply to all the use of this WSDL Interface description. When attached to a WSDL Binding component, capabilities and requirements represented by a policy apply to all the Endpoints that support this binding description.

A policy associated with a service policy subject applies to any message exchange (that is explicitly described by the Interface component in the Service component's {interface} property) using any of the endpoints offered by that service.

Policies associated with an endpoint policy subject apply to any message exchange (that is explicitly described by the Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property) made using that endpoint. Given that a WSDL Interface component may be used by one or more binding descriptions, it is RECOMMENDED that only a policy containing policy assertions that apply to any possible binding description should be attached.

Policies associated with an operation policy subject apply to the message exchange described by that operation. Given that a WSDL Interface Operation component may be used by one or more binding descriptions, it is RECOMMENDED that only a policy containing policy assertions that apply to any possible binding description should be attached.

Policies associated with a message policy subject apply to that message (input, output or fault). Given that a WSDL Interface Message Reference, Interface Fault, Interface Fault Reference components may be used by one or more binding descriptions, it is RECOMMENDED that only a policy containing policy assertions that apply to any possible binding should be attached.

Policies MAY be attached at different levels of the WSDL component hierarchy. A message exchange with an endpoint MAY be described by the policies in all four policy subjects simultaneously.

The common mechanism of associating a policy expression with a policy subject is to attach a reference to the policy expression to the policy subject. As described in the WS-Policy specification [Web Services Policy Framework], a reference to a policy expression is represented using the wsp:PolicyReference element. A policy attachment to a WSDL element is represented by attaching a wsp:PolicyReference element as a child element of the WSDL element.

Policy expressions can be included within a WSDL document or may reside external to a WSDL document. If including policy expressions with a WSDL document is the chosen approach, it is RECOMMENDED that the wsp:Policy elements are included as children of the wsdl20:description element after the wsdl20:types element and referenced using the wsp:PolicyReference elements.

To mandate the processing of a policy expression attached to a policy attachment point in a WSDL document, the expression MUST be marked as required using the @wsdl20:required flag.

If the wsp:Policy elements are included as children of the wsdl20:description element, these Policy elements MUST NOT be marked as required using the @wsdl20:required. (Note: these policy expressions may be included as children of the wsdl20:description element and may not be attached to any policy attachment point in a WSDL document.)

5.3 Extension to WSDL Component Model

This document adds an optional {policy} property to the following WSDL components:

  • Service

  • Endpoint

  • Binding

  • Binding Operation

  • Binding Fault

  • Binding Message Reference

  • Binding Fault Reference

  • Interface

  • Interface Operation

  • Interface Fault

  • Interface Message Reference

  • Interface Fault Reference

The {policy} property, when present, represents the capabilities and requirements as a policy. The value of the {policy} property is a policy as defined by Section 3 - Policy Model in the WS-Policy specification [Web Services Policy Framework]. The following table describes the mapping from XML representation to the {policy} property.

Table 5-2. Mapping from XML representation to the {policy} property
Component Value
Service A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:service element.
Endpoint A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:endpoint element.
Binding A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:binding element.
Binding Operation A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:binding/wsdl20:operation element.
Binding Fault A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:binding/wsdl20:fault element.
Binding Message Reference A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:binding/wsdl20:operation/wsdl20:input or wsdl20:binding/wsdl20:operation/wsdl20:output element.
Binding Fault Reference A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:binding/wsdl20:operation/wsdl20:infault or wsdl20:binding/wsdl20:operation/wsdl20:outfault element.
Interface A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:interface element.
Interface Operation A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:interface/wsdl20:operation element, if any.
Interface Fault A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:interface/wsdl20:fault element.
Interface Message Reference A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:interface/wsdl20:operation/wsdl20:input or wsdl20:interface/wsdl20:operation/wsdl20:output element.
Interface Fault Reference A policy corresponding to the merge of wsp:Policy or wsp:PolicyReference elements, if any, in the [children] of the wsdl20:interface/wsdl20:operation/wsdl20:infault or wsdl20:interface/wsdl20:operation/wsdl20:outfault element.

Two {policy} properties are equivalent when they represent policies that contain the same number of policy alternatives, and each policy alternative in the first policy is equivalent to some policy alternative in the second policy, and conversely.

Two policy alternatives are equivalent when each policy assertion in the first policy alternative is equivalent to some policy assertion in the second policy alternative, and conversely. If either policy alternative contains multiple policy assertions of the same type, policy alternative equality is dependent on the semantics of that assertion type.

Two policy assertions are equivalent if they have the same QName, if either policy assertion is an ignorable policy assertion, both assertions must be ignorable policy assertions and, if either policy assertion has a nested policy, both assertions must have a nested policy and the nested policies must be equal. If either assertion contains policy assertion parameters, then the policy assertion parameters SHOULD be compared for equality. Comparing policy assertion parameters for equality is not defined by this document, but policy assertion equality may be further refined by the corresponding policy assertion specification.

5.4 Effective Policy

The following diagram illustrates the four policy subjects in WSDL and how the effective policy is calculated for each of these policy subjects.


Policy Subjects and Effective Policy in WSDL 2.0

Figure 5-1. Policy Subjects and Effective Policy in WSDL 2.0


If multiple policies are attached to WSDL components that collectively represent a policy subject then the effective policy of these policies applies. (For example, there is a policy attached to an Endpoint component that describes the component and there is a policy attached to the Binding component in the Endpoint component’s {binding} property.) The effective policy is the merge of the policies that are attached to the same policy subject. The rest of this section describes how the effective policy is calculated for each of these policy subjects.

5.4.1 Service Policy Subject

The effective policy of a service policy subject is the policy in the {policy} property of a Service component that describes the service.

5.4.2 Endpoint Policy Subject

The effective policy of an endpoint policy subject is the merge of policies in the {policy} properties of:

  • An Endpoint component that describes the endpoint,

  • The Binding component in the Endpoint component’s {binding} property,

  • The Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property and

  • The Interface components in the {extended interfaces} property of the Interface component in the Service component’s {interface} property of the Endpoint component’s {parent} property.

5.4.3 Operation Policy Subject

If the Binding component has an Interface component in the {interface} property, then the effective policy of an operation policy subject MAY be calculated by merging the policies in the {policy} properties of:

  • The Interface Operation component that describes the operation and

  • The Binding Operation component (if any) whose {interface operation} property has the Interface Operation component.

If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an operation policy subject MUST be calculated in relation to a specific endpoint, and is the policy in the {policy} property of the Interface Operation component that describes the operation.

5.4.4 Message Policy Subject (input message)

If the Binding component has an Interface component in the {interface} property, then the effective policy of an input message MAY be calculated by merging the policies in the {policy} properties of:

  • The Interface Message Reference component that describes the input message and

  • The Binding Message Reference component whose {interface message reference} property has the Interface Message Reference component.

If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an input message MUST be calculated in relation to a specific endpoint, and is the policy in the {policy} property of the Interface Message Reference component that describes the input message.

5.4.5 Message Policy Subject (output message)

If the Binding component has an Interface component in the {interface} property, then the effective policy of an output message MAY be calculated by merging the policies in the {policy} properties of:

  • The Interface Message Reference component that describes the output message and

  • The Binding Message Reference component whose {interface message reference} property has the Interface Message Reference component.

If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an output message MUST be calculated in relation to a specific endpoint, and is the policy in the {policy} property of the Interface Message Reference component that describes the output message.

5.4.6 Message Policy Subject (input fault message)

If the Binding component has an Interface component in the {interface} property, then the effective policy of an input fault message MAY be calculated by merging the policies in the {policy} properties of:

  • The Interface Fault Reference component that describes the input fault message,

  • The Interface Fault component in the Interface Fault Reference component’s {interface fault} property,

  • The Binding Fault Reference component whose {interface fault reference} property has the Interface Fault Reference component and

  • The Binding Fault component whose {interface fault} property has the Interface Fault component in the Interface Fault Reference component’s {interface fault} property.

If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an input fault message MUST be calculated in relation to a specific endpoint, and is the merge of policies in the {policy} properties of:

  • The Interface Fault Reference component that describes the input fault message and

  • The Interface Fault component in the Interface Fault Reference component’s {interface fault} property.

5.4.7 Message Policy Subject (output fault message)

If the Binding component has an Interface component in the {interface} property, then the effective policy of an output fault message MAY be calculated by merging the policies in the {policy} properties of:

  • The Interface Fault Reference component that describes the output fault message,

  • The Interface Fault component in the Interface Fault Reference component’s {interface fault} property,

  • The Binding Fault Reference component whose {interface fault reference} property has the Interface Fault Reference component and

  • The Binding Fault component whose {interface fault} property has the Interface Fault component in the Interface Fault Reference component’s {interface fault} property for the endpoint.

If the Binding component does not have an Interface component in the {interface} property, then the effective policy of an output fault message MUST be calculated in relation to a specific endpoint, and is the merge of policies in the {policy} properties of:

  • The Interface Fault Reference component that describes the output fault message and

  • The Interface Fault component in the Interface Fault Reference component’s {interface fault} property.

6. Attaching Policies Using UDDI

This section defines a mechanism for associating policies with policy subjects through the use of UDDI. It defines a minimum level of support for associating policy expressions with entities in a UDDI registry. The calculation of effective policy for UDDI entities is described in Section 6.1 Calculating Effective Policy and Element Policy in UDDI. While the general concept for associating policy expressions with UDDI entities, which is specified in Sections 6.2 Referencing Remote Policy Expressions and 6.3 Registering Reusable Policy Expressions, is based on UDDI Version 2 [UDDI API 2.0, UDDI Data Structure 2.0], the necessary changes with respect to UDDI Version 3 [UDDI 3.0] are explained in Section 6.4 Registering Policies in UDDI Version 3.

There are essentially two approaches for registering policies in UDDI. One approach is to directly reference remotely accessible policy expressions in UDDI entities, the other is to register policy expressions as distinct tModels and then reference these tModels in each UDDI entity that is using the policy expression. While the former approach (see Section 6.2 Referencing Remote Policy Expressions) is expected to be used for policy expressions that are mainly unique for a given Web service, the latter approach (see Section 6.3 Registering Reusable Policy Expressions) is expected to be used for more modular and reusable policy expressions.

6.1 Calculating Effective Policy and Element Policy in UDDI

When attaching a policy to a UDDI entity a policy scope is implied for that attachment. The policy scope only contains the policy subjects associated with that entity, and not those associated with the children of that entity. This policy is the entity's element policy.

Each policy assertion contained within a UDDI entity's element policy should have the correct semantic such that the policy subject for that assertion is that UDDI entity. For example, assertions that describe behaviours regarding a service provider should only be contained within policies attached to a businessEntity structure.

For UDDI tModels that represent Web service types, the element policy is considered an intrinsic part of the tModel and applies to all uses of that tModel. In particular, it MUST be merged into the effective policy of every bindingTemplate that references that tModel.

Policies that apply to deployed Web services (bindingTemplates) are only considered in the effective policy of that deployed resource itself.

Each of these entities MAY have an element policy per Section 3. Policy Attachment. The remainder of this section defines how that element policy is interpreted to calculate the effective policy.

6.1.1 Service Provider Policy Subject

The following UDDI element is considered as the service provider policy subject:

  • uddi:businessEntity

This element MAY have element policy as per Section 3. Policy Attachment, and if present MUST be merged into the effective policy of the UDDI businessEntity Subject.

Policy attached to the service provider policy subject applies to behaviors or aspects of the service provider as a whole, irrespective of interactions over any particular service. This includes — but is not limited to — acting as a service consumer or a service provider in general.

6.1.2 Service Policy Subject

The following UDDI element is considered as the service policy subject:

  • uddi:businessService

This element MAY have element policy as per Section 3. Policy Attachment, and if present MUST be merged into the effective policy of the UDDI businessService Subject.

Policy attached to the service policy subject applies to behaviors or aspects of the service as a whole, irrespective of interactions over any particular endpoint. This includes — but is not limited to — acting as a consumer or a provider of the service.

6.1.3 Endpoint Policy Subject

The following UDDI elements collectively describe an endpoint:

  • uddi:bindingTemplate

  • uddi:tModel

These elements MAY have element policy as per Section 3. Policy Attachment. The policy scope implied by each of these elements contains the endpoint policy subject representing the deployed endpoint.

An endpoint policy subject applies to behaviours associated with an entire endpoint of the service, irrespective of any message exchange made. This includes — but is not limited to — aspects of communicating with or instantiating the endpoint.

The effective policy for a UDDI endpoint includes the element policy of the uddi:bindingTemplate element that defines the endpoint merged with the element policy of those uddi:tModel elements that are referenced in contained uddi:tModelInstanceInfo elements.

6.2 Referencing Remote Policy Expressions

UDDI tModels provide a generic mechanism for associating arbitrary metadata with services and other entities in a UDDI registry. To properly integrate Web Services Policy into the UDDI model, Web Services Policy 1.5 - Attachment pre-defines one tModel that is used to associate a remotely accessible policy with an entity in a UDDI registry.

This new tModel is called the remote policy reference category system and is defined in Appendix B.1 Remote Policy Reference Category System.

UDDI registries MUST use the (UDDI V2 [UDDI Data Structure 2.0]) tModelKey uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1 to uniquely identify this tModel so that UDDI registry users can expect the same behavior across different UDDI registries.

The tModel's valid values are those IRIs that identify external policy expressions; that is, when referencing this category system in a categoryBag, the corresponding keyValue of the keyedReference is the IRI of the policy expression.

Using the remote policy reference category system, one can then associate a policy expression with a businessEntity, a businessService, and a tModel using the entity's categoryBag. For example, associating the policy expression that is identified by the IRI http://www.example.com/myservice/policy with a businessService is done as follows: 

(01) <businessService serviceKey="…" >
(02)   <name>…</name>
(03)   <description>…</description>
(04)   <bindingTemplates>…</bindingTemplates>
(05)   <categoryBag>
(06)     <keyedReference
(07)        keyName="Policy Expression for example's Web services"
(08)        keyValue="http://www.example.com/myservice/policy"
(09)        tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" />
(10)   </categoryBag>
(11) </businessService>

The tModelKey of the keyedReference MUST match the fixed tModelKey from the remote policy reference category system. The keyValue MUST be the IRI that identifies the policy expression.

A different approach has to be taken to associate a policy expression with a bindingTemplate, since bindingTemplates do not contain a categoryBag in UDDI Version 2. Therefore, the bindingTemplate's tModelInstanceInfo and instanceParms MUST be used as follows: 

(01) <bindingTemplate bindingKey="…" >
(02)   <accessPoint>…</accessPoint>
(03)   <tModelInstanceDetails>
(04)     <tModelInstanceInfo
(05)        tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" >
(06)       <instanceDetails>
(07)         <instanceParms>
(08)           http://www.example.com/myservice/policy
(09)         </instanceParms>
(10)       </instanceDetails>
(11)     </tModelInstanceInfo>
(12)   </tModelInstanceDetails>
(13) </bindingTemplate>

The tModelKey of the tModelInstanceInfo MUST match the fixed tModelKey from the remote policy reference category system as defined above. The instanceParms MUST be the IRI that identifies the policy expression.

6.3 Registering Reusable Policy Expressions

In addition to using the approach outlined in the section above, publishers may register a specific policy expression in a UDDI registry as a distinct tModel. To properly categorize tModels as policy expressions, Web Services Policy 1.5 - Attachment pre-defines the Web Services Policy Types category system as a tModel. This tModel is defined in Appendix B.2 Web Services Policy Types Category System.

The following illustrates a tModel for the policy expression identified by the IRI http://www.example.com/myservice/policy.

(01) <tModel tModelKey="uuid:04cfa…">
(02)   <name>…</name>
(03)   <description xml:lang="EN">
(04)     Policy Expression for example's Web services
(05)   </description>
(06)   <overviewDoc>
(07)     <description xml:lang="EN">Web Services Policy Expression</description>
(08)     <overviewURL>http://www.example.com/myservice/policy</overviewURL>
(09)   </overviewDoc>
(10)   <categoryBag>
(11)     <keyedReference
(12)        keyName="Reusable policy Expression"
(13)        keyValue="policy"
(14)        tModelKey="uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" />
(15)     <keyedReference
(16)        keyName="Policy Expression for example's Web services"
(17)        keyValue="http://www.example.com/myservice/policy"
(18)        tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" />
(19)   </categoryBag>
(20) </tModel>

The first keyedReference specifies that the tModel represents a policy expression — rather than only being associated with one — by using the Web Services Policy Types category system's built-in category "policy", which is its single valid value. This is necessary in order to enable UDDI inquiries for policy expressions in general. The second keyedReference designates the policy expression the tModel represents by using the approach from the section above. This is necessary in order to enable UDDI inquiries for particular policy expressions based on their IRI.

Note that the policy expression IRI is also specified in the tModel's overview URL to indicate that it is a resolvable URL to actually retrieve the policy expression.

Web Services Policy 1.5 - Attachment pre-defines another tModel that is used to associate such a pre-registered, locally available policy expressions with an entity in a UDDI registry

This new tModel is called the local policy reference category system and is defined in Appendix B.3 Local Policy Reference Category System.

UDDI registries MUST use the tModelKey uuid:5da4fc61-a302-35ad-91d3-775150429035 to uniquely identify this tModel so that UDDI registry users can expect the same behavior across different UDDI registries.

The local policy reference category system is based on tModelKeys. The valid values of this category system are those tModelKeys identifying tModels that

  • exist in the same UDDI registry

  • and are categorized as "policy" using the Web Services Policy Types category system.

That is, when referencing this category system in a category bag, the corresponding keyValue of the keyedReference is the tModelKey of the tModel that represents the policy expression.

Given the local policy reference category system, one can then associate a policy expression tModel with a businessEntity, a businessService, and a tModel using the entity's categoryBag. For example, associating the policy expression tModel with the tModelKey "uuid:04cfa…" from above with a businessService is done as follows: 

(01) <businessService serviceKey="…" >
(02)   <name>…</name>
(03)   <description>…</description>
(04)   <bindingTemplates>…</bindingTemplates>
(05)   <categoryBag>
(06)     <keyedReference
(07)        keyName="Policy Expression for example's Web services"
(08)        keyValue="uuid:04cfa…"
(09)        tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" />
(10)   </categoryBag>
(11) </businessService>

The tModelKey of the keyedReference MUST match the fixed tModelKey from the local policy reference category system. The keyValue MUST be the tModelKey of the policy expression that is registered with the UDDI registry.

A different approach has to be taken to associate a policy expression with a bindingTemplate, since bindingTemplates do not contain a categoryBag in UDDI Version 2. Therefore, the bindingTemplate's tModelInstanceInfo and instanceParms MUST be used as follows: 

(01) <bindingTemplate bindingKey="…" >
(02)   <accessPoint>…</accessPoint>
(03)   <tModelInstanceDetails>
(04)     <tModelInstanceInfo
(05)        tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" >
(06)       <instanceDetails>
(07)         <instanceParms>uuid:04cfa…</instanceParms>
(08)       </instanceDetails>
(09)     </tModelInstanceInfo>
(10)   </tModelInstanceDetails>
(11) </bindingTemplate>

The tModelKey of the tModelInstanceInfo MUST match the fixed tModelKey from the local policy reference category system. The instanceParms MUST be the tModelKey of the policy expression that is registered with the UDDI registry.

6.4 Registering Policies in UDDI Version 3

UDDI Version 3 [UDDI 3.0] provides a number of enhancements in the areas of modeling and entity keying. Special considerations for UDDI multi-version support are outlined in chapter 10 of [UDDI 3.0]. The changes with respect to the previous sections are as follows.

First, the tModelKeys of the pre-defined tModels are migrated to domain-based keys. The migration is unique since the Version 2 keys introduced in this specification are already programmatically derived from the Version 3 keys given below.

The tModelKey for the remote policy reference tModel changes from "uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" to "uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference".

The tModelKey for the Web Services Policy Types tModel changes from "uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" to "uddi:w3.org:ws-policy:v1.5:attachment:policytypes".

The tModelKey for the local policy reference tModel changes from "uuid:5da4fc61-a302-35ad-91d3-775150429035" to "uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference".

Second, rather than putting policy expression references in a bindingTemplate's tModelInstanceInfo, they are added to the bindingTemplate's categoryBag, analogous to the mechanism described for other UDDI entities. For example, the example bindingTemplate from section 6.1 Calculating Effective Policy and Element Policy in UDDI would be changed as follows: 

(01) <bindingTemplate bindingKey="…" >
(02)   <accessPoint>…</accessPoint>
(03)   <tModelInstanceDetails>…</tModelInstanceDetails>
(04)   <categoryBag>
(05)     <keyedReference
(06)        keyName="Policy Expression for example's Web services"
(07)        keyValue="http://www.example.com/myservice/policy"
(08)        tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"
(09)     />
(10)   </categoryBag>
(11) </bindingTemplate>

Third, inquiries for reusable policy expression tModels described in Section 6.3 Registering Reusable Policy Expressions and UDDI tModel entities that are associated with remote policy expression is enhanced by the wildcard mechanism for keyValues in keyedReferences. For example, searching for all policy expression tModels whose IRI starts with http://www.example.com/, the following find_tModel API call can be used: 

(01) <find_tModel 
        xmlns="urn:uddi-org:api_v3" >
(02)   <categoryBag>
(03)     <keyedReference
(04)        keyValue="http://www.example.com/"
(05)        tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference"
(06)     />
(07)   </categoryBag>
(08)   <findQualifiers>
(09)     <findQualifier>approximateMatch</findQualifier>
(10)   </findQualifiers>
(11) </find_tModel>

Fourth, all UDDI entities may be digitally signed using XML digital signatures [XML-Signature]. Publishers who want to digitally sign their policy expression tModels or policy expression references in UDDI MUST use the Schema-centric canonicalization algorithm [SCC14N].

7. Security Considerations

It is RECOMMENDED that policy attachments be integrity protected to permit the detection of tampering. This can be done using a technology such as XML DSig [XML-Signature], SSL/TLS [IETF RFC 2246], or WS-Security 2004 [WS-Security 2004]. This also provides a mechanism for authenticating policy attachments by determining if the signer has the right to "speak for" the scope of the policy attachment.

Policies SHOULD NOT be accepted unless they are signed and have an associated security token to specify the signer has the right to "speak for" the scope containing the policy.

A more complete discussion of security considerations can be found in the Security Considerations section of the Web Services Policy 1.5 - Framework document [Web Services Policy Framework].

8. Conformance

8.1 External Policy Attachment Conformance

An element information item whose namespace name is "http://www.w3.org/ns/ws-policy" and whose local part is PolicyAttachment conforms to this specification if it is valid according to the XML Schema [XML Schema Structures] for that element as defined by this specification (http://www.w3.org/2007/02/ws-policy.xsd) and additionally adheres to all the constraints contained in Section 3.4 External Policy Attachment of this specification. Such a conformant element information item constitutes an external policy attachment.

8.2 WSDL 1.1 Attachment Conformance

A WSDL 1.1 [WSDL 1.1] description conforms to this specification when it incorporates one or more element policies and additionally adheres to all the constraints contained in section 4. Attaching Policies Using WSDL 1.1

8.3 WSDL 2.0 Attachment Conformance

A WSDL 2.0 [WSDL 2.0 Core Language] description conforms to this specification when it incorporates one or more element policies and additionally adheres to all the constraints contained in section 5. WS-Policy Attachment for WSDL 2.0

A. References

A.1 Normative References

[BP 1.1]
Basic Profile Version 1.1, K. Ballinger, et al, Editors. The Web Services-Interoperability Organization, 10 April 2006. This version of the Basic Profile Version 1.1 is http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html. The latest version of the Basic Profile Version 1.1 is available at http://www.ws-i.org/Profiles/BasicProfile-1.1.html
[IETF RFC 3023]
IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, January 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)
[IETF RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. Internet Engineering Task Force, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 3986]
Uniform Resource Identifier (URI): Generic Syntax , T. Berners-Lee, R. Fielding and L. Masinter, Authors. Network Working Group, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt.
[IETF RFC 3987]
Internationalized Resource Identifiers (IRIs) , M. Duerst and M. Suignard, Authors. Internet Engineering Task Force, January 2005. Available at http://www.ietf.org/rfc/rfc3987.txt.
[UDDI API 2.0]
UDDI Version 2.04 API, T. Bellwood, Editor. Organization for the Advancement of Structured Information Standards, 19 July 2002. This version of UDDI Version 2.0 API is http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm. The latest version of the UDDI 2.0 API is available at http://uddi.org/pubs/ProgrammersAPI_v2.htm.
[UDDI Data Structure 2.0]
UDDI Version 2.03 Data Structure Reference, C. von Riegen, Editor. Organization for the Advancement of Structured Information Standards, 19 July 2002. This version of UDDI Version 2.0 Data Structures is http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm. The latest version of the UDDI 2.0 Data Structures is available at http://uddi.org/pubs/DataStructure_v2.htm.
[UDDI 3.0]
UDDI Version 3.0.2, L. Clément, et al, Editors. Organization for the Advancement of Structured Information Standards, 19 October 2004. This version of the UDDI 3.0 specification is http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm. The latest version of the UDDI 3.0 specification is available at http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi_v3.htm.
[Web Services Policy Framework]
Web Services Policy 1.5 - Framework, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 04, September 2007. This version of the specification of the Web Services Policy 1.5 - Framework specification is http://www.w3.org/TR/2007/REC-ws-policy-20070904. The latest version of Web Services Policy 1.5 - Framework is available at http://www.w3.org/TR/ws-policy.
[WS-Addressing Core]
Web Services Addressing 1.0 - Core, M. Gudgin, M. Hadley, and T. Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the Web Services Addressing 1.0 - Core Recommendation is http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The latest version of Web Services Addressing 1.0 - Core is available at http://www.w3.org/TR/ws-addr-core.
[WSDL 1.1]
Web Services Description Language (WSDL) 1.1, E. Christensen, et al, Authors. World Wide Web Consortium, March 2001. Available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
[WSDL 2.0 Core Language]
Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This version of the WSDL 2.0 specification is http://www.w3.org/TR/2007/REC-wsdl20-20070626/. The latest version of WSDL 2.0 is available at http://www.w3.org/TR/wsdl20/.
[WS-Security 2004]
Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), A. Nadalin, C. Kaler, P. Hallam-Baker, and R. Monzillo, Editors. Organization for the Advancement of Structured Information Standards, March 2004. Available at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.
[XML BASE]
XML Base, Jonathan Marsh, Editor. World Wide Web Consortium, 27 June 2001. This version of the XML Base Recommendation is http://www.w3.org/TR/2001/REC-xmlbase-20010627/. The latest version of XML Base is available at http://www.w3.org/TR/xmlbase/.
[XML Information Set]
XML Information Set (Second Edition), J. Cowan and R. Tobin, Editors. World Wide Web Consortium, 24 October 2001, revised 4 February 2004. This version of the XML Information Set Recommendation is http://www.w3.org/TR/2004/REC-xml-infoset-20040204. The latest version of XML Information Set is available at http://www.w3.org/TR/xml-infoset.
[XML Namespaces]
Namespaces in XML 1.0 (Second Edition), T. Bray, D. Hollander, A. Layman, and R. Tobin, Editors. World Wide Web Consortium, 14 January 1999, revised 16 August 2006. This version of the XML Information Set Recommendation is http://www.w3.org/TR/2006/REC-xml-names-20060816/. The latest version of Namespaces in XML is available at http://www.w3.org/TR/REC-xml-names.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The latest version of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2.
[XML Schema Structures]
XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The latest version of XML Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.

A.2 Other References

[IETF RFC 2246]
IETF "RFC 2246: The TLS Protocol", T. Dierks, C. Allen, January 1999. (See http://www.ietf.org/rfc/rfc2246.txt.)
[WSDL11 ElementIds]
WSDL 1.1 Element Identifiers D. Orchard, A. S. Vedamuthu, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez, Ü. Yalçinalp, Editors. World Wide Web Consortium, 20 July 2007. This version of the WSDL 1.1 Element Identifiers Working Group Note is http://www.w3.org/TR/2007/NOTE-wsdl11elementidentifiers-20070720/. The latest version of WSDL 1.1 Element Identifiers is available at http://www.w3.org/TR/wsdl11elementidentifiers/.
[MTOM]
SOAP Message Transmission Optimization Mechanism, M. Gudgin, N. Mendelsohn, M. Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25 January 2005. This version of the SOAP Message Transmission Optimization Mechanism Recommendation is http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. The latest version of SOAP Message Transmission Optimization Mechanism is available at http://www.w3.org/TR/soap12-mtom/.
[WS-MTOMPolicy]
MTOM Serialization Policy Assertion (WS-MTOMPolicy), C. Ferris, et al, Authors. International Business Machines Corporation and Microsoft Corporation, Inc., September 2006. Available at http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/
[SCC14N]
Schema Centric XML Canonicalization Version 1.0, S. Aissi, A. Hately, and M. Hondo, Editors. Organization for the Advancement of Structured Information Standards, 23 May 2005. This version of the Schema Centric XML Canonicalization Version 1.0 is http://uddi.org/pubs/SchemaCentricCanonicalization-20050523.htm. The latest version of Schema Centric XML Canonicalization Version 1.0 is available at http://uddi.org/pubs/SchemaCentricCanonicalization.htm.
[WS-Addressing Metadata]
Web Services Addressing 1.0 - Metadata, M. Gudgin, M. Hadley, T. Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 4 September 2007. This version of the Web Services Addressing 1.0 - Metadata is http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. The latest version of Web Services Addressing 1.0 - Metadata is available at http://www.w3.org/TR/ws-addr-metadata.
[WS-MetadataExchange]
Web Services Metadata Exchange (WS-MetadataExchange), K. Ballinger, et al, Authors. BEA Systems Inc., Computer Associates International, Inc., International Business Machines Corporation, Microsoft Corporation, Inc., SAP AG, Sun Microsystems, and webMethods, August 2006. Available at http://schemas.xmlsoap.org/ws/2004/09/mex/
[WS-RM Policy]
Web Services Reliable Messaging Policy Assertion (WS-RM Policy), D. David, A. Kamarkar, G. Pilz, and Ü. Yalçinalp, Editors. Organization for the Advancement of Structured Information Standards, 14 June 2007. Available at http://docs.oasis-open.org/ws-rx/wsrmp/200702.
[WS-SecurityPolicy]
WS-SecurityPolicy v1.2, A. Nadalin, M. Goodner M. Gudgin, A. Barbir, and H. Granqvist, Editors. Organization for the Advancement of Structured Information Standards, 1 July 2007. Available at http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf. Namespace document available at http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702.
[WSDL 1.1 Binding for SOAP 1.2]
WSDL 1.1 Binding for SOAP 1.2, D. Angelov, et al, Authors. World Wide Web Consortium, 5 April 2006.  Available at http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/.
[XML-Signature]
XML-Signature Syntax and Processing, D. Eastlake, J. Reagle, and D. Solo, Editors. The Internet Society & World Wide Web Consortium, 12 February 2002. This version of the XML-Signature Syntax and Processing Recommendation is http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/. The latest version of XML-Signature Syntax and Processing is available at http://www.w3.org/TR/xmldsig-core/.
[XOP]
XML-binary Optimized Packaging, M. Gudgin, N. Mendelsohn, M. Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25 January 2005. This version of the XML-binary Optimized Packaging Recommendation is http://www.w3.org/TR/2005/REC-xop10-20050125/. The latest version of XML-binary Optimized Packaging is available at http://www.w3.org/TR/xop10/.
[XPointer Framework]
XPointer Framework, Paul Grosso, Eve Maler, Jonathan Marsh, Norman Walsh, Editors. World Wide Web Consortium, 25 March 2003. This version of the XPointer Framework Proposed Recommendation is http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The latest version of XPointer Framework is available at http://www.w3.org/TR/xptr-framework/.

B. UDDI tModel Definitions

This section contains the UDDI tModel definitions for the canonical tModels used in Section 6. Attaching Policies Using UDDI. The tModelKeys shown in the tModel structure sections are valid UDDI Version 3 keys. When using UDDI Version 2, the corresponding derived UDDI Version 2 keys must be used.

B.1 Remote Policy Reference Category System

B.1.1 Design Goals

This tModel is used to attach a policy to a UDDI entity by referencing the policy's IRI.

B.1.2 tModel Definition

Name: http://www.w3.org/ns/ws-policy/remotepolicyreference
Description: Category system used for UDDI entities to point to an external Web services policy attachment policy that describes their characteristics. See Web Services Policy 1.5 - Attachment specification for further details.
UDDI Key (V3): uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference
UDDI V1,V2 format key: uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1
Categorization: categorization
Checked: No

B.1.3 tModel Structure

(01) <tModel tModelKey="uuid:2ea5f9d3-9b84-39f9-b334-e9d5f535b4c1" >
(02)     <name>http://www.w3.org/ns/ws-policy/remotepolicyreference</name>
(03)   <description xml:lang="EN">Category system used for UDDI entities to point to an external
(04)    Web Services Policy Attachment policy expression that describes their characteristics.
(05)    See Web Services Policy 1.5 - Attachment specification for further details.</description>
(06)   <categoryBag>
(07)     <keyedReference
(08)        keyName="uddi-org:types:categorization"
(09)        keyValue="categorization"
(10)        tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" />
(11)   </categoryBag>
(12) </tModel>

B.2 Web Services Policy Types Category System

B.2.1 Design Goals

This tModel is used to categorize tModels as representing policy expressions. There is only one valid value, namely "policy", that indicates this very fact. It is RECOMMENDED that tModels categorized as representing policy expressions reference no more and no less than this very policy expression using the remote policy reference category system.

B.2.2 tModel Definition

Name: http://www.w3.org/ns/ws-policy/policytypes
Description: Web services policy types category system used for UDDI tModels to characterize them as Web services policy–based policy expressions.
UDDI Key (V3): uddi:w3.org:ws-policy:v1.5:attachment:policytypes
UDDI V1,V2 format key: uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941
Categorization: categorization
Checked: No

B.2.3 tModel Structure

(01) <tModel tModelKey="uuid:90eda65e-ffd7-33df-965f-98ebb1c2a941" >
(02)   <name>http://www.w3.org/ns/ws-policy/policytypes</name>
(03)   <description xml:lang="EN">Web Services Policy Types category system used for UDDI tModels
(04)    to characterize them as Web Services Policy – based policy expressions.</description>
(05)   <categoryBag>
(06)     <keyedReference
(07)        keyName="uddi-org:types:categorization"
(08)        keyValue="categorization"
(09)        tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" />
(10)   </categoryBag>
(11) </tModel>

B.3 Local Policy Reference Category System

B.3.1 Design Goals

This tModel is used to attach a policy expression to a UDDI entity by referencing the UDDI entity that represents this policy expression. The local policy reference category system is based on tModelKeys. It is expected that referenced tModels are registered with the same UDDI registry and are categorized as representing policy expressions using the Web services policy types category system.

B.3.2 tModel Definition

Name: http://www.w3.org/ns/ws-policy/localpolicyreference
Description: Category system used for UDDI entities to point to a Web services policy policy expression tModel that describes their characteristics. See Web Services Policy 1.5 - Attachment specification for further details.
UDDI Key (V3): uddi:w3.org:ws-policy:v1.5:attachment:localpolicyreference
UDDI V1,V2 format key: uuid:5da4fc61-a302-35ad-91d3-775150429035
Categorization: categorization
Checked: Yes

B.3.3 tModel Structure

(01) <tModel tModelKey="uuid:5da4fc61-a302-35ad-91d3-775150429035" >
(02)   <name>http://www.w3.org/ns/ws-policy/localpolicyreference</name>
(03)   <description xml:lang="en">Category system used for UDDI entities to point to a
(04)    Web Services Policy policy expression tModel that describes their characteristics.
(05)    See Web Services Policy 1.5 - Attachment specification for further details.</description>
(06)   <categoryBag>
(07)     <keyedReference
(08)        keyName="uddi-org:types:categorization"
(09)        keyValue="categorization"
(10)        tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" />
(11)     <keyedReference
(12)        keyName="uddi-org:types:checked"
(13)        keyValue="checked"
(14)        tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62aB4" />
(15)       <keyedReference
(16)        keyName="uddi-org:entityKeyValues"
(17)        keyValue="tModelKey"
(18)        tModelKey="uuid:916b87bf-0756-3919-8eae-97dfa325e5a4" />
(19)   </categoryBag>
(20) </tModel> 

C. Acknowledgements (Non-Normative)

This document is the work of the W3C Web Services Policy Working Group.

Members of the Working Group are (at the time of writing, and by alphabetical order): Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Glen Daniels (Progress Software), Doug Davis (IBM Corporation), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones (Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation), Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods (A subsidiary of Software AG)).

Previous members of the Working Group were: Jeffrey Crump, Jong Lee, Bob Natale, Eugene Osovetsky, Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.

The people who have contributed to discussions on public-ws-policy@w3.org are also gratefully acknowledged.