Assertion Authors should understand the functionality that the WS-Policy framework provides and apply the knowledge of the policy framework processing when defining the set of assertions.
Assertions can be simple or they can be complex. Assertion Authors may choose to specify multiple peer assertions, each carrying the semantic of a particular behavior, or they may choose to specify assertions that contain assertion parameters and/or nested policy expressions (nested assertions), where each nested assertion of which relates to an aspect of the behavior, yet encapsulated within a single assertion. There are advantages to simplifying the set of assertions. The ultimate goal of policy is to enable interoperability. By keeping assertion design as simple as possible, Assertion Authors will more likely be able to meet that objective.
Assertion Authors need to have a specific goal in mind for the assertions that they author. Assertion specifications should include a detailed specification of the assertion’s semantics and a set of valid policy subjects to which the assertion maybe attached. The specification should also include the scope of the assertion in the context of a particular policy subject. For example, an assertion with Endpoint Policy Subject can be scoped to a given message exchange with that endpoint, or it can be scoped to all messages exchanged with that endpoint. The former case permits a client to select a different alternative with each successive message exchange. Finally, the ability to combine individual assertions may also need to be considered. For example, if an assertion applies to the SOAP protocol, it would be necessary to consider how its presence must interact with other policy assertions that are defined for security.
Assertion Authors should include the following items in an assertion specification:
The definition of the assertion's semantic (See best practice 8. Specify Semantics Clearly).
The specification of the set of valid policy subjects to which an assertion may be attached (See best practice 26. Specify WSDL Policy Subject(s)).
The scope of the assertion in the context of a particular policy subject (See best practices in Section 5.7 Considerations for Policy Attachment).
Any composition considerations if the assertion is used with other assertions in a context (See best practice 32. Specify Composition with Related Assertions).
The WS-Policy Attachment specification defines a number of different policy subjects to which an assertion can be attached. For attaching to WSDL subjects see 5.7 Considerations for Policy Attachment for more detail. Additionally, the framework provides for the means to extend the set of policy subjects beyond the set of subjects defined in the WS-Policy Attachment specification.
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.
Best Practice 1: Semantics Independent of Attachment Mechanisms
The semantics of a policy assertion should not depend on the attachment mechanism used.
...
The Policy attachment mechanism used to communicate the policy assertions should not affect or imply additional semantics in the interpretation of Policy alternatives. If it did, each policy assertion would need to be written with different (and possibly unknown) attachment mechanisms in mind. 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.
Best Practice 21: Reusable Assertions
Assertion Authors are encouraged to create policy assertions that can be used regardless of attachment mechanism.
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.
Best Practice 20: 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.