- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Sat, 27 Oct 2007 00:51:11 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv27137
Modified Files:
ws-policy-guidelines.xml ws-policy-guidelines.html
Log Message:
Fixed typos (re 5206 and editors' action 379).
s/Example 1/SignBeforeEncrypting assertion/ and
s/Example 2/EncryptBeforeSigning assertion/ in 5.3.5 Order of Behaviors.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.112
retrieving revision 1.113
diff -u -d -r1.112 -r1.113
--- ws-policy-guidelines.html 24 Oct 2007 15:55:39 -0000 1.112
+++ ws-policy-guidelines.html 27 Oct 2007 00:51:09 -0000 1.113
@@ -121,14 +121,15 @@
5.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br>
5.3.3 <a href="#self-describing"> Self Describing Messages </a><br>
5.3.4 <a href="#single-domains">Single Domains</a><br>
+ 5.3.5 <a href="#order-of-behaviors">Order of Behaviors</a><br>
5.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br>
5.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
5.5 <a href="#Ignorable">Designating Ignorable Behavior</a><br>
- 5.5.1 <a href="#d3e802">Ignorable behavior in authoring</a><br>
- 5.5.2 <a href="#d3e815">Ignorable behavior at runtime</a><br>
+ 5.5.1 <a href="#d3e827">Ignorable behavior in authoring</a><br>
+ 5.5.2 <a href="#d3e840">Ignorable behavior at runtime</a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d3e830">Optional behavior at runtime</a><br>
+ 5.6.1 <a href="#d3e855">Optional behavior at runtime</a><br>
5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment</a><br>
5.7.1 <a href="#general-attachment-guidelines">General Guidelines</a><br>
5.7.2 <a href="#wsdl-attachment-guidelines">Considerations for Policy Attachment in WSDL</a><br>
@@ -170,18 +171,10 @@
specifications and the Primer. It is intended to provide
non-normative guidelines for WS-Policy Assertion Authors who
need to know the features of the language and understand the
- requirements for describing policy assertions. Some of the
- guidance for WS-Policy Assertion Authors can also be helpful
- for:
-
- </p><ul><li><p>WS-Policy expression authors who need to understand
- the syntax of the language and understand how to build consistent
- policy expressions
- </p></li><li><p>Consumers of policy expressions who need to understand
- the requirements contained in policy assertions
- </p></li><li><p>Providers of policy expressions who need to understand
- how to use the assertions authored by Assertion Authors
- </p></li></ul><p>This document assumes a basic understanding of XML,
+ requirements for describing policy assertions. Some of the guidance
+ for WS-Policy Assertion Authors can also be helpful for those who use
+ the policy assertions created by Assertion Authors.
+ </p><p>This document assumes a basic understanding of XML,
Namespaces in XML, WSDL, SOAP and the Web Services Policy language.
</p><p>This is a non-normative document and does
not provide a definitive specification of the Web Services
@@ -196,7 +189,9 @@
<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Best Practice Statements</h2><p>The following Best Practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ul><li><p><a href="#bp-compatibility-tests"><b>1. Define assertions relevant to compatibility tests</b></a></p></li><li><p><a href="#bp-ignorable-for-not-related-to-compatibility-tests"><b>2. Mark Ignorable Assertions not related to compatibility</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>6. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>7. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>8. Document Ignorable Behavior</b></a></p></li><li><p><a hrf="#ignorableAssertions"><b>9. Document Use of the Ignorable
Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>10. Assertion Authors should allow use of wsp:Optional</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>11. Assertions should not describe message
semantics</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>12. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>13. Use Parameters for Useful
- Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>14. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>15. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>16. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>17. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>18. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>19. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-assertion-semantics"><b>20. Semantics Independent of Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-semantics-multiple-same-type"><b>21. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-leverage-defined-attacment-mechanisms"><b>22. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>23. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>24. Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>25. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-consider-scope"><b>26. Consider Scope of Attachment Points</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>27. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>28. Define Rules for Attachment of an Assertion
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>14. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>15. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>16. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>17. 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 </b></a></p></li><li><p><a href="#bp-limitoptional-assertion-use"><b>18. Limit use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>19. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-assertion-semantics"><b>20. Semantics Independent of Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-semantics-multiple-same-type"><b>21. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>22. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>23. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>24. Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>25. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-consider-scope"><b>26. Consider Scope of Attachment Points</b></a></p></li>li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>27. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>28. Define Rules for Attachment of an Assertion
type to Multiple WSDL policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>29. Specify Preferred WSDL Attachment Point</b></a></p></li><li><p><a href="#bp-UDDI-tmodels"><b>30. Use defined tModels when appropriate</b></a></p></li><li><p><a href="#bp-specify-composition"><b>31. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>32. Independent Assertions for Different Versions of a
Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>33. Document changes to policy
subject</b></a></p></li></ul></div><div class="div1">
@@ -679,7 +674,46 @@
</p><p>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.</p><div class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Best
-Practice 12: Avoid Duplication of Assertions</span></p><p class="practice">Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.</p></div></div></div><div class="div2">
+Practice 12: Avoid Duplication of Assertions</span></p><p class="practice">Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.</p></div></div><div class="div3">
+<h4><a name="order-of-behaviors" id="order-of-behaviors"></a>5.3.5 Order of Behaviors</h4><p> A policy alternative is a collection of zero or more policy assertions.
+ Assertions within a policy alternative are not ordered.</p><p>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.</p><p>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.</p><p>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. </p><p>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 <code>wsse:Security</code> 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 <code>wsse:Security</code> header, and then prepend the signature element." </p><p>The Web Services Security Policy specification provides assertions which let users control
+ whether to sign the message before encrypting or sign it after encrypting. </p><p>In the example below, the SignBeforeEncrypting assertion requires producers to sign a message
+ before encrypting.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-7. </span>SignBeforeEncrypting assertion</i></p><div class="exampleInner"><pre><wsp:Policy>
+ <sp:AsymmetricBinding>
+ <wsp:Policy>
+ <sp:IncludeTimestamp />
+ <sp:SignBeforeEncrypting />
+ <sp:EncryptSignature />
+ <sp:ProtectTokens />
+ <wsp:Policy/>
+ </sp:AsymmetricBinding>
+ <wsam:Addressing>...</wsam:Addressing>
+</wsp:Policy> </pre></div></div><p>In the example below, the EncryptBeforeSigning assertion requires producers
+ to sign a message after encrypting. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-8. </span>EncryptBeforeSigning assertion</i></p><div class="exampleInner"><pre><wsp:Policy>
+ <sp:AsymmetricBinding>
+ <wsp:Policy>
+ <sp:IncludeTimestamp />
+ <sp:EncryptBeforeSigning />
+ <sp:EncryptSignature />
+ <sp:ProtectTokens />
+ <wsp:Policy/>
+ </sp:AsymmetricBinding>
+ <wsam:Addressing>...</wsam:Addressing>
+</wsp:Policy> </pre></div></div></div></div><div class="div2">
<h3><a name="comparison" id="comparison"></a>5.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information
in an assertion beyond its type: assertion parameters and nested policy
expressions. We cover these two cases below followed by a comparison of these
@@ -708,7 +742,7 @@
These two parameters identify the parts of a wire message that should be
protected. These parameters carry additional useful information for
engaging the behavior.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-7. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><wsp:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-9. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><wsp:Policy>
<sp:SignedParts>
<sp:Body/>
<sp:Header/>
@@ -782,7 +816,7 @@
already requires the use of transport-level security for
protecting messages).
</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-8. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-10. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
<Policy>
<sp:TransportToken>
<Policy>
@@ -828,7 +862,7 @@
<code>HttpToken</code> 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.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-9. </span>Empty Nested Policy Expression</i></p><div class="exampleInner"><pre><sp:TransportToken>
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-11. </span>Empty Nested Policy Expression</i></p><div class="exampleInner"><pre><sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy/>
@@ -838,70 +872,75 @@
certificate will not be able to use this provider solely on the basis
of intersection algorithm alone.</p></div></div><div class="div2">
<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><div class="div3">
-<h4><a name="d3e802" id="d3e802"></a>5.5.1 Ignorable behavior in authoring</h4><p>
+<h4><a name="d3e827" id="d3e827"></a>5.5.1 Ignorable behavior in authoring</h4><p>
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 <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. 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 <a href="#DefineIgnorable"><b>8. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>9. Document Use of the Ignorable
Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
-<h4><a name="d3e815" id="d3e815"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+<h4><a name="d3e840" id="d3e840"></a>5.5.2 Ignorable behavior at runtime</h4><p>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.
</p><p>
As said in <a href="ws-policy-primer.html#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</a> in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>, "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.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.6 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e830" id="d3e830"></a>5.6.1 Optional behavior at runtime</h4><p>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.
- </p><div class="boxedtext"><p><a name="bp-limit-optional-assertions" id="bp-limit-optional-assertions"></a><span class="practicelab">Best
-Practice 17: Limit use of Optional Assertions</span></p><p class="practice">Assertion Authors should not use optional assertions for behaviors that must be present
- in compatible policy expressions.</p></div><p> The target scope of an optional assertion is an important factor for
+<h4><a name="d3e855" id="d3e855"></a>5.6.1 Optional behavior at runtime</h4><p> The target scope of an assertion is an important factor for
Assertion Authors to consider as it determines the
- <em>granularity</em> 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 <em> engaged </em>. 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.
- </p><p>
- When optional behaviors are indicated by attaching assertions with
+ <em>granularity</em> 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.
+ </p><p> 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 of the rest of the interaction will
+ 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 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.
+ 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. One approach that is currently taken
- by WS-RM Policy [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] 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.
+ than one specific policy subject. The approach taken by
+ WS-RM Policy [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] 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).
</p><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Best
-Practice 18: Consider entire message exchange pattern when specifying Assertions that may be optional</span></p><p class="practice">Assertion Authors should associate optional assertions with the appropriate endpoint and use the smallest
- possible granularity to limit the degree to which optionality applies.</p></div><p>
- 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 [<a href="#self-describing"><b>5.3.3 Self Describing Messages </b></a>] 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).
+Practice 17: 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 </span></p><p class="practice">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.</p></div><p>
+ 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.
+ </p><div class="boxedtext"><p><a name="bp-limitoptional-assertion-use" id="bp-limitoptional-assertion-use"></a><span class="practicelab">Best
+Practice 18: Limit use of an Optional Assertion</span></p><p class="practice">Assertion Authors should disallow the use of the wsp:Optional
+ attribute on assertions that represent behaviors that must be engaged.</p></div><p>
+ 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 [<a href="#self-describing"><b>5.3.3 Self Describing Messages </b></a>]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).
</p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Best
-Practice 19: Indicate use of an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties,
- either out of band or as reflected by the message content.</p></div><p>
+Practice 19: Indicate use of an Optional Assertion</span></p><p class="practice">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.</p></div><p>
The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an example that outlines the
use of
<cite><a href="#MTOM">MTOM</a></cite> as an optional behavior that can be engaged by a consumer.
@@ -918,14 +957,12 @@
alternate that contains the MTOM assertion is being obeyed (
<a href="#bp-indicate-optional-assertion-use">Best Practice: Indicate use of an Optional Assertion</a>).
</p><p>
- Note that if a MTOM assertion were only bound to an inbound message endpoint,
- then it would not be clear whether the outbound message from the provider would
- also utilize the behavior. Thus this assertion should be associated at the granularity
+ 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. This is important for an
- optional assertion where it may not be clear whether it is to apply in a message
- exchange when optionally used in part of that exchange
- (<a href="#bp-entire-mep-for-optional">Best Practice: Consider entire message exchange pattern when specifying Assertions that may be optional</a>).
+ to avoid inappropriate assumptions by implementations.
</p></div></div><div class="div2">
<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>5.7 Considerations for Policy Attachment</h3><div class="div3">
<h4><a name="general-attachment-guidelines" id="general-attachment-guidelines"></a>5.7.1 General Guidelines</h4><p>Although a policy assertion may be constrained to a specific set of policy subjects by Assertion Authors,
@@ -1123,7 +1160,7 @@
additional assertions
related to [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>], an interrelated security domain. One such additional assertion
specifies the use of transport security to protect a message sequence, for example.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-10. </span>Reliable Message Sequence Security</i></p><div class="exampleInner"><pre><wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... /></pre></div></div><p>The Reliable Message Policy specification states
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-12. </span>Reliable Message Sequence Security</i></p><div class="exampleInner"><pre><wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... /></pre></div></div><p>The Reliable Message Policy specification states
"This assertion is effectively meaningless unless it occurs in conjunction with the
<code>RMAssertion</code> and a <code>sp:TransportBinding</code> assertion that requires the use of some transport-level
security mechanism (e.g. <code>sp:HttpsToken</code>)".
@@ -1671,4 +1708,15 @@
</td></tr><tr><td rowspan="1" colspan="1">20071024</td><td rowspan="1" colspan="1">TIB</td><td rowspan="1" colspan="1">Implemented the resolution for issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5186">5186</a>. Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/374">374</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20071026</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5206">5206</a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/379">379</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20071026</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5189">5189</a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/381">381</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20071026</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Fixed typos (re <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5206">5206</a> and editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/379">379</a>).
+ s/Example 1/SignBeforeEncrypting assertion/
+ and
+ s/Example 2/EncryptBeforeSigning assertion/ in <a href="#order-of-behaviors"><b>5.3.5 Order of Behaviors</b></a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.129
retrieving revision 1.130
diff -u -d -r1.129 -r1.130
--- ws-policy-guidelines.xml 26 Oct 2007 16:28:51 -0000 1.129
+++ ws-policy-guidelines.xml 27 Oct 2007 00:51:08 -0000 1.130
@@ -854,7 +854,7 @@
<p>In the example below, the SignBeforeEncrypting assertion requires producers to sign a message
before encrypting.</p>
- <example> <head>Example 1</head>
+ <example> <head>SignBeforeEncrypting assertion</head>
<eg xml:space="preserve"><wsp:Policy>
<sp:AsymmetricBinding>
<wsp:Policy>
@@ -871,7 +871,7 @@
to sign a message after encrypting. </p>
- <example> <head>Example 2</head>
+ <example> <head>EncryptBeforeSigning assertion</head>
<eg xml:space="preserve"><wsp:Policy>
<sp:AsymmetricBinding>
<wsp:Policy>
@@ -2815,7 +2815,17 @@
<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5189">5189</loc>. Editors' action
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/381">381</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20071026</td>
+ <td>ASV</td>
+ <td>Fixed typos (re <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5206">5206</loc> and editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/379">379</loc>).
+ s/Example 1/SignBeforeEncrypting assertion/
+ and
+ s/Example 2/EncryptBeforeSigning assertion/ in <specref ref="order-of-behaviors"></specref>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Saturday, 27 October 2007 00:51:24 UTC