This document is also available in these non-normative formats: PDF, PostScript, XML, and plain text.
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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 an updated Public Working Draft of the Web Services
Policy 1.5 - Attachment specification for review by W3C members and
other interested parties. It has been produced by the Web Services Policy Working
Group, which is part of the W3C Web Services Activity.
A list of changes in this version of
the document and a diff-marked version
against the previous version of this document are available.
Major changes in this version of the document encompass an
enhancement of the conformance section,
a new section on WS-Policy Attachment for WSDL
2.0, and a clarification of the relation between
wsp:PolicyReference
and the wsp:Policy
element.
Discussion of this document takes place on the public public-ws-policy@w3.org mailing list (public archive) and within Bugzilla. 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.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
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
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
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)
D. Changes in this Version of the
Document (Non-Normative)
E. Web Services Policy 1.5 - Attachment
Change Log (Non-Normative)
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].
This section specifies the notations, namespaces, and terminology used in this specification.
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/2006/07/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.
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]).
Prefix | XML Namespace | Specification |
---|---|---|
mtom |
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization |
[WS-OptimizedSerializationPolicy] |
rmp |
http://docs.oasis-open.org/ws-rx/wsrmp/200602 |
[WS-RM Policy] |
sp |
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy |
[WS-SecurityPolicy] |
wsa |
http://www.w3.org/2005/08/addressing |
[WS-Addressing Core] |
wsap |
http://www.w3.org/2006/05/addressing/wsdl |
[WS-Addressing Policy] |
wsdl11 |
http://schemas.xmlsoap.org/wsdl/ |
[WSDL 1.1] |
wsdl20 |
http://www.w3.org/2006/01/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/2006/07/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/2006/07/ws-policy. A normative XML Schema [XML Schema Structures, XML Schema Datatypes] document can be obtained by dereferencing the XML 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 but rather change only when a subsequent revision, published as a WD, CR or PR draft results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification.
Under this policy, the following are examples of backwards compatible changes that would not result in assignment of a new XML namespace URI:
Addition of new global element, attribute, complexType and simpleType definitions.
Addition of new elements or attributes in locations covered by a previously specified wildcard.
Modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid.
Modifications to the cardinality of elements for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule.
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:
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.
The element policy is the policy attached to the policy subjects associated with the element information item that contains it.
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.
A policy is a potentially empty collection of policy alternatives.
A policy alternative is a potentially empty collection of policy assertions.
A policy assertion represents an individual requirement, capability, or other property of a behavior.
A policy attachment is a mechanism for associating policy with one or more policy scopes.
A policy expression is an XML Infoset representation of a policy, either in a normal form or in an equivalent compact form.
A policy scope is a collection of policy subjects to which a policy may apply.
A policy subject is an entity (e.g., an endpoint, message, resource, interaction) with which a policy can be associated.
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/200602" xmlns:wsp="http://www.w3.org/2006/07/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) <rmp:InactivityTimeout Milliseconds="600000" /> (04) <rmp:BaseRetransmissionInterval Milliseconds="3000" /> (05) <rmp:ExponentialBackoff /> (06) <rmp:AcknowledgementInterval Milliseconds="200" /> (07) </rmp:RMAssertion> (08) </wsp:Policy>
Example 2-2. Example X509 Security Policy Expression.
(01) <wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://www.w3.org/2006/07/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://schemas.xmlsoap.org/ws/2005/07/securitypolicy/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://schemas.xmlsoap.org/ws/2005/07/securitypolicy/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.
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.
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, [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 by: [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.
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.
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/2006/07/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.]
Note that the policy scope of the attachment is specific to the policy attachment Mechanism using it; accordingly, any policy attachment mechanism using this attribute MUST define the policy scope of the attachment.
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/200602" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://www.w3.org/2006/07/ws-policy" > (02) <rmp:RMAssertion> (03) <rmp:InactivityTimeout Milliseconds="600000" /> (04) <rmp:BaseRetransmissionInterval Milliseconds="3000" /> (05) <rmp:ExponentialBackoff /> (06) <rmp:AcknowledgementInterval Milliseconds="200" /> (07) </rmp:RMAssertion> (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: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/>
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 optional element 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
.
The RECOMMENDED means of associating a policy with a policy subject that has a WSDL 1.1 [WSDL 1.1] description is to attach a reference to the policy within the WSDL component corresponding to the target policy subject.
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, 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:
wsdl11:portType
wsdl11:portType/wsdl11:operation/wsdl11:input
wsdl11:portType/wsdl11:operation/wsdl11:output
wsdl11:portType/wsdl11:operation/wsdl11:fault
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.
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.
(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.
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.
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.
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.
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.
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/200602" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://www.w3.org/2006/07/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) <rmp:InactivityTimeout Milliseconds="600000" /> (05) <rmp:BaseRetransmissionInterval Milliseconds="3000" /> (06) <rmp:ExponentialBackoff /> (07) <rmp:AcknowledgementInterval Milliseconds="200" /> (08) </rmp:RMAssertion> (09) </wsp:Policy> (10) <wsp:Policy wsu:Id="X509EndpointPolicy" > (11) <sp:AsymmetricBinding> (12) <wsp:Policy> <!-- Details omitted for readability --> (13) <sp:IncludeTimestamp /> (14) <sp:OnlySignEntireHeadersAndBody /> (15) </wsp:Policy> (16) </sp:AsymmetricBinding> (17) </wsp:Policy> (18) <wsp:Policy wsu:Id="SecureMessagePolicy" > (19) <sp:SignedParts> (20) <sp:Body /> (21) </sp:SignedParts> (22) <sp:EncryptedParts> (23) <sp:Body /> (24) </sp:EncryptedParts> (25) </wsp:Policy> (26) <wsdl11:import namespace="http://www.example.com/stock" location="http://www.example.com/stock/stock.wsdl" /> (27) <wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" > (28) <wsoap12:binding style="document" (29) transport="http://schemas.xmlsoap.org/soap/http" /> (30) <wsp:PolicyReference URI="#RmPolicy" wsdl11:required="true" /> (31) <wsp:PolicyReference URI="#X509EndpointPolicy" wsdl11:required="true" /> (32) <wsdl11:operation name="GetLastTradePrice" > (33) <wsoap12:operation soapAction="http://www.example.com/stock/Quote/GetLastTradePriceRequest" /> (34) <wsdl11:input> (35) <wsoap12:body use="literal" /> (36) <wsp:PolicyReference URI="#SecureMessagePolicy" wsdl11:required="true" /> (37) </wsdl11:input> (38) <wsdl11:output> (39) <wsoap12:body use="literal" /> (40) <wsp:PolicyReference URI="#SecureMessagePolicy" (41) wsdl11:required="true" /> (42) </wsdl11:output> (43) </wsdl11:operation> (44) </wsdl11:binding> (45) </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://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://www.w3.org/2006/07/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>
This section describes a mechanism for associating policy expressions with Web service constructs in WSDL 2.0. The mechanism consists of:
A model for attaching policies to WSDL 2.0 constructs. The model defines:
A partitioning of WSDL constructs into service, endpoint, operation and message policy subjects.
The semantics of attaching a policy to each policy subject.
How to combine policies attached to more than one WSDL component within a single policy subject.
An XML representation of policy expressions attached to WSDL 2.0
constructs and annotating those policy expressions as required
extensions using the WSDL-defined extensibility flag
@wsdl20:required
.
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.)
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) <Policy wsu:Id="common"> (04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/> (05) <wsap:UsingAddressing /> (06) </Policy> (07) <Policy wsu:Id="secure"> (08) <ExactlyOne> (09) <sp:TransportBinding>…</sp:TransportBinding> (10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding > (11) </ExactlyOne> (12) </Policy> (13) <wsdl20:binding name="SecureBinding" (14) interface="tns:RealTimeDataInterface" > (15) <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) <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) <Policy> (02) <All> (03) <Policy> (04) <mtom:OptimizedMimeSerialization wsp:Optional="true"/> (05) <wsap:UsingAddressing /> (06) </Policy> (07) <Policy> (08) <ExactlyOne> (09) <sp:TransportBinding>…</sp:TransportBinding> (10) <sp:AsymmetricBinding>…</sp:AsymmetricBinding > (11) </ExactlyOne> (12) </Policy> (13) </All> (14) </Policy>
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 Policy
or 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.
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 PolicyReference
element. A
policy attachment to a WSDL element is represented by attaching a
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
Policy
elements are included as children of the
wsdl20:description
element after the
wsdl20:types
element and referenced using the
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 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.)
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.
Component | Value |
---|---|
Service | A policy
corresponding to the merge of
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:service element. |
Endpoint | A policy
corresponding to the merge of
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:endpoint element. |
Binding | A policy
corresponding to the merge of
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:binding element. |
Binding Operation | A policy
corresponding to the merge of
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:binding/wsdl20:operation element. |
Binding Fault | A policy
corresponding to the merge of
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:binding/wsdl20:fault element. |
Binding Message Reference | A policy
corresponding to the merge of
Policy or 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
Policy or 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
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:interface element. |
Interface Operation | A policy
corresponding to the merge of
Policy or 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
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:interface/wsdl20:fault element. |
Interface Message Reference | A policy
corresponding to the merge of
Policy or 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
Policy or PolicyReference elements, if
any, in the [children] of the
wsdl20:interface/wsdl20:operation/wsdl20:infault or
wsdl20:interface/wsdl20:operation/wsdl20:outfault
element. |
The following diagram illustrates the four policy subjects in WSDL and how the effective policy is calculated for each of these policy subjects.
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.
The effective policy of a service policy subject is the policy in the {policy} property of a Service component that describes the service.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:a27078e4-fd38-320a-806f-6749e84f8005
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:a27078e4-fd38-320a-806f-6749e84f8005" /> (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:a27078e4-fd38-320a-806f-6749e84f8005" > (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.
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:fa1d77dc-edf0-3a84-a99a-5972e434e993" /> (15) <keyedReference (16) keyName="Policy Expression for example's Web services" (17) keyValue="http://www.example.com/myservice/policy" (18) tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" /> (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:a27f7d45-ec90-31f7-a655-efe91433527c
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:a27f7d45-ec90-31f7-a655-efe91433527c" /> (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:a27f7d45-ec90-31f7-a655-efe91433527c" > (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.
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:a27078e4-fd38-320a-806f-6749e84f8005"
to
"uddi:schemas.xmlsoap.org:remotepolicyreference:2003_03"
.
The tModelKey
for the Web Services
Policy Types tModel changes from
"uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993"
to
"uddi:schemas.xmlsoap.org:policytypes:2003_03"
.
The tModelKey
for the local policy
reference tModel changes from
"uuid:a27f7d45-ec90-31f7-a655-efe91433527c"
to
"uddi:schemas.xmlsoap.org:localpolicyreference:2003_03"
.
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:schemas.xmlsoap.org:remotepolicyreference:2003_03" (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:schemas.xmlsoap.org:remotepolicyreference:2003_03" (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].
It is RECOMMENDED that policy attachments be signed to prevent tampering. 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.
An element information item whose namespace name is "http://www.w3.org/2006/07/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/2006/07/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.
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
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
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 2 keys. When using UDDI Version 3, the corresponding derived UDDI Version 2 keys must be used.
This tModel is used to attach a policy to a UDDI entity by referencing the policy's IRI.
Name: | http://schemas.xmlsoap.org/ws/2003/03/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:schemas.xmlsoap.org:remotepolicyreference:2003_03 |
UDDI V1,V2 format key: |
uuid:a27078e4-fd38-320a-806f-6749e84f8005 |
Categorization: | categorization |
Checked: | No |
(01) <tModel tModelKey="uuid:a27078e4-fd38-320a-806f-6749e84f8005" > (02) <name>http://schemas.xmlsoap.org/ws/2003/03/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>
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.
Name: | http://schemas.xmlsoap.org/ws/2003/03/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:schemas.xmlsoap.org:policytypes:2003_03 |
UDDI V1,V2 format key: |
uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993 |
Categorization: | categorization |
Checked: | No |
(01) <tModel tModelKey="uuid:fa1d77dc-edf0-3a84-a99a-5972e434e993" > (02) <name>http://schemas.xmlsoap.org/ws/2003/03/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>
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.
Name: | http://schemas.xmlsoap.org/ws/2003/03/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:schemas.xmlsoap.org:localpolicyreference:2003_03 |
UDDI V1,V2 format key: |
uuid:a27f7d45-ec90-31f7-a655-efe91433527c |
Categorization: | categorization |
Checked: | Yes |
(01) <tModel tModelKey="uuid:a27f7d45-ec90-31f7-a655-efe91433527c" > (02) <name>http://schemas.xmlsoap.org/ws/2003/03/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>
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), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
Previous members of the Working Group were: Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
The people who have contributed to discussions on public-ws-policy@w3.org are also gratefully acknowledged.
A list of substantive changes since the Working Draft dated 27 September 2006 is below:
Enhanced the Conformance section.
Added a new section - 5. WS-Policy Attachment for WSDL 2.0 - that describes a mechanism for associating policy expressions with Web service constructs in WSDL 2.0.
Clarified that a wsp:PolicyReference can be used any place where a wsp:Policy element can be used
Date | Author | Description |
---|---|---|
20060712 | ASV | Updated the list of editors. Completed action items 20 from the Austin F2F. |
20060712 | DBO | Completed action item 12 |
20060718 | DBO | Completed action items Editors to remove extraneous namespace decl in the example at the end of section 3.4 18, RFC2606 for domain names 09 (note: PLH had already done but it didn't show up in the change log) editors to straighten up Note after example 3-1 11 |
20060719 | TIB | Completed action item 22: Linked SVG graphic |
20060721 | ASV | Completed action items 23, 25 and 26 from the Austin F2F. |
20060721 | ASV | Completed action item 29 from the Austin F2F. |
20060726 | ASV | Incorporated the XML namespace URI versioning policy adopted by the WG. |
20060808 | DBO | Completed action items: 15 as early as possible in the doc, use the definition that are defined in the doc. Issue 3545, use of {any} and {@any} in xpath-like expressions not defined in Notational Conventions section |
20060808 | ASV | Implemented the resolution for issue 3543. |
20060809 | DBO | Implemented the resolution for issue 3546: wsdl 2.0 status mention. |
20060809 | ASV | Implemented the resolution for issue 3556 and the resolution for issue 3558. |
20060811 | DBO | Completed action items: 15 remove use if emph/ital terms. Framework: removed emph on conceptually replace and support; attachment: make merge a termdef |
20060813 | ASV | Added a new Section D. Changes in this Version of the Document (that provides a list of substantive chanages since the previous publication). |
20060825 | PY | Implemented the resolution for issue 3544. |
20060827 | TIB | Completed action item: resolution for adding Conformance section. |
20060827 | TIB | Implemented the resolution for issue 3605: typo in example. |
20060829 | ASV | Implemented the resolution for issue 3561: replaced URI with IRI. |
200609006 | DBO | Completed partial resolution for issue 3590. for adding document attribute extensbility of wsp:Policy/@{any} and wsp:Policy/.../wsp:PolicyReference/@{any}, specifically making attribute extensibility for any namespace. |
20060906 | ASV | Implemented the resolution for issue 3557: clarify the use of domain expressions. |
20060924 | TIB | Implemented the resolution for issue 3709: Editorial corrections from UDDI team. |
20060925 | ASV | Created 5. WS-Policy Attachment for WSDL 2.0 per action item 2 from the Bellevue F2F. This section is based on a contribution from BEA, IBM, Microsoft and Oracle. |
20061002 | DBO | Implemented the for issue 3559: Conformance Section. |
20061002 | DBO | Implemented the resolution for issue 3712:wsp:PolicyReference can be used in any place where you can use wsp:Policy |
20061008 | MH | Implemented the resolution for issue summary of Action 10 from F2F replaced "subject" instances with "policy subject" |
20061012 | PY | Updated "Changes in this Version" section (Appendix D) |
20061019 | PY | Completed action item: 57 PaulC's comments. |