Assertion Authors are part of a community that chooses to exploit the WS-Policy Framework by creating their own specifications to define a set of assertions that express the capabilities and constraints of that target domain. The WS-Policy Framework is based on a declarative model, meaning that it is incumbent on the Assertion Authors to define both the semantics of the assertions as well as the scope of their target domain in their specification. The set of metadata for any particular domain will vary in the granularity of assertion specification required. It is the intent of this document to help communities utilize the framework in such a way that multiple WS-Policy domains can co-exist and consumers and providers can utilize the framework consistently across domains.

Assertion authors should review the conformance sections of the WS-Policy Framework and Attachment specifications and an assertion must adhere to all the constraints contained in the Framework and Attachment specifications.

Assertion Authors should also specify a policy subject. For instance, if a policy assertion were to be used with WSDL, an assertion description should specify a WSDL policy subject.

An example of a domain specification that follows these practices is the WS-SecurityPolicy specification []. The WS-SecurityPolicy authors have defined the scope of their target domain (security) as follows:

"This document [WS-SecurityPolicy] defines a set of security policy assertions for use with the WS-Policy framework with respect to security features provided in WSS: SOAP Message Security, WS-Trust and WS-SecureConversation. This document takes the approach of defining a base set of assertions that describe how messages are to be secured. Flexibility with respect to token types, cryptographic algorithms and mechanisms used, including using transport level security is part of the design and allows for evolution over time. The intent is to provide enough information for compatibility and interoperability to be determined by web service participants along with all information necessary to actually enable a participant to engage in a secure exchange of messages."

An example of scoping individual assertions to policy subjects is also provided by the WS-Security Policy specification in Appendix A.

A consumer of WS-Policy Assertions can be any entity that is capable of parsing a WS-Policy XML expression and selecting one alternative from the policy. This selected alternative is then used to govern the creation of a message to send to the subject to which the policy alternative was attached. The WS-Policy Attachment specification defines a set of attachment mechanisms for use with common web service subjects: WSDL definitions [, ], and UDDI directory entries [, , ].

In the degenerate case, a human could read the XML and determine if a message could be constructed conformant to the advertised policy.

It is expected that consumers of WS-Policy will include a wide range of client configurations, from stand alone client applications to "active" web service requesters that are capable of adapting to the constraints and capabilities expressed in a WS-Policy document and modifying their own configurations dynamically.

A provider who expresses capabilities and requirements of a Web service as policies can be any web service implementation that can specify its on-the-wire message behavior as a policy expression that conforms to the Web Services Policy 1.5 - Framework [] and Web Services Policy 1.5 - Attachment [] specifications. The Web Services Policy 1.5 - Attachment specification has defined a set of subjects and an extensible mechanism for attaching policies to web services subjects.

When deploying services with policies it is useful for providers to anticipate how to evolve their services capabilities over time. If forward compatibility is a concern in order to accommodate compatibility with different and potentially new clients, providers should refer to and that describes service and policy assertion evolution.

New Assertion Authors are encouraged to try to not overload assertions. A single assertion indicates a single behavior. Sets of assertions can by grouped by an operator "All". This indicates that there is a relationship between the assertions.

If grouping is utilized, choices between such groupings can be indicated by an "ExactlyOne" operator. This basic set of operators allows Assertion Authors a wide range of options for expressing the possible combinations of assertions within their domain.

It requires a good deal of effort to evaluate the capabilities of a domain and capture them in a way that reflects the options of the domain if the domain has a lot of assertions to define. Interoperability testing of new policy domains is recommended to ensure that consumers and providers are able to use the new domain assertions. To facilitate proper progression of an assertion, Assertion Authors should start with a simple working assertion that allows extensibility. As the design work progresses, one may add more parameters or nested policy assertions to meet one's interoperability needs.

Start with a Simple Assertion Assertion Authors should start with a simple working assertion that allows assertion parameter extensibility.

New Assertion Authors are encouraged to look at to see an example of a relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at to see an example of a complex domain that has been decomposed into a set of policy expressions.

Web Services Policy language allows Assertion Authors to invent their own XML dialects to represent policy assertions. The policy language relies only on the policy assertion XML element QName. This QName is unique and identifies the behavior represented by a policy assertion. Assertion Authors have the option to represent an assertion parameter as a child element (by leveraging natural XML nesting) or an attribute of an assertion. The general guidelines on when to use XML elements versus attributes apply. Use a unique QName to identify a distinct behavior.

Use Unique QNames Assertion Authors should use a unique QName to identify a distinct behavior.

Provide an XML definition > Assertion authors should provide an XML schema definition to specify the syntax of an assertion. A reader-friendly description such as an XML outline (see below) is also useful.

An example of a specification that provides an XML Outline is the Web Services Reliable Messaging Policy document []. The definition of the outline syntax used in that specification is found in its Terminology section (1.1). As an example of the outline syntax in use, the following outline has been copied from the aforementioned specification.

The syntax of an assertion can be represented using an XML outline (plus an XML schema document). If the assertion has a nested policy expression then the assertion XML outline can enumerate the nested assertions that are allowed. An example is the following:

Specify Semantics Clearly > Assertion authors should clearly and completely specify the semantics of a policy assertion.

Document Ignorable Behavior > An assertion description should include guidance as to the use of (or constraint against the use of) the wsp:Ignorable attribute to indicate whether or not the behavior indicated by the QName may be ignored by policy intersection.

Document Use of the Ignorable Attribute in XML > An Assertion Author should document, in the XML outline and/or schema for the assertion, whether or not the assertion allows for the use of the wsp:Ignorable attribute.

The Policy Framework provides two modes of authoring policy expressions: compact and normal form. One of the mechanisms that the Policy Framework provides to policy authors for purposes of writing compact policy expressions is the wsp:Optional attribute. Assertion Authors should allow for the use of the wsp:Optional attribute in the XML outline and/or schema definition of an assertion as this will allow policy expression authors to compose compact policy expressions.

Assertion Authors should allow use of wsp:Optional An assertion's XML outline and/or schema definition should allow the use of the wsp:Optional attribute so as to enable policy authors to compose compact policy expressions.

For example, consider the following two equivalent policy expressions:

If the assertion author had not provided for the wsp:Optional attribute to be included on the assertion, then policy expression authors would be forced to express the optionality of a behavior as two explicit policy alternatives, one with and one without that assertion when including assertions of that type in their policies.

WS-Policy is intended to communicate the requirements, capabilities and behaviors of nodes that provide the message's path, not specifically to declare properties of the message semantics. One of the advantages of Web services is that an XML message can be stored and later examined (e.g. as a record of a business transaction) or interpreted by an intermediary; however, if information that is necessary to understand a message is not available, these capabilities suffer.

Policy assertions should not be used to express the semantics of a message. Rather, if a property is required to understand a message, it should be communicated in the message, or be made available by some other means (e.g., being referenced by a URI in the message) instead of being communicated as a policy element. Note that there are other specifications that target specification of semantics of a message, such as .

If the messages could not be made self describing by utilizing additional properties present in the message as required by the assertion, it would be necessary to determine the behaviors engaged at runtime by additional means. A general protocol that aids in determining such behaviors may be utilized, however a standard protocol for this purpose is currently not available to ensure interoperability. Thus, a private protocol should be used with care.

Another approach is to use of the assertion to selectively apply to subjects. For example, a dedicated endpoint may be allocated to ensure the engagement of a behavior that is expressed by a policy assertion. This approach can be considered when messages cannot be self describing.

Policy assertions should not be used to express the semantics of a message. Firstly, an assertion type indicates a runtime behavior. Secondly, Assertion Authors need to indicate how the runtime behavior represented in the assertion type can be inferred or indicated from a message at runtime. If there is a need for the behavior to be represented in a persistent way or if there is a need for additional data or metadata that is present in a message to be persisted, it should be incorporated into the assertion design or in the message itself. In essence, the Assertion Authors should consider how to make messages self describing when utilizing their assertions by specifying additional properties, headers, etc. that must be present in a message as part of their assertion design.

Assertions should not describe message semantics Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.

For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed in policy that isn't attached to the message, it isn't possible to later decipher it. This is very different from expressing, in policy, what ciphers (and so forth) are supported by a particular endpoint, or those that are required in a particular message; the latter are the intended uses of the WS-Policy framework.

When considering the creation of a new domain of policy assertions, it is important to identify whether or not the domain is self-contained or at least if a subset of the domain can be well defined. A domain that expresses a broad set of capabilities will also need to have a community supporting implementations of these capabilities to provide value to the consumers. Ultimately it is the consumers and providers that will determine whether a particular set of assertions correctly characterize a domain. A new community should avoid duplicating assertions that have already been defined as this will create ambiguity not clarification. New Assertion Authors should focus on creating assertions for those specific constraints and capabilities that do not overlap with other domains but that communicate new functionality.

The model advocated for new assertion development is a cooperative marketplace [some might say it is an "opt-in" model]. The providers of services need to find value in the set of assertions or they will not include the assertions in their service descriptions.

It is the responsibility of the Assertion Authors to avoid duplication of assertions. A review by a broad community is the best way to ensure that the granularity of a set of domain assertions is appropriate.

Avoid Duplication of Assertions Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.

A policy alternative is a collection of zero or more policy assertions. Assertions within a policy alternative are not ordered.

The order of assertions in a policy alternative and order in which behaviors (indicated by assertions) are applied are two distinct concepts. The order of assertions in a policy alternative has no bearing on the order in which behaviors are applied.

Specifying the order in which behaviors are applied is outside the scope of the Web Services Policy Framework. However, the Framework says that assertion authors can write assertions that indicate the order in which behaviors are applied.

According to the SOAP processing model, the order of headers and body processing (for behaviors such as addressing, security, reliability and transaction) is at the discretion of the SOAP node and SOAP-based protocols may be used to control the order of processing.

The Web Services Security specification provides producers with a choice of signing a message before encrypting or signing a message after encrypting. That is, WS-Security 1.1, section 8 says, lines 1173-1183 - says "Finally, if a producer wishes to sign a message before encryption, then following the ordering rules laid out in section 5, "Security Header", they SHOULD first prepend the signature element to the wsse:Security header, and then prepend the encryption element, ... Likewise, if a producer wishes to sign a message after encryption, they SHOULD first prepend the encryption element to the wsse:Security header, and then prepend the signature element."

The Web Services Security Policy specification provides assertions which let users control whether to sign the message before encrypting or sign it after encrypting.

In the example below, the SignBeforeEncrypting assertion requires producers to sign a message before encrypting.

In the example below, the EncryptBeforeSigning assertion requires producers to sign a message after encrypting.

Policy assertion parameters are the opaque payload of an assertion. Parameters carry additional useful information for engaging the behavior described by an assertion and are preserved through policy processing such as normalization, merge and policy intersection. Requesters may use policy intersection to select a compatible policy alternative for an interaction. Assertion parameters do not affect the outcome of policy intersection unless the assertion specifies domain specific processing for policy intersection.

In the XML representation of a policy assertion, the child elements and attributes of the assertion excluding child elements and attributes from the policy language namespace name are the assertion parameters.

Use Parameters for Useful Information Assertion Authors should represent useful additive information necessary for engaging the behavior represented by a policy assertion as assertion parameters.

In the example below, sp:Body and sp:Header elements are the two assertion parameters of the sp:SignedParts policy assertion (this assertion requires the parts of a message to be protected). These two parameters identify the parts of a wire message that should be protected. These parameters carry additional useful information for engaging the behavior.

The framework provides the ability to "nest" policy assertions. For domains with a complex set of options, nesting provides one way to indicate dependent elements within a behavior. In particular, when assertion authors define an assertion type that allows nested policy expression, it is important to also define the semantics of that assertion when it contains an empty nested policy expression (for example: <wsam:Addressing><wsp:Policy/></wsam:Addressing>).

The following design questions below can help to determine when to use nested policy expressions:

If the answers are yes to both of these questions then leveraging nested policy expressions is something to consider. Keep in mind that a nested policy expression participates in the policy intersection algorithm. If a requester uses policy intersection to select a compatible policy alternative then the assertions in a nested policy expression play a first class role in the outcome. If there is a nested policy expression, an assertion description should declare it and enumerate the nested policy assertions that are allowed. There is one caveat to watch out for: policy assertions with deeply nested policy can greatly increase the complexity of a policy and should be avoided when they are not needed.

Use Nested Assertions for Dependent Behaviors Assertion Authors should represent dependent behaviors that are relevant to a compatibility test and apply to the same policy subject using nested policy assertions.

Enumerate Nested Assertions If there is a nested policy expression, then the Assertion Authors should enumerate the nested policy assertions that are allowed.

Assertion Authors should recognize that the framework can yield multiple assertions of the same type. The QName of the assertion is the only vehicle for the framework to match a specific assertion, NOT the contents of the element. If the assertion is a parameterized assertion the authors must understand that this type of assertion will require additional processing by consumers in order to disambiguate the assertions or to understand the semantics of the name value pairs, complex content, attribute values contribution to the processing. The tradeoff is the generality vs. the flexibility and complexity of the comparison expected for a domain.

If the assertion authors want to delegate the processing to the framework, utilizing nesting should be considered. Otherwise, domain specific comparison algorithms may need to be devised and be delegated to the specific domain handlers that are not visible to the WS-Policy framework. However, domain specific intersection processing reduces interop and increases the burden to implement an assertion.

Discourage Domain Specific Intersection Assertion authors should only specify domain specific intersection semantics when policy intersection is insufficient.

We will use the WS-SecurityPolicy to illustrate the use of nested assertions.

Securing messages is a complex usage scenario. The WS-SecurityPolicy Assertion Authors have defined the sp:TransportBinding policy assertion to indicate the use of transport-level security for protecting messages. Just indicating the use of transport-level security for protecting messages is not sufficient. To successfully interact with a Web service, the consumer must know not only that transport-level security is required, but also the transport token to use, the secure transport to use, the algorithm suite to use for performing cryptographic operations, etc. The sp:TransportBinding policy assertion can represent these dependent behaviors.

A policy assertion like the sp:TransportBinding identifies a visible behavior that is a requirement. A nested policy expression can be used to enumerate the dependent behaviors on the Transport binding. A nested policy expression is a policy expression that is a child element of another policy assertion element. A nested policy expression further qualifies the behavior of its parent policy assertion.

In the example below, the child Policy element is a nested policy expression and further qualifies the behavior of the sp:TransportBinding policy assertion. The sp:TransportToken is a nested policy assertion of the sp:TransportBinding policy assertion. The sp:TransportToken assertion requires the use of a specific transport token and further qualifies the behavior of the sp:TransportBinding policy assertion (which already requires the use of transport-level security for protecting messages).

The sp:AlgorithmSuite is a nested policy assertion of the sp:TransportBinding policy assertion. The sp:AlgorithmSuite assertion requires the use of the algorithm suite identified by its nested policy assertion (sp:Basic256Rsa15 in the example above) and further qualifies the behavior of the sp:TransportBinding policy assertion.

Setting aside the details of using transport-level security, a policy-aware client that recognizes this policy assertion can engage transport-level security and its dependent behaviors automatically. This means the complexity of security usage is absorbed by a policy-aware client and hidden from Web service application developers.

Assertion Authors should note the effect of nested policy expressions on policy intersection in their nested policy design. The result of intersecting an assertion that contains an empty nested policy expression with an assertion of the same type without a nested policy expression is that the assertions are not compatible. Therefore, when providers require dependent behaviors these behaviors should be explicitly specified as assertions in a nested policy expression. When the definition of an assertion allows for nested dependent behaviors, but the use of the assertion only contains an empty nested policy expression, this specific use indicates the specification of no nested dependent behaviors. This use must not be interpreted as being compatible with "any" of the nested dependent behaviors that are allowed by the assertion, unless otherwise specified by the assertion definition.

As an example, WS-Security Policy defines sp:HttpToken assertion to contain three possible nested elements, sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a policy expression by a provider, it will indicate that none of the dependent behaviors namely authentication or client certificate is required.

A non-anonymous client who requires authentication or client certificate will not be able to use this provider solely on the basis of intersection algorithm alone.

The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatibility assessment between two alternatives. [see and ]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow and to include this guidance in the assertion's definition.

Regardless of whether the assertion allows the ignorable attribute, assertion authors should indicate the semantic of the runtime behavior in the description of the assertion.

As said in section 3.4.1 Strict and Lax Policy Intersection in , "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.

The target scope of an assertion is an important factor for Assertion Authors to consider as it determines the granularity of the scope for which the behavior is to be engaged. For example, if an assertion has a scope of endpoint policy subject the behavior indicated by that assertion applies to all , messages exchanged in both directions (e.g. both request and response messages) with the specific endpoint to which the policy alternative including that assertion is attached.

Certain behaviors might provide in their specification for the optional use of that behavior in the context of a subset of a given interaction. When such optional behaviors are indicated by attaching assertions with only one side of an interaction, such as an inbound message of a request-response, the engagement in the context of the rest of the interaction such as the outbound message, will be undefined. Therefore, the Assertion Authors are encouraged to consider the implications of attachment of an assertion that indicates such optional behavior at a message policy subject on the interaction as a whole. For example, if reliable messaging (RM) is applied to a request message because the policy attached to the inbound message in a request-response operation had an alternative that incldued RM in its assertions, is the application of RM to the outbound message permitted, even if there is no policy attached to that subject? Leaving the semantics either unspecified or incompletely specified may result in implementations making assumptions that might have undesireable consequences. This is especially important if the assertion is applicable to more than one specific policy subject. The approach taken by WS-RM Policy [] is to provide for an RM assertion to be attached at either or both message and endpoint policy subjects. In order to eliminate the ambiguity associated with only using a message policy subject, the WS-RM Policy requires a policy to be attached to an endpoint policy subject as well as a message policy subject whenever a policy is attached to a message policy subject. The combination directly addresses the unstated semantic that if RM is used for inbound messages, that it MAY be used for outbound messages, even if the assertion is not attached to the outbound message (and vice-versa).

Consider entire message exchange pattern when specifying Assertions that represent optional behavior related to a subset of that message exchange pattern when considering appropriate policy subject attachment points Assertion Authors should associate assertions that represent optional behavior with the appropriate policy subject and use the smallest possible granularity (See Best Practice 28) to limit the degree to which optional behavior applies.

Behaviors that must be engaged in the context of an interaction must not be marked with wsp:Optional="true". since this creates two alternatives; one with and one without that assertion. This would allow the policy consumer to select the policy alternative that does not contain that assertion, and thus result in an interaction that did not engage the required behavior that was indicated by that assertion.

Limit use of an Optional Assertion Assertion Authors should disallow the use of the wsp:Optional attribute on assertions that represent behaviors that must be engaged.

Behaviors must be engaged with respect to messages that are targeted to the provider so that the provider can determine that the optional behavior is engaged. In ohter words, the need for self describing messages []should not be forgotten. An explicit, out of band mechanism might be necessary to enable a client to indicate that the optional behavior is engaged. (Such an out of band mechanism is outside the scope of the WS-Policy Framework).

Indicate use of an Optional Assertion When a given behavior may be optional, it must be possible for both message participants to determine that the assertion has been selected by both parties, either out of band or as reflected by the message content.

The document contains an example that outlines the use of as an optional behavior that can be engaged by a consumer. Related to this behavior is an assertion that identifies the use of MIME Multipart/Related serialization []. Policy-aware clients that recognize and engage this policy assertion will use Optimized MIME Serialization for messages.

The semantics of the MTOM assertion declare that the behavior must be reflected in messages by requiring that they use an obvious wire format (MIME Multipart/Related serialization). Thus, this optional behavior is self describing. For example, an inbound message to a web service that requires MTOM must adhere to Optimized MIME Serialization. By examining the message, the provider can determine whether the policy alternate that contains the MTOM assertion is being obeyed ( Best Practice: Indicate use of an Optional Assertion).

Note that if a MTOM assertion were only bound to the policy subject representing the inbound message, then it would not be clear to the service provider whether the outbound whether the outbound messages generated by that provider should also utilize that behavior. Thus this assertion should be associated at the granularity of an entire message exchange. The semantics of the assertion should specify this to avoid inappropriate assumptions by implementations.

Although a policy assertion may be constrained to a specific set of policy subjects by Assertion Authors, its semantics should not be dependent upon the mechanism by which the policy expression is attached to a given policy subject. For instance, an assertion "Foo" has the same semantics when attached to an operation policy subject regardless of whether it was attached using XML element policy attachment or the external URI attachment mechanism. Independence from a specific attachment mechanism allows policy tools to choose the most appropriate mechanism to attach a policy without having to analyze the contents of the policy.

Semantics Independent of Attachment Mechanisms The semantics of a policy assertion should not depend on the attachment mechanism used.

For example, a security policy expression can be assigned a key reference and be attached to a UDDI binding or can be embedded in a WSDL document.

Since multiple attachment mechanisms may be used, a policy alternative created during the process of calculating an effective policy can contain multiple instances of the same policy assertion type ( i.e., the SignedParts assertion). It is therefore also important for the policy authors to define what it means if multiple assertions are present.

Describe Semantics of Multiple Assertions of Same Type Assertion Authors should specify the semantics of multiple instances of the same policy assertion type in the same policy alternative and the semantics of parameters and nested policy (if any) when there are multiple instances of a policy assertion type in the same policy alternative regardless of the mechanism used to attach them to a policy subject.

Assertion authors should review sections 3.2 and 4.5 of the Policy Framework for more detail on the processing for multiple assertions of the same type.

Leverage Defined Attachment Mechanisms Assertion Authors should leverage defined attachment models when possible to document the use of the policy assertions they author and ensure that there are no additional semantics implied by the defined attachment models for their assertions.

Use Defined Policy Subjects Assertion Assertion Authors should leverage defined policy subjects when possible to facilitate the deployment of their policy assertions. Common Policy subjects have been defined and used by other policy assertion authors and new policy assertions that leverage these existing subjects will be easier to define and group.

Identify Policy Subjects Policy assertion authors should unambiguously identify the appropriate policy subjects for their assertions. If the best practices are followed, and the assertions are scoped according to their subject, then multiple policy domains may be combined without conflict. Each domain should define any limitations at the policy subject level that might impact interoperability.

Assertion Authors should review the policy subjects defined in WS-PolicyAttachments and identify which of the existing policy subjects can be used with the assertions they define. That identification will facilitate the deployment of their policy assertions.

An example of this practice is the Reliable Messaging Policy Assertion document []. In the Sequence STR Assertion (section 2.5.1) the Reliable Messaging Policy Assertion authors state that "The STR assertion defines the requirement that an RM Sequence MUST be bound to an explicit token that is referenced from a wsse:SecurityTokenReference in the CreateSequence message. This assertion MUST apply to [Endpoint Policy Subject]. This assertion MUST NOT be used for an endpoint that does not also use the RM assertion". This is illustrative of how the domain assertion author can specify additional constraints and assumptions for attachment and engagement of behavior in addition to the capabilities specified in Web Services Policy 1.5 - Attachment []. Such additional constraints must be clearly specified by the assertion authors.

A behavior identified by a policy assertion applies to the associated policy subject. If a policy assertion is to be used within WSDL, Assertion Authors should specify a WSDL policy subject.

The specific WSDL policy subject is determined with respect to a behavior as follows:

Specify WSDL Policy Subject(s) Assertion Authors should specify the set of relevant WSDL policy subjects with which the assertion may be associated.

Assertion Authors that utilize WSDL policy subjects need to understand how the assertions will be processed in intersection and merging, and the specific implications of the processing for a specific attachment point and policy subject. This topic is considered in detail in

For a given WSDL policy subject, there may be several attachment points. For example, there are three attachment points for the endpoint policy subject: the port, binding and portType element. Assertion Authors should identify the relevant attachment point when defining a new assertion.

Consider Scope of Attachment Points To determine the relevant attachment points, Assertion Authors should consider the scope of the attachment point.

For example, an assertion should only be allowed in the portType element if the assertion reasonably applies to any endpoint that ever references that portType. Most of the known policy assertions are designed for the endpoint, operation or message policy subject.

In using WSDL attachment, it should be noted that the service policy subject is a collection of endpoint policy subjects. The endpoint policy subject is a collection of operation WSDL policy subjects and so on. As a result, the WSDL policy subjects compose naturally. It is quite tempting to associate the identified behavior to a broader policy subject than to a fine granular policy subject. For instance, it is convenient to attach a supporting token assertion (defined by the Web Services Security Policy specification) to an endpoint policy subject instead of a message policy subject. The best practice is to choose the most granular WSDL policy subject to which the behavior represented by a policy assertion applies.

Choose the Most Granular WSDL Policy Subject Assertion Authors should choose the most granular WSDL policy subject to which the behavior represented by a policy assertion applies.

For authoring convenience, Assertion Authors may allow the association of an assertion to multiple WSDL policy subjects within the same context of use (e.g in the same WSDL description). If an assertion is allowed to be associated with multiple WSDL policy subjects as is possible with WSDL, then the Assertion Authors have the burden to describe the rules when multiple instances of the same assertion are attached to different WSDL policy subjects in order to avoid non-interoperable behavior.

Define Rules for Attachment of an Assertion type to Multiple WSDL policy subjects If an assertion is allowed to be associated with multiple WSDL policy subjects, the assertion author should describe the rules for multiple instances of the same assertion attached to multiple WSDL policy subjects in the same context.

To give one example, section 2.3 of the Web Services Reliable Messaging Policy Assertion specification [] gives rules on which WSDL policy subjects may be associated with the RM Policy assertion, and which WSDL 1.1 elements may have RM Policy assertions attached.

If the behavior indicated by an assertion varies when attached to different policy subjects the Assertion Authors should consider the following:

Since many attachment points are available in WSDL, it would be necessary for Assertion Authors to recommend a preferred attachment point. One approach would be to identify different attachment points in a policy subject, choose the most granular policy subject that the behavior applies to and specify that as a preferred attachment point. However, this approach only works if the policy subject is a true WSDL construct other than some other protocol concept that is layered over WSDL message exchanges. For example, as described previously the WS-RM Policy is a capability that governs a target endpoint's capability to accept message sequences that are beyond single message exchange. Therefore, its semantics encompass the cases when message level WSDL policy subjects may be used as attachment but also considers the case when sequences are present. In addition, when the policy assertions do not target wire-level behaviors but rather abstract requirements, this technique does not apply.

Specify Preferred WSDL Attachment Point If an assertion can be attached at multiple attachment points within a policy subject, Assertion Authors should specify a preferred attachment point for the chosen policy subject.

Assertion Authors that utilize WSDL policy subjects need to understand how the assertions will be processed in merging and the specific implications of a result where multiple assertions of the assertion type are in an alternative, in the merged policy. For example, consider the SignedParts assertion defined in WS-SecurityPolicy 1.2. The definition of SignedParts assertion explicitly permits multiple SignedParts assertions to be present within a policy alternative, and declares it to be equivalent to a single SignedParts assertion containing the union of all specified message parts. So, if a SignedParts assertion is specified in a WSDL binding at the input message level and subsequently an additional SignedParts assertion is specified at the WSDL endpoint policy subject level, then the effective policy at the endpoint could have more than one SignedParts assertion in the same alternative. However, the clear semantics defined by the SignedParts assertion enable processing of the multiple occurrences properly.

In general, UDDI protocol messages can be used to save TModel, businessEntity, businessService and bindingTemplate definitions with policies attached. These definitions can also be the target of a "find" protocol message, thus allowing authors to store and retrieve policy assertions. There are two ways to associate policy expressions with UDDI definitions: direct referece, and registering policy as a UDDI TModel. Assertion Authors defining new assertions should consider each approach.

Use defined tModels when appropriate UDDI defines the following policy subjects: Service Provider Policy, Service Policy subject and Endpoint Policy subject.

When defining assertions and recommending a service provider policy subject [uddi:BusinessEntity], or a service policy subject [uddi:buisnessService], assertion authors are scoping the behaviors to the service provider as a whole. When defining assertions and recommending an endpoint policy subject [uddi:bindingTemplate, uddi:tModel], assertion authors are scoping behaviors to a deployed endpoint.