Web Services Policy 1.5 - Guidelines for Policy Assertion Authors

4.1.1 Assertion Authors

Assertion Authors are a community that chooses to exploit the WS-Policy Framework by creating their own specification 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.

When using the WS-Policy Framework, any Assertion Authors defining new WS-Policy assertions must adhere to the MUST's and SHOULD's in the specification and should review the conformance section of the specification.

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 [WS-SecurityPolicy]. 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.

4.1.2 Consumers

A consumer of WS-Policy Assertions can be any entity that is capable of parsing a WS-Policy XML element 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 models for use with common web service subjects: WSDL definitions [WSDL 1.1, WSDL 2.0 Core Language], UDDI directory entries [UDDI API 2.0, UDDI Data Structure 2.0, UDDI 3.0], and WS-Addressing Endpoint References (EPR) [WS-Addressing Core].

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.

4.1.3 Providers

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 [Web Services Policy Framework] and Web Services Policy 1.5 - Attachment [Web Services Policy 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 6. Versioning Policy Assertions and Web Services Policy Primer that describes service and policy assertion evolution.

5.3.1 Minimal approach

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 and they now constitute a policy alternative.

If grouping is utilized, choices between alternatives can be indicated by an "exactly one" 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.

New Assertion Authors are encouraged to look at Web Services Reliable Messaging Policy to see an example of a relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at WS-SecurityPolicy to see an example of a complex domain that has been decomposed into a set of policy expressions.

5.3.2 QName and XML Information Set representation

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 is: Use a unique QName to identify a distinct behavior

An example of this method is given in the Web Services Reliable Messaging Policy document [Web Services Reliable Messaging Policy] and included below for illustration. The unique Qname for RM in this case is "RMAssertion".

The syntax of an assertion can be represented using an XML outline (plus an XML schema document) to specify the syntax of an assertion.

 <wsrmp:RMAssertion [wsp:Optional="true"]? ...> 
   <wsp:Policy >
     [ <wsrmp:SequenceSTR/> |
       <wsrmp:SequenceTransportSecurity/> ] ?
     <wsrmp:DeliveryAssurance/> 
     <wsp:Policy >
        [ <wsrmp:ExactlyOnce/> | 
          <wsrmp:AtLeastOnce/> |
          <wsrmp:AtMostOnce/> ]
        <wsrmp:InOrder/> ?
     </wsp:Policy>
     </wsrmp:DeliveryAssurance> ] ?
    </wsp:Policy>
 </wsrmp:RMAssertion/>
 

Outlines can also illustrate the nesting of assertions. In the example above, the assertion DeliveryAssurance, has nested policy assertions and the XML outline enumerates the nested assertions (ExactlyOnce, AtLeastOnce,AtMostOnce)that are allowed.

To give a general example, the definiton of assertion syntax for a hypothetical assertion such as SampleAssertion, should allow attribute extensibility as part of the XML definition, allowing the attributes defined by wsp:Policy to be used.

/samplePrefix:SampleAssertion/@any
This is an extensibility mechanism to allow additional attributes to be added to the element, including wsp:Optional.
				

When an XML outline is included as part of an assertion description it is possible to use the wsp:Optional attribute in the outline. In the RM case above, wsp:Optional was used.

When an XML outline is included as part of an assertion description it is possible to use the wsp:Ignorable attribute in the outline. In the example below, wsp:Ignorable was used to indciate behavior that does not impact intersection.

5.3.3 Self Describing Messages

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

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.

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.

5.3.4 Single Domains

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.

5.4.1 Assertions with Parameters

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

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.

<wsp:Policy>
  <sp:SignedParts>
    <sp:Body/>
    <sp:Header/>
  </sp:SignedParts>
</wsp:Policy>

5.4.2 Nested Assertions

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.

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

• Are these assertions designed for the same policy subject?

• Do these assertions represent dependent behaviors?

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.

The main consideration for selecting parameters or nesting of assertions is that the framework intersection algorithm processes nested alternatives, but does not consider parameters in its algorithm.

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.

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

<sp:TransportBinding>
  <Policy>
    <sp:TransportToken>
      <Policy>
        <sp:HttpsToken>
          <wsp:Policy/>
        </sp:HttpsToken>
      </Policy>
    </sp:TransportToken>
    <sp:AlgorithmSuite>
      <Policy>
        <sp:Basic256Rsa15/>
      </Policy>
    </sp:AlgorithmSuite>
  </Policy>
</sp:TransportBinding>

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.

<sp:TransportToken> 
  <wsp:Policy> 
	<sp:HttpsToken> 
	  <wsp:Policy/> 
	</sp:HttpsToken> 
  </wsp:Policy> 
</sp:TransportToken>

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.

5.5.1 Ignorable Behavior in Intersection

Ignorable assertions represent behaviors that may be ingored by the intersection algorithm. At a minimum, assertion authors need to document the semantics of the assertions [see Best Practice 2] and included in that definition should be some indication of the impact of the assertion behavior at intersection and at runtime.

When policy expression authors include these assertions in service policies, some behaviors may be marked by using the wsp:Ignorable attribute with a value of "true". (In order to simplify reference to such assertions, we just use the phrase "ignorable assertions" in this section). It is recommended that if it is possible to use the wsp:Ignorable attribute, that the assertion authors indicat this in any XML outline [Best Practice 7]. During intersection, there are two defined modes for processing, lax and strict. Policy assertions marked with an attribute to indicate that the assertion can be ignored by the interstection algorithm are processed differently by the algorithm specified in the Policy Framesork [see strict and lax mode in Framework and Primer for details]. Assertion Authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and indicate this in the definition of the assertion. The use of the ignorable attribute influences whether or not certain assertions are part of the compatability assessment between two alternatives. See [tbd] for details on the use of the ignorable attribute.

5.5.2 Ignorable Behavior at runtime

Ignorable behaviors indicate behavior at the time of intersection. At runtime, a party that indicated an ignorable behavior in its policy may engage the behavior that was marked "ignorable" for intersection. Assertion authors should indicate the semantic of the runtime behavior in the description of the assertion that allows the ignorable attribute.

Policy intersection in strict mode will result in alternatives that consist only of assertions known to both parties. Hence, the runtime behavior is known to both parties.

Policy intersection in lax mode may result in alternatives with assertions that exist in one party's policy but not the other party's policy. In the case where one party chooses to engage in runtime behavior with another party based on alternatives from a lax mode intersection algorithm, the runtime behavior is out of scope of the policy framework.

5.6.1 Optional behavior in Compact authoring

Optional behaviors represent behaviors that may be engaged by a consumer. When using the compact authoring form for assertions, such behaviors are marked by using wsp:Optional attribute with a value of "true". (In order to simplify reference to such assertions, we just use the phrase “optional assertions” in this section.) During the process of normalization the runtime behavior is indicated by two policy alternatives, one with and one without the assertion. In a consumer/provider scenario, the choice of engaging the runtime behavior is upon the consumer by selecting the appropriate policy alternative. The provider may influence what is possible by choosing whether or not to include policy alternatives in a policy expression, by using the wsp:Optional attribute. Assertion Authors should clearly indicate in the assertion definition that it is possible to be optional [See Section xx].

The portion of the assertion definition that describes policy subjects and assertion attachment should indicate that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.

Continuing the example with the hypothetical SampleAssertion, the section on Assertion Attachment should include discussion of optionality.

The SampleAssertion policy assertion indicates behavior over all messages in a binding, so
it has an Endpoint Policy Subject and must be attached to a wsdl:binding or wsdl:port. 
The assertion may be optional when attached to these subjects, allowing use of wsp:Optional.
					

5.6.2 Optional behavior at runtime

Since optional behaviors indicate optionality for both the provider and the consumer, behaviors that must always be engaged by a consumer must not be marked as "optional" with a value "true" since this would allow the consumer to select the policy alternative that does not contain the assertion, and thus not engaging the behavior.

The target scope of an optional assertion is an important factor for Assertion Authors to consider as it determines the granularity where the behavior is optionally engaged. For example, if the assertion is targeted for an endpoint policy subject, it is expected to govern all the messages that are indicated by the specific endpoint when optional behavior is engaged . Since the behavior would be applicable to policy subject that is designated, it is important for the Assertion Authors to choose the appropriate level of granularity for optional behaviors, to consider whether a specific message or all messages, etc. are targeted.

When 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 of the rest of the interaction will be undefined. Therefore, the Assertion Authors are encouraged to consider how the attachment on a message policy subject on a response message should be treated when optional behaviors are specified for message exchanges within a request response for response messages, using message policy subject. Leaving the semantics not specified or incompletely specified may result in providers making assumptions. Similarly, if engagement of a behavior is only specified for an outbound message, the Assertion Authors should consider describing the semantics if the incoming messages also utilized the behavior. This is especially important if the assertion is applicable to more than one specific policy subject. One approach that is currently taken by WS-RM Policy [Web Services Reliable Messaging Policy] is to introduce both message and endpoint policy subjects for one of its assertions and require the use of endpoint policy subject when message policy subject is used via attachment.

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 other words, the need for self describing messages [5.3.3 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 WS-Policy Framework).

7.2.1 Interaction between Subjects

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 (i.e. WS-SecurityPolicy - binding abstraction to group capabilities per message exchange).