A Policy Assertion identifies a visible domain specific behavior that is a capability or requirement. In the example below, Policy Expression uses the TransportBinding Security Policy Assertion. This assertion identifies the use of transport level security – such as HTTPS - for protecting messages.
<wsp:Policy>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</sp:TransportToken>
...
</wsp:Policy>
</sp:TransportBinding>
</wsp:Policy>
TransportBinding is a Policy Assertion. A Policy Assertion is an XML element. The QName of this element represents the behavior identified by this Policy Assertion. Policy Assertion may contain Parameters and a Nested Policy.
RequireClientCertificate is a Parameter of the HttpsToken Policy Assertion. Parameters are the opaque payload of a Policy Assertion and are preserved through policy processing such as normalize, merge and intersect. A Parameter can be either an XML element child or attribute of a Policy Assertion element.
TransportToken is a Nested Policy Assertion of the TransportBinding Policy Assertion. TransportToken assertion requires the use of a transport token. A Nested Policy Assertion further qualifies a dependent behavior of a Policy Assertion.
Policy Assertions are defined by users, product designers and protocol authors. What are the minimum requirements for describing a Policy Assertion? Policy Framework and Attachment specifications outline the following:
- Description must clearly and completely specify the syntax and semantics of a Policy Assertion
- If there is a Nested Policy Expression, description must declare it and enumerate the Nested Policy Assertions that are allowed
- Description must specify the semantics when there are multiple instances of a Policy Assertion in the same Policy Alternative
- If a Policy Assertion is to be used with WSDL, description must specify a WSDL Policy Subject – such as Service, Endpoint, Operation and Message.
Wala!
Comments