- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 09 Feb 2007 17:35:26 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv29041
Modified Files:
ws-policy-primer.html ws-policy-framework.html
ws-policy-attachment.html ws-policy-guidelines.html
Log Message:
Updated the Acknowledgements Appendix to be current
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -d -r1.36 -r1.37
--- ws-policy-primer.html 31 Jan 2007 21:09:22 -0000 1.36
+++ ws-policy-primer.html 9 Feb 2007 17:35:23 -0000 1.37
@@ -8,6 +8,12 @@
div.note,
div.notice { margin-left: 2em; }
+ol.enumar { list-style-type: decimal; }
+ol.enumla { list-style-type: lower-alpha; }
+ol.enumlr { list-style-type: lower-roman; }
+ol.enumua { list-style-type: upper-alpha; }
+ol.enumur { list-style-type: upper-roman; }
+
dt.label { display: run-in; }
li, p { margin-top: 0.3em;
@@ -48,21 +54,56 @@
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
-</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"><link rel="contents" href="#contents"></head><body><div class="head">
-<h1>Web Services Policy 1.5 - Primer</h1>
-<h2>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
+</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"></head><body><div class="head">
+<h1><a name="title" id="title"></a>Web Services Policy 1.5 - Primer</h1>
+<h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
<a href="ws-policy-primer.html">ws-policy-primer.html</a>
</dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematis">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
-<h2><a name="abstract">Abstract</a></h2><p>
+<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
<em>Web Services Policy 1.5 - Primer</em> is an introductory description of the Web Services Policy
language. This document describes the policy language features using numerous examples. The
associated Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment specifications provide the
complete normative description of the Web Services Policy language. </p></div><div>
-<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
- no official standing.</strong></p><p></p></div><hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#basic-concepts-policy-expression">Basic Concepts: Policy Expression</a><br> 2.1 <a href="#web-services-policy">Web Services Policy</a><br> 2.2 <a href="#simple-message">Simple Message</a><br> 2.3 <a href="#secure-message">Secure Message</a><br> 2.4 <a href="#other-assertions">Other Assertions</a><br> 2.5 <a href="#combining-policy-assertions">Combining Policy Assertions</a><br> 2.6 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 2.7 <a href="#ignorable-policy-assertions">Ignorable Policy Expressions</a><br> 2.8 <a href="#nested-policy-expressions">Nested Policy Expressions</a><br> 2.9 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a<br> 2.10 <a href="#attaching-policy-expressions-to-wsdl">Attaching Policy Expressions to WSDL</a><br> 2.11 <a href="#policy-automates-web-services-interaction">Policy Automates Web Services Interaction</a><br>3. <a href="#advanced-concepts-policy-expression">Advanced Concepts: Policy Expression</a><br> 3.1 <a href="#policy-expression">Policy Expression</a><br> 3.2 <a href="#normal-form-for-policy-expressions">Normal Form for Policy Expressions</a><br> 3.3 <a href="#policy-data-model">Policy Data Model</a><br> 3.4 <a href="#compatible-policies">Compatible Policies</a><br> 3.4.1 <a href="#strict-lax-policy-intersection">Strict and Lax Policy Intersection</a><br> 3.5 <a href="#attaching-policy-expressions-to-wsdl2">Attaching Policy Expressions to WSDL</a><br> 3.6 <a href="#policy-rerieval">Policy Retrieval</a><br> 3.7 <a href="#combine-policies">Combine Policies</a><br> 3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br> 3.8.1 <a href="#ignorable-and-versioning">Ignorable and Versioning</a><br> 3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br> 3.10 <a href="#versioning-policy-language">Versioning Policy Language</a><br> 3.10.1 <a href="#versioning-policy-framework">Policy Framework</a><br> 3.10.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>4. <a href="#conclusion">Conclusion</a><br></p>
-<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>B. <a href="#xml-namespaces">XML Namespaces</a><br>C. <a href="#references">References</a><br>D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>E. <a href="#change-description">Changes in this Version of the Document</a> (Non-Normative)<br>F. <a href="#change-log">Web Services Policy 1.5 - Primer Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
-<h2><a name="introduction"></a>1. Introduction</h2><p>This document, <em>Web Services Policy 1.5 - Primer</em>, provides an introductory description of the
+<h2><a name="status" id="status"></a>Status of this Document</h2><p><strong>This document is an editors' copy that has
+ no official standing.</strong></p><p></p></div><div class="toc">
+<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
+2. <a href="#basic-concepts-policy-expression">Basic Concepts: Policy Expression</a><br>
+ 2.1 <a href="#web-services-policy">Web Services Policy</a><br>
+ 2.2 <a href="#simple-message">Simple Message</a><br>
+ 2.3 <a href="#secure-message">Secure Message</a><br>
+ 2.4 <a href="#other-assertions">Other Assertions</a><br>
+ 2.5 <a href="#combining-policy-assertions">Combining Policy Assertions</a><br>
+ 2.6 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br>
+ 2.7 <a href="#ignorable-policy-assertions">Ignorable Policy Expressions</a><br>
+ 2.8 <a href="#nested-policy-expressions">Nested Policy Expressions</a><br>
+ 2.9 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>
+ 2.10 <a href="#attaching-policy-expressions-to-wsdl">Attaching Policy Expressions to WSDL</a><br>
+ 2.11 <a href="#policy-automates-web-services-interaction">Policy Automates Web Services Interaction</a><br>
+3. <a href="#advanced-concepts-policy-expression">Advanced Concepts: Policy Expression</a><br>
+ 3.1 <a href="#policy-expression">Policy Expression</a><br>
+ 3.2 <a href="#normal-form-for-policy-expressions">Normal Form for Policy Expressions</a><br>
+ 3.3 <a href="#policy-data-model">Policy Data Model</a><br>
+ 3.4 <a href="#compatible-policies">Compatible Policies</a><br>
+ 3.4.1 <a href="#strict-lax-policy-intersection">Strict and Lax Policy Intersection</a><br>
+ 3.5 <a href="#attaching-policy-expressions-to-wsdl2">Attaching Policy Expressions to WSDL</a><br>
+ 3.6 <a href="#policy-retrieval">Policy Retrieval</a><br>
+ 3.7 <a href="#combine-policies">Combine Policies</a><br>
+ 3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br>
+ 3.8.1 <a href="#ignorable-and-versioning">Ignorable and Versioning</a><br>
+ 3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br>
+ 3.10 <a href="#versioning-policy-language">Versioning Policy Language</a><br>
+ 3.10.1 <a href="#versioning-policy-framework">Policy Framework</a><br>
+ 3.10.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>
+4. <a href="#conclusion">Conclusion</a><br>
+</p>
+<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>
+B. <a href="#xml-namespaces">XML Namespaces</a><br>
+C. <a href="#references">References</a><br>
+D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>
+E. <a href="#change-description">Changes in this Version of the Document</a> (Non-Normative)<br>
+F. <a href="#change-log">Web Services Policy 1.5 - Primer Change Log</a> (Non-Normative)<br>
+</p></div><hr><div class="body"><div class="div1">
+<h2><a name="introduction" id="introduction"></a>1. Introduction</h2><p>This document, <em>Web Services Policy 1.5 - Primer</em>, provides an introductory description of the
Web Services Policy language and should be read alongside the formal descriptions contained
in the WS-Policy and WS-PolicyAttachment specifications.</p><p>This document is:</p><ul><li><p>for policy expression authors who need to understand the syntax of the language and
understand how to build consistent policy expressions,</p></li><li><p>for policy implementers whose software modules read and write policy expressions
@@ -82,8 +123,8 @@
Services Policy language. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the namespaces that are used in
this document. (XML elements without a namespace prefix are from the Web Services Policy XML
Namespace.)</p></div><div class="div1">
-<h2><a name="basic-concepts-policy-expression"></a>2. Basic Concepts: Policy Expression</h2><div class="div2">
-<h3><a name="web-services-policy"></a>2.1 Web Services Policy</h3><p>Web services are being successfully used for interoperable solutions across various
+<h2><a name="basic-concepts-policy-expression" id="basic-concepts-policy-expression"></a>2. Basic Concepts: Policy Expression</h2><div class="div2">
+<h3><a name="web-services-policy" id="web-services-policy"></a>2.1 Web Services Policy</h3><p>Web services are being successfully used for interoperable solutions across various
industries. One of the key reasons for interest and investment in Web services is that
they are well-suited to enable service-oriented systems. XML-based technologies such as
SOAP, XML Schema and WSDL provide a broadly-adopted foundation on which to build
@@ -116,7 +157,8 @@
Services Policy is a simple language that has four elements - <code>Policy, All</code>,
<code>ExactlyOne</code> and <code>PolicyReference</code> - and one attribute -
<code>wsp:Optional</code>.</p></div><div class="div2">
-<h3><a name="simple-message"></a>2.2 Simple Message</h3><p>Let us start by considering a SOAP Message in the example below.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-1. </span>SOAP Message</i></p><div class="exampleInner"><pre><soap:Envelope>
+<h3><a name="simple-message" id="simple-message"></a>2.2 Simple Message</h3><p>Let us start by considering a SOAP Message in the example below.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-1. </span>SOAP Message</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
<wsa:To>http://stock.contoso.com/realquote</wsa:To>
<wsa:Action>http://stock.contoso.com/GetRealQuote</wsa:Action>
@@ -146,7 +188,8 @@
Contoso may augment the service WSDL description with a policy that requires the use of
addressing. The client application developer can use a policy-aware client that understands this policy and engages
addressing automatically.</p><p>How does Contoso use policy to represent the use of addressing? The example below
- illustrates a policy expression that requires the use of addressing.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-2. </span>Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+ illustrates a policy expression that requires the use of addressing.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-2. </span>Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<wsap:UsingAddressing />
</Policy></pre></div></div><p>The policy expression in the above example consists of a <code>Policy</code> main element
and a child element <code>wsap:UsingAddressing.</code> Child elements of the
@@ -162,8 +205,9 @@
reference WSDL constructs (such as port, binding and portType), Web Services Policy does
not require a message to reference a policy expression though the policy expression
describes the message.</p></div><div class="div2">
-<h3><a name="secure-message"></a>2.3 Secure Message</h3><p>In addition to requiring the use of addressing, Contoso requires the use of
- transport-level security for protecting messages.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-3. </span>Secure Message</i></p><div class="exampleInner"><pre><soap:Envelope>
+<h3><a name="secure-message" id="secure-message"></a>2.3 Secure Message</h3><p>In addition to requiring the use of addressing, Contoso requires the use of
+ transport-level security for protecting messages.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-3. </span>Secure Message</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
<wss:Security soap:mustUnderstand="1" >
<wsu:Timestamp wsu:Id="_0">
@@ -181,7 +225,8 @@
prefixes <code>wss</code> and <code>wsu</code> are used here to denote the Web Services
Security and Utility namespaces.)</p><p>Similar to the use of addressing, Contoso indicates the use of transport-level security
using a policy expression. The example below illustrates a policy expression that requires
- the use of addressing and transport-level security for securing messages.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-4. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+ the use of addressing and transport-level security for securing messages.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-4. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<wsap:UsingAddressing />
<sp:TransportBinding>...</sp:TransportBinding>
</Policy></pre></div></div><p>The <code>sp:TransportBinding</code> element is a policy assertion. (The prefix
@@ -192,7 +237,7 @@
SOAP Envelopes.</p><p>The client application developer can use a policy-aware client that recognizes this policy expression and engages
both addressing and transport-level security automatically.</p><p>For the moment, let us set aside the contents of the <code>sp:TransportBinding</code>
policy assertion and consider its details in a later section.</p></div><div class="div2">
-<h3><a name="other-assertions"></a>2.4 Other Assertions</h3><p>Thus far, we explored how Contoso uses policy expressions and assertions for representing
+<h3><a name="other-assertions" id="other-assertions"></a>2.4 Other Assertions</h3><p>Thus far, we explored how Contoso uses policy expressions and assertions for representing
behaviors that must be engaged for a Web service interaction. What is a policy assertion?
What role does it play? In brief, a policy assertion is a piece of service metadata, and
it identifies a domain (such as messaging, security, reliability and transaction) specific
@@ -216,21 +261,23 @@
</p></li><li><p>
Devices Profile for Web Services [<cite><a href="#WS-Device">Devices Profile for Web Services</a></cite>]
</p></li><li><p>…</p></li></ul></div><div class="div2">
-<h3><a name="combining-policy-assertions"></a>2.5 Combining Policy Assertions</h3><p>Policy assertions can be combined in different ways to express consistent combinations of
+<h3><a name="combining-policy-assertions" id="combining-policy-assertions"></a>2.5 Combining Policy Assertions</h3><p>Policy assertions can be combined in different ways to express consistent combinations of
behaviors (capabilities and requirements). There are three policy operators for combining
policy assertions: <code>Policy</code>, <code>All</code> and <code>ExactlyOne</code>
(the <code>Policy</code> operator is a synonym for <code>All).</code></p><p>Let us consider the <code>All</code> operator first. The policy expression in the example
below requires the use of addressing and transport-level security. There are two policy
assertions. These assertions are combined using the <code>All</code> operator. Combining
policy assertions using the <code>Policy</code> or <code>All</code> operator means that
- all the behaviors represented by these assertions are required.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-5. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre><All>
+ all the behaviors represented by these assertions are required.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-5. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre><All>
<wsap:UsingAddressing />
<sp:TransportBinding>…</sp:TransportBinding>
</All></pre></div></div><p>In addition to requiring the use of addressing, Contoso allows either the use of
transport- or message-level security for protecting messages. Web Services Policy language
can indicate this choice of behaviors in a machine-readable form. To indicate the use of
message-level security for protecting messages, Contoso uses the
- <code>sp:AsymmetricBinding</code> policy assertion (see the example below).</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-6. </span>Asymmetric Binding Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:AsymmetricBinding>…</sp:AsymmetricBinding></pre></div></div><p>The <code>sp:AsymmetricBinding</code> element is a policy assertion. (The prefix
+ <code>sp:AsymmetricBinding</code> policy assertion (see the example below).</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-6. </span>Asymmetric Binding Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:AsymmetricBinding>…</sp:AsymmetricBinding></pre></div></div><p>The <code>sp:AsymmetricBinding</code> element is a policy assertion. (The prefix
<code>sp</code> is used here to denote the Web Services Security Policy namespace.) This
assertion identifies the use of message-level security – such as <em>WS-Security
1.0</em> - for protecting messages. Policy-aware clients can recognize this policy
@@ -239,7 +286,8 @@
<code>ExactlyOne</code> policy operator. Policy assertions combined using the
<code>ExactlyOne</code> operator requires exactly one of the behaviors represented by
the assertions. The policy expression in the example below requires the use of either
- transport- or message-level security for protecting messages.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-7. </span>Transport- or Message-Level Security Policy Expression</i></p><div class="exampleInner"><pre><ExactlyOne>
+ transport- or message-level security for protecting messages.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-7. </span>Transport- or Message-Level Security Policy Expression</i></p><div class="exampleInner"><pre><ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</ExactlyOne></pre></div></div><p>Contoso requires the use of addressing and requires the use of either transport- or
@@ -247,7 +295,8 @@
the <code>All</code> and <code>ExactlyOne</code> operators. Policy operators can be mixed
to represent different combinations of behaviors (capabilities and requirements). The
policy expression in the example below requires the use of addressing and one of
- transport- or message-level security for protecting messages.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-8. </span>Addressing and Transport- OR Message-Level Security Policy Expression</i></p><div class="exampleInner"><pre><All>
+ transport- or message-level security for protecting messages.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-8. </span>Addressing and Transport- OR Message-Level Security Policy Expression</i></p><div class="exampleInner"><pre><All>
<wsap:UsingAddressing />
<ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
@@ -255,12 +304,13 @@
</ExactlyOne>
</All></pre></div></div><p>Using this policy expression, Contoso gives the choice of mechanisms for protecting
messages to clients (or requesters).</p></div><div class="div2">
-<h3><a name="optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3><p>Through a customer survey program, Contoso learns that a significant number of their
+<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3><p>Through a customer survey program, Contoso learns that a significant number of their
customers prefer to use the Optimized MIME Serialization (as defined in the MTOM
specification) for sending and receiving messages. Contoso adds optional support for the
Optimized MIME Serialization and expresses this optional behavior in a machine-readable
form.</p><p>To indicate the use of optimization using the Optimized MIME Serialization, Contoso uses
- the <code>mtom:OptimizedMimeSerialization</code> policy assertion (see the example below).</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-9. </span>Optimized MIME Serialization Policy Assertion</i></p><div class="exampleInner"><pre><mtom:OptimizedMimeSerialization /></pre></div></div><p>The <code>mtom:OptimizedMimeSerialization</code> element is a policy assertion. (The
+ the <code>mtom:OptimizedMimeSerialization</code> policy assertion (see the example below).</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-9. </span>Optimized MIME Serialization Policy Assertion</i></p><div class="exampleInner"><pre><mtom:OptimizedMimeSerialization /></pre></div></div><p>The <code>mtom:OptimizedMimeSerialization</code> element is a policy assertion. (The
prefix <code>mtom</code> is used here to denote the Optimized MIME Serialization Policy
namespace.) This assertion identifies the use of MIME Multipart/Related serialization
as required for request and response
@@ -280,7 +330,8 @@
a content-type header of "application/xop+xml" for the outer package. In this case, the response message
will also be optimized, also having a Multipart/Related message and content-type header of "application/xop+xml".
Note that when optimized messages are used, the Multipart/Related message can have a single part containing the
- primary SOAP envelope.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-10. </span>Optional MIME Serialization, Addressing and Transport- OR Message-Level Security
+ primary SOAP envelope.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-10. </span>Optional MIME Serialization, Addressing and Transport- OR Message-Level Security
Policy Expression</i></p><div class="exampleInner"><pre><All>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
@@ -291,33 +342,34 @@
</All></pre></div></div><p>Contoso is able to meet their customer needs by adding optional support for the Optimized
MIME Serialization. An optional policy assertion represents a behavior that may be
engaged.</p></div><div class="div2">
-<h3><a name="ignorable-policy-assertions"></a>2.7 Ignorable Policy Expressions</h3><p>
+<h3><a name="ignorable-policy-assertions" id="ignorable-policy-assertions"></a>2.7 Ignorable Policy Expressions</h3><p>
Suppose Contoso decides that it will log SOAP messages sent and received in an exchange.
This behavior has no direct impact on the messages sent on the wire, and does not affect interoperability.
Some parties might have a concern about such logging and might decide not to interact with Contoso knowing
that such logging is performed. To address this concern, Contoso includes a Logging assertion in its policy to enable
- such parties to be aware of logging. By marking the Logging assertion with the <code class="attr">wsp:Ignorable</code> attribute with a
+ such parties to be aware of logging. By marking the Logging assertion with the <code>wsp:Ignorable</code> attribute with a
value of "true" Contoso indicates that a requester may choose to either ignore such assertions or to consider
them as part of policy intersection. An assertion that may be ignored for policy intersection is called an
ignorable assertion.
</p><p>
- The <code class="attr">wsp:Ignorable</code> attribute allows providers to clearly indicate which policy assertions indicate behaviors that
+ The <code>wsp:Ignorable</code> attribute allows providers to clearly indicate which policy assertions indicate behaviors that
don’t manifest on the wire and may not be of concern to a requester when determining policy compatibility.
- Using the <code class="attr">wsp:Optional</code> attribute would be incorrect in this scenario, since it would indicate that the behavior
+ Using the <code>wsp:Optional</code> attribute would be incorrect in this scenario, since it would indicate that the behavior
would not occur if the alternative without the assertion were selected.
- </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-11. </span>Ignorable Logging Policy Assertion</i></p><div class="exampleInner"><pre><log:Logging wsp:Ignorable="true" /></pre></div></div><p>
+ </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-11. </span>Ignorable Logging Policy Assertion</i></p><div class="exampleInner"><pre><log:Logging wsp:Ignorable="true" /></pre></div></div><p>
(The log: prefix is used here to denote a hypothetical example namespace for this example logging policy assertion.)
</p><p>
- The attribute <code class="attr">wsp:Ignorable</code> is of type <em>xs:boolean</em>.
+ The attribute <code>wsp:Ignorable</code> is of type <em>xs:boolean</em>.
Omitting this attribute is semantically equivalent to including it with a value of "false".
</p><p>
- The use of the <code class="attr">wsp:Ignorable</code> attribute has no impact on normalization.
- Assertions marked with the <code class="attr">wsp:Ignorable</code> attribute remain marked with the <code class="attr">wsp:Ignorable</code> attribute
+ The use of the <code>wsp:Ignorable</code> attribute has no impact on normalization.
+ Assertions marked with the <code>wsp:Ignorable</code> attribute remain marked with the <code>wsp:Ignorable</code> attribute
after normalization.
Ignorable assertions may have an impact on determining compatibility of policies
(See <a href="#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy Intersection</b></a> ).
</p></div><div class="div2">
-<h3><a name="nested-policy-expressions"></a>2.8 Nested Policy Expressions</h3><p>In the previous sections, we considered two security policy assertions. In this section,
+<h3><a name="nested-policy-expressions" id="nested-policy-expressions"></a>2.8 Nested Policy Expressions</h3><p>In the previous sections, we considered two security policy assertions. In this section,
let us look at one of the security policy assertions in little more detail.</p><p>As you would expect, securing messages is a complex usage scenario. Contoso uses the
<code>sp:TransportBinding</code> policy assertion to indicate the use of transport-level
security for protecting messages. Just indicating the use of transport-level security for
@@ -340,7 +392,8 @@
the <code>sp:TransportBinding</code> policy assertion. The <code>sp:TransportToken</code>
assertion requires the use of a specific transport token and further qualifies the
behavior of the <code>sp:TransportBinding</code> policy assertion (which 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 2-12. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
+ the use of transport-level security for protecting messages).</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-12. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
<Policy>
<sp:TransportToken>
<Policy>
@@ -364,7 +417,7 @@
transport-level security and its dependent behaviors automatically. That is, the
complexity of security usage is absorbed by a policy-aware client and hidden from these
Web service developers.</p></div><div class="div2">
-<h3><a name="Referencing_Policy_Expressions"></a>2.9 Referencing Policy Expressions</h3><p>Contoso has numerous Web service offerings that provide different kinds of real-time
+<h3><a name="Referencing_Policy_Expressions" id="Referencing_Policy_Expressions"></a>2.9 Referencing Policy Expressions</h3><p>Contoso has numerous Web service offerings that provide different kinds of real-time
quotes and book information on securities such as
<code>GetRealQuote</code>, <code>GetRealQuotes</code> and
<code>GetExtendedRealQuote</code>. To accommodate the diversity of Contoso’s customers,
@@ -376,7 +429,8 @@
policy or within another policy expression. There are three mechanisms to identify a policy
expression: the <code>wsu:Id</code> <code>xml:id</code> and <code>Name</code> attributes. A
<code>PolicyReference</code> element can be used to reference a policy expression
- identified using either of these mechanisms.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-13. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”common”>
+ identified using either of these mechanisms.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-13. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
</Policy></pre></div></div><p>In the example above, the <code>wsu:Id</code> attribute is used to identify a policy
@@ -387,7 +441,8 @@
<code>http://real.contoso.com/policy.xml#common. (</code>The absolute IRI is formed by
combining the document IRI, <code>#</code> and the value of the <code>wsu:Id</code>
attribute.)</p><p> In addition to the Example 2-12, Contoso could have used either the xml:id or wsu:Id.
- An example of the use of xml:id similar to that of wsu:Id is shown in Example 2-13. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-14. </span>Common Policy Expression [xml:id]</i></p><div class="exampleInner"><pre><Policy xml:id=”common”>
+ An example of the use of xml:id similar to that of wsu:Id is shown in Example 2-13. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-14. </span>Common Policy Expression [xml:id]</i></p><div class="exampleInner"><pre><Policy xml:id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
</Policy></pre></div></div><p> Conditions and constraints on the use of the |xml:id| attribute in conjunction with Canonical
@@ -395,12 +450,14 @@
Significant care is suggested in the use of xml:id.
</p><p>For re-use, a <code>PolicyReference</code> element can be used to reference a policy
expression as a standalone policy or within another policy expression. The example below
- is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-15. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="#common"/></pre></div></div><p>For referencing a policy expression within the same XML document, Contoso uses the
+ is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-15. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="#common"/></pre></div></div><p>For referencing a policy expression within the same XML document, Contoso uses the
<code>wsu:Id</code> attribute for identifying a policy expression and an IRI to this ID
value for referencing this policy expression using a <code>PolicyReference</code> element.</p><p>The example below is a policy expression that re-uses the common policy expression within
another policy expression. This policy expression requires the use of addressing, one of
transport- or message-level security for protecting messages and allows the use of
- optimization.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-16. </span>Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
+ optimization.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-16. </span>Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
<All>
<PolicyReference URI="#common"/>
<ExactlyOne>
@@ -414,11 +471,13 @@
resides in. As such, referencing a policy expression using the <code>Name</code> attribute
relies on additional out of band information. In the example below, the <code>Name</code>
attribute identifies the policy expression. The IRI of this policy expression is
- <code>http://real.contoso.com/policy/common</code>.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-17. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy Name=”http://real.contoso.com/policy/common”>
+ <code>http://real.contoso.com/policy/common</code>.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-17. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy Name=”http://real.contoso.com/policy/common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
-</Policy></pre></div></div><p>The example below is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-18. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="http://real.contoso.com/policy/common"/></pre></div></div></div><div class="div2">
-<h3><a name="attaching-policy-expressions-to-wsdl"></a>2.10 Attaching Policy Expressions to WSDL</h3><p>A majority of Contoso’s customers use WSDL for building their client applications.
+</Policy></pre></div></div><p>The example below is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-18. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="http://real.contoso.com/policy/common"/></pre></div></div></div><div class="div2">
+<h3><a name="attaching-policy-expressions-to-wsdl" id="attaching-policy-expressions-to-wsdl"></a>2.10 Attaching Policy Expressions to WSDL</h3><p>A majority of Contoso’s customers use WSDL for building their client applications.
Contoso leverages this usage by attaching policy expressions to the WSDL binding
descriptions.</p><p>In the example below, the <code>SecureBinding</code> WSDL binding description defines a
binding for an interface that provides real-time quotes and book information on
@@ -430,7 +489,8 @@
expression attached to the <code>SecureBinding</code> WSDL binding description applies to
any message exchange associated with any <code>port</code> that supports this binding
description. This includes all the message exchanges described by operations in the
- <code>RealTimeDataInterface</code>.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-19. </span>Secure Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
+ <code>RealTimeDataInterface</code>.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-19. </span>Secure Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
…
@@ -440,7 +500,8 @@
<code>GetDelayedQuotes,</code>
<code>GetSymbol</code> and <code>GetSymbols</code>). Contoso does not require the use of
security for these services, but requires the use of addressing and allows the use of
- optimization.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 2-20. </span>Open Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" >
+ optimization.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-20. </span>Open Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" >
<PolicyReference URI="#common" />
<wsdl:operation name="GetDelayedQuote">…</wsdl:operation>
…
@@ -466,7 +527,7 @@
documents and engages behaviors automatically for each of these endpoints. Any complexity
of varying behaviors across Web service endpoints is absorbed by a policy-aware client or
tool and hidden from these Web service developers.</p></div><div class="div2">
-<h3><a name="policy-automates-web-services-interaction"></a>2.11 Policy Automates Web Services Interaction</h3><p>As you have seen, Web Services Policy is a simple language that has four elements -
+<h3><a name="policy-automates-web-services-interaction" id="policy-automates-web-services-interaction"></a>2.11 Policy Automates Web Services Interaction</h3><p>As you have seen, Web Services Policy is a simple language that has four elements -
<code>Policy, All</code>, <code>ExactlyOne</code> and <code>PolicyReference</code> - and
one attribute - <code>wsp:Optional</code>. In practice, service providers, like Contoso,
use policy expressions to represent combinations of capabilities and requirements. Web
@@ -475,12 +536,12 @@
complexity is absorbed by policy-aware clients (or tools) and is invisible to these Web
service developers.</p><p>Web Services Policy extends the foundation on which to build interoperable Web services,
hides complexity from developers and automates Web service interactions.</p></div></div><div class="div1">
-<h2><a name="advanced-concepts-policy-expression"></a>3. Advanced Concepts: Policy Expression</h2><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we covered the basics of Web Services
+<h2><a name="advanced-concepts-policy-expression" id="advanced-concepts-policy-expression"></a>3. Advanced Concepts: Policy Expression</h2><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we covered the basics of Web Services
Policy language. This is the advanced section that provides more in-depth materials
for Web Services Policy implementers and assertion authors. This section covers the
following topics:</p><ul><li><p>What is a policy expression?</p></li><li><p>What is the normal form of a policy expression and how to normalize policy
expressions?</p></li><li><p>What is the policy data model?</p></li><li><p>How to select a compatible policy alternative?</p></li><li><p>How to attach policy expressions to WSDL constructs?</p></li><li><p>How to combine policies?</p></li><li><p>What are the extensibility points?</p></li><li><p>What are the parts of a policy assertion?</p></li></ul><div class="div2">
-<h3><a name="policy-expression"></a>3.1 Policy Expression</h3><p>A policy expression is the XML representation and interoperable form of a Web Services
+<h3><a name="policy-expression" id="policy-expression"></a>3.1 Policy Expression</h3><p>A policy expression is the XML representation and interoperable form of a Web Services
Policy. A policy expression consists of a <code>Policy</code> wrapper element and a
variety of child and descendant elements. Child and descendent elements from the policy
language are <code>Policy, All</code>, <code>ExactlyOne</code>
@@ -490,7 +551,8 @@
nested policy expression. Policy assertions can also be marked optional to represent
behaviors that may be engaged (capabilities) for an interaction. The optional marker is
the <code>wsp:Optional</code> attribute which is placed on a policy assertion element.</p><p>Let us take a closer look at Contoso’s policy expression (see below) from the previous
- section.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span>Contoso’s Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+ section.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span>Contoso’s Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<All>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
@@ -503,12 +565,13 @@
and <code>ExactlyOne</code> elements are the policy operators. All other child elements
of the <code>All</code> and <code>ExactlyOne</code> elements are policy assertions from
domains such as messaging, addressing, security, reliability and transactions.</p></div><div class="div2">
-<h3><a name="normal-form-for-policy-expressions"></a>3.2 Normal Form for Policy Expressions</h3><p>Web Services Policy language defines two forms of policy expressions: compact and normal
+<h3><a name="normal-form-for-policy-expressions" id="normal-form-for-policy-expressions"></a>3.2 Normal Form for Policy Expressions</h3><p>Web Services Policy language defines two forms of policy expressions: compact and normal
form. Up to this point, we have used the compact form. The compact form is less verbose
than the normal form. The compact form is useful for authoring policy expressions. The
normal form is an intuitive representation of the policy data model. We will look into the
policy data model in the next section.</p><p>The normal form uses a subset of constructs used in the compact form and follows a simple
- outline for its XML representation:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-2. </span>Normal Form for Policy Expressions</i></p><div class="exampleInner"><pre><Policy>
+ outline for its XML representation:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-2. </span>Normal Form for Policy Expressions</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<x:AssertionA>…</x:AssertionA>
@@ -530,7 +593,8 @@
expression in the normal form has at most one policy alternative.</p><p>The normal form represents a policy as a collection of policy alternatives and a policy
alternative as a collection of policy assertions in a straight-forward manner.</p><p>The example below is a policy expression in the normal form. This expression contains two
policy alternatives: one that requires the use of transport-level security and the other
- that requires the use of message-level security for protecting messages.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-3. </span>Transport- or Message-Level Security Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
+ that requires the use of message-level security for protecting messages.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-3. </span>Transport- or Message-Level Security Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<sp:TransportBinding>…</sp:TransportBinding>
@@ -543,7 +607,8 @@
Policy language describes the algorithm for this conversion.</p><p>Let us re-consider Contoso’s policy expression (see the example below). Contoso requires
the use of addressing and either transport- or message-level security and allows the use
of optimization. This policy expression is in the compact form and has four policy
- alternatives for requesters:</p><ol><li><p>Requires the use of addressing and transport-level security</p></li><li><p>Requires the use of addressing and message-level security</p></li><li><p>Requires the use of optimization, addressing and transport-level security and</p></li><li><p>Requires the use of optimization, addressing and message-level security.</p></li></ol><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-4. </span>Contoso’s Secure Policy Expression in Compact Form</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
+ alternatives for requesters:</p><ol class="enumar"><li><p>Requires the use of addressing and transport-level security</p></li><li><p>Requires the use of addressing and message-level security</p></li><li><p>Requires the use of optimization, addressing and transport-level security and</p></li><li><p>Requires the use of optimization, addressing and message-level security.</p></li></ol><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-4. </span>Contoso’s Secure Policy Expression in Compact Form</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
<All>
<PolicyReference URI=”#common”/>
<ExactlyOne>
@@ -561,7 +626,8 @@
than the normal form. The normal form represents a policy as a collection of policy
alternatives. Each of the <code>All</code> operators is a policy alternative. There are
four policy alternatives in the normal form. These alternatives map to bullets (a) through
- (d) above.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span>Contoso’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
+ (d) above.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span>Contoso’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (a) -->
<wsap:UsingAddressing/>
@@ -591,7 +657,7 @@
most one policy alternative.</p><p>The <code>PolicyReference</code> element is replaced with its referenced policy
expression. See section <a href="#policy-retrieval"><b>3.6 Policy Retrieval</b></a> for more details on how to
retrieve referenced policy expressions.</p></div><div class="div2">
-<h3><a name="policy-data-model"></a>3.3 Policy Data Model</h3><p>In the previous section, we considered the normal form for policy expressions. As we
+<h3><a name="policy-data-model" id="policy-data-model"></a>3.3 Policy Data Model</h3><p>In the previous section, we considered the normal form for policy expressions. As we
discussed, the normal form represents a policy as a collection of policy alternatives. In
this section, let us look at the policy data model.</p><p>Contoso uses a policy to convey the conditions for an interaction. Policy-aware clients,
like the one used by the developer in our example (as explained earlier in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>), view policy as an unordered collection of
@@ -633,13 +699,14 @@
alternatives.</p></li><li><p>The <code>Policy</code> wrapper element and policy alternatives which correspond to
the <code>Policy/ExactlyOne</code> element map to a policy.</p></li></ul><p>The diagram below describes this mapping from the normal form of a policy expression to
the policy data model.</p><div class="figure" style="text-align: center"><br><img src="normal-form-2-data-model.jpg" alt="Mapping from Normal Form to Policy Data Model"><p style="text-align:left"><i><span>Figure 3-2. </span>Mapping from Normal Form to Policy Data Model</i></p><br></div></div><div class="div2">
-<h3><a name="compatible-policies"></a>3.4 Compatible Policies</h3><p>A provider, like Contoso, and a requester, like the policy-aware client used in our example, may represent
+<h3><a name="compatible-policies" id="compatible-policies"></a>3.4 Compatible Policies</h3><p>A provider, like Contoso, and a requester, like the policy-aware client used in our example, may represent
their capabilities and requirements for an interaction as policies and want to limit their
message exchanges to mutually compatible policies. Web Services Policy defines an
intersection mechanism for selecting compatible policy alternatives when there are two or
more policies.</p><p>The example below is a copy of Contoso’s policy expression (from <a href="#normal-form-for-policy-expressions"><b>3.2 Normal Form for Policy Expressions</b></a>). As we saw before, Contoso offers four
policy alternatives. Of them, one of the policy alternatives requires the use of
- addressing and transport-level security.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-6. </span>Contoso’s Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+ addressing and transport-level security.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-6. </span>Contoso’s Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - Contoso’s Policy Alternative (a) -->
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) -->
@@ -653,7 +720,8 @@
interaction with Contoso’s Web services. The developer represents these behaviors using a policy
expression illustrated in the example below in normal form. This policy expression
contains one policy alternative that requires the use of addressing and transport-level
- security.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-7. </span>The Client Application's Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
+ security.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-7. </span>The Client Application's Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - - - - - Client’s Policy Alternative -->
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (t1) -->
@@ -684,7 +752,7 @@
satisfy Contoso’s conditions or requirements.</p><p>Similarly, policy intersection can be used to check if providers expose endpoints that
conform to a standard policy. For example, a major retailer might require all their
supplier endpoints to be compatible with an agreed upon policy.</p><div class="div3">
-<h4><a name="strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy Intersection</h4><p>
+<h4><a name="strict-lax-policy-intersection" id="strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy Intersection</h4><p>
The previous sections outlined how the normal-form of a policy expression relate to the policy data model and how the
compatibility of requester and provider policies may be determined.
This section outlines how ignorable assertions may impact the process of determining compatibility.
@@ -696,17 +764,17 @@
assertion in the other, and vice versa. For this to be possible they must share the same policy alternative vocabulary.
The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
When using the strict intersection mode ignorable assertions are part of the policy alternative vocabulary, so the
- <code class="attr">wsp:Ignorable</code> attribute does not impact the intersection result even when the <code class="attr">wsp:Ignorable</code>
+ <code>wsp:Ignorable</code> attribute does not impact the intersection result even when the <code>wsp:Ignorable</code>
attribute value is “true”.
</p><p>
If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax
intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the
- <code class="attr">wsp:Ignorable</code> attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode
+ <code>wsp:Ignorable</code> attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode
two policy alternatives are compatible when each non-ignorable assertion in one is compatible with an assertion in the
other, and vice versa. For this to be possible the two policy alternatives must share a policy alternative vocabulary for
all “non-ignorable” assertions.
</p></div></div><div class="div2">
-<h3><a name="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Contoso attached
+<h3><a name="attaching-policy-expressions-to-wsdl2" id="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Contoso attached
their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
<code>binding</code> element, a policy expression can be attached to other WSDL elements
such as <code>service</code>, <code>port</code>, <code>operation</code>
@@ -728,7 +796,8 @@
<code>binding/operation/fault</code>, <code>portType/operation/fault</code>, and
<code>message</code> element collectively represent the message policy subject for the
fault message. Policy expressions associated with a message policy subject apply only to
- that message.</p><p>In the example below, the policy expression is attached to an endpoint policy subject.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span>Contoso’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
+ that message.</p><p>In the example below, the policy expression is attached to an endpoint policy subject.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span>Contoso’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
…
@@ -742,7 +811,7 @@
port. Let us consider how to combine policy expressions in the next section.</p><p>Most of the policy assertions are designated for the endpoint, operation or message
policy subject. The commonly used WSDL attachment points are:</p><a name="Table2"></a><table border="1" cellspacing="0" cellpadding="5"><tbody><tr><th rowspan="1" colspan="1">Policy Subject</th><td rowspan="1" colspan="1">Commonly used attachment point (s)</td></tr><tr><th rowspan="1" colspan="1">Endpoint</th><td rowspan="1" colspan="1"><code>binding</code> element</td></tr><tr><th rowspan="1" colspan="1">Operation</th><td rowspan="1" colspan="1"><code>binding/operation</code> element</td></tr><tr><th rowspan="1" colspan="1">Message</th><td rowspan="1" colspan="1"><code>binding/operation/input</code> and <code>binding/operation/output</code>
elements</td></tr></tbody></table><br></div><div class="div2">
-<h3><a name="policy-retrieval"></a>3.6 Policy Retrieval</h3><p>
+<h3><a name="policy-retrieval" id="policy-retrieval"></a>3.6 Policy Retrieval</h3><p>
Just as other service metadata languages, Web Services Policy does not mandate
any specific policy retrieval mechanism. Any combination of any retrieval mechanisms in
any order may be used for referencing policy expressions. Example retrieval mechanisms
@@ -763,11 +832,12 @@
rules for policy references between separate XML documents apply as described
in <a href="#Referencing_Policy_Expressions"><b>2.9 Referencing Policy Expressions</b></a>.
</p></div><div class="div2">
-<h3><a name="combine-policies"></a>3.7 Combine Policies</h3><p>Multiple policy expressions may be attached to WSDL constructs. Let us consider how
+<h3><a name="combine-policies" id="combine-policies"></a>3.7 Combine Policies</h3><p>Multiple policy expressions may be attached to WSDL constructs. Let us consider how
Contoso could have used multiple policy expressions in a WSDL document. In the example
below, there are two policy expressions <code>#common2</code> and <code>#secure2</code>
attached to the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code>
- WSDL port descriptions.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-9. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p><div class="exampleInner"><pre><Policy wsu:Id=”common2”>
+ WSDL port descriptions.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-9. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p><div class="exampleInner"><pre><Policy wsu:Id=”common2”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
</Policy>
@@ -804,7 +874,8 @@
<code>#secure2</code> policy expression has two policy alternatives. The
combination of these two policies is equivalent to Contoso’s secure policy in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a> and has four policy alternatives. In other
words, the combination of two policies is the cross product of alternatives in these two
- policies.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-10. </span>Effective Policy of the Endpoint Policy Subject in the Previous Example</i></p><div class="exampleInner"><pre><Policy>
+ policies.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-10. </span>Effective Policy of the Endpoint Policy Subject in the Previous Example</i></p><div class="exampleInner"><pre><Policy>
<All>
<Policy>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
@@ -822,7 +893,7 @@
unordered collection of policy alternatives. That is, the order of policy alternatives is
insignificant. Therefore, the order of combining these policy expressions is
insignificant.</p></div><div class="div2">
-<h3><a name="extensibility-and-versioning"></a>3.8 Extensibility and Versioning</h3><p>Web Services Policy language is an extensible language by design. The
+<h3><a name="extensibility-and-versioning" id="extensibility-and-versioning"></a>3.8 Extensibility and Versioning</h3><p>Web Services Policy language is an extensible language by design. The
<code>Policy</code>, <code>ExactlyOne</code>, <code>All</code>
and <code>wsp:PolicyReference</code> elements are extensible. The <code>Policy</code>
element allows child element and attribute extensibility, while the
@@ -837,7 +908,8 @@
allows service providers, like Contoso, to deploy new behaviors using additional policy
assertions without breaking compatibility with clients that rely on any older policy
alternatives.</p><p>The example below represents a Contoso version 1 policy expression. This expression
- requires the use of addressing and transport-level security for protecting messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Contoso’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+ requires the use of addressing and transport-level security for protecting messages. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Contoso’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsap:UsingAddressing/>
@@ -852,7 +924,8 @@
message-level security. The clients that rely on addressing and transport-level security
may continue to interact with Contoso’s using the old policy alternative. Of course, these
clients have the option to migrate from using old policy alternatives to new policy
- alternatives.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Contoso’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+ alternatives.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Contoso’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsap:UsingAddressing/>
@@ -883,7 +956,7 @@
known WSDL constructs and allows Web service developers to fill in code for custom or
unknown constructs in the WSDL.
</p><div class="div3">
-<h4><a name="ignorable-and-versioning"></a>3.8.1 Ignorable and Versioning</h4><p>
+<h4><a name="ignorable-and-versioning" id="ignorable-and-versioning"></a>3.8.1 Ignorable and Versioning</h4><p>
One potential use of the wsp:Ignorable attribute is to mark versioning related
information. One scenario is that a service will support a particular version
of a service until a certain point in time. After that time, the service will
@@ -896,7 +969,8 @@
certain point in time using a Contoso specific expiry assertion. The example
below shows Contoso version 2 policy expression with a hypothetical ignorable EndOfLife
Assertion.
- </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+ </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
Assertion</i></p><div class="exampleInner"><pre>
<Policy>
<ExactlyOne>
@@ -940,7 +1014,7 @@
other way or it will not be conveyed at all. This can usefully smooth the
transition between versions.
</p></div></div><div class="div2">
-<h3><a name="parts-of-a-policy-assertion"></a>3.9 Parts of a Policy Assertion</h3><p>As we discussed, a policy assertion identifies a domain specific behavior or requirement
+<h3><a name="parts-of-a-policy-assertion" id="parts-of-a-policy-assertion"></a>3.9 Parts of a Policy Assertion</h3><p>As we discussed, a policy assertion identifies a domain specific behavior or requirement
or condition. A policy assertion has a QName that identifies its behavior or requirement
or condition. A policy assertion may contain assertion parameters and a nested policy.</p><p>Let us look at the anatomy of a policy assertion from the security domain. The policy
expression in the diagram below uses the <code>sp:IssuedToken</code> policy assertion.
@@ -978,16 +1052,17 @@
by a third party. Service providers, like Contoso, must convey this usage and all the
necessary information to obtain this security token for Web service developers. This is a
key piece of metadata for a successful interaction with Contoso’s Web services.</p></div><div class="div2">
-<h3><a name="versioning-policy-language"></a>3.10 Versioning Policy Language</h3><p>
+<h3><a name="versioning-policy-language" id="versioning-policy-language"></a>3.10 Versioning Policy Language</h3><p>
<table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">
The WG is contemplating moving some or all of this material into a non-normative appendix of the framework or attachment document. User feedback is solicited
</td></tr></table>
</p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new or modified constructs. These constructs may be compatible or incompatible with previous versions. Some of the possible new constructs that have been mentioned previously are: new operators, operator cardinality, policy identification, compact syntax, Policy Inclusion, security, referencing, attachment points, alternative
priority, effective dating, negotiation. </p><p>WS-Policy provides extensibility points on 6 elements with a combination of attribute and/or element extensibility.
- The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:</p><ol><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and a proposal to add any element ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li></ol><div class="div3">
-<h4><a name="versioning-policy-framework"></a>3.10.1 Policy Framework</h4><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
+ The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and a proposal to add any element ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li></ol><div class="div3">
+<h4><a name="versioning-policy-framework" id="versioning-policy-framework"></a>3.10.1 Policy Framework</h4><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false".
- After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-14. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre><wsp:Policy>
+ After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-14. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
...
@@ -996,7 +1071,8 @@
...
</wsp:All>
</wsp:ExactlyOne>
-</wsp:Policy></pre></div></div><p>The normalization rule for wsp:Optional="false" would be applied to the wsp16:Choice, yielding the following expression:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre><wsp:Policy>
+</wsp:Policy></pre></div></div><p>The normalization rule for wsp:Optional="false" would be applied to the wsp16:Choice, yielding the following expression:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:ExactlyOne>
<wsp:All>
@@ -1010,12 +1086,14 @@
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Alternatively, the wsp:Optional could be set to "true" on the choice, as
- in:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-16. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre><wsp:Policy>
+ in:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-16. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"
wsp:Optional="true">
...
</wsp16:Choice>
-</wsp:Policy></pre></div></div><p>The normalized form will be:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-17. </span>Normalized policy</i></p><div class="exampleInner"><pre><wsp:Policy>
+</wsp:Policy></pre></div></div><p>The normalized form will be:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-17. </span>Normalized policy</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
@@ -1026,7 +1104,8 @@
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Because the wsp16:Choice alternative isn't understood in either normalized form, it will not be chosen as one of the alternatives and will effectively be ignored. Policy intersection may be more difficult with such compatible extensions. For example, the previous will "look"
like it has a wsp16:Choice typed assertion. To determine intersection with a Policy that does not have the wsp16:Choice type assertion, domain specific processing would have to be done. However, there is an alternative that does not have the wsp16:Choice, so intersection would yield the expected result.
- </p><p>Note: it is possible to add new names to the existing namespace, such as: </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-18. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre><wsp:Policy>
+ </p><p>Note: it is possible to add new names to the existing namespace, such as: </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-18. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -1036,7 +1115,8 @@
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Notice that using a new namespace can result in backwards and forwards compatibility if normalization results in an optional alternative. </p><p>Best practice: insert new elements in an optional alternative or mark with wsp:Optional="true". </p><p>Incompatible versions of the Policy language may be indicated by a new namespace name for at least the new and/or incompatible elements or attributes. Imagine that the Choice operator is required by a future version of Policy, then there will be a new namespace for the Policy element. We use the wsp20 prefix to indicate a hypothetical Policy Language 2.0 that is intended to be incompatible with Policy Language
- 1.5:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-19. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre><wsp20:Policy>
+ 1.5:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-19. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre><wsp20:Policy>
<wsp20:ExactlyOne>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -1044,12 +1124,14 @@
...
</wsp20:ExactlyOne>
</wsp20:Policy> </pre></div></div><p>The new Policy operator could be embedded inside an existing Policy
- element:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-20. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre><wsp:Policy>
+ element:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-20. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
</wsp20:Choice>
...
-</wsp20:Policy> </pre></div></div><p>This will be treated as an Assertion for normalization and intersection computation. This will result in only one alternative that requires the wsp20:Choice, the intended behaviour for incompatible changes.</p><p>Best practice: use a new namespace for new incompatible construct and insert inside either: new Policy element OR existing All for future incompatible policy extensions.</p><p>A future version of WS-Policy could support the current operators in the existing namespace, such as:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-21. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre><wsp20:Policy>
+</wsp20:Policy> </pre></div></div><p>This will be treated as an Assertion for normalization and intersection computation. This will result in only one alternative that requires the wsp20:Choice, the intended behaviour for incompatible changes.</p><p>Best practice: use a new namespace for new incompatible construct and insert inside either: new Policy element OR existing All for future incompatible policy extensions.</p><p>A future version of WS-Policy could support the current operators in the existing namespace, such as:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-21. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre><wsp20:Policy>
<wsp:ExactlyOne>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -1057,8 +1139,9 @@
...
</wsp:ExactlyOne>
</wsp20:Policy> </pre></div></div><p>It is difficult to predict whether this functionality would be useful. The future version of WS-Policy doesn't appear to be precluded from doing this.</p></div><div class="div3">
-<h4><a name="versioning-policy-attachment"></a>3.10.2 Policy Attachment</h4><p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
- WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p><p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-22. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
+<h4><a name="versioning-policy-attachment" id="versioning-policy-attachment"></a>3.10.2 Policy Attachment</h4><p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
+ WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p><p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-22. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:Policy>
@@ -1079,7 +1162,8 @@
</wsp:Policy>
<wsdl11:operation name="GetLastTradePrice" > ....
...</pre></div></div><p>The PolicyReference element is element or attribute extensible.
- One example of an addition is a list of backup URIs for the PolicyReference:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 3-23. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
+ One example of an addition is a list of backup URIs for the PolicyReference:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-23. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:Policy>
@@ -1094,15 +1178,15 @@
</wsp:Policy>
<wsdl11:operation name="GetLastTradePrice" > ....
...</pre></div></div><p>The policy framework specification says that any unknown attributes are ignored. A Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p><p>PolicyAttachment and AppliesTo also have extensibility points. We choose not to illustrate these at this time.</p></div></div></div><div class="div1">
-<h2><a name="conclusion"></a>4. Conclusion</h2><p>Service providers use Web Services Policy to represent combinations of behaviors
+<h2><a name="conclusion" id="conclusion"></a>4. Conclusion</h2><p>Service providers use Web Services Policy to represent combinations of behaviors
(capabilities and requirements). Web service developers use policy-aware clients that
understand policy expressions and engage the behaviors represented by providers
automatically. These behaviors may include security, reliability, transaction, message
optimization, etc. Web Services Policy is a simple language, hides complexity from
developers, automates Web service interactions, and enables secure, reliable and transacted
Web Services.</p></div></div><div class="back"><div class="div1">
-<h2><a name="security-considerations"></a>A. Security Considerations</h2><p>Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
-<h2><a name="xml-namespaces"></a>B. XML Namespaces</h2><p>The table below lists XML Namespaces that are used in this document. The choice of any
+<h2><a name="security-considerations" id="security-considerations"></a>A. Security Considerations</h2><p>Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
+<h2><a name="xml-namespaces" id="xml-namespaces"></a>B. XML Namespaces</h2><p>The table below lists XML Namespaces that are used in this document. The choice of any
namespace prefix is arbitrary and not semantically significant.</p><a name="nsprefix"></a><table summary="Prefixes and XML Namespaces used in this specification" border="1" cellspacing="0" cellpadding="5"><caption>Table B-1. Prefixes and XML Namespaces used in this specification.</caption><thead><tr><th rowspan="1" colspan="1">Prefix</th><th rowspan="1" colspan="1">XML Namespace</th><th rowspan="1" colspan="1">Specifications</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">
<code>mtom</code>
</td><td rowspan="1" colspan="1">
@@ -1144,7 +1228,7 @@
</td><td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</code>
</td><td rowspan="1" colspan="1">[<cite><a href="#WS-Security2004">WS-Security 2004</a></cite>]</td></tr></tbody></table><br></div><div class="div1">
-<h2><a name="references"></a>C. References</h2><dl><dt class="label"><a name="MTOM"></a>[MTOM] </dt><dd>
+<h2><a name="references" id="references"></a>C. References</h2><dl><dt class="label"><a name="MTOM"></a>[MTOM] </dt><dd>
<cite><a href="http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message Transmission Optimization Mechanism</a></cite>, M. Gudgin, N.
Mendelsohn, M. Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25 January
2005. This version of the SOAP Message Transmission Optimization Mechanism Recommendation
@@ -1242,21 +1326,21 @@
J. Kahan and K. Lanz, Editors. World Wide Web
Consortium, 17 August 2006.
Available at http://www.w3.org/2006/04/c14n-note/c14n-note.html.> </dd></dl></div><div class="div1">
-<h2><a name="acknowledgments"></a>D. Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/2002/ws/policy/">W3C Web Services Policy
+<h2><a name="acknowledgments" id="acknowledgments"></a>D. Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/2002/ws/policy/">W3C Web Services Policy
Working Group</a>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip now (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation), Bob Natale (MITRE Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporaton), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
</p><p>
Previous members of the Working Group were:
- Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
+ Jong Lee (BEA Systems, Inc.), Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
</p><p>
The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-ws-policy/">discussions
on public-ws-policy@w3.org</a> are also gratefully
acknowledged.
</p></div><div class="div1">
-<h2><a name="change-description"></a>E. Changes in this Version of the Document (Non-Normative)</h2><p>A list of substantive changes since the Working Draft dated 21 December, 2006 is below:</p><ul><li><p>TBD.</p></li></ul></div><div class="div1">
-<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Primer Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060816</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Created first draft per action item <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action02">2</a> from the
+<h2><a name="change-description" id="change-description"></a>E. Changes in this Version of the Document (Non-Normative)</h2><p>A list of substantive changes since the Working Draft dated 21 December, 2006 is below:</p><ul><li><p>TBD.</p></li></ul></div><div class="div1">
+<h2><a name="change-log" id="change-log"></a>F. Web Services Policy 1.5 - Primer Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060816</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Created first draft per action item <a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action02">2</a> from the
Austin F2F. This draft is based on a <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0001.html">contribution</a> from Microsoft.</td></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the
<a href="http://www.w3.org/2006/08/23-ws-policy-minutes.html#action06">resolution</a>
for issue
Index: ws-policy-framework.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework.html,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -d -r1.97 -r1.98
--- ws-policy-framework.html 7 Feb 2007 22:34:13 -0000 1.97
+++ ws-policy-framework.html 9 Feb 2007 17:35:24 -0000 1.98
@@ -8,6 +8,12 @@
div.note,
div.notice { margin-left: 2em; }
+ol.enumar { list-style-type: decimal; }
+ol.enumla { list-style-type: lower-alpha; }
+ol.enumlr { list-style-type: lower-roman; }
+ol.enumua { list-style-type: upper-alpha; }
+ol.enumur { list-style-type: upper-roman; }
+
dt.label { display: run-in; }
li, p { margin-top: 0.3em;
@@ -48,23 +54,64 @@
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
-</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"><link rel="contents" href="#contents"></head><body><div class="head">
-<h1>Web Services Policy 1.5 - Framework</h1>
-<h2>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
+</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"></head><body><div class="head">
+<h1><a name="title" id="title"></a>Web Services Policy 1.5 - Framework</h1>
+<h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
<a href="ws-policy-framework.html">ws-policy-framework.html</a>
- </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8</a></dd><dt>Previous versions:</dt><dd>
+ </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8</a></dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2006/WD-ws-policy-20060927">http://www.w3.org/TR/2006/WD-ws-policy-20060927</a>
</dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark/a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
-<h2><a name="abstract">Abstract</a></h2><p>The Web Services Policy 1.5 - Framework provides a general purpose model and corresponding
+<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>The Web Services Policy 1.5 - Framework provides a general purpose model and corresponding
syntax to describe the policies of entities in a Web services-based system.</p><p>Web Services Policy Framework defines a base set of
constructs that can be used and extended by other Web
services specifications to describe a broad range of service
requirements and capabilities.</p></div><div>
-<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
- no official standing.</strong></p><p></p></div><hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#tocRange">Introduction</a><br> 1.1 <a href="#Example">Example</a><br>2. <a href="#Notation_Terminlogy">Notations and Terminology</a><br> 2.1 <a href="#Notational_Conventions">Notational Conventions</a><br> 2.2 <a href="#Extensibility">Extensibility</a><br> 2.3 <a href="#XML_Namespaces">XML Namespaces</a><br> 2.4 <a href="#Terminology">Terminology</a><br>3. <a href="#Policy_Model">Policy Model</a><br> 3.1 <a href="#rPolicy_Assertion">Policy Assertion</a><br> 3.2 <a href="#rPolicy_Alternative">Policy Alternative</a><br> 3.3 <a href="#rPolicy">Policy</a><br> 3.4 <a href="#Web_services">Policies of Entities in a Web Services Based System</a><br>4. <a href="#rPolicy_Expression">Policy Expression</a><br> 4.1 <ahref="#Normal_Form_Policy_Expression">Normal Form Policy Expression</a><br> 4.2 <a href="#Policy_Identification">Policy Identification</a><br> 4.3 <a href="#Compact_Policy_Expression">Compact Policy Expression</a><br> 4.3.1 <a href="#Optional_Policy_Assertions">Optional Policy Assertions</a><br> 4.3.2 <a href="#Policy_Assertion_Nesting">Policy Assertion Nesting</a><br> 4.3.3 <a href="#Policy_Operators">Policy Operators</a><br> 4.3.4 <a href="#Policy_References">Policy References</a><br> 4.3.5 <a href="#Policy_Inclusion">Policy Inclusion</a><br> 4.3.6 <a href="#normalization">Normalization</a><br> 4.4 <a href="#ignorable-policy-assertions">Ignorable Policy Assertins</a><br> 4.5 <a href="#Policy_Intersection">Policy Intersection</a><br> 4.6 <a href="#IRI_Policy_Expressions">Use of IRIs in Policy Expressions</a><br>5. <a href="#Security_Considerations">Security Considerations</a><br> 5.1 <a href="#information-disclosure-threats">Information Disclosure Threats</a><br> 5.2 <a href="#spoofing-and-tampering-threats">Spoofing and Tampering Threats</a><br> 5.3 <a href="#downgrade-threats">Downgrade Threats</a><br> 5.4 <a href="#repudiation-threats">Repudiation Threats</a><br> 5.5 <a href="#denial-of-service-threats">Denial of Service Threats</a><br> 5.6 <a href="#general-xml-considerations">General XML Considerations</a><br>6. <a href="#Conformance">Conformance</a><br></p>
-<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#media-type">The application/wspolicy+xml Media Type</a><br> A.1 <a href="#ietf-reg">Registration</a><br>B. <a href="#References">References</a><br> B.1 <a href="#Normative-References">Normative References</a><br> B.2 <a href="#Informative-References">Other References</a><br>C. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>D. <a href="#change-description">Changes in this Version of the Document</a> (Non-Normative)<br>E. <a href="#change-log">Web Services Policy 1.5 - Framework Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
-<h2><a name="tocRange"></a>1. Introduction</h2><p>Web Services Policy 1.5 - Framework defines a framework and a model for expressing policies that
+<h2><a name="status" id="status"></a>Status of this Document</h2><p><strong>This document is an editors' copy that has
+ no official standing.</strong></p><p></p></div><div class="toc">
+<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#tocRange">Introduction</a><br>
+ 1.1 <a href="#Example">Example</a><br>
+2. <a href="#Notation_Terminlogy">Notations and Terminology</a><br>
+ 2.1 <a href="#Notational_Conventions">Notational Conventions</a><br>
+ 2.2 <a href="#Extensibility">Extensibility</a><br>
+ 2.3 <a href="#XML_Namespaces">XML Namespaces</a><br>
+ 2.4 <a href="#Terminology">Terminology</a><br>
+3. <a href="#Policy_Model">Policy Model</a><br>
+ 3.1 <a href="#rPolicy_Assertion">Policy Assertion</a><br>
+ 3.2 <a href="#rPolicy_Alternative">Policy Alternative</a><br>
+ 3.3 <a href="#rPolicy">Policy</a><br>
+ 3.4 <a href="#Web_services">Policies of Entities in a Web Services Based System</a><br>
+4. <a href="#rPolicy_Expression">Policy Expression</a><br>
+ 4.1 <a href="#Normal_Form_Policy_Expression">Normal Form Policy Expression</a><br>
+ 4.2 <a href="#Policy_Identification">Policy Identification</a><br>
+ 4.3 <a href="#Compact_Policy_Expression">Compact Policy Expression</a><br>
+ 4.3.1 <a href="#Optional_Policy_Assertions">Optional Policy Assertions</a><br>
+ 4.3.2 <a href="#Policy_Assertion_Nesting">Policy Assertion Nesting</a><br>
+ 4.3.3 <a href="#Policy_Operators">Policy Operators</a><br>
+ 4.3.4 <a href="#Policy_References">Policy References</a><br>
+ 4.3.5 <a href="#Policy_Inclusion">Policy Inclusion</a><br>
+ 4.3.6 <a href="#normalization">Normalization</a><br>
+ 4.4 <a href="#ignorable-policy-assertions">Ignorable Policy Assertions</a><br>
+ 4.5 <a href="#Policy_Intersection">Policy Intersection</a><br>
+ 4.6 <a href="#IRI_Policy_Expressions">Use of IRIs in Policy Expressions</a><br>
+5. <a href="#Security_Considerations">Security Considerations</a><br>
+ 5.1 <a href="#information-disclosure-threats">Information Disclosure Threats</a><br>
+ 5.2 <a href="#spoofing-and-tampering-threats">Spoofing and Tampering Threats</a><br>
+ 5.3 <a href="#downgrade-threats">Downgrade Threats</a><br>
+ 5.4 <a href="#repudiation-threats">Repudiation Threats</a><br>
+ 5.5 <a href="#denial-of-service-threats">Denial of Service Threats</a><br>
+ 5.6 <a href="#general-xml-considerations">General XML Considerations</a><br>
+6. <a href="#Conformance">Conformance</a><br>
+</p>
+<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A. <a href="#media-type">The application/wspolicy+xml Media Type</a><br>
+ A.1 <a href="#ietf-reg">Registration</a><br>
+B. <a href="#References">References</a><br>
+ B.1 <a href="#Normative-References">Normative References</a><br>
+ B.2 <a href="#Informative-References">Other References</a><br>
+C. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>
+D. <a href="#change-description">Changes in this Version of the Document</a> (Non-Normative)<br>
+E. <a href="#change-log">Web Services Policy 1.5 - Framework Change Log</a> (Non-Normative)<br>
+</p></div><hr><div class="body"><div class="div1">
+<h2><a name="tocRange" id="tocRange"></a>1. Introduction</h2><p>Web Services Policy 1.5 - Framework defines a framework and a model for expressing policies that
refer to domain-specific capabilities, requirements, and general characteristics of
entities in a Web services-based system.
</p><p>A <a title="policy" href="#policy">policy</a> is a collection of policy alternatives. A
@@ -95,8 +142,9 @@
defined in Web Services Policy 1.5 - Attachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>], or additional
mechanisms not covered by Web Services Policy 1.5 - Attachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>],
for purposes of associating policy with policy scopes and subjects.</p><div class="div2">
-<h3><a name="Example"></a>1.1 Example</h3><p><a href="#ex-wsp-use-security-assertations">Example 1-1</a> illustrates a security <a title="policy expression" href="#policy_expression">policy expression</a> using
- assertions defined in WS-SecurityPolicy [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]:</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><a name="ex-wsp-use-security-assertations"></a><i><span>Example 1-1. </span>Use of Web Services Policy with security policy assertions.</i></p><div class="exampleInner"><pre>
+<h3><a name="Example" id="Example"></a>1.1 Example</h3><p><a href="#ex-wsp-use-security-assertations">Example 1-1</a> illustrates a security <a title="policy expression" href="#policy_expression">policy expression</a> using
+ assertions defined in WS-SecurityPolicy [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]:</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><a name="ex-wsp-use-security-assertations" id="ex-wsp-use-security-assertations"></a><i><span>Example 1-1. </span>Use of Web Services Policy with security policy assertions.</i></p><div class="exampleInner"><pre>
(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
@@ -114,12 +162,12 @@
(12) </wsp:All>
(13) </wsp:ExactlyOne>
(14) </wsp:Policy></pre></div></div><p>Lines (03-06) represent one
- policy alternative for signing a message body.</p><p>Lines (08-11) represent a second policy alternative for encrypting a message body. </p><p>Lines (02-13) illustrate the <code class="elt">ExactlyOne</code> policy
+ policy alternative for signing a message body.</p><p>Lines (08-11) represent a second policy alternative for encrypting a message body. </p><p>Lines (02-13) illustrate the <code>ExactlyOne</code> policy
operator. Policy operators group policy assertions into
policy alternatives. A valid interpretation of the policy
above would be that an invocation of a Web service will either sign or encrypt the message body.</p></div></div><div class="div1">
-<h2><a name="Notation_Terminlogy"></a>2. Notations and Terminology</h2><p>This section specifies the notations, namespaces, and terminology used in this specification.</p><div class="div2">
-<h3><a name="Notational_Conventions"></a>2.1 Notational Conventions</h3><p>This specification uses the following syntax within normative outlines: </p><ul><li><p>The syntax appears as an XML instance, but values
+<h2><a name="Notation_Terminlogy" id="Notation_Terminlogy"></a>2. Notations and Terminology</h2><p>This section specifies the notations, namespaces, and terminology used in this specification.</p><div class="div2">
+<h3><a name="Notational_Conventions" id="Notational_Conventions"></a>2.1 Notational Conventions</h3><p>This specification uses the following syntax within normative outlines: </p><ul><li><p>The syntax appears as an XML instance, but values
in <em>italics</em> indicate data types instead of
literal values.</p></li><li><p>Characters are appended to elements and attributes
to indicate cardinality:</p><ul><li><p>"?" (0 or 1)</p></li><li><p>"*" (0 or more)</p></li><li><p>"+" (1 or more)</p></li></ul></li><li><p>The character "|" is used to indicate an exclusive choice
@@ -141,7 +189,7 @@
over the XML Schema [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>]
descriptions.
</p></div><div class="div2">
-<h3><a name="Extensibility"></a>2.2 Extensibility</h3><p>Within normative outlines, in this specification, ellipses (i.e., "…")
+<h3><a name="Extensibility" id="Extensibility"></a>2.2 Extensibility</h3><p>Within normative outlines, in this specification, ellipses (i.e., "…")
indicate a point of extensibility that allows other Element or Attribute
Information Items. Information Items <span class="rfc2119">MAY</span> be added at the
indicated extension points but <span class="rfc2119">MUST NOT</span> contradict the semantics
@@ -152,7 +200,7 @@
<span class="rfc2119">MUST</span> be treated as a policy assertion,
unless specified otherwise
such as in Section <a href="#Policy_References"><b>4.3.4 Policy References</b></a>.</p></div><div class="div2">
-<h3><a name="XML_Namespaces"></a>2.3 XML Namespaces</h3><p> This specification uses a number of namespace prefixes throughout; they are
+<h3><a name="XML_Namespaces" id="XML_Namespaces"></a>2.3 XML Namespaces</h3><p> This specification uses a number of namespace prefixes throughout; they are
listed in <a href="#nsprefix">Table 2-1</a>. Note that the choice of any namespace
prefix is arbitrary and not semantically significant (see [<cite><a href="#XML-NS">XML Namespaces</a></cite>]).</p><a name="nsprefix"></a><table summary="Namespace prefixes usage in this specification" border="1" cellspacing="0" cellpadding="5"><caption>Table 2-1. Prefixes and Namespaces used in this specification</caption><thead><tr><th rowspan="1" colspan="1">Prefix</th><th rowspan="1" colspan="1">Namespace</th><th rowspan="1" colspan="1">Specification</th></tr></thead><tbody><tr><td rowspan="1" colspan="1"><code>sp</code></td><td rowspan="1" colspan="1"><code>http://schemas.xmlsoap.org/ws/2005/07/securitypolicy</code></td><td rowspan="1" colspan="1">[<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]</td></tr><tr><td rowspan="1" colspan="1"><code>wsp</code></td><td rowspan="1" colspan="1"><code>http://www.w3.org/ns/ws-policy</code></td><td rowspan="1" colspan="1">This specification</td></tr><tr><td rowspan="1" colspan="1"><code>wsu</code></td><td rowspan="1" colspan="1"<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</code></td><td rowspan="1" colspan="1">[<cite><a href="#WS-Security">WS-Security 2004</a></cite>]</td></tr><tr><td rowspan="1" colspan="1"><code>xs</code></td><td rowspan="1" colspan="1"><code>http://www.w3.org/2001/XMLSchema</code></td><td rowspan="1" colspan="1">[<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>]</td></tr></tbody></table><br><p>All information items defined by this specification
are identified by the XML namespace URI [<cite><a href="#XML-NS">XML Namespaces</a></cite>] <code>http://www.w3.org/ns/ws-policy</code>. A <a href="http://www.w3.org/ns/ws-policy">normative XML Schema</a> [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>, <cite><a href="#XMLSchemaPart2">XML Schema Datatypes</a></cite>] document can be obtained by
@@ -175,7 +223,7 @@
for which the value-space of possible instance documents conformant to
the previous revision of the schema would still be valid
with regards to the revised cardinality rule.</p></li></ul></div><div class="div2">
-<h3><a name="Terminology"></a>2.4 Terminology</h3><p>
+<h3><a name="Terminology" id="Terminology"></a>2.4 Terminology</h3><p>
The keywords "<span class="rfc2119">MUST</span>", "<span class="rfc2119">MUST
NOT</span>", "<span class="rfc2119">REQUIRED</span>",
"<span class="rfc2119">SHALL</span>", "<span class="rfc2119">SHALL
@@ -232,25 +280,25 @@
<a href="#policy_vocabulary">policy vocabulary</a>
</dt><dd><p>A <b>policy vocabulary</b> is the set of all
<a title="policy assertion type" href="#policy_assertion_type">policy assertion types</a> used in a policy.</p></dd></dl></div></div><div class="div1">
-<h2><a name="Policy_Model"></a>3. Policy Model</h2><p>This section defines an abstract model for policies and for operations upon policies.</p><p>The descriptions below use XML Infoset terminology for convenience of description. However, this abstract model itself is independent of how it is represented as an XML Infoset. </p><div class="div2">
-<h3><a name="rPolicy_Assertion"></a>3.1 Policy Assertion</h3><p>[<a name="policy_assertion" title="policy assertion">Definition</a>: A <b>policy assertion</b>
+<h2><a name="Policy_Model" id="Policy_Model"></a>3. Policy Model</h2><p>This section defines an abstract model for policies and for operations upon policies.</p><p>The descriptions below use XML Infoset terminology for convenience of description. However, this abstract model itself is independent of how it is represented as an XML Infoset. </p><div class="div2">
+<h3><a name="rPolicy_Assertion" id="rPolicy_Assertion"></a>3.1 Policy Assertion</h3><p>[<a name="policy_assertion" id="policy_assertion" title="policy assertion">Definition</a>: A <b>policy assertion</b>
represents a requirement, a capability, or other property of a behavior.]
A <a title="policy assertion" href="#policy_assertion">policy assertion</a> identifies a behavior that is a
requirement or capability of a <a title="policy subject" href="#policy_subject">policy subject</a>.
- [<a name="policy_subject" title="policy subject">Definition</a>: A <b>policy subject</b> is an entity
+ [<a name="policy_subject" id="policy_subject" title="policy subject">Definition</a>: A <b>policy subject</b> is an entity
(e.g., an endpoint, message, resource, operation) with which a
<a title="policy" href="#policy">policy</a> can be associated. ]
Assertions indicate domain-specific (e.g.,
security, transactions) semantics and are expected to be
defined in separate, domain-specific specifications.</p><p>An assertion MAY indicate that it is an ignorable policy assertion
(see <a href="#ignorable-policy-assertions"><b>4.4 Ignorable Policy Assertions</b></a>).
- [<a name="ignorable_policy_assertion" title="ignorable policy assertion">Definition</a>: An
+ [<a name="ignorable_policy_assertion" id="ignorable_policy_assertion" title="ignorable policy assertion">Definition</a>: An
<b>ignorable policy assertion</b> is
an assertion that may be ignored for policy intersection (as defined in
<a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#Policy_Intersection">4.5 Policy Intersection</a>).] By default, an assertion is not
ignorable for policy intersection.
</p><p>Assertions are typed by the authors
- that define them. [<a name="policy_assertion_type" title="policy assertion type">Definition</a>: A <b>policy assertion type</b>
+ that define them. [<a name="policy_assertion_type" id="policy_assertion_type" title="policy assertion type">Definition</a>: A <b>policy assertion type</b>
represents a class of <a title="policy assertion" href="#policy_assertion">policy assertions</a> and implies a
schema for the assertion and assertion-specific semantics.] The <a title="policy assertion type" href="#policy_assertion_type">policy assertion
type</a> is identified only by the XML Infoset <strong>[namespace name]</strong> and <strong>[local name]</strong> properties (that
@@ -269,7 +317,7 @@
XML namespace name are <a title="policy assertion parameter" href="#policy_assertion_parameter">policy assertion parameters</a>
and <span class="rfc2119">MAY</span> be used to
parameterize the behavior indicated by the assertion.
- [<a name="policy_assertion_parameter" title="policy assertion parameter">Definition</a>: A <b>policy assertion parameter</b>
+ [<a name="policy_assertion_parameter" id="policy_assertion_parameter" title="policy assertion parameter">Definition</a>: A <b>policy assertion parameter</b>
qualifies the behavior indicated by a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.]
For example, an
assertion identifying support for a specific reliable
@@ -282,14 +330,14 @@
to consider when the identity of the root Element
Information Item alone is enough to convey the requirement
or capability.</p></div><div class="div2">
-<h3><a name="rPolicy_Alternative"></a>3.2 Policy Alternative</h3><p>[<a name="policy_alternative" title="policy alternative">Definition</a>: A <b>policy alternative</b>
+<h3><a name="rPolicy_Alternative" id="rPolicy_Alternative"></a>3.2 Policy Alternative</h3><p>[<a name="policy_alternative" id="policy_alternative" title="policy alternative">Definition</a>: A <b>policy alternative</b>
is a potentially empty collection of <a title="policy assertion" href="#policy_assertion">policy assertions</a>.] An
alternative with zero assertions indicates no
behaviors. An alternative with one or more assertions
indicates behaviors implied by those, and only those
- assertions. [<a name="policy_vocabulary" title="policy vocabulary">Definition</a>: A <b>policy vocabulary</b> is the set of all
+ assertions. [<a name="policy_vocabulary" id="policy_vocabulary" title="policy vocabulary">Definition</a>: A <b>policy vocabulary</b> is the set of all
<a title="policy assertion type" href="#policy_assertion_type">policy assertion types</a> used in a policy.]
- [<a name="policy_alternative_vocabulary" title="policy alternative vocabulary">Definition</a>: A <b>policy alternative vocabulary</b> is the set of
+ [<a name="policy_alternative_vocabulary" id="policy_alternative_vocabulary" title="policy alternative vocabulary">Definition</a>: A <b>policy alternative vocabulary</b> is the set of
all <a title="policy assertion type" href="#policy_assertion_type">policy assertion
types</a> within the <a title="policy alternative" href="#policy_alternative">policy
alternative</a>.]
@@ -307,7 +355,7 @@
specific to the assertion type and are outside the scope
of this document.</p><p>Note: Depending on the semantics of the domain specific policy assertions a combination of the
policy assertions can be required to specify a particular behavior. </p></div><div class="div2">
-<h3><a name="rPolicy"></a>3.3 Policy</h3><p>[<a name="policy" title="policy">Definition</a>: A <b>policy</b> is a potentially empty collection of
+<h3><a name="rPolicy" id="rPolicy"></a>3.3 Policy</h3><p>[<a name="policy" id="policy" title="policy">Definition</a>: A <b>policy</b> is a potentially empty collection of
<a title="policy alternative" href="#policy_alternative">policy alternatives</a>. ] A policy with zero alternatives
contains no choices; a policy with one or more
alternatives indicates choice in requirements or
@@ -320,7 +368,7 @@
generally a function of the semantics of assertions within
the alternative and is therefore beyond the scope of this
specification.</p></div><div class="div2">
-<h3><a name="Web_services"></a>3.4 Policies of Entities in a Web Services Based System</h3><p>Applied to a Web services based system, <a title="policy" href="#policy">policy</a> is used to convey conditions
+<h3><a name="Web_services" id="Web_services"></a>3.4 Policies of Entities in a Web Services Based System</h3><p>Applied to a Web services based system, <a title="policy" href="#policy">policy</a> is used to convey conditions
on an interaction between entities (requester application,
provider service, Web infrastructure component, etc).
An interaction involves one or more message exchanges between two
@@ -360,8 +408,8 @@
assertions in new alternatives while allowing entities
to continue to use old alternatives in a
backward-compatible manner.</p></div></div><div class="div1">
-<h2><a name="rPolicy_Expression"></a>4. Policy Expression</h2><p>This section describes how to convey <a title="policy" href="#policy">policy</a> in an interoperable form,
- using the XML Infoset representation of a policy. [<a name="policy_expression" title="policy expression">Definition</a>: A <b>policy expression</b>
+<h2><a name="rPolicy_Expression" id="rPolicy_Expression"></a>4. Policy Expression</h2><p>This section describes how to convey <a title="policy" href="#policy">policy</a> in an interoperable form,
+ using the XML Infoset representation of a policy. [<a name="policy_expression" id="policy_expression" title="policy expression">Definition</a>: A <b>policy expression</b>
is an XML Infoset representation of a <a title="policy" href="#policy">policy</a>,
either in a normal form or in an equivalent compact form.]
</p><p>The normal form (see Section <a href="#Normal_Form_Policy_Expression"><b>4.1 Normal Form Policy Expression</b></a>) of a policy expression is the most
@@ -375,7 +423,7 @@
Schema.</p><p>While the policy language XML Schema is a representation of the compact
form, the normal form is more restrictive as outlined in Section
<a href="#Normal_Form_Policy_Expression"><b>4.1 Normal Form Policy Expression</b></a>.</p><div class="div2">
-<h3><a name="Normal_Form_Policy_Expression"></a>4.1 Normal Form Policy Expression</h3><p>To facilitate interoperability, this specification
+<h3><a name="Normal_Form_Policy_Expression" id="Normal_Form_Policy_Expression"></a>4.1 Normal Form Policy Expression</h3><p>To facilitate interoperability, this specification
defines a normal form for <a title="policy expression" href="#policy_expression">policy expressions</a> that
is a straightforward XML Infoset representation of a
policy, enumerating each of its <a title="policy alternative" href="#policy_alternative">alternatives</a> that in turn
@@ -384,15 +432,15 @@
(02) <wsp:ExactlyOne>
(03) ( <wsp:All> ( <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> )* </wsp:All> )*
(04) </wsp:ExactlyOne>
-(05) </wsp:Policy> </pre></div><p>The following describes the Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code class="elt">/wsp:Policy</code> </dt><dd><p>A policy expression.</p></dd><dt class="label"><code class="elt">/wsp:Policy/wsp:ExactlyOne</code> </dt><dd><p>
+(05) </wsp:Policy> </pre></div><p>The following describes the Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code>/wsp:Policy</code></dt><dd><p>A policy expression.</p></dd><dt class="label"><code>/wsp:Policy/wsp:ExactlyOne</code></dt><dd><p>
A collection of policy alternatives. If there are no Element
Information Items in the <strong>[children]</strong> property, there are no
admissible policy alternatives, i.e., no behavior is
- admissible.</p></dd><dt class="label"><code class="elt">/wsp:Policy/wsp:ExactlyOne/wsp:All</code> </dt><dd><p>
+ admissible.</p></dd><dt class="label"><code>/wsp:Policy/wsp:ExactlyOne/wsp:All</code></dt><dd><p>
A policy alternative; a collection of policy assertions. If there
are no Element Information Items in the <strong>[children]</strong> property, this is an
admissible policy alternative that is empty, i.e., no behavior is
- specified.</p></dd><dt class="label"><code>/wsp:Policy/wsp:ExactlyOne/wsp:All/*</code></dt><dd><p>XML Infoset representation of a policy assertion.</p></dd><dt class="label"><code class="attr">/wsp:Policy/@{any}</code> </dt><dd><p>Additional attributes <span class="rfc2119">MAY</span> be specified but
+ specified.</p></dd><dt class="label"><code>/wsp:Policy/wsp:ExactlyOne/wsp:All/*</code></dt><dd><p>XML Infoset representation of a policy assertion.</p></dd><dt class="label"><code>/wsp:Policy/@{any}</code></dt><dd><p>Additional attributes <span class="rfc2119">MAY</span> be specified but
<span class="rfc2119">MUST NOT</span> contradict the semantics of the
<strong>[owner element]</strong>; if an attribute is not recognized, it
<span class="rfc2119">SHOULD</span> be ignored.</p></dd></dl><p>If an <a title="policy assertion" href="#policy_assertion">assertion</a> in the
@@ -417,21 +465,21 @@
(14) </wsp:Policy></pre></div><p>Lines (03-07) and Lines (08-11) express the two alternatives in the
policy. If the first alternative is selected, the message body needs to be signed [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>] is supported;
conversely, if the second alternative is selected, the message body needs to be encrypted. </p></div><div class="div2">
-<h3><a name="Policy_Identification"></a>4.2 Policy Identification</h3><p>A <a title="policy expression" href="#policy_expression">policy expression</a>
+<h3><a name="Policy_Identification" id="Policy_Identification"></a>4.2 Policy Identification</h3><p>A <a title="policy expression" href="#policy_expression">policy expression</a>
<span class="rfc2119">MAY</span> be associated with an IRI [<cite><a href="#RFC3987">IETF RFC 3987</a></cite>]. The schema outline
for attributes to associate an IRI is as follows:</p><div class="exampleInner"><pre>(01) <wsp:Policy ( Name="<emph>xs:anyURI</emph>" )?
(02) ( wsu:Id="<emph>xs:ID</emph>" | xml:id="<emph>xs:ID</emph>" )?
(03) … >
(04) …
-(05) </wsp:Policy></pre></div><p>The following describes the Attribute Information Items listed and defined in the schema outline above:</p><dl><dt class="label"><code class="attr">/wsp:Policy/@Name</code> </dt><dd><p>The identity of the policy expression as an absolute IRI [<cite><a href="#RFC3987">IETF RFC 3987</a></cite>]. If
+(05) </wsp:Policy></pre></div><p>The following describes the Attribute Information Items listed and defined in the schema outline above:</p><dl><dt class="label"><code>/wsp:Policy/@Name</code></dt><dd><p>The identity of the policy expression as an absolute IRI [<cite><a href="#RFC3987">IETF RFC 3987</a></cite>]. If
omitted, there is no implied value. This IRI <span class="rfc2119">MAY</span> be
used to refer to a policy from other XML documents using a <a title="policy attachment" href="#policy_attachment">policy attachment</a> mechanism such as
-those defined in WS-PolicyAttachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>]. [<a name="policy_attachment" title="policy attachment">Definition</a>: A
+those defined in WS-PolicyAttachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>]. [<a name="policy_attachment" id="policy_attachment" title="policy attachment">Definition</a>: A
<b>policy attachment</b> is a mechanism for associating
<a title="policy" href="#policy">policy</a> with one or more <a title="policy scope" href="#policy_scope">policy scopes</a>.]
- [<a name="policy_scope" title="policy scope">Definition</a>: A <b>policy scope</b> is a collection of
+ [<a name="policy_scope" id="policy_scope" title="policy scope">Definition</a>: A <b>policy scope</b> is a collection of
<a title="policy subject" href="#policy_subject">policy subjects</a> to which a policy may apply.]
- </p></dd><dt class="label"><code class="attr">/wsp:Policy/(@wsu:Id | @xml:id)</code> </dt><dd><p>The identity of the policy expression as an <code>ID</code> within the
+ </p></dd><dt class="label"><code>/wsp:Policy/(@wsu:Id | @xml:id)</code></dt><dd><p>The identity of the policy expression as an <code>ID</code> within the
enclosing XML document. If omitted, there is no implied value.
The constraints of the XML 1.0 [<cite><a href="#XML10">XML 1.0</a></cite>] ID type MUST be met.
To refer to this policy expression, an IRI-reference
@@ -453,7 +501,7 @@
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" >
(02) <!-- Details omitted for readability -->
(03) </wsp:Policy></pre></div></div><div class="div2">
-<h3><a name="Compact_Policy_Expression"></a>4.3 Compact Policy Expression</h3><p>To express a <a title="policy" href="#policy">policy</a> in a more compact form while still using the
+<h3><a name="Compact_Policy_Expression" id="Compact_Policy_Expression"></a>4.3 Compact Policy Expression</h3><p>To express a <a title="policy" href="#policy">policy</a> in a more compact form while still using the
XML Infoset, this specification defines three constructs: an attribute
to decorate an <a title="policy assertion" href="#policy_assertion">assertion</a>,
semantics for recursively nested policy operators, and a policy
@@ -462,14 +510,14 @@
To interpret a compact expression in an interoperable form, a
policy expression in the compact form can be converted
(see Section <a href="#normalization"><b>4.3.6 Normalization</b></a>) to the normal form (see Section <a href="#Normal_Form_Policy_Expression"><b>4.1 Normal Form Policy Expression</b></a>).</p><p>A <a title="policy expression" href="#policy_expression">policy expression</a>
- consists of a <code class="elt">wsp:Policy</code> wrapper element and
+ consists of a <code>wsp:Policy</code> wrapper element and
zero or more child and descendent elements.</p><div class="div3">
-<h4><a name="Optional_Policy_Assertions"></a>4.3.1 Optional Policy Assertions</h4><p>To indicate that a <a title="policy assertion" href="#policy_assertion">policy
+<h4><a name="Optional_Policy_Assertions" id="Optional_Policy_Assertions"></a>4.3.1 Optional Policy Assertions</h4><p>To indicate that a <a title="policy assertion" href="#policy_assertion">policy
assertion</a> is optional, this specification defines an attribute
that is a compact authoring style for expressing a pair of <a title="policy alternative" href="#policy_alternative">alternatives</a>,
one with and one without that assertion. The schema outline for
this attribute is as follows:</p><div class="exampleInner"><pre>(01) <<emph>Assertion</emph> ( wsp:Optional="<emph>xs:boolean</emph>" )? …> … </<emph>Assertion</emph>></pre></div><p>The following describes the Attribute Information Item defined in
-the schema outline above:</p><dl><dt class="label"><code class="attr">/Assertion/@wsp:Optional</code> </dt><dd><p>If the actual value (See XML Schema Part 1 [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>]) is true, the expression of the assertion is semantically equivalent to the following:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
+the schema outline above:</p><dl><dt class="label"><code>/Assertion/@wsp:Optional</code></dt><dd><p>If the actual value (See XML Schema Part 1 [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>]) is true, the expression of the assertion is semantically equivalent to the following:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
(02) <wsp:All> <<emph>Assertion</emph> …> … </<emph>Assertion</emph>> </wsp:All>
(03) <wsp:All />
(04) </wsp:ExactlyOne></pre></div><p>If the actual value (See XML Schema Part 1 [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>]) is false, the expression of the assertion is semantically equivalent to the following:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
@@ -490,20 +538,20 @@
(05) </wsp:All>
(06) <wsp:All />
(07) </wsp:ExactlyOne>
-(08) </wsp:Policy></pre></div><p>The <code class="attr">@wsp:Optional</code> attribute in Line (02) of the first
+(08) </wsp:Policy></pre></div><p>The <code>@wsp:Optional</code> attribute in Line (02) of the first
policy expression indicates that the assertion in Line (02) is to be
included in a policy alternative whilst excluded from another; it is
included in Lines (03-05) and excluded in Line (06). Note that
-<code class="attr">@wsp:Optional</code> does not appear in the normal form of a
+<code>@wsp:Optional</code> does not appear in the normal form of a
policy expression.</p></div><div class="div3">
-<h4><a name="Policy_Assertion_Nesting"></a>4.3.2 Policy Assertion Nesting</h4><p>Any <a title="policy assertion" href="#policy_assertion">policy assertion</a>
-<span class="rfc2119">MAY</span> contain a <a title="policy expression" href="#policy_expression">policy expression</a>. [<a name="nested_policy_expression" title="nested policy expression">Definition</a>: A <b>nested policy expression</b> is a <a title="policy expression" href="#policy_expression">policy expression</a> that is an Element Information Item in the <strong>[children]</strong> property of a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.] The schema
+<h4><a name="Policy_Assertion_Nesting" id="Policy_Assertion_Nesting"></a>4.3.2 Policy Assertion Nesting</h4><p>Any <a title="policy assertion" href="#policy_assertion">policy assertion</a>
+<span class="rfc2119">MAY</span> contain a <a title="policy expression" href="#policy_expression">policy expression</a>. [<a name="nested_policy_expression" id="nested_policy_expression" title="nested policy expression">Definition</a>: A <b>nested policy expression</b> is a <a title="policy expression" href="#policy_expression">policy expression</a> that is an Element Information Item in the <strong>[children]</strong> property of a <a title="policy assertion" href="#policy_assertion">policy assertion</a>.] The schema
outline for a <a title="nested policy expression" href="#nested_policy_expression">nested policy expression</a> is:</p><div class="exampleInner"><pre>(01) <<emph>Assertion</emph> …>
(02) …
(03) ( <wsp:Policy …> … </wsp:Policy> )?
(04) …
-(05) </<emph>Assertion</emph>></pre></div><p>The following describes additional processing constraints on the outline listed above:</p><dl><dt class="label"><code class="elt">/Assertion/wsp:Policy</code> </dt><dd><p>This indicates that the assertion contains a nested policy
-expression. If there is no <code class="elt">wsp:Policy</code> Element Information
+(05) </<emph>Assertion</emph>></pre></div><p>The following describes additional processing constraints on the outline listed above:</p><dl><dt class="label"><code>/Assertion/wsp:Policy</code></dt><dd><p>This indicates that the assertion contains a nested policy
+expression. If there is no <code>wsp:Policy</code> Element Information
Item in the <strong>[children]</strong> property,
the assertion has no nested policy expression.
</p><p>If the schema outline for an assertion type requires a nested
@@ -515,7 +563,7 @@
Section <a href="#Policy_Operators"><b>4.3.3 Policy Operators</b></a>, this is equivalent to a
nested policy expression with a single alternative that has zero
assertions.</p><p>Note: This specification does not define processing for arbitrary
-<code class="elt">wsp:Policy</code> Element Information Items in the descendants
+<code>wsp:Policy</code> Element Information Items in the descendants
of an assertion parameter, e.g., in the <strong>[children]</strong> property of one of the <strong>[children]</strong> as in:
<div class="exampleInner"><pre>
(01)<wsp:Policy>
@@ -528,7 +576,7 @@
(08) </Lorem>
(09)</wsp:Policy></pre></div>.</p></dd></dl><p>Policy assertions containing a nested policy expression are
normalized recursively. The nesting of a policy expression (and a
-<code class="elt">wsp:Policy</code> child) is retained in the normal form, but in
+<code>wsp:Policy</code> child) is retained in the normal form, but in
the normal form, each nested policy expression contains at most one
policy alternative. If an assertion A contains a nested policy
expression E, and if E contains more than one policy alternative,
@@ -613,57 +661,57 @@
alternative (Lines 03-18) contains a single nested algorithm suite
alternative (Line 08) as does the second alternative (Lines 19-34 and
24). </p></div><div class="div3">
-<h4><a name="Policy_Operators"></a>4.3.3 Policy Operators</h4><p><a title="policy" href="#policy">Policies</a> are used to convey a set of capabilities, requirements, and general characteristics of entities (see <a href="#tocRange"><b>1. Introduction</b></a>).
+<h4><a name="Policy_Operators" id="Policy_Operators"></a>4.3.3 Policy Operators</h4><p><a title="policy" href="#policy">Policies</a> are used to convey a set of capabilities, requirements, and general characteristics of entities (see <a href="#tocRange"><b>1. Introduction</b></a>).
These are generally expressible as a set of <a title="policy alternative" href="#policy_alternative">policy alternatives</a>.
- Policy operators (<code class="elt">wsp:Policy</code> , <code class="elt">wsp:All</code> and <code class="elt">wsp:ExactlyOne</code> elements)
+ Policy operators (<code>wsp:Policy</code>, <code>wsp:All</code> and <code>wsp:ExactlyOne</code> elements)
are used to group <a title="policy assertion" href="#policy_assertion">policy assertions</a>
into <a title="policy alternative" href="#policy_alternative">policy alternatives</a>.
To compactly express complex policies, policy operators
<span class="rfc2119">MAY</span> be recursively nested; that is, one or more
-instances of <code class="elt">wsp:Policy</code> , <code class="elt">wsp:All</code> , and/or
-<code class="elt">wsp:ExactlyOne</code> <span class="rfc2119">MAY</span> be nested within
-<code class="elt">wsp:Policy</code> , <code class="elt">wsp:All</code> , and/or
-<code class="elt">wsp:ExactlyOne</code> .</p><p>The schema outline for the <code class="elt">wsp:Policy</code> element in the compact form is as follows:</p><div class="exampleInner"><pre>(01) <wsp:Policy … >
+instances of <code>wsp:Policy</code>, <code>wsp:All</code>, and/or
+<code>wsp:ExactlyOne</code> <span class="rfc2119">MAY</span> be nested within
+<code>wsp:Policy</code>, <code>wsp:All</code>, and/or
+<code>wsp:ExactlyOne</code>.</p><p>The schema outline for the <code>wsp:Policy</code> element in the compact form is as follows:</p><div class="exampleInner"><pre>(01) <wsp:Policy … >
(02) ( <wsp:Policy …>…</wsp:Policy> |
(03) <wsp:ExactlyOne>…</wsp:ExactlyOne> |
(04) <wsp:All>…</wsp:All> |
(05) <wsp:PolicyReference … >…</wsp:PolicyReference> |
(06) …
(07) )*
-(08) </wsp:Policy></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code class="elt">/wsp:Policy</code> </dt><dd><p>This element is the <code class="elt">wsp:Policy</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:Policy/wsp:Policy</code> </dt><dd><p>This element is a nested <code class="elt">wsp:Policy</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:Policy/wsp:ExactlyOne</code> </dt><dd><p>This element is a nested <code class="elt">wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:Policy/wsp:All</code> </dt><dd><p>This element is a nested <code class="elt">wsp:All</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:Policy/wsp:PolicyReference</code> </dt><dd><p>This element references a policy expression to be included per Section
- <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>.</p></dd><dt class="label"><code class="elt">/wsp:Policy/@{any}</code> </dt><dd><p>Additional attributes <span class="rfc2119">MAY</span> be specified but
+(08) </wsp:Policy></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code>/wsp:Policy</code></dt><dd><p>This element is the <code>wsp:Policy</code> operator.</p></dd><dt class="label"><code>/wsp:Policy/wsp:Policy</code></dt><dd><p>This element is a nested <code>wsp:Policy</code> operator.</p></dd><dt class="label"><code>/wsp:Policy/wsp:ExactlyOne</code></dt><dd><p>This element is a nested <code>wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code>/wsp:Policy/wsp:All</code></dt><dd><p>This element is a nested <code>wsp:All</code> operator.</p></dd><dt class="label"><code>/wsp:Policy/wsp:PolicyReference</code></dt><dd><p>This element references a policy expression to be included per Section
+ <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>.</p></dd><dt class="label"><code>/wsp:Policy/@{any}</code></dt><dd><p>Additional attributes <span class="rfc2119">MAY</span> be specified but
<span class="rfc2119">MUST NOT</span> contradict the semantics of the
<strong>[owner element]</strong>;
- if an attribute is not recognized, it <span class="rfc2119">SHOULD</span> be ignored.</p></dd><dt class="label"><code class="elt">/wsp:Policy/{any}</code> </dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified. Such elements
+ if an attribute is not recognized, it <span class="rfc2119">SHOULD</span> be ignored.</p></dd><dt class="label"><code>/wsp:Policy/{any}</code></dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified. Such elements
<span class="rfc2119">MUST NOT</span> use the Web Services Policy language
XML namespace name and <span class="rfc2119">MUST NOT</span> contradict the semantics
- of the <strong>[parent element]</strong>.</p></dd></dl><p>The schema outline for the <code class="elt">wsp:ExactlyOne</code> element in the compact form is as follows:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
+ of the <strong>[parent element]</strong>.</p></dd></dl><p>The schema outline for the <code>wsp:ExactlyOne</code> element in the compact form is as follows:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
(02) ( <wsp:Policy … >…</wsp:Policy> |
(03) <wsp:ExactlyOne>…</wsp:ExactlyOne> |
(04) <wsp:All>…</wsp:All> |
(05) <wsp:PolicyReference … >…</wsp:PolicyReference> |
(06) …
(07) )*
-(08) </wsp:ExactlyOne></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code class="elt">/wsp:ExactlyOne</code> </dt><dd><p>This element is the <code class="elt">wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:ExactlyOne/wsp:Policy</code> </dt><dd><p>This element is a nested <code class="elt">wsp:Policy</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:ExactlyOne/wsp:ExactlyOne</code> </dt><dd><p>This element is a nested <code class="elt">wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:ExactlyOne/wsp:All</code> </dt><dd><p>This element is a nested <code class="elt">wsp:All operator</code> .</p></dd><dt class="label"><code class="elt">/wsp:ExactlyOne/wsp:PolicyReference</code> </dt><dd><p>This element references a policy expression to be included per Section
- <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>.</p></dd><dt class="label"><code class="elt">/wsp:ExactlyOne/{any}</code> </dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified. Such elements
+(08) </wsp:ExactlyOne></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code>/wsp:ExactlyOne</code></dt><dd><p>This element is the <code>wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code>/wsp:ExactlyOne/wsp:Policy</code></dt><dd><p>This element is a nested <code>wsp:Policy</code> operator.</p></dd><dt class="label"><code>/wsp:ExactlyOne/wsp:ExactlyOne</code></dt><dd><p>This element is a nested <code>wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code>/wsp:ExactlyOne/wsp:All</code></dt><dd><p>This element is a nested <code>wsp:All operator</code>.</p></dd><dt class="label"><code>/wsp:ExactlyOne/wsp:PolicyReference</code></dt><dd><p>This element references a policy expression to be included per Section
+ <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>.</p></dd><dt class="label"><code>/wsp:ExactlyOne/{any}</code></dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified. Such elements
<span class="rfc2119">MUST NOT</span> use the Web Services Policy language
XML namespace name and <span class="rfc2119">MUST NOT</span> contradict the semantics
- of the <strong>[parent element]</strong>.</p></dd></dl><p>The schema outline for the <code class="elt">wsp:All</code> element in the compact form is as follows:</p><div class="exampleInner"><pre>(01) <wsp:All>
+ of the <strong>[parent element]</strong>.</p></dd></dl><p>The schema outline for the <code>wsp:All</code> element in the compact form is as follows:</p><div class="exampleInner"><pre>(01) <wsp:All>
(02) ( <wsp:Policy … >…</wsp:Policy> |
(03) <wsp:ExactlyOne>…</wsp:ExactlyOne> |
(04) <wsp:All>…</wsp:All> |
(05) <wsp:PolicyReference … >…</wsp:PolicyReference> |
(06) …
(07) )*
-(08) </wsp:All></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code class="elt">/wsp:All</code> </dt><dd><p>This element is the <code class="elt">wsp:All</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:All/wsp:Policy</code> </dt><dd><p>This element is a nested <code class="elt">wsp:Policy</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:All/wsp:ExactlyOne</code> </dt><dd><p>This element is a nested <code class="elt">wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:All/wsp:All</code> </dt><dd><p>This element is a nested <code class="elt">wsp:All</code> operator.</p></dd><dt class="label"><code class="elt">/wsp:All/wsp:PolicyReference</code> </dt><dd><p>This element references a policy expression to be included per Section
- <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>.</p></dd><dt class="label"><code class="elt">/wsp:All/{any}</code> </dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified. Such elements
+(08) </wsp:All></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code>/wsp:All</code></dt><dd><p>This element is the <code>wsp:All</code> operator.</p></dd><dt class="label"><code>/wsp:All/wsp:Policy</code></dt><dd><p>This element is a nested <code>wsp:Policy</code> operator.</p></dd><dt class="label"><code>/wsp:All/wsp:ExactlyOne</code></dt><dd><p>This element is a nested <code>wsp:ExactlyOne</code> operator.</p></dd><dt class="label"><code>/wsp:All/wsp:All</code></dt><dd><p>This element is a nested <code>wsp:All</code> operator.</p></dd><dt class="label"><code>/wsp:All/wsp:PolicyReference</code></dt><dd><p>This element references a policy expression to be included per Section
+ <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>.</p></dd><dt class="label"><code>/wsp:All/{any}</code></dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified. Such elements
<span class="rfc2119">MUST NOT</span> use the Web Services Policy language
XML namespace name and <span class="rfc2119">MUST NOT</span> contradict the semantics
- of the <strong>[parent element]</strong>.</p></dd></dl><div class="note"><p class="prefix"><b>Note:</b></p><p>The <code class="elt">wsp:All</code> and
- <code class="elt">wsp:ExactlyOne</code> elements do not allow attribute extensibility
- because such attributes cannot be preserved through normalization.</p></div><p>The following rules are used to transform a compact policy expression into a normal form policy expression:</p><dl><dt class="label">Equivalence</dt><dd><p>Use of <code class="elt">wsp:Policy</code> as an operator within a policy expression is
- equivalent to <code class="elt">wsp:All</code> .</p><p>
- A collection of assertions in an <code class="elt">wsp:All</code> operator is equivalent
+ of the <strong>[parent element]</strong>.</p></dd></dl><div class="note"><p class="prefix"><b>Note:</b></p><p>The <code>wsp:All</code> and
+ <code>wsp:ExactlyOne</code> elements do not allow attribute extensibility
+ because such attributes cannot be preserved through normalization.</p></div><p>The following rules are used to transform a compact policy expression into a normal form policy expression:</p><dl><dt class="label">Equivalence</dt><dd><p>Use of <code>wsp:Policy</code> as an operator within a policy expression is
+ equivalent to <code>wsp:All</code>.</p><p>
+ A collection of assertions in an <code>wsp:All</code> operator is equivalent
to a <a title="policy alternative" href="#policy_alternative">policy alternative</a>. For instance,
</p><div class="exampleInner"><pre>(01) <wsp:All>
(02) <!-- assertion 1 -->
@@ -673,14 +721,14 @@
(03) <!-- assertion 1 -->
(04) <!-- assertion 2 -->
(05) </wsp:All>
-(06) </wsp:ExactlyOne></pre></div></dd><dt class="label">Empty</dt><dd><ul><li><p><code><wsp:All /></code> expresses a policy with zero policy assertions. Note that since <code class="elt">wsp:Policy</code> is equivalent to <code class="elt">wsp:All</code> , <code><wsp:Policy /></code> is therefore equivalent to <code><wsp:All /></code>, i.e., a policy alternative with zero assertions.</p></li><li><p><code><wsp:ExactlyOne /></code> expresses a policy with zero policy alternatives.</p></li></ul></dd><dt class="label">Commutative</dt><dd><p>In line with the previous statements that policy assertions within
+(06) </wsp:ExactlyOne></pre></div></dd><dt class="label">Empty</dt><dd><ul><li><p><code><wsp:All /></code> expresses a policy with zero policy assertions. Note that since <code>wsp:Policy</code> is equivalent to <code>wsp:All</code>, <code><wsp:Policy /></code> is therefore equivalent to <code><wsp:All /></code>, i.e., a policy alternative with zero assertions.</p></li><li><p><code><wsp:ExactlyOne /></code> expresses a policy with zero policy alternatives.</p></li></ul></dd><dt class="label">Commutative</dt><dd><p>In line with the previous statements that policy assertions within
a policy alternative and policy alternatives within a policy are not
-ordered (see <a href="#rPolicy_Alternative"><b>3.2 Policy Alternative</b></a> and <a href="#rPolicy"><b>3.3 Policy</b></a>, respectively), <code class="elt">wsp:All</code> and
-<code class="elt">wsp:ExactlyOne</code> are commutative. For example,</p><div class="exampleInner"><pre>(01) <wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:All> <emph><!-- assertion 2 --> <!-- assertion 1 --> </emph></wsp:All></pre></div><p>and:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
+ordered (see <a href="#rPolicy_Alternative"><b>3.2 Policy Alternative</b></a> and <a href="#rPolicy"><b>3.3 Policy</b></a>, respectively), <code>wsp:All</code> and
+<code>wsp:ExactlyOne</code> are commutative. For example,</p><div class="exampleInner"><pre>(01) <wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:All> <emph><!-- assertion 2 --> <!-- assertion 1 --> </emph></wsp:All></pre></div><p>and:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
(02) <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
(03) </wsp:ExactlyOne></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
(02) <emph><!-- assertion 2 --> <!-- assertion 1 --></emph>
-(03) </wsp:ExactlyOne></pre></div></dd><dt class="label">Associative</dt><dd><p><code class="elt">wsp:All</code> and <code class="elt">wsp:ExactlyOne</code> are associative. For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
+(03) </wsp:ExactlyOne></pre></div></dd><dt class="label">Associative</dt><dd><p><code>wsp:All</code> and <code>wsp:ExactlyOne</code> are associative. For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
(02) <emph><!-- assertion 1 --></emph>
(03) <emph> </emph><wsp:All> <emph><!-- assertion 2 --> </emph></wsp:All>
(04) </wsp:All></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All></pre></div><p>and:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
@@ -688,7 +736,7 @@
(03) <emph> </emph><wsp:ExactlyOne> <emph><!-- assertion 2 --> </emph></wsp:ExactlyOne>
(04) </wsp:ExactlyOne></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
(02) <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
-(03) </wsp:ExactlyOne></pre></div></dd><dt class="label">Idempotent</dt><dd><p><code class="elt">wsp:All</code> and <code class="elt">wsp:ExactlyOne</code> are idempotent. For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
+(03) </wsp:ExactlyOne></pre></div></dd><dt class="label">Idempotent</dt><dd><p><code>wsp:All</code> and <code>wsp:ExactlyOne</code> are idempotent. For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
(02) <wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All>
(03) </wsp:All></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:All> <emph><!-- assertion 1 --> <!-- assertion 2 --> </emph></wsp:All></pre></div><p>and:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
(02) <wsp:ExactlyOne>
@@ -696,7 +744,7 @@
(04) <emph> </emph></wsp:ExactlyOne>
(05) </wsp:ExactlyOne></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne>
(02) <emph><!-- assertion 1 --> <!-- assertion 2 --></emph>
-(03) </wsp:ExactlyOne></pre></div></dd><dt class="label">Distributive</dt><dd><p><code class="elt">wsp:All</code> distributes over <code class="elt">wsp:ExactlyOne</code> . For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
+(03) </wsp:ExactlyOne></pre></div></dd><dt class="label">Distributive</dt><dd><p><code>wsp:All</code> distributes over <code>wsp:ExactlyOne</code>. For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
(02) <wsp:ExactlyOne>
(03) <emph> <!-- assertion 1 --></emph>
(04) <emph> <!-- assertion 2 --></emph>
@@ -722,7 +770,7 @@
(03) <wsp:All><emph><!-- assertion 1 --><!-- assertion 4 --></emph></wsp:All>
(04) <wsp:All><emph><!-- assertion 2 --><!-- assertion 3 --></emph></wsp:All>
(05) <wsp:All><emph><!-- assertion 2 --><!-- assertion 4 --></emph></wsp:All>
-(06) </wsp:ExactlyOne></pre></div><p>Distributing <code class="elt">wsp:All</code> over an empty <code class="elt">wsp:ExactlyOne</code> is equivalent to no alternatives. For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
+(06) </wsp:ExactlyOne></pre></div><p>Distributing <code>wsp:All</code> over an empty <code>wsp:ExactlyOne</code> is equivalent to no alternatives. For example,</p><div class="exampleInner"><pre>(01) <wsp:All>
(02) <wsp:ExactlyOne />
(03) </wsp:All></pre></div><p>is equivalent to:</p><div class="exampleInner"><pre>(01) <wsp:ExactlyOne /></pre></div><p>and:</p><div class="exampleInner"><pre>(01) <wsp:All>
(02) <wsp:ExactlyOne>
@@ -738,9 +786,9 @@
(04) <sp:WssUsernameToken10 />
(05) <sp:WssUsernameToken11 />
(06) </wsp:ExactlyOne>
-(07) </wsp:Policy></pre></div></dd></dl><p>Applying Section <a href="#Optional_Policy_Assertions"><b>4.3.1 Optional Policy Assertions</b></a> to <code class="attr">@wsp:Optional</code> in Line
-(02), and distributing <code class="elt">wsp:All</code> over
-<code class="elt">wsp:ExactlyOne</code> per Section <a href="#Policy_Operators"><b>4.3.3 Policy Operators</b></a> for the assertions
+(07) </wsp:Policy></pre></div></dd></dl><p>Applying Section <a href="#Optional_Policy_Assertions"><b>4.3.1 Optional Policy Assertions</b></a> to <code>@wsp:Optional</code> in Line
+(02), and distributing <code>wsp:All</code> over
+<code>wsp:ExactlyOne</code> per Section <a href="#Policy_Operators"><b>4.3.3 Policy Operators</b></a> for the assertions
in Lines (04-05) yields:</p><div class="exampleInner"><pre>(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsp="http://www.w3.org/ns/ws-policy" >
@@ -758,7 +806,7 @@
(13) <sp:WssUsernameToken11 />
(14) </wsp:All>
(15) </wsp:ExactlyOne>
-(16) </wsp:Policy></pre></div><p>Note that the assertion listed in Line (02) in the first listing expands into the two alternatives in Lines (03-06) in the second listing.</p><p>Finally, noting that <code class="elt">wsp:Policy</code> is equivalent to <code class="elt">wsp:All</code> , and distributing <code class="elt">wsp:All</code> over <code class="elt">wsp:ExactlyOne</code> yields the following normal form policy expression:</p><div class="exampleInner"><pre>(01) <wsp:Policy
+(16) </wsp:Policy></pre></div><p>Note that the assertion listed in Line (02) in the first listing expands into the two alternatives in Lines (03-06) in the second listing.</p><p>Finally, noting that <code>wsp:Policy</code> is equivalent to <code>wsp:All</code>, and distributing <code>wsp:All</code> over <code>wsp:ExactlyOne</code> yields the following normal form policy expression:</p><div class="exampleInner"><pre>(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02) <wsp:ExactlyOne>
@@ -778,12 +826,12 @@
(16) </wsp:All>
(17) </wsp:ExactlyOne>
(18) </wsp:Policy></pre></div><p>Note that the two alternatives listed in Lines (03-06) in the second listing are combined with the two alternatives listed in Lines (09-14) in the second listing to create four alternatives in the normalized policy, Lines (03-06), (07-10), (11-13), and (14-16).</p></div><div class="div3">
-<h4><a name="Policy_References"></a>4.3.4 Policy References</h4><p>The <code class="elt">wsp:PolicyReference</code> element is used to reference <a title="policy expression" href="#policy_expression">policy expressions</a>. The semantics of the <code class="elt">wsp:PolicyReference</code> element are determined by the context in which it is used (for an example, see <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>).</p><p>The schema outline for the <code class="elt">wsp:PolicyReference</code> element is as follows:</p><div class="exampleInner"><pre>(01) <wsp:PolicyReference
+<h4><a name="Policy_References" id="Policy_References"></a>4.3.4 Policy References</h4><p>The <code>wsp:PolicyReference</code> element is used to reference <a title="policy expression" href="#policy_expression">policy expressions</a>. The semantics of the <code>wsp:PolicyReference</code> element are determined by the context in which it is used (for an example, see <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>).</p><p>The schema outline for the <code>wsp:PolicyReference</code> element is as follows:</p><div class="exampleInner"><pre>(01) <wsp:PolicyReference
(02) URI="<emph>xs:anyURI</emph>"
(03) ( Digest="<emph>xs:base64Binary</emph>" ( DigestAlgorithm="<emph>xs:anyURI</emph>" )? )?
(04) … >
(05) …
-(06) </wsp:PolicyReference></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code class="elt">/wsp:PolicyReference</code> </dt><dd><p>This element references a policy expression that is being referenced.</p></dd><dt class="label"><code class="attr">/wsp:PolicyReference/@URI</code> </dt><dd><p>This attribute references a policy expression by an IRI. For a policy
+(06) </wsp:PolicyReference></pre></div><p>The following describes the Attribute and Element Information Items defined in the schema outline above:</p><dl><dt class="label"><code>/wsp:PolicyReference</code></dt><dd><p>This element references a policy expression that is being referenced.</p></dd><dt class="label"><code>/wsp:PolicyReference/@URI</code></dt><dd><p>This attribute references a policy expression by an IRI. For a policy
expression within the same XML Document, the reference <span class="rfc2119">SHOULD</span> be an
IRI-reference to a policy expression identified by an <code>ID</code>.
For an external policy expression, there is no requirement that the IRI
@@ -791,17 +839,17 @@
After retrieval, there is no requirement to check that the retrieved policy
expression is associated (Section <a href="#Policy_Identification"><b>4.2 Policy Identification</b></a>) with this IRI.
The IRI included in the retrieved policy expression, if any, <span class="rfc2119">MAY</span> be
-different than the IRI used to retrieve the policy expression. </p></dd><dt class="label"><code class="attr">/wsp:PolicyReference/@Digest</code> </dt><dd><p>This attribute is of type <code class="attr">xs:base64Binary</code> and specifies the digest of the referenced policy expression. This is used to ensure the included policy is the expected policy.
- If omitted, there is no implied value.</p></dd><dt class="label"><code class="attr">/wsp:PolicyReference/@DigestAlgorithm</code> </dt><dd><p>This optional URI attribute specifies the digest algorithms being used. This specification predefines the default algorithm below, although additional algorithms can be expressed. </p></dd></dl><table cellspacing="0" cellpadding="5" border="1"><thead><tr><th rowspan="1" colspan="1">URI</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1"><code>http://www.w3.org/ns/ws-policy/Sha1Exc</code> (implied)</td><td rowspan="1" colspan="1">The digest is a SHA1 hash over the octet stream resulting from using the Exclusive XML canonicalization defined for XML Signature [<cite><a href="#XML-Signature">XML-Signature</a></cite>].</td></tr></tbody></table><br><dl><dt class="label"><code class="attr">/wsp:PolicyReference/@{any}</code> </dt><dd><p>Additional attributes <span class="rfc2119">MAY</span> be specified but
+different than the IRI used to retrieve the policy expression. </p></dd><dt class="label"><code>/wsp:PolicyReference/@Digest</code></dt><dd><p>This attribute is of type <code>xs:base64Binary</code> and specifies the digest of the referenced policy expression. This is used to ensure the included policy is the expected policy.
+ If omitted, there is no implied value.</p></dd><dt class="label"><code>/wsp:PolicyReference/@DigestAlgorithm</code></dt><dd><p>This optional URI attribute specifies the digest algorithms being used. This specification predefines the default algorithm below, although additional algorithms can be expressed. </p></dd></dl><table cellspacing="0" cellpadding="5" border="1"><thead><tr><th rowspan="1" colspan="1">URI</th><th rowspan="1" colspan="1">Description</th></tr></thead><tbody><tr><td rowspan="1" colspan="1"><code>http://www.w3.org/ns/ws-policy/Sha1Exc</code> (implied)</td><td rowspan="1" colspan="1">The digest is a SHA1 hash over the octet stream resulting from using the Exclusive XML canonicalization defined for XML Signature [<cite><a href="#XML-Signature">XML-Signature</a></cite>].</td></tr></tbody></table><br><dl><dt class="label"><code>/wsp:PolicyReference/@{any}</code></dt><dd><p>Additional attributes <span class="rfc2119">MAY</span> be specified but
<span class="rfc2119">MUST NOT</span> contradict the semantics of the
<strong>[owner element]</strong>;
if an attribute is not recognized, it
-<span class="rfc2119">SHOULD</span> be ignored.</p></dd><dt class="label"><code class="elt">/wsp:PolicyReference/{any}</code> </dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified but
+<span class="rfc2119">SHOULD</span> be ignored.</p></dd><dt class="label"><code>/wsp:PolicyReference/{any}</code></dt><dd><p>Additional elements <span class="rfc2119">MAY</span> be specified but
<span class="rfc2119">MUST NOT</span> contradict the semantics of the
<strong>[parent element]</strong>;
if an element is not recognized, it
<span class="rfc2119">SHOULD</span> be ignored.</p></dd></dl></div><div class="div3">
-<h4><a name="Policy_Inclusion"></a>4.3.5 Policy Inclusion</h4><p>In order to share <a title="policy assertion" href="#policy_assertion">assertions</a> across <a title="policy expression" href="#policy_expression">policy expressions</a>, the <code class="elt">wsp:PolicyReference</code> element <span class="rfc2119">MAY</span> be present anywhere a policy assertion is allowed inside a policy expression. This element is used to include the content of one policy expression in another policy expression.</p><p>When a <code class="elt">wsp:PolicyReference</code> element references a <code class="elt">wsp:Policy</code> element, then the semantics of inclusion are simply to replace the <code class="elt">wsp:PolicyReference</code> element with a <code class="elt">wsp:All</code> element whose <strong>[children]</strong> property is the same as the <strong>[children]</strong> property of the referenced <code class="elt">wsp:Policy</code> element. That is, the contents of the referenced policy conceptually replac the <code class="elt">wsp:PolicyReference</code> element and are wrapped in a <code class="elt">wsp:All</code> operator. Using the <code class="elt">wsp:PolicyReference</code> element, a policy expression <span class="rfc2119">MUST NOT</span> reference itself either directly or indirectly. (Note: References that have a <code class="attr">@Digest</code> attribute <span class="rfc2119">SHOULD</span> be validated before being included.)</p><p>In the example below two policies include and extend a common policy. In the first example there is a single policy document containing two policy assertions. The expression is given an identifier but not a fully qualified location. The second and third expressions reference the first expression by URI indicating the referenced expression is within the document. </p><div class="exampleInner"><pre>(01) <wsp:Policy
+<h4><a name="Policy_Inclusion" id="Policy_Inclusion"></a>4.3.5 Policy Inclusion</h4><p>In order to share <a title="policy assertion" href="#policy_assertion">assertions</a> across <a title="policy expression" href="#policy_expression">policy expressions</a>, the <code>wsp:PolicyReference</code> element <span class="rfc2119">MAY</span> be present anywhere a policy assertion is allowed inside a policy expression. This element is used to include the content of one policy expression in another policy expression.</p><p>When a <code>wsp:PolicyReference</code> element references a <code>wsp:Policy</code> element, then the semantics of inclusion are simply to replace the <code>wsp:PolicyReference</code> element with a <code>wsp:All</code> element whose <strong>[children]</strong> property is the same as the <strong>[children]</strong> property of the referenced <code>wsp:Policy</code> element. That is, the contents of the referenced policy conceptually replace the <code>wsp:PolicyReference</code> element and are wapped in a <code>wsp:All</code> operator. Using the <code>wsp:PolicyReference</code> element, a policy expression <span class="rfc2119">MUST NOT</span> reference itself either directly or indirectly. (Note: References that have a <code>@Digest</code> attribute <span class="rfc2119">SHOULD</span> be validated before being included.)</p><p>In the example below two policies include and extend a common policy. In the first example there is a single policy document containing two policy assertions. The expression is given an identifier but not a fully qualified location. The second and third expressions reference the first expression by URI indicating the referenced expression is within the document. </p><div class="exampleInner"><pre>(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
@@ -822,9 +870,9 @@
(03) <wsp:PolicyReference URI="#Protection" />
(04) <sp:OnlySignEntireHeadersAndBody />
(05) </wsp:Policy></pre></div><p>There are times when it is desirable to "re-use" a portion of a policy expression. Generally, this can be accomplished by placing the common assertions in a separate policy expression and referencing it. </p></div><div class="div3">
-<h4><a name="normalization"></a>4.3.6 Normalization</h4><p>To interpret a compact <a title="policy expression" href="#policy_expression">expression</a> in an interoperable form,
+<h4><a name="normalization" id="normalization"></a>4.3.6 Normalization</h4><p>To interpret a compact <a title="policy expression" href="#policy_expression">expression</a> in an interoperable form,
a compact expression may be converted to the corresponding normal form
- expression by the following procedure:</p><ol><li><p>Start with the Element Information Item E (as defined in the XML Information Set [<cite><a href="#XMLInfoset">XML Information Set</a></cite>]) of the
+ expression by the following procedure:</p><ol class="enumar"><li><p>Start with the Element Information Item E (as defined in the XML Information Set [<cite><a href="#XMLInfoset">XML Information Set</a></cite>]) of the
policy expression. The <strong>[namespace
name]</strong> of E is always <code>"http://www.w3.org/ns/ws-policy"</code>. In the base case,
the <strong>[local name]</strong> property of E is
@@ -832,7 +880,7 @@
<code>"Policy"</code>, <code>"ExactlyOne"</code>, or
<code>"All"</code>.</p></li><li><p>Expand Element Information Items (as defined in the XML Information Set [<cite><a href="#XMLInfoset">XML Information Set</a></cite>]) in the <strong>[children]</strong> property of E that are policy
references per Section <a href="#Policy_Inclusion"><b>4.3.5 Policy Inclusion</b></a>.</p></li><li><p>Convert each Element Information Item C in the <strong>[children]</strong> property of E into normal
- form.</p><ol><li><p>If the <strong>[namespace name]</strong>
+ form.</p><ol class="enumla"><li><p>If the <strong>[namespace name]</strong>
property of C is <code>"http://www.w3.org/ns/ws-policy"</code> and the <strong>[local
name]</strong> property of C is <code>"Policy"</code>,
<code>"ExactlyOne"</code>, or <code>"All"</code>, C is an expression
@@ -845,14 +893,14 @@
is not required to explicitly convert a compact expression into the
normal form as long as the processing results are indistinguishable
from doing so.</p></div></div><div class="div2">
-<h3><a name="ignorable-policy-assertions"></a>4.4 Ignorable Policy Assertions</h3><p>The <code class="attr">wsp:Ignorable</code> attribute indicates if a policy assertion is an
+<h3><a name="ignorable-policy-assertions" id="ignorable-policy-assertions"></a>4.4 Ignorable Policy Assertions</h3><p>The <code>wsp:Ignorable</code> attribute indicates if a policy assertion is an
<a title="ignorable policy assertion" href="#ignorable_policy_assertion">ignorable policy assertion</a>. The schema
-outline for this attribute is as follows:</p><div class="exampleInner"><pre>(01) <Assertion ( wsp:Ignorable="xs:boolean" )? … > … </Assertion></pre></div><p>The following describes the Attribute Information Item defined in the schema outline above:</p><dl><dt class="label"><code class="attr">/Assertion/@wsp:Ignorable</code> </dt><dd><p>This attribute is of type <code>xs:boolean</code>. If the actual
+outline for this attribute is as follows:</p><div class="exampleInner"><pre>(01) <Assertion ( wsp:Ignorable="xs:boolean" )? … > … </Assertion></pre></div><p>The following describes the Attribute Information Item defined in the schema outline above:</p><dl><dt class="label"><code>/Assertion/@wsp:Ignorable</code></dt><dd><p>This attribute is of type <code>xs:boolean</code>. If the actual
value (See XML Schema Part 1 [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>]) is true,
the assertion is an <a title="ignorable policy assertion" href="#ignorable_policy_assertion">ignorable policy assertion</a>. If the actual value is false,
the assertion is not an <a title="ignorable policy assertion" href="#ignorable_policy_assertion">ignorable policy assertion</a>. Omitting
this attribute is semantically equivalent to including it with a value of false.</p></dd></dl></div><div class="div2">
-<h3><a name="Policy_Intersection"></a>4.5 Policy Intersection</h3><p>Policy intersection is useful when two or more parties express <a title="policy" href="#policy">policy</a> and
+<h3><a name="Policy_Intersection" id="Policy_Intersection"></a>4.5 Policy Intersection</h3><p>Policy intersection is useful when two or more parties express <a title="policy" href="#policy">policy</a> and
want to limit the <a title="policy alternative" href="#policy_alternative">policy alternatives</a> to those
that are mutually compatible. For example, when a requester and a provider express requirements
on a message exchange, intersection identifies compatible policy alternatives (if any) included
@@ -901,7 +949,7 @@
(18) </sp:EncryptedParts>
(19) </wsp:All>
(20) </wsp:ExactlyOne>
-(21) </wsp:Policy></pre></div><p>The listing above contains two policy alternatives. The first alternative, (Lines 03-10) contains two policy assertions. One indicates which elements should be signed (Lines 04-06); its type is <code class="elt">sp:SignedElements</code> (Line 04), and its parameters include an XPath expression for the content to be signed (Line 05). The other assertion (Lines 07-09) has a similar structure: type (Line 07) and parameters (Line 08).</p><p>The second alternative (Lines 11-19) also contains two assertions, each with type (Line 12 and Line 16) and parameters (Lines 13-14 and Line 17).</p><p>As this example illustrates, compatibility between two policy assertions is based on assertion type and delegates parameter processing to domain-specific processing.</p><div class="exampleInner"><pre>(01) <wsp:Policy
+(21) </wsp:Policy></pre></div><p>The listing above contains two policy alternatives. The first alternative, (Lines 03-10) contains two policy assertions. One indicates which elements should be signed (Lines 04-06); its type is <code>sp:SignedElements</code> (Line 04), and its parameters include an XPath expression for the content to be signed (Line 05). The other assertion (Lines 07-09) has a similar structure: type (Line 07) and parameters (Line 08).</p><p>The second alternative (Lines 11-19) also contains two assertions, each with type (Line 12 and Line 16) and parameters (Lines 13-14 and Line 17).</p><p>As this example illustrates, compatibility between two policy assertions is based on assertion type and delegates parameter processing to domain-specific processing.</p><div class="exampleInner"><pre>(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsp="http://www.w3.org/ns/ws-policy" >
<!-- Policy P2 -->
@@ -939,19 +987,19 @@
(15) </wsp:All>
(16) </wsp:ExactlyOne>
(17) </wsp:Policy></pre></div><p>Note that there are > 1 assertions of the type
-<code class="elt">sp:SignedParts</code> ; when the behavior associated with
-<code class="elt">sp:SignedParts</code> is invoked, the contents of both
+<code>sp:SignedParts</code>; when the behavior associated with
+<code>sp:SignedParts</code> is invoked, the contents of both
assertions are used to indicate the correct behavior. Whether these
two assertions are compatible depends on the domain-specific semantics
-of the <code class="elt">sp:SignedParts</code> assertion. To leverage
+of the <code>sp:SignedParts</code> assertion. To leverage
intersection, assertion authors are encouraged to factor assertions
such that two assertions of the same assertion type are always (or at
least typically) compatible.</p></div><div class="div2">
-<h3><a name="IRI_Policy_Expressions"></a>4.6 Use of IRIs in Policy Expressions</h3><p>Policy expressions use IRIs for some identifiers. This document does not define a base URI but relies
+<h3><a name="IRI_Policy_Expressions" id="IRI_Policy_Expressions"></a>4.6 Use of IRIs in Policy Expressions</h3><p>Policy expressions use IRIs for some identifiers. This document does not define a base URI but relies
on the mechanisms defined in XML Base [<cite><a href="#XMLBASE">XML BASE</a></cite>] and RFCs 3023 [<cite><a href="#RFC3023">IETF RFC 3023</a></cite>],
3986 [<cite><a href="#RFC3986">IETF RFC 3986</a></cite>] and 3987 [<cite><a href="#RFC3987">IETF RFC 3987</a></cite>]
for establishing a base URI against which relative IRIs can be made absolute.</p></div></div><div class="div1">
-<h2><a name="Security_Considerations"></a>5. Security Considerations</h2><p>It is <span class="rfc2119">RECOMMENDED</span> that <a title="policy" href="#policy">policies</a> and
+<h2><a name="Security_Considerations" id="Security_Considerations"></a>5. Security Considerations</h2><p>It is <span class="rfc2119">RECOMMENDED</span> that <a title="policy" href="#policy">policies</a> and
<a title="policy assertion" href="#policy_assertion">assertions</a> be integrity protected to permit the detection of tampering. This can be done using a technology such as XML DSig [<cite><a href="#XML-Signature">XML-Signature</a></cite>], SSL/TLS [<cite><a href="#RFC2246">IETF RFC 2246</a></cite>], or WS-Security 2004 [<cite><a href="#WS-Security">WS-Security 2004</a></cite>].</p><p>Policies <span class="rfc2119">SHOULD NOT</span> be accepted unless they are signed and have an
associated security token to specify the signer has the right to
"speak for" the <a title="policy scope" href="#policy_scope">scope</a> containing the policy. That is, a relying party
@@ -963,7 +1011,7 @@
policy authors, policy assertion authors, and policy implementers need to consider when
exposing, consuming and designing <a title="policy expression" href="#policy_expression">policy expressions</a>, authoring policy assertions or
implementing policy.</p><div class="div2">
-<h3><a name="information-disclosure-threats"></a>5.1 Information Disclosure Threats</h3><p>A policy is used to represent the capabilities and requirements of a Web Service.
+<h3><a name="information-disclosure-threats" id="information-disclosure-threats"></a>5.1 Information Disclosure Threats</h3><p>A policy is used to represent the capabilities and requirements of a Web Service.
Policies may include sensitive information. Malicious consumers may acquire sensitive
information, fingerprint the service and infer service vulnerabilities. These threats can
be mitigated by requiring authentication for sensitive information, by omitting sensitive
@@ -971,19 +1019,19 @@
policy metadata, policy providers can use mechanisms from other Web Services
specifications such as WS-Security [<cite><a href="#WS-Security">WS-Security 2004</a></cite>] and
WS-MetadataExchange [<cite><a href="#WS-MetadataExchange">WS-MetadataExchange</a></cite>] .</p></div><div class="div2">
-<h3><a name="spoofing-and-tampering-threats"></a>5.2 Spoofing and Tampering Threats</h3><p>If a policy expression is unsigned it could be easily tampered with or replaced. To
+<h3><a name="spoofing-and-tampering-threats" id="spoofing-and-tampering-threats"></a>5.2 Spoofing and Tampering Threats</h3><p>If a policy expression is unsigned it could be easily tampered with or replaced. To
prevent tampering or spoofing of policy, requestors should discard a policy unless it is
signed by the provider and presented with sufficient credentials. Requestors should also
check that the signer is actually authorized to express policies for the given policy
subject.</p></div><div class="div2">
-<h3><a name="downgrade-threats"></a>5.3 Downgrade Threats</h3><p>A policy may offer several alternatives that vary from weak to strong set of
+<h3><a name="downgrade-threats" id="downgrade-threats"></a>5.3 Downgrade Threats</h3><p>A policy may offer several alternatives that vary from weak to strong set of
requirements. An adversary may interfere and remove all the alternatives except the
weakest one (say no security requirements). Or, an adversary may interfere and discard
this policy and insert a weaker policy previously issued by the same provider. Policy
authors or providers can mitigate these threats by sun-setting older or weaker policy
alternatives. Requestors can mitigate these threats by discarding policies unless they are
signed by the provider.</p></div><div class="div2">
-<h3><a name="repudiation-threats"></a>5.4 Repudiation Threats</h3><p>Malicious providers may include policy assertions in its policy whose behavior cannot be
+<h3><a name="repudiation-threats" id="repudiation-threats"></a>5.4 Repudiation Threats</h3><p>Malicious providers may include policy assertions in its policy whose behavior cannot be
verified by examining the wire message from the provider to requestor. In general,
requestors have no guarantee that a provider will behave as described in the provider’s
policy expression. The provider may not and perform a malicious activity. For example, say
@@ -993,13 +1041,14 @@
examining the wire message from the provider to requestor. Assertion authors can mitigate
this threat by not designing assertions whose behavior cannot be verified using wire
messages.</p></div><div class="div2">
-<h3><a name="denial-of-service-threats"></a>5.5 Denial of Service Threats</h3><p>Malicious providers may provide a policy expression with a large number of alternatives,
+<h3><a name="denial-of-service-threats" id="denial-of-service-threats"></a>5.5 Denial of Service Threats</h3><p>Malicious providers may provide a policy expression with a large number of alternatives,
a large number of assertions in alternatives, deeply nested policy expressions or chains
of PolicyReference elements that expand exponentially (see the chained sample below; this
is similar to the well-known DTD entity expansion attack). Policy implementers need to
anticipate these rogue providers and use a configurable bound with defaults on number of
policy alternatives, number of assertions in an alternative, depth of nested policy
- expressions, etc.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><a name="ex-chained-policy-reference-elements"></a><i><span>Example 5-1. </span>Chained Policy Reference Elements</i></p><div class="exampleInner"><pre>(01) <wsp:Policy wsu:Id="p1">
+ expressions, etc.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><a name="ex-chained-policy-reference-elements" id="ex-chained-policy-reference-elements"></a><i><span>Example 5-1. </span>Chained Policy Reference Elements</i></p><div class="exampleInner"><pre>(01) <wsp:Policy wsu:Id="p1">
(02) <wsp:PolicyReference URI="#p2"/ >
(03) <wsp:PolicyReference URI="#p2"/>
(04) </wsp:Policy>
@@ -1028,18 +1077,18 @@
may require the consumers to establish a large number of TCP connections. Policy
implementers need to anticipate such rogue providers and use a configurable bound with
defaults on number of PolicyReference elements per policy expression.</p></div><div class="div2">
-<h3><a name="general-xml-considerations"></a>5.6 General XML Considerations</h3><p>Implementers of Web Services policy language should be careful to protect their software
+<h3><a name="general-xml-considerations" id="general-xml-considerations"></a>5.6 General XML Considerations</h3><p>Implementers of Web Services policy language should be careful to protect their software
against general XML threats like deeply nested XML or XML that contains malicious
content.</p></div></div><div class="div1">
-<h2><a name="Conformance"></a>6. Conformance</h2><p>An element information item whose namespace name is "http://www.w3.org/ns/ws-policy" and whose local part is Policy or PolicyReference conforms to this specification if it is valid according to the XML Schema [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>] for that element as defined by this specification (<a href="http://www.w3.org/ns/ws-policy.xsd">http://www.w3.org/ns/ws-policy.xsd</a>) and additionally adheres to all the constraints contained in this specification. Such a conformant element information item constitutes a <a title="policy expression" href="#policy_expression">policy expression</a>.
+<h2><a name="Conformance" id="Conformance"></a>6. Conformance</h2><p>An element information item whose namespace name is "http://www.w3.org/ns/ws-policy" and whose local part is Policy or PolicyReference conforms to this specification if it is valid according to the XML Schema [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>] for that element as defined by this specification (<a href="http://www.w3.org/ns/ws-policy.xsd">http://www.w3.org/ns/ws-policy.xsd</a>) and additionally adheres to all the constraints contained in this specification. Such a conformant element information item constitutes a <a title="policy expression" href="#policy_expression">policy expression</a>.
</p></div></div><div class="back"><div class="div1">
-<h2><a name="media-type"></a>A. The application/wspolicy+xml Media Type</h2><p>This appendix defines the "application/wspolicy+xml"
+<h2><a name="media-type" id="media-type"></a>A. The application/wspolicy+xml Media Type</h2><p>This appendix defines the "application/wspolicy+xml"
media type which can be used to describe Web Services Policy documents
- serialized as XML. Either <code class="attr">wsp:Policy</code> or <code class="attr">wsp:PolicyAttachment</code> could be the root element of such a document.
+ serialized as XML. Either <code>wsp:Policy</code> or <code>wsp:PolicyAttachment</code> could be the root element of such a document.
The "application/wspolicy+xml" media type is being submitted to the
IESG for review, approval, and registration with IANA.
</p><div class="div2">
-<h3><a name="ietf-reg"></a>A.1 Registration</h3><dl><dt class="label">MIME media type name:</dt><dd><p>application</p></dd><dt class="label">MIME subtype name:</dt><dd><p>wspolicy+xml</p></dd><dt class="label">Required parameters:</dt><dd><p>none</p></dd><dt class="label">Optional parameters:</dt><dd><dl><dt class="label">charset</dt><dd><p>This parameter has identical semantics to the charset parameter
+<h3><a name="ietf-reg" id="ietf-reg"></a>A.1 Registration</h3><dl><dt class="label">MIME media type name:</dt><dd><p>application</p></dd><dt class="label">MIME subtype name:</dt><dd><p>wspolicy+xml</p></dd><dt class="label">Required parameters:</dt><dd><p>none</p></dd><dt class="label">Optional parameters:</dt><dd><dl><dt class="label">charset</dt><dd><p>This parameter has identical semantics to the charset parameter
of the "application/xml" media type as specified in
<cite><a href="#RFC3023">IETF RFC 3023</a></cite>.</p></dd></dl></dd><dt class="label">Encoding considerations:</dt><dd><p>Identical to those of "application/xml"
as described in <cite><a href="#RFC3023">IETF RFC 3023</a></cite>,
@@ -1055,8 +1104,8 @@
Web Consortium's
<a href="http://www.w3.org/2002/ws/desc/">Web Service Policy Working Group</a>.
The W3C has change control over these specifications.</p></dd></dl></dd></dl></div></div><div class="div1">
-<h2><a name="References"></a>B. References</h2><div class="div2">
-<h3><a name="Normative-References"></a>B.1 Normative References</h3><dl><dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd>
+<h2><a name="References" id="References"></a>B. References</h2><div class="div2">
+<h3><a name="Normative-References" id="Normative-References"></a>B.1 Normative References</h3><dl><dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd>
<cite><a href="ws-policy-attachment.html">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
P. Yendluri, T. Boubez and Ü. Yalçinalp,
Editors. World Wide Web Consortium, @@,
@@ -1151,7 +1200,7 @@
</dd><dt class="label"><a name="RFC3023"></a>[IETF RFC 3023] </dt><dd>IETF
"RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July
1998. (See <cite><a href="http://www.ietf.org/rfc/rfc3023.txt">http://www.ietf.org/rfc/rfc3023.txt</a></cite>.)</dd></dl></div><div class="div2">
-<h3><a name="Informative-References"></a>B.2 Other References</h3><dl><dt class="label"><a name="C14NNOTE"></a>[C14N 1.0 Note] </dt><dd>
+<h3><a name="Informative-References" id="Informative-References"></a>B.2 Other References</h3><dl><dt class="label"><a name="C14NNOTE"></a>[C14N 1.0 Note] </dt><dd>
<cite><a href="http://www.w3.org/2006/04/c14n-note/c14n-note.html">Known Issues with Canonical XML 1.0 (C14N/1.0)</a></cite>,
J. Kahan and K. Lanz, Editors. World Wide Web
Consortium, 17 August 2006.
@@ -1234,26 +1283,26 @@
version of XML-Signature Syntax and Processing</a> is
available at http://www.w3.org/TR/xmldsig-core/.
</dd></dl></div></div><div class="div1">
-<h2><a name="acknowledgments"></a>C. Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/2002/ws/policy/">W3C Web Services Policy
+<h2><a name="acknowledgments" id="acknowledgments"></a>C. Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/2002/ws/policy/">W3C Web Services Policy
Working Group</a>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip now (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation), Bob Natale (MITRE Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporaton), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
</p><p>
Previous members of the Working Group were:
- Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
+ Jong Lee (BEA Systems, Inc.), Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
</p><p>
The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-ws-policy/">discussions
on public-ws-policy@w3.org</a> are also gratefully
acknowledged.
</p></div><div class="div1">
-<h2><a name="change-description"></a>D. Changes in this Version of the Document (Non-Normative)</h2><p>A list of major editorial changes since the Working Draft dated 17 November, 2006
+<h2><a name="change-description" id="change-description"></a>D. Changes in this Version of the Document (Non-Normative)</h2><p>A list of major editorial changes since the Working Draft dated 17 November, 2006
is below:</p><ul><li><p>Reorganized the content in Section
<a href="#Compact_Policy_Expression"><b>4.3 Compact Policy Expression</b></a>.</p></li><li><p>Documented the schema outline & description for policy operators
- (<code class="elt">wsp:Policy</code> , <code class="elt">wsp:All</code> and <code class="elt">wsp:ExactlyOne</code> elements)
+ (<code>wsp:Policy</code>, <code>wsp:All</code> and <code>wsp:ExactlyOne</code> elements)
in Section <a href="#Policy_Operators"><b>4.3.3 Policy Operators</b></a>.</p></li><li><p>Explicitly described the interaction between Web Services Policy and XML Base in
Section <a href="#IRI_Policy_Expressions"><b>4.6 Use of IRIs in Policy Expressions</b></a>.</p></li></ul></div><div class="div1">
-<h2><a name="change-log"></a>E. Web Services Policy 1.5 - Framework Change Log (Non-Normative)</h2><a name="ws-policy-framework-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060712</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated the list of editors. Completed action items
+<h2><a name="change-log" id="change-log"></a>E. Web Services Policy 1.5 - Framework Change Log (Non-Normative)</h2><a name="ws-policy-framework-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060712</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated the list of editors. Completed action items
<a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action12">12</a>,
<a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action16">16</a> and
<a href="http://www.w3.org/2006/07/12-ws-policy-minutes.html#action20">20</a>
@@ -1385,7 +1434,7 @@
</td></tr><tr><td rowspan="1" colspan="1">20061002</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Completed action item:
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/7">7</a>.
</td></tr><tr><td rowspan="1" colspan="1">20061002</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Implemented the
- <a href="http://www.w3.org/2005/06/tracker/wspolicy/actions/64"></a>
+ <a href="http://www.w3.org/2005/06/tracker/wspolicy/actions/64">http://www.w3.org/2005/06/tracker/wspolicy/actions/64</a>
for issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3559">3559</a>: Conformance Section.
</td></tr><tr><td rowspan="1" colspan="1">20061002</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Implemented the
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -d -r1.25 -r1.26
--- ws-policy-guidelines.html 31 Jan 2007 20:26:25 -0000 1.25
+++ ws-policy-guidelines.html 9 Feb 2007 17:35:24 -0000 1.26
@@ -8,6 +8,12 @@
div.note,
div.notice { margin-left: 2em; }
+ol.enumar { list-style-type: decimal; }
+ol.enumla { list-style-type: lower-alpha; }
+ol.enumlr { list-style-type: lower-roman; }
+ol.enumua { list-style-type: upper-alpha; }
+ol.enumur { list-style-type: upper-roman; }
+
dt.label { display: run-in; }
li, p { margin-top: 0.3em;
@@ -48,12 +54,12 @@
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
-</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"><link rel="contents" href="#contents"></head><body><div class="head">
-<h1>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</h1>
-<h2>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
+</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"></head><body><div class="head">
+<h1><a name="title" id="title"></a>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</h1>
+<h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
<a href="ws-policy-guidelines.html">ws-policy-guidelines.html</a>
</dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mthematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
-<h2><a name="abstract">Abstract</a></h2><p>
+<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
<em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em> is intended to provide guidance for assertion
authors that will work with the Web Services Policy 1.5 - Framework [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>] and Web Services Policy 1.5 - Attachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>] specifications to create domain
specific assertions. The focus of this document is to provide
@@ -61,12 +67,52 @@
the care needed in using WS-Policy to achieve the best
possible results for interoperability. It is a complementary
guide to using the specifications. </p></div><div>
-<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
- no official standing.</strong></p><p></p></div><hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">What is an Assertion? </a><br>3. <a href="#d3e169">Who is involved in authoring Assertions? </a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> Assertion Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br> 43.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br> nbsp; 4.5.1 <a href="#d3e510">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e518">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> 4.8 <a href="#interrelated-domains">Interrelated domains</a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 6.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 6.2 < href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 6.2.1 <a href="#interaction">Interaction between Subjects</a><br> 6.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>7. <a href="#scenario">Scenario and a worked example</a><br></p>
-<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>B. <a href="#xml-namespaces">XML Namespaces</a><br>C. <a href="#references">References</a><br>D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>E. <a href="#change-description">Changes in this Version of
- the Document</a> (Non-Normative)<br>F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
-<h2><a name="introduction"></a>1. Introduction</h2><p>The WS-Policy specification defines a policy to be a collection
+<h2><a name="status" id="status"></a>Status of this Document</h2><p><strong>This document is an editors' copy that has
+ no official standing.</strong></p><p></p></div><div class="toc">
+<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
+2. <a href="#Assertions">What is an Assertion? </a><br>
+3. <a href="#d3e169">Who is involved in authoring Assertions? </a><br>
+ 3.1 <a href="#roles"> Roles and Responsibilities </a><br>
+ 3.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
+ 3.1.2 <a href="#consumers">Consumers</a><br>
+ 3.1.3 <a href="#providers">Providers</a><br>
+4. <a href="#general-guidelines">General Guidelines for Assertion Authors</a><br>
+ 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>
+ 4.2 <a href="#compact-full">Authoring Styles </a><br>
+ 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br>
+ 4.3.1 <a href="#minimal-approach">Minimal approach</a><br>
+ 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br>
+ 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br>
+ 4.3.4 <a href="#single-domains">Single Domains</a><br>
+ 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br>
+ 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
+ 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
+ 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
+ 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
+ 4.5.1 <a href="#d3e510">Optional behavior in Compact authoring</a><br>
+ 4.5.2 <a href="#d3e518">Optional behavior at runtime</a><br>
+ 4.6 <a href="#typing-assertions">Typing Assertions</a><br>
+ 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
+ 4.8 <a href="#interrelated-domains">Interrelated domains</a><br>
+5. <a href="#lifecycle">Lifecycle of Assertions</a><br>
+ 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>
+ 5.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>
+6. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br>
+ 6.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br>
+ 6.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br>
+ 6.2.1 <a href="#interaction">Interaction between Subjects</a><br>
+ 6.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>
+7. <a href="#scenario">Scenario and a worked example</a><br>
+</p>
+<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>
+B. <a href="#xml-namespaces">XML Namespaces</a><br>
+C. <a href="#references">References</a><br>
+D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>
+E. <a href="#change-description">Changes in this Version of
+ the Document</a> (Non-Normative)<br>
+F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br>
+</p></div><hr><div class="body"><div class="div1">
+<h2><a name="introduction" id="introduction"></a>1. Introduction</h2><p>The WS-Policy specification defines a policy to be a collection
of policy alternatives with each policy alternative a
collection of policy assertions. The Web Services Policy 1.5 - Framework provides a flexible framework to
represent
@@ -112,7 +158,7 @@
the Socratic style of beginning with a question, and then answering
the question.
</p></div><div class="div1">
-<h2><a name="Assertions"></a>2. What is an Assertion? </h2><p>An assertion is a piece of metadata that describes a
+<h2><a name="Assertions" id="Assertions"></a>2. What is an Assertion? </h2><p>An assertion is a piece of metadata that describes a
capability related to a specific WS-Policy domain. Sets of domain-specific assertions
are typically defined in a dedicated specification that describes
their semantics, applicability and scoping requirements as well
@@ -172,7 +218,7 @@
best practices will be an assertion specification that describes
a contract for the consumers and providers of the capabilities and constraints of the domain.
</p></div><div class="div1">
-<h2><a name="d3e169"></a>3. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
+<h2><a name="d3e169" id="d3e169"></a>3. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
express their own domain knowledge, it is necessary to provide basic
functionality that all domains could exploit and then allow
points of extension where authors of the various WS-Policy
@@ -184,10 +230,10 @@
privacy policy, QoS characteristics). WS-Policy provides a
single policy grammar to allow both kinds of assertions to be reasoned about in a consistent manner.
</p><div class="div2">
-<h3><a name="roles"></a>3.1 Roles and Responsibilities </h3><p>Below we capture some of the characteristics of the roles
+<h3><a name="roles" id="roles"></a>3.1 Roles and Responsibilities </h3><p>Below we capture some of the characteristics of the roles
and responsibilities for the authors, consumers and providers.
</p><div class="div3">
-<h4><a name="domain-owners"></a>3.1.1 Assertion Authors</h4><p>Assertion Authors are defined
+<h4><a name="domain-owners" id="domain-owners"></a>3.1.1 Assertion Authors</h4><p>Assertion Authors are defined
by the WS-Policy Framework to be a community that chooses to
exploit the WS-Policy Framework by creating their own
specification to define a set of assertions that express the
@@ -225,7 +271,7 @@
engage in a secure exchange of messages." </em>
</p><p>An example of scoping individual assertions to policy subjects is also provided by the WS-Security Policy specification in Appendix A.
</p></div><div class="div3">
-<h4><a name="consumers"></a>3.1.2 Consumers</h4><p>A consumer of WS-Policy
+<h4><a name="consumers" id="consumers"></a>3.1.2 Consumers</h4><p>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
@@ -246,7 +292,7 @@
expressed in a WS-Policy document and modifying their own
configurations dynamically.
</p></div><div class="div3">
-<h4><a name="providers"></a>3.1.3 Providers</h4><p>A provider who expresses capabilities and requirements of a Web service
+<h4><a name="providers" id="providers"></a>3.1.3 Providers</h4><p>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 [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>]
@@ -265,12 +311,12 @@
<cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> that describes service and
policy assertion evolution.
</p></div></div></div><div class="div1">
-<h2><a name="general-guidelines"></a>4. General Guidelines for Assertion Authors</h2><p> As Assertion Authors begin the task of inventing XML dialects to represent policy assertions they can take
+<h2><a name="general-guidelines" id="general-guidelines"></a>4. General Guidelines for Assertion Authors</h2><p> As Assertion Authors begin the task of inventing XML dialects to represent policy assertions they can take
advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy
relies on the QName of a policy assertion being an XML element but allows Assertion Authors to optionally
provide additional semantics through nesting assertions, or specifying assertion parameters.
This section covers several aspects of assertion design and provides some answers to the following questions:</p><ul><li><p>What is the intended use of the policy assertion?</p></li><li><p>Which authoring style will be used?</p></li><li><p>Is this a new policy domain? Does it need to compose with other domains?</p></li><li><p>How complex are the assertions?</p></li><li><p>Is there a need to consider nesting?</p></li><li><p>Do optional behaviors need to be represented?</p></li></ul><div class="div2">
-<h3><a name="assertion-target"></a>4.1 Assertions and Their Target Use</h3><p>Assertion Authors need to have some definition of what the goal is for the assertions
+<h3><a name="assertion-target" id="assertion-target"></a>4.1 Assertions and Their Target Use</h3><p>Assertion Authors need to have some definition of what the goal is for the assertions
they author. Assertion Authors should also understand the
functionality the WS-Policy framework provides and apply the
knowledge of framework processing when defining the set of assertions.
@@ -342,7 +388,7 @@
its presence must interact with other policy assertions
that are defined for security.
</p></li></ul></div><div class="div2">
-<h3><a name="compact-full"></a>4.2 Authoring Styles </h3><p> WS-Policy supports two different authoring styles. A compact form is one in which an expression consists of three
+<h3><a name="compact-full" id="compact-full"></a>4.2 Authoring Styles </h3><p> WS-Policy supports two different authoring styles. A compact form is one in which an expression consists of three
constructs: an attribute to decorate an assertion (to indicate whether it is required or optional), semantics for
recursively nested policy operators, and a policy reference/inclusion mechanism.
</p><div class="exampleOuter"><div class="exampleInner"><pre><wsp:Policy xmlns:wsp='http://www.w3.org/ns/ws-policy'
@@ -402,7 +448,7 @@
readable for humans when an assertion is marked as optional
using the <code>wsp:optional</code> attribute as our example illustrates above.
</p><p>Best practice: use the authoring style most appropriate for the target audience </p></div><div class="div2">
-<h3><a name="new-guidelines-domains"></a>4.3 Considerations when Modeling New Assertions</h3><p>When creating a new policy domain, it is important to
+<h3><a name="new-guidelines-domains" id="new-guidelines-domains"></a>4.3 Considerations when Modeling New Assertions</h3><p>When creating a new policy domain, it is important to
understand how policy expressions are used by a
framework implementation that has followed the specifications.
</p><p>The examples given in this document reference WS-Policy like WS-SecurityPolicy and WS-RM Policy.
@@ -412,7 +458,7 @@
order to enable dynamic negotiation of business requirements
and capabilities at runtime.
</p><div class="div3">
-<h4><a name="minimal-approach"></a>4.3.1 Minimal approach</h4><p>New Assertion Authors are encouraged to try to not overload assertions. A single assertion indicates a single
+<h4><a name="minimal-approach" id="minimal-approach"></a>4.3.1 Minimal approach</h4><p>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.
</p><p>If grouping is utilized, choices between alternatives can be indicated by
@@ -433,7 +479,7 @@
your interoperability needs.
</p><p>Best practice: Start with a simple working assertion that allows extensibility.
</p></div><div class="div3">
-<h4><a name="QName_and_XML_Information_Set_representation"></a>4.3.2 QName and XML Information Set representation</h4><p>Web Services Policy language allows Assertion Authors to invent
+<h4><a name="QName_and_XML_Information_Set_representation" id="QName_and_XML_Information_Set_representation"></a>4.3.2 QName and XML Information Set representation</h4><p>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
@@ -445,7 +491,7 @@
</p><p>Best practice: Use a unique QName to identify the behavior and provide an XML outline
(plus an XML schema document) to specify the syntax of an assertion.
</p></div><div class="div3">
-<h4><a name="self-describing"></a>4.3.3 Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, capabilities, preferences and
+<h4><a name="self-describing" id="self-describing"></a>4.3.3 Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, capabilities, preferences 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
@@ -485,7 +531,7 @@
can be considered when messages cannot be self describing.
</p><p>Best practice: Policy assertions should not be used to express the semantics of a message.
</p></div><div class="div3">
-<h4><a name="single-domains"></a>4.3.4 Single Domains</h4><p>When considering the creation of a
+<h4><a name="single-domains" id="single-domains"></a>4.3.4 Single Domains</h4><p>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
@@ -510,11 +556,11 @@
assertions is appropriate.
</p><p>Best practice: Avoid duplication of assertions.
</p></div></div><div class="div2">
-<h3><a name="comparison"></a>4.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information in an
+<h3><a name="comparison" id="comparison"></a>4.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information in an
assertion beyond its type. We cover these two cases below followed by a
comparison of these approaches targeting when to use either of the approach.
</p><div class="div3">
-<h4><a name="parameterized-assertions"></a>4.4.1 Assertions with Parameters</h4><p>The framework allows WS-Policy domain authors to define
+<h4><a name="parameterized-assertions" id="parameterized-assertions"></a>4.4.1 Assertions with Parameters</h4><p>The framework allows WS-Policy domain authors to define
policy assertion parameters to qualify an assertion.
Policy assertion parameters are defined <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>.
Policy assertion parameters are the opaque payload of an assertion.
@@ -530,7 +576,8 @@
elements are the two assertion parameters of the
<code>sp:SignedParts</code> policy assertion
(this assertion requires the parts of a message to be protected).
- </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 4-3. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><wsp:Policy>
+ </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-3. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><wsp:Policy>
<sp:SignedParts>
<sp:Body/>
<sp:Header/>
@@ -540,7 +587,7 @@
the behavior described by an assertion but not relevant to policy
intersection.
</p></div><div class="div3">
-<h4><a name="nested-assertions"></a>4.4.2 Nested Assertions</h4><p>The framework provides the ability to "nest" policy assertions. For domains with a complex set of
+<h4><a name="nested-assertions" id="nested-assertions"></a>4.4.2 Nested Assertions</h4><p>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 granularity of assertions is
determined by the authors and it is recommended that care be
@@ -575,7 +622,8 @@
the <code>sp:TransportBinding</code> policy assertion (which
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 4-4. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
+ </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-4. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
<Policy>
<sp:TransportToken>
<Policy>
@@ -601,7 +649,7 @@
security usage is absorbed by a policy-aware client and hidden
from Web service application developers.
</p></div><div class="div3">
-<h4><a name="which-one-to-use"></a>4.4.3 Considerations for choosing parameters vs nesting</h4><p>The main consideration for selecting parameters or nesting
+<h4><a name="which-one-to-use" id="which-one-to-use"></a>4.4.3 Considerations for choosing parameters vs nesting</h4><p>The main consideration for selecting parameters or nesting
of assertions is that <em>the framework intersection
algorithm processes nested alternatives, but does not consider
parameters in its algorithm</em>.
@@ -630,8 +678,8 @@
delegated to the specific domain handlers that are not visible
to the WS-Policy framework.
</p></div></div><div class="div2">
-<h3><a name="optional-policy-assertion"></a>4.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e510"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
+<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>4.5 Designating Optional Behaviors</h3><div class="div3">
+<h4><a name="d3e510" id="d3e510"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
compact authoring form for assertions, behaviors are marked by
using <code>wsp:Optional</code> attribute that has a value,
"true". During the process of normalization, the runtime
@@ -642,7 +690,7 @@
runtime behavior. In order to simplify reference to such
assertions, we just use the term optional assertions in this section.
</p></div><div class="div3">
-<h4><a name="d3e518"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
+<h4><a name="d3e518" id="d3e518"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
example that proposes the use of <cite><a href="#MTOM">MTOM</a></cite> as an
optional behavior that can be engaged by a consumer. The
primer proposes that an assertion that identifies the use of
@@ -720,7 +768,7 @@
engaged when they are designing their assertion, whether by
specific headers or some other means. See also <a href="#self-describing"><b>4.3.3 Self Describing Messages </b></a>.
</p></div></div><div class="div2">
-<h3><a name="typing-assertions"></a>4.6 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
+<h3><a name="typing-assertions" id="typing-assertions"></a>4.6 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
identifying a policy assertion, Assertion Authors should be
aware of the possible evolution of their assertions and how
this would impact the semantics of the assertion overtime. A namespace
@@ -751,14 +799,14 @@
precise about their semantics and include information that
restricts their set of permissible policy subjects
appropriately and indicates which QNames are associated with
- which subjects.</p><ol><li><p>Description must clearly and completely specify the syntax (plus an XML Schema
+ which subjects.</p><ol class="enumar"><li><p>Description must clearly and completely specify the syntax (plus an XML Schema
document) and semantics of a policy assertion.</p></li><li><p>If there is a nested policy expression, description must declare it and enumerate the
nested policy assertions that are allowed. </p></li><li><p>A policy alternative may contain multiple instances of the same policy assertion.
Description must specify the semantics of parameters and nested policy (if any) when
there are multiple instances of a policy assertion in the same policy alternative.
</p></li><li><p>If a policy assertion is to be used with WSDL, description must specify a WSDL policy
subject – such as service, endpoint, operation and message.</p></li></ol></div><div class="div2">
-<h3><a name="levels-of-abstraction"></a>4.7 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
+<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>4.7 Levels of Abstraction in WSDL </h3><p>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 must specify a WSDL
policy subject. The policy subject is determined with respect
@@ -828,7 +876,7 @@
policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
</p></div><div class="div2">
-<h3><a name="interrelated-domains"></a>4.8 Interrelated domains</h3><p>Assertion authors need to be clear about how assertions defined in
+<h3><a name="interrelated-domains" id="interrelated-domains"></a>4.8 Interrelated domains</h3><p>Assertion authors need to be clear about how assertions defined in
their domain may fit with assertions for interrelated domains. A
classic example of such an interrelated domain is security, because
security tends to
@@ -840,15 +888,15 @@
assertions and should also make sure that when adding assertions those new assertions are consistent
with pre-existing assertions of any
interrelated domain. </p></div></div><div class="div1">
-<h2><a name="lifecycle"></a>5. Lifecycle of Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
+<h2><a name="lifecycle" id="lifecycle"></a>5. Lifecycle of Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
how they anticipate new assertions being added to the set. There are three aspects that govern an assertions lifecycle:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
or modified constructs. These constructs may be compatible or incompatible with previous versions.
</p><p> Assertion Authors should review the WS-Policy Primer <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
and the specifications <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> <cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>
for details on extensibility.
</p><p> The current WS-Policy language <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> provides extensibility points
- on 6 elements with a combination of attribute and/or element extensibility:</p><ol><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>ExactlyOne, All: element from ##other namespace; no attribute extensibility</p></li><li><p>PolicyReference: any element and any attribute</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li><li><p>URI: any attribute</p></li></ol></li><li><p> Subject attachment Extensibility </p><p>PolicyAttachment and AppliesTo also have extensibility points.</p></li></ul><div class="div2">
-<h3><a name="Referencing_Policy_Expressions"></a>5.1 Referencing Policy Expressions</h3><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> illustrates how
+ on 6 elements with a combination of attribute and/or element extensibility:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>ExactlyOne, All: element from ##other namespace; no attribute extensibility</p></li><li><p>PolicyReference: any element and any attribute</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li><li><p>URI: any attribute</p></li></ol></li><li><p> Subject attachment Extensibility </p><p>PolicyAttachment and AppliesTo also have extensibility points.</p></li></ul><div class="div2">
+<h3><a name="Referencing_Policy_Expressions" id="Referencing_Policy_Expressions"></a>5.1 Referencing Policy Expressions</h3><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> illustrates how
providers can utilize the identification mechanism defined in the Policy specification
to expose a complex policy expression as a reusable building block for
other policy expressions by reference. Assertion
@@ -862,50 +910,52 @@
manageability of the expressions as they are uniquely
identified.
</p></div><div class="div2">
-<h3><a name="extending-assertions"></a>5.2 Evolution of Assertions (Versioning and Compatibility)</h3><p>Over time, there may be multiple equivalent behaviors emerging in the Web
+<h3><a name="extending-assertions" id="extending-assertions"></a>5.2 Evolution of Assertions (Versioning and Compatibility)</h3><p>Over time, there may be multiple equivalent behaviors emerging in the Web
Service interaction space. Examples of such multiple equivalent behaviors are WSS: SOAP Message Security 1.0
vs. 1.1 and WS-Addressing August 2004 version vs. WS-Addressing W3C Recommendation
[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
are mutually exclusive for an interaction. Such equivalent
behaviors can be modeled as independent assertions. The
policy expression in the example below requires the use of
- WSS: SOAP Message Security 1.0. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-1. </span>Message-level Security and WSS: SOAP Message Security 1.0</i></p><div class="exampleInner"><pre><Policy>
+ WSS: SOAP Message Security 1.0. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-1. </span>Message-level Security and WSS: SOAP Message Security 1.0</i></p><div class="exampleInner"><pre><Policy>
<sp:Wss10>…</sp:Wss10>
</Policy></pre></div></div><p>The policy expression in the example below requires the use of WSS: SOAP Message
Security 1.1. These are multiple equivalent behaviors and are represented using distinct
- policy assertions.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-2. </span>Message-level Security and WSS: SOAP Message Security 1.1</i></p><div class="exampleInner"><pre><Policy>
+ policy assertions.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-2. </span>Message-level Security and WSS: SOAP Message Security 1.1</i></p><div class="exampleInner"><pre><Policy>
<sp:Wss11>…</sp:Wss11>
</Policy></pre></div></div><p>Best practice: use independent assertions for modeling multiple equivalent
behaviors.</p></div></div><div class="div1">
-<h2><a name="best-practices-attachment"></a>6. Applying Best Practices for Policy Attachment</h2><div class="div2">
-<h3><a name="context-free-policies"></a>6.1 Appropriate Attachment: Preserving Context-Free Policies</h3><p>Policy attachment should not affect the interpretation of
+<h2><a name="best-practices-attachment" id="best-practices-attachment"></a>6. Applying Best Practices for Policy Attachment</h2><div class="div2">
+<h3><a name="context-free-policies" id="context-free-policies"></a>6.1 Appropriate Attachment: Preserving Context-Free Policies</h3><p>Policy attachment should not affect 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. In particular, the timing of a
policy attachment or the role that a party who attaches
policy should have no bearing on the evaluation of the policy
assertion </p></div><div class="div2">
-<h3><a name="appropriate-attachment-assertion-subjects"></a>6.2 Appropriate Attachment: Identifying Assertion Subjects</h3><p>Each policy attachment mechanism should unambiguously
+<h3><a name="appropriate-attachment-assertion-subjects" id="appropriate-attachment-assertion-subjects"></a>6.2 Appropriate Attachment: Identifying Assertion Subjects</h3><p>Each policy attachment mechanism should unambiguously
identify the subject of the attached assertions. Generally,
this should be a specific SOAP node or a specific message
between two SOAP nodes. Some attachment mechanisms may
encompass multiple notes or messages, for example, "the
message along its entire path". </p><div class="div3">
-<h4><a name="interaction"></a>6.2.1 Interaction between Subjects</h4><p>If the best practices are followed, and the assertions
+<h4><a name="interaction" id="interaction"></a>6.2.1 Interaction between Subjects</h4><p>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). </p></div></div><div class="div2">
-<h3><a name="identifying-assertion-sources"></a>6.3 Appropriate Attachment: Identifying Assertion Sources </h3><p>As with identifying Policy subjects, policy attachment
+<h3><a name="identifying-assertion-sources" id="identifying-assertion-sources"></a>6.3 Appropriate Attachment: Identifying Assertion Sources </h3><p>As with identifying Policy subjects, policy attachment
mechanisms should make it possible to clearly identify the
source of a policy assertion both for debugging and for
verification. This could take several forms: it could be
assumed (in WSDL, the source of the assertion is the same
as the WSDL provider) or it could be proven (using
<cite><a href="#WS-Trust">WS-Trust</a></cite>). </p></div></div><div class="div1">
-<h2><a name="scenario"></a>7. Scenario and a worked example</h2><p>To illustrate the topics explored in this document, we
+<h2><a name="scenario" id="scenario"></a>7. Scenario and a worked example</h2><p>To illustrate the topics explored in this document, we
include an example of a web service and how a fictitious company
might utilize the WS-Policy Framework to enable Web Service
interoperability. Company A has determined to utilize WS-Security,
@@ -928,7 +978,8 @@
the use of transport-level security for protecting messages as
well as including addressing headers. Employees of Company A have
already incorporated <code>wss:Security</code> headers into their
- messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-1. </span>Message with Security Headers</i></p><div class="exampleInner"><pre><soap:Envelope>
+ messages. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 7-1. </span>Message with Security Headers</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
<wss:Security soap:mustUnderstand ="1">
<wsu:Timestamp wsu:Id=_0">
@@ -947,7 +998,8 @@
messages. </p><p>The example below illustrates a policy expression that
CompanyA has created for its employees to use on their web
services to indicate the use of addressing and transport-level
- security for securing messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-2. </span> CompanyA-ProfileA </i></p><div class="exampleInner"><pre>
+ security for securing messages. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 7-2. </span> CompanyA-ProfileA </i></p><div class="exampleInner"><pre>
<Policy URI=http://www.CompanyA.com/WebServicesProfileA.xml>
<wsa:UsingAddressing />
<sp:TransportBinding></sp:TransportBinding>
@@ -975,7 +1027,8 @@
service the ability to provide additional integrity protection by
including WS-Security Headers to protect the message content
after it is processed by the transport. The additional security
- processing is not required by all Company A web services. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-3. </span>CompanyA-ProfileB (not expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
+ processing is not required by all Company A web services. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 7-3. </span>CompanyA-ProfileB (not expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing/>
<ExactlyOne>
<sp:TransportBinding></sp:TransportBinding>
@@ -999,7 +1052,8 @@
represent (ed) these dependent behaviors as "nested" policy
assertions. </p><p>In the example below the child Policy element is a nested
policy behavior and further qualifies the behavior of the
- <code>sp:TransportBinding</code> policy assertion. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-4. </span>CompanyA-ProfileB (fully expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
+ <code>sp:TransportBinding</code> policy assertion. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 7-4. </span>CompanyA-ProfileB (fully expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing/>
<ExactlyOne>
<sp:TransportBinding>
@@ -1046,12 +1100,14 @@
specification and attach the policies to the web service endpoint
policy subject as recommended by the WS-SecurityPolicy
specification. For the default web services, the URI is included
- in the wsdl binding for each web service. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-5. </span></i></p><div class="exampleInner"><pre><wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault">
+ in the wsdl binding for each web service. </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 7-5. </span></i></p><div class="exampleInner"><pre><wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault">
<wsp:PolicyReference URI="http://www.CompanyA.com/WebServicesProfileA.xml">
<wsdl:operation name="GetQuote"> </wsdl:operation>
</wsdl:binding></pre></div></div><p>The partner specified policy is included in the beginning of
the WSDL 1.1 document and referenced by the binding for the service
- as in the example below.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-6. </span></i></p><div class="exampleInner"><pre>
+ as in the example below.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 7-6. </span></i></p><div class="exampleInner"><pre>
<wsdl:definitions name="StockQuote"
targetNamespace="http:..">
<wsp:Policy wsu:Id="CompanyA-ProfileB">
@@ -1087,8 +1143,8 @@
calculation of an effective policy and this also indicates they need
to consider policy subjects.</p><p>The policy framework only defines an algorithm for calculating
effective policies for WSDL 1.1 based subjects. </p></div></div><div class="back"><div class="div1">
-<h2><a name="security-considerations"></a>A. Security Considerations</h2><p> Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
-<h2><a name="xml-namespaces"></a>B. XML Namespaces</h2><p>The table below lists XML Namespaces that are used in this document. The choice of any
+<h2><a name="security-considerations" id="security-considerations"></a>A. Security Considerations</h2><p> Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
+<h2><a name="xml-namespaces" id="xml-namespaces"></a>B. XML Namespaces</h2><p>The table below lists XML Namespaces that are used in this document. The choice of any
namespace prefix is arbitrary and not semantically significant.</p><a name="nsprefix"></a><table summary="Prefixes and XML Namespaces used in this specification" border="1" cellspacing="0" cellpadding="5"><caption>Table B-1. Prefixes and XML Namespaces used in this specification.</caption><thead><tr><th rowspan="1" colspan="1">Prefix</th><th rowspan="1" colspan="1">XML Namespace</th><th rowspan="1" colspan="1">Specifications</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">
<code>soap</code>
</td><td rowspan="1" colspan="1">
@@ -1122,7 +1178,7 @@
</td><td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</code>
</td><td rowspan="1" colspan="1">[<cite><a href="#WS-Security2004">WS-Security 2004</a></cite>]</td></tr></tbody></table><br></div><div class="div1">
-<h2><a name="references"></a>C. References</h2><dl><dt class="label"><a name="MTOM"></a>[MTOM] </dt><dd>
+<h2><a name="references" id="references"></a>C. References</h2><dl><dt class="label"><a name="MTOM"></a>[MTOM] </dt><dd>
<cite><a href="http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message Transmission Optimization Mechanism</a></cite>, M. Gudgin, N.
Mendelsohn, M. Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25 January
2005. This version of the SOAP Message Transmission Optimization Mechanism Recommendation
@@ -1227,23 +1283,23 @@
<cite><a href="http://www.w3.org/TR/sawsdl/">Semantic Annotations for WSDL and XML Schema</a></cite> Joel Farrell, Holger Lausen, Editors. World Wide Web Consortium, 26 January 2007. This version of the
specification is at http://www.w3.org/TR/sawsdl. The <a href="http://www.w3.org/TR/sawsdl/"> latest version of Semantic Annotations for WSDL and XML Schema</a> is available at
http://www.w3.org/TR/sawsdl/.</dd></dl></div><div class="div1">
-<h2><a name="acknowledgments"></a>D. Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/2002/ws/policy/">W3C Web Services Policy
+<h2><a name="acknowledgments" id="acknowledgments"></a>D. Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/2002/ws/policy/">W3C Web Services Policy
Working Group</a>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip now (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation), Bob Natale (MITRE Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporaton), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
</p><p>
Previous members of the Working Group were:
- Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
+ Jong Lee (BEA Systems, Inc.), Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
</p><p>
The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-ws-policy/">discussions
on public-ws-policy@w3.org</a> are also gratefully
acknowledged.
</p></div><div class="div1">
-<h2><a name="change-description"></a>E. Changes in this Version of
+<h2><a name="change-description" id="change-description"></a>E. Changes in this Version of
the Document (Non-Normative)</h2><p>A list of substantive changes since the Working Draft dated 21 December,
2006 is below:</p><ul><li><p>TBD</p></li></ul></div><div class="div1">
-<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspa="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixes for Frederick's editorial comments (20061025)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Optionality discussion feedback integration</td></tr><tr><td rowspan="1" colspan="1">20061115</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">First attempt at restructuring to include primer content</td></tr><tr><td rowspan="1" colspan="1">20061120</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Restructure to address action items 64,77, which refer to bugzilla 3705 and F2F RESOLUTION 3792 </td></tr><tr><td rowspan="1" colspan="1">20061127</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated the list of editors. Added
+<h2><a name="change-log" id="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rospan="1" colspan="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixes for Frederick's editorial comments (20061025)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Optionality discussion feedback integration</td></tr><tr><td rowspan="1" colspan="1">20061115</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">First attempt at restructuring to include primer content</td></tr><tr><td rowspan="1" colspan="1">20061120</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Restructure to address action items 64,77, which refer to bugzilla 3705 and F2F RESOLUTION 3792 </td></tr><tr><td rowspan="1" colspan="1">20061127</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated the list of editors. Added
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html">Frederick</a> and
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">Umit</a> to the list of editors.
Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86">86</a>.
Index: ws-policy-attachment.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-attachment.html,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -d -r1.87 -r1.88
--- ws-policy-attachment.html 7 Feb 2007 22:34:13 -0000 1.87
+++ ws-policy-attachment.html 9 Feb 2007 17:35:24 -0000 1.88
@@ -8,6 +8,12 @@
div.note,
div.notice { margin-left: 2em; }
+ol.enumar { list-style-type: decimal; }
+ol.enumla { list-style-type: lower-alpha; }
+ol.enumlr { list-style-type: lower-roman; }
+ol.enumua { list-style-type: upper-alpha; }
+ol.enumur { list-style-type: upper-roman; }
+
dt.label { display: run-in; }
[...1087 lines suppressed...]
from the Austin F2F.</td></tr><tr><td rowspan="1" colspan="1">20060712</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Completed action item <a href=" http://www.w3.org/2006/07/12-ws-policy-minutes.html#action12">12</a>
</td></tr><tr><td rowspan="1" colspan="1">20060718</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Completed action items
@@ -1798,7 +1875,7 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3709">3709</a>: Editorial corrections from UDDI team.
</td></tr><tr><td rowspan="1" colspan="1">20060925</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Created <a href="#ws-policy-attachment-for-wsdl20"><b>5. WS-Policy Attachment for WSDL 2.0</b></a> per action item <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/37">2</a> from the
Bellevue F2F. This section is based on a <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0037.html">contribution</a> from BEA, IBM, Microsoft and Oracle.</td></tr><tr><td rowspan="1" colspan="1">20061002</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Implemented the
- <a href="http://www.w3.org/2005/06/tracker/wspolicy/actions/64"></a>
+ <a href="http://www.w3.org/2005/06/tracker/wspolicy/actions/64">http://www.w3.org/2005/06/tracker/wspolicy/actions/64</a>
for issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3559">3559</a>: Conformance Section.
</td></tr><tr><td rowspan="1" colspan="1">20061002</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Implemented the
@@ -1876,7 +1953,7 @@
item </a>(re
issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4226">4226</a>)
to section <a href="#ws-policy-attachment-for-wsdl20"><b>5. WS-Policy Attachment for WSDL 2.0</b></a>: added wsp prefix to <a href="#table-wsdl20-effective-policy-example">Example 5-2</a>
- and all occurrences of <code class="elt">Policy</code> and <code class="elt">PolicyReference</code> .
+ and all occurrences of <code>Policy</code> and <code>PolicyReference</code>.
</td></tr><tr><td rowspan="1" colspan="1">20070123</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Fixed a typo in <a href="#Informative-References"><b>A.2 Other References</b></a>: "[IETF RFC 3023]IETF "RFC 2246:".
</td></tr><tr><td rowspan="1" colspan="1">20070124</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated Section <a href="#change-description"><b>D. Changes in this Version of the Document</b></a>.
</td></tr><tr><td rowspan="1" colspan="1">20070207</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the resolution for issue
Received on Friday, 9 February 2007 17:36:08 UTC