You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3688 lines
157 KiB
3688 lines
157 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang=
|
|
"en-US">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
|
|
<meta http-equiv="Content-Type" content=
|
|
"text/html; charset=utf-8" />
|
|
<title>Web Services Policy 1.5 - Guidelines for Policy Assertion
|
|
Authors</title>
|
|
|
|
<style type="text/css">
|
|
/*<![CDATA[*/
|
|
/**/
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
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;
|
|
margin-bottom: 0.3em; }
|
|
|
|
.diff-chg { background-color: yellow; }
|
|
.diff-del { background-color: red; text-decoration: line-through;}
|
|
.diff-add { background-color: lime; }
|
|
|
|
table { empty-cells: show; }
|
|
|
|
table caption {
|
|
font-weight: normal;
|
|
font-style: italic;
|
|
text-align: left;
|
|
margin-bottom: .5em;
|
|
}
|
|
|
|
div.issue {
|
|
color: red;
|
|
}
|
|
.rfc2119 {
|
|
font-variant: small-caps;
|
|
}
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
div.boxedtext {
|
|
border: solid #bebebe 1px;
|
|
margin: 2em 1em 1em 2em;
|
|
}
|
|
|
|
span.practicelab {
|
|
margin: 1.5em 0.5em 1em 1em;
|
|
font-weight: bold;
|
|
font-style: italic;
|
|
}
|
|
|
|
span.practicelab { background: #dfffff; }
|
|
|
|
span.practicelab {
|
|
position: relative;
|
|
padding: 0 0.5em;
|
|
top: -1.5em;
|
|
}
|
|
p.practice
|
|
{
|
|
margin: 1.5em 0.5em 1em 1em;
|
|
}
|
|
|
|
@media screen {
|
|
p.practice {
|
|
position: relative;
|
|
top: -2em;
|
|
padding: 0;
|
|
margin: 1.5em 0.5em -1em 1em;
|
|
}
|
|
}
|
|
/**/
|
|
/*]]>*/
|
|
</style>
|
|
<link rel="stylesheet" type="text/css" href=
|
|
"http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" />
|
|
</head>
|
|
<body>
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width=
|
|
"72" /></a></p>
|
|
<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>W3C Working Group
|
|
Note 12 November 2007</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112">http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/ws-policy-guidelines">http://www.w3.org/TR/ws-policy-guidelines</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070928">http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070928</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 (A subsidiary of Software AG)</dd>
|
|
<dd>Toufic Boubez, Layer 7 Technologies</dd>
|
|
<dd>Ümit Yalçinalp, SAP AG.</dd>
|
|
</dl>
|
|
<p>This document is also available in these non-normative formats:
|
|
<a href="ws-policy-guidelines.pdf">PDF</a>, <a href=
|
|
"ws-policy-guidelines.ps">PostScript</a>, <a href=
|
|
"ws-policy-guidelines.xml">XML</a>, and <a href=
|
|
"ws-policy-guidelines.txt">plain text</a>.</p>
|
|
<p class="copyright"><a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 <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" 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 best practices
|
|
and patterns to follow as well as illustrate 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" id="status"></a>Status of this Document</h2>
|
|
<p><em>This section describes the status of this document at the
|
|
time of its publication. Other documents may supersede this
|
|
document. A list of current W3C publications and the latest
|
|
revision of this technical report can be found in the <a href=
|
|
"http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em></p>
|
|
<p>This is a <a href=
|
|
"http://www.w3.org/2004/02/Process-20040205/tr#WGNote">W3C Working
|
|
Group Note</a> of the Web Services Policy 1.5 - Guidelines for
|
|
Policy Assertion Authors specification, developed by the members of
|
|
the <a href="http://www.w3.org/2002/ws/policy/">Web Services Policy
|
|
Working Group</a>, which is part of the <a href=
|
|
"http://www.w3.org/2002/ws/Activity">W3C Web Services
|
|
Activity</a>.</p>
|
|
<p>A list of <a href="#change-description">changes in this version
|
|
of the document</a> and a <a href=
|
|
"ws-policy-guidelines-diff20070928.html">diff-marked version
|
|
against the previous version of this document</a> are available.
|
|
Please send comments about this document to the <a href=
|
|
"mailto:public-ws-policy-comments@w3.org">public-ws-policy-comments@w3.org</a>
|
|
mailing list (<a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy-comments/">public
|
|
archive</a>) with a subject that is prefaced with
|
|
[ws-policy-guidelines].</p>
|
|
<p>Publication as a Working Group Note does not imply endorsement
|
|
by the W3C Membership. This is a draft document and may be updated,
|
|
replaced or obsoleted by other documents at any time. It is
|
|
inappropriate to cite this document as other than work in
|
|
progress.</p>
|
|
<p>This document was produced by a group operating under the
|
|
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
|
|
February 2004 W3C Patent Policy</a>. W3C maintains a <a href=
|
|
"http://www.w3.org/2004/01/pp-impl/39293/status">public list of any
|
|
patent disclosures</a> made in connection with the deliverables of
|
|
the group; that page also includes instructions for disclosing a
|
|
patent. An individual who has actual knowledge of a patent which
|
|
the individual believes contains <a href=
|
|
"http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
|
|
Essential Claim(s)</a> must disclose the information in accordance
|
|
with <a href=
|
|
"http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
|
|
section 6 of the W3C Patent Policy</a>.</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="#best-practices-list">List of Best Practice
|
|
Statements</a><br />
|
|
3. <a href="#Assertions">What is an Assertion?</a><br />
|
|
4. <a href="#assertion-authors">Who is involved in authoring
|
|
Assertions?</a><br />
|
|
4.1 <a href="#roles">Roles and
|
|
Responsibilities</a><br />
|
|
4.1.1 <a href=
|
|
"#domain-owners">Assertion Authors</a><br />
|
|
4.1.2 <a href=
|
|
"#consumers">Consumers</a><br />
|
|
4.1.3 <a href=
|
|
"#providers">Providers</a><br />
|
|
5. <a href="#general-guidelines">General Guidelines for Assertion
|
|
Authors</a><br />
|
|
5.1 <a href="#assertion-target">Assertions
|
|
and Their Target Use</a><br />
|
|
5.2 <a href="#compact-full">Authoring
|
|
Styles</a><br />
|
|
5.3 <a href=
|
|
"#new-guidelines-domains">Considerations when Modeling New
|
|
Assertions</a><br />
|
|
5.3.1 <a href=
|
|
"#minimal-approach">Minimal approach</a><br />
|
|
5.3.2 <a href=
|
|
"#QName_and_XML_Information_Set_representation">QName and XML
|
|
Information Set representation</a><br />
|
|
5.3.3 <a href=
|
|
"#self-describing">Self Describing Messages</a><br />
|
|
5.3.4 <a href=
|
|
"#single-domains">Single Domains</a><br />
|
|
5.3.5 <a href=
|
|
"#order-of-behaviors">Order of Behaviors</a><br />
|
|
5.4 <a href="#comparison">Comparison of
|
|
Nested and Parameterized Assertions</a><br />
|
|
5.4.1 <a href=
|
|
"#parameterized-assertions">Assertions with Parameters</a><br />
|
|
5.4.2 <a href=
|
|
"#nested-assertions">Nested Assertions</a><br />
|
|
5.5 <a href="#Ignorable">Designating
|
|
Ignorable Behavior</a><br />
|
|
5.5.1 <a href=
|
|
"#d3e882">Ignorable behavior in authoring</a><br />
|
|
5.5.2 <a href=
|
|
"#d3e895">Ignorable behavior at runtime</a><br />
|
|
5.6 <a href=
|
|
"#optional-policy-assertion">Designating Optional
|
|
Behaviors</a><br />
|
|
5.6.1 <a href=
|
|
"#d3e910">Optional behavior at runtime</a><br />
|
|
5.7 <a href=
|
|
"#levels-of-abstraction">Considerations for Policy
|
|
Attachment</a><br />
|
|
5.7.1 <a href=
|
|
"#general-attachment-guidelines">General Guidelines</a><br />
|
|
5.7.2 <a href=
|
|
"#wsdl-attachment-guidelines">Considerations for Policy Attachment
|
|
in WSDL</a><br />
|
|
5.7.3 <a href=
|
|
"#UDDI-attachment-guidelines">Considerations for Policy Attachment
|
|
in UDDI</a><br />
|
|
5.8 <a href=
|
|
"#interrelated-domains">Interrelated domains</a><br />
|
|
6. <a href="#versioning-policy-assertions">Versioning Policy
|
|
Assertions</a><br />
|
|
6.1 <a href=
|
|
"#Referencing_Policy_Expressions">Referencing Policy
|
|
Expressions</a><br />
|
|
6.2 <a href=
|
|
"#extending-assertions">Evolution of Assertions (Versioning and
|
|
Compatibility)</a><br />
|
|
6.3 <a href=
|
|
"#supporting-new-policy-subjects">Supporting New Policy
|
|
Subjects</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. Each policy alternative is a collection of
|
|
policy assertions. The Web Services Policy 1.5 - Framework provides
|
|
a flexible framework to represent consistent combinations of
|
|
behaviors from a variety of domains. A policy assertion is a
|
|
machine readable metadata expression that identifies behaviors
|
|
required for Web services interactions. <em>Web Services Policy 1.5
|
|
- Guidelines for Policy Assertion Authors</em> is a resource
|
|
primarily for Assertion Authors and provides guidelines on the use
|
|
of Web Services Policy 1.5 - Framework and Web Services Policy 1.5
|
|
- Attachment specifications to create and use domain specific
|
|
assertions to enable interoperability.</p>
|
|
<p>WS-Policy Assertions communicate the requirements and
|
|
capabilities of a web service by adhering to the specification,
|
|
WS-Policy Framework. To enable interoperability of web services
|
|
different sets of WS-Policy Assertions need to be defined by
|
|
different communities based upon domain-specific requirements of
|
|
the web service.</p>
|
|
<p>The focus of these guidelines is to capture best practices and
|
|
usage patterns for practitioners. It is a complementary guide to
|
|
the Framework and Attachments specifications and the Primer. It is
|
|
intended to provide non-normative guidelines for WS-Policy
|
|
Assertion Authors who need to know the features of the language and
|
|
understand the requirements for describing policy assertions. Some
|
|
of the guidance for WS-Policy Assertion Authors can also be helpful
|
|
for those who use the policy assertions created by Assertion
|
|
Authors.</p>
|
|
<p>This document assumes a basic understanding of XML, Namespaces
|
|
in XML, WSDL, SOAP and the Web Services Policy language.</p>
|
|
<p>This is a non-normative document and does not provide a
|
|
definitive specification of the Web Services Policy framework.
|
|
<a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all
|
|
the namespace prefixes that are used in this document. (XML
|
|
elements without a namespace prefix are from the Web Services
|
|
Policy XML Namespace.)</p>
|
|
<p>As a companion document to the primer, this document also
|
|
follows the Socratic style of beginning with a question, and then
|
|
answering the question.</p>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="best-practices-list" id="best-practices-list"></a>2.
|
|
List of Best Practice Statements</h2>
|
|
<p>The following Best Practices appear in this document with
|
|
discussion and examples, and are summarized here for quick
|
|
reference:</p>
|
|
<ul>
|
|
<li>
|
|
<p><a href="#bp-compatibility-tests"><b>1. Define assertions
|
|
relevant to compatibility tests</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href=
|
|
"#bp-ignorable-for-not-related-to-compatibility-tests"><b>2. Mark
|
|
Ignorable Assertions not related to compatibility</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-semantics-and-form"><b>3. Semantics Independent of
|
|
the Form</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-assertion-start"><b>4. Start with a Simple
|
|
Assertion</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#XMLOutline"><b>6. Provide an XML
|
|
definition</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#AssertionDefinitions"><b>7. Specify Semantics
|
|
Clearly</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#DefineIgnorable"><b>8. Document Ignorable
|
|
Behavior</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#ignorableAssertions"><b>9. Document Use of the
|
|
Ignorable Attribute in XML</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-assertion-xml-allow-optional"><b>10. Assertion
|
|
Authors should allow use of wsp:Optional</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-not-necessary-to-understand-a-message"><b>11.
|
|
Assertions should not describe message semantics</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-assertion-duplication"><b>12. Avoid Duplication of
|
|
Assertions</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-assertion-parameters"><b>13. Use Parameters for
|
|
Useful Information</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-dependent-behaviors"><b>14. Use Nested Assertions
|
|
for Dependent Behaviors</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-declare-nested-assertions"><b>15. Enumerate Nested
|
|
Assertions</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-discourage-domain-specific-intersection"><b>16.
|
|
Discourage Domain Specific Intersection</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-entire-mep-for-optional"><b>17. Consider entire
|
|
message exchange pattern when specifying Assertions that represent
|
|
optional behavior related to a subset of that message exchange
|
|
pattern when considering appropriate policy subject attachment
|
|
points</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-limitoptional-assertion-use"><b>18. Limit use of an
|
|
Optional Assertion</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-indicate-optional-assertion-use"><b>19. Indicate
|
|
use of an Optional Assertion</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-assertion-semantics"><b>20. Semantics Independent
|
|
of Attachment Mechanisms</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-semantics-multiple-same-type"><b>21. Describe
|
|
Semantics of Multiple Assertions of Same Type</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-leverage-defined-attachment-mechanisms"><b>22.
|
|
Leverage Defined Attachment Mechanisms</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-use-defined-policy-subjects"><b>23. Use Defined
|
|
Policy Subjects</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-identify-policy-subjects"><b>24. Identify Policy
|
|
Subjects</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-WSDL-policy-subject"><b>25. Specify WSDL Policy
|
|
Subject(s)</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-WSDL-consider-scope"><b>26. Consider Scope of
|
|
Attachment Points</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-WSDL-policy-subject-Granularity"><b>27. Choose the
|
|
Most Granular WSDL Policy Subject</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-WSDL-multiple-policy-subjects"><b>28. Define Rules
|
|
for Attachment of an Assertion type to Multiple WSDL policy
|
|
subjects</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-WSDL-preferred-attachment-point"><b>29. Specify
|
|
Preferred WSDL Attachment Point</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-UDDI-tmodels"><b>30. Use defined tModels when
|
|
appropriate</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-specify-composition"><b>31. Specify Composition
|
|
with Related Assertions</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-independent-assertions"><b>32. Independent
|
|
Assertions for Different Versions of a Behavior</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p><a href="#bp-policy-subject-change"><b>33. Document changes to
|
|
policy subject</b></a></p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="Assertions" id="Assertions"></a>3. What is an
|
|
Assertion?</h2>
|
|
<p>An assertion is a piece of metadata that describes a capability
|
|
related to a specific domain that has chosen to express their
|
|
capabilities via the WS-Policy expressions. Sets of domain-specific
|
|
assertions are typically defined in a dedicated specification that
|
|
describes their semantics, applicability and scoping requirements
|
|
as well as their data type definition using XML Schema
|
|
[<cite><a href="#XMLSchemaPart1">XML Schema
|
|
Structures</a></cite>].</p>
|
|
<p>Policy assertions representing shared and visible behaviors are
|
|
useful pieces of metadata to enable interoperability and tooling
|
|
for automation. The key to understanding when to design policy
|
|
assertions is to have clarity on the characteristics of a behavior
|
|
represented by a policy assertion. Some useful ways to discover
|
|
relevant behaviors are to ask questions like the following:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Is this behavior a requirement?</p>
|
|
</li>
|
|
<li>
|
|
<p>Is the behavior visible?</p>
|
|
<p>A visible behavior refers to a requirement that manifests itself
|
|
on the wire. Web services provide interoperable machine-to-machine
|
|
interaction among disparate systems. Web service interoperability
|
|
is the capability of disparate systems to exchange data using
|
|
common data formats and protocols supporting characteristics such
|
|
as messaging, security, reliability and transaction. Such data
|
|
formats and protocols manifest on the wire. Providers and
|
|
requesters rely on wire messages conforming to such formats and
|
|
protocols to achieve interoperability.</p>
|
|
<p>If an assertion describes a behavior that does not manifest on
|
|
the wire then the assertion will not impact the interoperability of
|
|
wire messages, but may still be relevant to enabling an
|
|
interoperable interaction. For example, a provider may not wish to
|
|
interact unless a client can accept an assertion describing
|
|
provider behavior. An example is an assertion that describes the
|
|
privacy notice information of a provider and the associated
|
|
regulatory safeguard in place on the provider's side. For cases
|
|
where the provider does not intend the assertion to impact
|
|
interoperability it may mark it as ignorable.</p>
|
|
<p>If an assertion has no wire or message-level visible behavior
|
|
then the interacting participants may require some sort of
|
|
additional mechanism to indicate compliance with the assertion and
|
|
to enable dispute resolution. Introducing an additional
|
|
non-repudiation mechanism adds unnecessary complexity to processing
|
|
a policy assertion.</p>
|
|
</li>
|
|
<li>
|
|
<p>Does the behavior apply to two or more Web service
|
|
participants?</p>
|
|
<p>A shared behavior refers to a requirement that is relevant to an
|
|
interoperable Web service interaction and involves two or more
|
|
participants. If an assertion only describes one participant's
|
|
behavior the assertion may still be relevant to enabling an
|
|
interoperable interaction. An example is the use of logging or
|
|
auditing by the provider. If an assertion only describes one
|
|
participant's behavior then the assertion may be marked as
|
|
ignorable (indicating it does not impact interoperability). An
|
|
ignorable policy assertion is ignored for lax policy intersection.
|
|
If an assertion is not an ignorable assertion then it is deemed
|
|
important for agreement between both parties.</p>
|
|
</li>
|
|
<li>
|
|
<p>Does the behavior have an implied scoping to a policy subject
|
|
such as service, endpoint, operation and message?</p>
|
|
</li>
|
|
<li>
|
|
<p>Is there a requirement that a choice must be made for successful
|
|
interaction?</p>
|
|
<p>Sometimes providers and requesters are required to engage in
|
|
certain behaviors. The use of optimization and reliable messaging
|
|
are two examples.</p>
|
|
</li>
|
|
</ul>
|
|
<p>There are already many examples in the industry that adhere to
|
|
the above practices, such as <cite><a href="#WS-RM-Policy">Web
|
|
Services Reliable Messaging Policy Assertion</a></cite> and
|
|
<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>.
|
|
Some common characteristics from these documents may be considered
|
|
as <em>best practices</em> for new Assertion Authors:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Specify both the syntax and the semantics of the assertions</p>
|
|
</li>
|
|
<li>
|
|
<p>If nested or parameterized assertions are defined, be clear
|
|
about their usage</p>
|
|
</li>
|
|
<li>
|
|
<p>Describe the policy subjects the assertions can be attached
|
|
to.</p>
|
|
</li>
|
|
</ul>
|
|
<p>In this document we will explain why these practices should be
|
|
followed so that the assertion developers defining such a
|
|
specification will be well informed and able to adequately specify
|
|
assertions for their domain.</p>
|
|
<p>It is expected that consumers of the metadata specified by the
|
|
Assertion Authors will also benefit from understanding these
|
|
practices as it will help them utilize the assertions in the
|
|
context of the WS-Policy framework. A result of following the 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="assertion-authors" id="assertion-authors"></a>4. 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
|
|
assertions for a particular domain can provide additional
|
|
semantics.</p>
|
|
<p>Some policy assertions specify traditional requirements and
|
|
capabilities that will ultimately manifest on the wire (e.g.,
|
|
authentication scheme, transport protocol selection). Other policy
|
|
assertions have no wire manifestation yet are critical to proper
|
|
service selection and usage (e.g., 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" id="roles"></a>4.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" id="domain-owners"></a>4.1.1 Assertion
|
|
Authors</h4>
|
|
<p>Assertion Authors are part of a community that chooses to
|
|
exploit the WS-Policy Framework by creating their own
|
|
specifications to define a set of assertions that express the
|
|
capabilities and constraints of that target domain. The WS-Policy
|
|
Framework is based on a declarative model, meaning that it is
|
|
incumbent on the Assertion Authors to define both the semantics of
|
|
the assertions as well as the scope of their target domain in their
|
|
specification. The set of metadata for any particular domain will
|
|
vary in the granularity of assertion specification required. It is
|
|
the intent of this document to help communities utilize the
|
|
framework in such a way that multiple WS-Policy domains can
|
|
co-exist and consumers and providers can utilize the framework
|
|
consistently across domains.</p>
|
|
<p>Assertion authors should review the conformance sections of the
|
|
WS-Policy Framework and Attachment specifications and an assertion
|
|
must adhere to all the constraints contained in the Framework and
|
|
Attachment specifications.</p>
|
|
<p>Assertion Authors should also specify a policy subject. For
|
|
instance, if a policy assertion were to be used with WSDL, an
|
|
assertion description should specify a WSDL policy subject.</p>
|
|
<p>An example of a domain specification that follows these
|
|
practices is the WS-SecurityPolicy specification [<cite><a href=
|
|
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]. The
|
|
WS-SecurityPolicy authors have defined the scope of their target
|
|
domain (security) as follows:</p>
|
|
<p><em>"This document [WS-SecurityPolicy] defines a set of security
|
|
policy assertions for use with the WS-Policy framework with respect
|
|
to security features provided in WSS: SOAP Message Security,
|
|
WS-Trust and WS-SecureConversation. This document takes the
|
|
approach of defining a base set of assertions that describe how
|
|
messages are to be secured. Flexibility with respect to token
|
|
types, cryptographic algorithms and mechanisms used, including
|
|
using transport level security is part of the design and allows for
|
|
evolution over time. The intent is to provide enough information
|
|
for compatibility and interoperability to be determined by web
|
|
service participants along with all information necessary to
|
|
actually enable a participant to engage in a secure exchange of
|
|
messages."</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" id="consumers"></a>4.1.2 Consumers</h4>
|
|
<p>A consumer of WS-Policy Assertions can be any entity that is
|
|
capable of parsing a WS-Policy XML expression and selecting one
|
|
alternative from the policy. This selected alternative is then used
|
|
to govern the creation of a message to send to the subject to which
|
|
the policy alternative was attached. The WS-Policy Attachment
|
|
specification defines a set of attachment mechanisms for use with
|
|
common web service subjects: WSDL definitions [<cite><a href=
|
|
"#WSDL11">WSDL 1.1</a></cite>, <cite><a href="#WSDL20">WSDL 2.0
|
|
Core Language</a></cite>], and UDDI directory entries
|
|
[<cite><a href="#UDDIAPI20">UDDI API 2.0</a></cite>, <cite><a href=
|
|
"#UDDIDataStructure20">UDDI Data Structure 2.0</a></cite>,
|
|
<cite><a href="#UDDI30">UDDI 3.0</a></cite>].</p>
|
|
<p>In the degenerate case, a human could read the XML and determine
|
|
if a message could be constructed conformant to the advertised
|
|
policy.</p>
|
|
<p>It is expected that consumers of WS-Policy will include a wide
|
|
range of client configurations, from stand alone client
|
|
applications to "active" web service requesters that are capable of
|
|
adapting to the constraints and capabilities expressed in a
|
|
WS-Policy document and modifying their own configurations
|
|
dynamically.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="providers" id="providers"></a>4.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>] and Web Services Policy 1.5 - Attachment
|
|
[<cite><a href="#WS-PolicyAttachment">Web Services Policy
|
|
Attachment</a></cite>] specifications. The Web Services Policy 1.5
|
|
- Attachment specification has defined a set of subjects and an
|
|
extensible mechanism for attaching policies to web services
|
|
subjects.</p>
|
|
<p>When deploying services with policies it is useful for providers
|
|
to anticipate how to evolve their services capabilities over time.
|
|
If forward compatibility is a concern in order to accommodate
|
|
compatibility with different and potentially new clients, providers
|
|
should refer to <a href="#versioning-policy-assertions"><b>6.
|
|
Versioning Policy Assertions</b></a> and <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" id="general-guidelines"></a>5.
|
|
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" id="assertion-target"></a>5.1
|
|
Assertions and Their Target Use</h3>
|
|
<p>Assertion Authors should understand the functionality that the
|
|
WS-Policy framework provides and apply the knowledge of the policy
|
|
framework processing when defining the set of assertions.</p>
|
|
<p>Assertions can be simple or they can be complex. Assertion
|
|
Authors may choose to specify multiple peer assertions, each
|
|
carrying the semantic of a particular behavior, or they may choose
|
|
to specify assertions that contain assertion parameters and/or
|
|
nested policy expressions (nested assertions), where each nested
|
|
assertion of which relates to an aspect of the behavior, yet
|
|
encapsulated within a single assertion. There are advantages to
|
|
simplifying the set of assertions. The ultimate goal of policy is
|
|
to enable interoperability. By keeping assertion design as simple
|
|
as possible, Assertion Authors will more likely be able to meet
|
|
that objective.</p>
|
|
<p>Assertion Authors need to have a specific goal in mind for the
|
|
assertions that they author. Assertion specifications should
|
|
include a detailed specification of the assertion’s semantics and a
|
|
set of valid policy subjects to which the assertion maybe attached.
|
|
The specification should also include the scope of the assertion in
|
|
the context of a particular policy subject. For example, an
|
|
assertion with Endpoint Policy Subject can be scoped to a given
|
|
message exchange with that endpoint, or it can be scoped to all
|
|
messages exchanged with that endpoint. The former case permits a
|
|
client to select a different alternative with each successive
|
|
message exchange. Finally, the ability to combine individual
|
|
assertions may also need to be considered. For example, if an
|
|
assertion applies to the SOAP protocol, it would be necessary to
|
|
consider how its presence must interact with other policy
|
|
assertions that are defined for security.</p>
|
|
<p>Assertion Authors should include the following items in an
|
|
assertion specification:</p>
|
|
<ul>
|
|
<li>
|
|
<p>The definition of the assertion's semantic (See best practice
|
|
<a href="#AssertionDefinitions"><b>7. Specify Semantics
|
|
Clearly</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The specification of the set of valid policy subjects to which
|
|
an assertion may be attached (See best practice <a href=
|
|
"#bp-WSDL-policy-subject"><b>25. Specify WSDL Policy
|
|
Subject(s)</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The scope of the assertion in the context of a particular policy
|
|
subject (See best practices in Section <a href=
|
|
"#levels-of-abstraction"><b>5.7 Considerations for Policy
|
|
Attachment</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>Any composition considerations if the assertion is used with
|
|
other assertions in a context (See best practice <a href=
|
|
"#bp-specify-composition"><b>31. Specify Composition with Related
|
|
Assertions</b></a>).</p>
|
|
</li>
|
|
</ul>
|
|
<p>The WS-Policy Attachment specification defines a number of
|
|
different policy subjects to which an assertion can be attached.
|
|
For attaching to WSDL subjects see <a href=
|
|
"#levels-of-abstraction"><b>5.7 Considerations for Policy
|
|
Attachment</b></a> for more detail. Additionally, the framework
|
|
provides for the means to extend the set of policy subjects beyond
|
|
the set of subjects defined in the WS-Policy Attachment
|
|
specification.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-compatibility-tests" id=
|
|
"bp-compatibility-tests"></a><span class="practicelab">Best
|
|
Practice 1: Define assertions relevant to compatibility
|
|
tests</span></p>
|
|
<p class="practice">Assertion authors should define assertions for
|
|
behaviors that are relevant to compatibility assessment, such as
|
|
web service protocols that manifest on the wire.</p>
|
|
</div>
|
|
<p>Assertion authors may define assertions that are not related to
|
|
compatibility assessment. These assertions may be used to
|
|
accurately describe behaviour, even if they do not affect
|
|
compatibility. WS-Policy has the wsp:Ignorable attribute that may
|
|
be used for indicating assertions that are not related to
|
|
compatibility assessment, described in <a href="#Ignorable"><b>5.5
|
|
Designating Ignorable Behavior</b></a></p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-ignorable-for-not-related-to-compatibility-tests"
|
|
id="bp-ignorable-for-not-related-to-compatibility-tests"></a><span class="practicelab">Best
|
|
Practice 2: Mark Ignorable Assertions not related to
|
|
compatibility</span></p>
|
|
<p class="practice">Assertion authors should recommend that
|
|
assertions that are not relevant to compatibility assessment be
|
|
marked with the wsp:Ignorable attribute.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="compact-full" id="compact-full"></a>5.2 Authoring
|
|
Styles</h3>
|
|
<p>WS-Policy supports two different authoring styles, compact form
|
|
and normal form. 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. A policy expression in the compact
|
|
form can be translated into its normal form using the policy
|
|
normalization algorithm described in the Web Service Policy
|
|
Framework (see section 4.3 Compact Policy Expression).</p>
|
|
<p>The two forms of a policy expression are semantically
|
|
equivalent. When multiple alternatives are present in a policy, the
|
|
normal form may express the choices more explicitly. On the other
|
|
hand, the compact form may be more readable for humans when an
|
|
assertion is marked as optional using the <code>wsp:optional</code>
|
|
attribute. A policy processor may normalize a policy expression
|
|
originally authored in compact form at any time without changing
|
|
the semantics of the policy. In general, it is not possible to
|
|
guarantee in what form a policy expression would be when it is
|
|
processed. As a result, the description for a policy assertion
|
|
should not depend on the style used to author a policy expression
|
|
that contains the assertion.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-semantics-and-form" id=
|
|
"bp-semantics-and-form"></a><span class="practicelab">Best Practice
|
|
3: Semantics Independent of the Form</span></p>
|
|
<p class="practice">The semantics of an assertion should be
|
|
independent of the form (compact or normal form) of policy
|
|
expressions that contain the assertion.</p>
|
|
</div>
|
|
<p>In the example below, the policy expression is shown in its two
|
|
forms, compact and normal. In compact form, the
|
|
<code>wsrmp:RMAssertion</code> assertion is augmented by the
|
|
<code>wsp:Optional="true"</code> attribute. While the compact form
|
|
of the expression might be more human readable, the semantics of
|
|
the particular assertion are independent of the form and of the
|
|
presence (or absence) of the <code>wsp:optional</code>
|
|
attribute.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-1.</span> Policy Expression in Compact Form</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy xmlns:wsp='http://www.w3.org/ns/ws-policy'
|
|
xmlns:sp='http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
|
|
xmlns:wsrmp='http://docs.oasis-open.org/ws-rx/wsrmp/200608'>
|
|
<wsrmp:RMAssertion wsp:Optional="true"/>
|
|
<wsp:ExactlyOne>
|
|
<wsp:All>
|
|
<sp:TransportBinding>
|
|
<wsp:Policy>
|
|
<sp:TransportToken>
|
|
<wsp:Policy>
|
|
<sp:HttpsToken>
|
|
<wsp:Policy>
|
|
<sp:RequireClientCertificate/>
|
|
</wsp:Policy>
|
|
</sp:HttpsToken>
|
|
</wsp:Policy>
|
|
</sp:TransportToken>
|
|
</wsp:Policy>
|
|
</sp:TransportBinding>
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-2.</span> Policy Expression in Normal Form</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy xmlns:wsp='http://www.w3.org/ns/ws-policy'
|
|
xmlns:sp='http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
|
|
xmlns:wsrmp='http://docs.oasis-open.org/ws-rx/wsrmp/200608'>
|
|
<wsp:ExactlyOne>
|
|
<wsp:All>
|
|
<wsrmp:RMAssertion/>
|
|
<sp:TransportBinding>
|
|
<wsp:Policy>
|
|
<sp:TransportToken>
|
|
<wsp:Policy>
|
|
<sp:HttpsToken>
|
|
<wsp:Policy>
|
|
<sp:RequireClientCertificate/>
|
|
</wsp:Policy>
|
|
</sp:HttpsToken>
|
|
</wsp:Policy>
|
|
</sp:TransportToken>
|
|
</wsp:Policy>
|
|
</sp:TransportBinding>
|
|
</wsp:All>
|
|
|
|
<wsp:All>
|
|
<sp:TransportBinding>
|
|
<wsp:Policy>
|
|
<sp:TransportToken>
|
|
<wsp:Policy>
|
|
<sp:HttpsToken>
|
|
<wsp:Policy>
|
|
<sp:RequireClientCertificate/>
|
|
</wsp:Policy>
|
|
</sp:HttpsToken>
|
|
</wsp:Policy>
|
|
</sp:TransportToken>
|
|
</wsp:Policy>
|
|
</sp:TransportBinding>
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="new-guidelines-domains" id=
|
|
"new-guidelines-domains"></a>5.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 are based on existing
|
|
assertions such as WS-SecurityPolicy and WS-RM Policy. These policy
|
|
expressions represent web services message exchange requirements,
|
|
but policy authoring can be done by individual groups that wish to
|
|
represent web services application requirements and deployments
|
|
that wish to reuse the WS-Policy framework in order to enable
|
|
dynamic negotiation of business requirements and capabilities at
|
|
runtime.</p>
|
|
<div class="div3">
|
|
<h4><a name="minimal-approach" id="minimal-approach"></a>5.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.</p>
|
|
<p>If grouping is utilized, choices between such groupings can be
|
|
indicated by an "ExactlyOne" operator. This basic set of operators
|
|
allows Assertion Authors a wide range of options for expressing the
|
|
possible combinations of assertions within their domain.</p>
|
|
<p>It requires a good deal of effort to evaluate the capabilities
|
|
of a domain and capture them in a way that reflects the options of
|
|
the domain if the domain has a lot of assertions to define.
|
|
Interoperability testing of new policy domains is recommended to
|
|
ensure that consumers and providers are able to use the new domain
|
|
assertions. To facilitate proper progression of an assertion,
|
|
Assertion Authors should start with a simple working assertion that
|
|
allows extensibility. As the design work progresses, one may add
|
|
more parameters or nested policy assertions to meet one's
|
|
interoperability needs.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-assertion-start" id=
|
|
"bp-assertion-start"></a><span class="practicelab">Best Practice 4:
|
|
Start with a Simple Assertion</span></p>
|
|
<p class="practice">Assertion Authors should start with a simple
|
|
working assertion that allows assertion parameter
|
|
extensibility.</p>
|
|
</div>
|
|
<p>New Assertion Authors are encouraged to look at <cite><a href=
|
|
"#WS-RM-Policy">Web Services Reliable Messaging Policy
|
|
Assertion</a></cite> to see an example of a relatively simple
|
|
domain that has defined three assertions. Assertion Authors are
|
|
encouraged to look at <cite><a href=
|
|
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example
|
|
of a complex domain that has been decomposed into a set of policy
|
|
expressions.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="QName_and_XML_Information_Set_representation" id=
|
|
"QName_and_XML_Information_Set_representation"></a>5.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 represent an
|
|
assertion parameter as a child element (by leveraging natural XML
|
|
nesting) or an attribute of an assertion. The general guidelines on
|
|
when to use XML elements versus attributes apply. Use a unique
|
|
QName to identify a distinct behavior.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-unique-qnames" id=
|
|
"bp-unique-qnames"></a><span class="practicelab">Best Practice 5:
|
|
Use Unique QNames</span></p>
|
|
<p class="practice">Assertion Authors should use a unique QName to
|
|
identify a distinct behavior.</p>
|
|
</div>
|
|
<div class="boxedtext">
|
|
<p><a name="XMLOutline" id="XMLOutline"></a><span class=
|
|
"practicelab">Best Practice 6: Provide an XML definition</span></p>
|
|
<p class="practice">Assertion authors should provide an XML schema
|
|
definition to specify the syntax of an assertion. A reader-friendly
|
|
description such as an XML outline (see below) is also useful.</p>
|
|
</div>
|
|
<p>An example of a specification that provides an XML Outline is
|
|
the Web Services Reliable Messaging Policy document [<cite><a href=
|
|
"#WS-RM-Policy">Web Services Reliable Messaging Policy
|
|
Assertion</a></cite>]. The definition of the outline syntax used in
|
|
that specification is found in its Terminology section (1.1). As an
|
|
example of the outline syntax in use, the following outline has
|
|
been copied from the aforementioned specification.</p>
|
|
<div class="exampleOuter">
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsrmp:RMAssertion [wsp:Optional="true"]? ...>
|
|
<wsp:Policy >
|
|
[ <wsrmp:SequenceSTR/> |
|
|
<wsrmp:SequenceTransportSecurity/> ] ?
|
|
<wsrmp:DeliveryAssurance/>
|
|
<wsp:Policy >
|
|
[ <wsrmp:ExactlyOnce/> |
|
|
<wsrmp:AtLeastOnce/> |
|
|
<wsrmp:AtMostOnce/> ]
|
|
<wsrmp:InOrder/> ?
|
|
</wsp:Policy>
|
|
</wsrmp:DeliveryAssurance> ] ?
|
|
</wsp:Policy>
|
|
</wsrmp:RMAssertion/>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>The syntax of an assertion can be represented using an XML
|
|
outline (plus an XML schema document). If the assertion has a
|
|
nested policy expression then the assertion XML outline can
|
|
enumerate the nested assertions that are allowed. An example is the
|
|
following:</p>
|
|
<div class="exampleOuter">
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<sp:IssuedToken sp:IncludeToken="xs:anyURI"? ... >
|
|
<sp:Issuer> wsa:EndpointReferenceType</sp:Issuer>?
|
|
<sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? >
|
|
...
|
|
</sp:RequestSecurityTokenTemplate >
|
|
<wsp:Policy >
|
|
<sp:RequireDerivedKeys /> ?
|
|
<sp:RequireExternalReference /> ?
|
|
<sp:RequireInternalReference /> ?
|
|
...
|
|
</wsp:Policy> ?
|
|
...
|
|
</sp:IssuedToken>
|
|
|
|
|
|
</pre></div>
|
|
</div>
|
|
<div class="boxedtext">
|
|
<p><a name="AssertionDefinitions" id=
|
|
"AssertionDefinitions"></a><span class="practicelab">Best Practice
|
|
7: Specify Semantics Clearly</span></p>
|
|
<p class="practice">Assertion authors should clearly and completely
|
|
specify the semantics of a policy assertion.</p>
|
|
</div>
|
|
<div class="boxedtext">
|
|
<p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class=
|
|
"practicelab">Best Practice 8: Document Ignorable
|
|
Behavior</span></p>
|
|
<p class="practice">An assertion description should include
|
|
guidance as to the use of (or constraint against the use of) the
|
|
wsp:Ignorable attribute to indicate whether or not the behavior
|
|
indicated by the QName may be ignored by policy intersection.</p>
|
|
</div>
|
|
<div class="boxedtext">
|
|
<p><a name="ignorableAssertions" id=
|
|
"ignorableAssertions"></a><span class="practicelab">Best Practice
|
|
9: Document Use of the Ignorable Attribute in XML</span></p>
|
|
<p class="practice">An Assertion Author should document, in the XML
|
|
outline and/or schema for the assertion, whether or not the
|
|
assertion allows for the use of the wsp:Ignorable attribute.</p>
|
|
</div>
|
|
<p>The Policy Framework provides two modes of authoring policy
|
|
expressions: compact and normal form. One of the mechanisms that
|
|
the Policy Framework provides to policy authors for purposes of
|
|
writing compact policy expressions is the <code>wsp:Optional</code>
|
|
attribute. Assertion Authors should allow for the use of the
|
|
<code>wsp:Optional</code> attribute in the XML outline and/or
|
|
schema definition of an assertion as this will allow policy
|
|
expression authors to compose compact policy expressions.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-assertion-xml-allow-optional" id=
|
|
"bp-assertion-xml-allow-optional"></a><span class=
|
|
"practicelab">Best Practice 10: Assertion Authors should allow use
|
|
of wsp:Optional</span></p>
|
|
<p class="practice">An assertion's XML outline and/or schema
|
|
definition should allow the use of the wsp:Optional attribute so as
|
|
to enable policy authors to compose compact policy expressions.</p>
|
|
</div>
|
|
<p>For example, consider the following two equivalent policy
|
|
expressions:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-5.</span> Normal form expression:</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<wsp:ExactlyOne>
|
|
<wsp:All>
|
|
<wsam:Addressing>
|
|
<wsp:Policy/>
|
|
</wsam:Addressing>
|
|
</wsp:All>
|
|
<wsp:All>
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-6.</span> Compact form expression:</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<wsam:Addressing wsp:Optional="true">
|
|
<wsp:Policy/>
|
|
</wsam:Addressing>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>If the assertion author had not provided for the
|
|
<code>wsp:Optional</code> attribute to be included on the
|
|
assertion, then policy expression authors would be forced to
|
|
express the optionality of a behavior as two explicit policy
|
|
alternatives, one with and one without that assertion when
|
|
including assertions of that type in their policies.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="self-describing" id="self-describing"></a>5.3.3 Self
|
|
Describing Messages</h4>
|
|
<p>WS-Policy is intended to communicate the requirements,
|
|
capabilities and behaviors of nodes that provide the message's
|
|
path, not specifically to declare properties of the message
|
|
semantics. One of the advantages of Web services is that an XML
|
|
message can be stored and later examined (e.g. as a record of a
|
|
business transaction) or interpreted by an intermediary; however,
|
|
if information that is necessary to understand a message is not
|
|
available, these capabilities suffer.</p>
|
|
<p>Policy assertions should not be used to express the semantics of
|
|
a message. Rather, if a property is required to understand a
|
|
message, it should be communicated in the message, or be made
|
|
available by some other means (e.g., being referenced by a URI in
|
|
the message) instead of being communicated as a policy element.
|
|
Note that there are other specifications that target specification
|
|
of semantics of a message, such as <cite><a href=
|
|
"#SAWSDL">SAWSDL</a></cite>.</p>
|
|
<p>If the messages could not be made self describing by utilizing
|
|
additional properties present in the message as required by the
|
|
assertion, it would be necessary to determine the behaviors engaged
|
|
at runtime by additional means. A general protocol that aids in
|
|
determining such behaviors may be utilized, however a standard
|
|
protocol for this purpose is currently not available to ensure
|
|
interoperability. Thus, a private protocol should be used with
|
|
care.</p>
|
|
<p>Another approach is to use of the assertion to selectively apply
|
|
to subjects. For example, a dedicated endpoint may be allocated to
|
|
ensure the engagement of a behavior that is expressed by a policy
|
|
assertion. This approach can be considered when messages cannot be
|
|
self describing.</p>
|
|
<p>Policy assertions should not be used to express the semantics of
|
|
a message. Firstly, an assertion type indicates a <em>runtime</em>
|
|
behavior. Secondly, Assertion Authors need to indicate how the
|
|
runtime behavior represented in the assertion type can be inferred
|
|
or indicated from a message at runtime. If there is a need for the
|
|
behavior to be represented in a persistent way or if there is a
|
|
need for additional data or metadata that is present in a message
|
|
to be persisted, it should be incorporated into the assertion
|
|
design or in the message itself. In essence, the Assertion Authors
|
|
should consider how to make messages self describing when utilizing
|
|
their assertions by specifying additional properties, headers, etc.
|
|
that must be present in a message as part of their assertion
|
|
design.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-not-necessary-to-understand-a-message" id=
|
|
"bp-not-necessary-to-understand-a-message"></a><span class=
|
|
"practicelab">Best Practice 11: Assertions should not describe
|
|
message semantics</span></p>
|
|
<p class="practice">Assertion Authors should not define policy
|
|
assertions to represent information that is necessary to understand
|
|
a message.</p>
|
|
</div>
|
|
<p>For example, if the details of a message's encryption ( e.g.,
|
|
the cipher used, etc) are expressed in policy that isn't attached
|
|
to the message, it isn't possible to later decipher it. This is
|
|
very different from expressing, in policy, what ciphers (and so
|
|
forth) are supported by a particular endpoint, or those that are
|
|
required in a particular message; the latter are the intended uses
|
|
of the WS-Policy framework.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="single-domains" id="single-domains"></a>5.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 expresses a broad set of capabilities will
|
|
also need to have a community supporting implementations of these
|
|
capabilities to provide value to the consumers. Ultimately it is
|
|
the consumers and providers that will determine whether a
|
|
particular set of assertions correctly characterize a domain. A new
|
|
community should avoid duplicating assertions that have already
|
|
been defined as this will create ambiguity not clarification. New
|
|
Assertion Authors should focus on creating assertions for those
|
|
specific constraints and capabilities that do not overlap with
|
|
other domains but that communicate new functionality.</p>
|
|
<p>The model advocated for new assertion development is a
|
|
cooperative marketplace [some might say it is an "opt-in" model].
|
|
The providers of services need to find value in the set of
|
|
assertions or they will not include the assertions in their service
|
|
descriptions.</p>
|
|
<p>It is the responsibility of the Assertion Authors to avoid
|
|
duplication of assertions. A review by a broad community is the
|
|
best way to ensure that the granularity of a set of domain
|
|
assertions is appropriate.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-assertion-duplication" id=
|
|
"bp-assertion-duplication"></a><span class="practicelab">Best
|
|
Practice 12: Avoid Duplication of Assertions</span></p>
|
|
<p class="practice">Assertion Authors should reuse an existing
|
|
assertion (rather than create a new one) whenever possible.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="order-of-behaviors" id="order-of-behaviors"></a>5.3.5
|
|
Order of Behaviors</h4>
|
|
<p>A policy alternative is a collection of zero or more policy
|
|
assertions. Assertions within a policy alternative are not
|
|
ordered.</p>
|
|
<p>The order of assertions in a policy alternative and order in
|
|
which behaviors (indicated by assertions) are applied are two
|
|
distinct concepts. The order of assertions in a policy alternative
|
|
has no bearing on the order in which behaviors are applied.</p>
|
|
<p>Specifying the order in which behaviors are applied is outside
|
|
the scope of the Web Services Policy Framework. However, the
|
|
Framework says that assertion authors can write assertions that
|
|
indicate the order in which behaviors are applied.</p>
|
|
<p>According to the SOAP processing model, the order of headers and
|
|
body processing (for behaviors such as addressing, security,
|
|
reliability and transaction) is at the discretion of the SOAP node
|
|
and SOAP-based protocols may be used to control the order of
|
|
processing.</p>
|
|
<p>The Web Services Security specification provides producers with
|
|
a choice of signing a message before encrypting or signing a
|
|
message after encrypting. That is, WS-Security 1.1, section 8 says,
|
|
lines 1173-1183 - says "Finally, if a producer wishes to sign a
|
|
message before encryption, then following the ordering rules laid
|
|
out in section 5, "Security Header", they SHOULD first prepend the
|
|
signature element to the <code>wsse:Security</code> header, and
|
|
then prepend the encryption element, ... Likewise, if a producer
|
|
wishes to sign a message after encryption, they SHOULD first
|
|
prepend the encryption element to the <code>wsse:Security</code>
|
|
header, and then prepend the signature element."</p>
|
|
<p>The Web Services Security Policy specification provides
|
|
assertions which let users control whether to sign the message
|
|
before encrypting or sign it after encrypting.</p>
|
|
<p>In the example below, the SignBeforeEncrypting assertion
|
|
requires producers to sign a message before encrypting.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-7.</span> SignBeforeEncrypting assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<sp:AsymmetricBinding>
|
|
<wsp:Policy>
|
|
<sp:IncludeTimestamp />
|
|
<sp:SignBeforeEncrypting />
|
|
<sp:EncryptSignature />
|
|
<sp:ProtectTokens />
|
|
<wsp:Policy/>
|
|
</sp:AsymmetricBinding>
|
|
<wsam:Addressing>...</wsam:Addressing>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>In the example below, the EncryptBeforeSigning assertion
|
|
requires producers to sign a message after encrypting.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-8.</span> EncryptBeforeSigning assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<sp:AsymmetricBinding>
|
|
<wsp:Policy>
|
|
<sp:IncludeTimestamp />
|
|
<sp:EncryptBeforeSigning />
|
|
<sp:EncryptSignature />
|
|
<sp:ProtectTokens />
|
|
<wsp:Policy/>
|
|
</sp:AsymmetricBinding>
|
|
<wsam:Addressing>...</wsam:Addressing>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="comparison" id="comparison"></a>5.4 Comparison of
|
|
Nested and Parameterized Assertions</h3>
|
|
<p>There are two different ways to provide additional information
|
|
in an assertion beyond its type: assertion parameters and nested
|
|
policy expressions. We cover these two cases below followed by a
|
|
comparison of these approaches targeting when to use either of the
|
|
two approaches.</p>
|
|
<p>The main consideration for choosing between use of parameters or
|
|
nested policy expressions is that the framework intersection
|
|
algorithm processes nested policy expressions, but does not
|
|
consider parameters in the algorithm.</p>
|
|
<div class="div3">
|
|
<h4><a name="parameterized-assertions" id=
|
|
"parameterized-assertions"></a>5.4.1 Assertions with
|
|
Parameters</h4>
|
|
<p>Policy assertion parameters are the opaque payload of an
|
|
assertion. Parameters carry additional useful information for
|
|
engaging the behavior described by an assertion and are preserved
|
|
through policy processing such as normalization, merge and policy
|
|
intersection. Requesters may use policy intersection to select a
|
|
compatible policy alternative for an interaction. Assertion
|
|
parameters do not affect the outcome of policy intersection unless
|
|
the assertion specifies domain specific processing for policy
|
|
intersection.</p>
|
|
<p>In the XML representation of a policy assertion, the child
|
|
elements and attributes of the assertion excluding child elements
|
|
and attributes from the policy language namespace name are the
|
|
assertion parameters.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-assertion-parameters" id=
|
|
"bp-assertion-parameters"></a><span class="practicelab">Best
|
|
Practice 13: Use Parameters for Useful Information</span></p>
|
|
<p class="practice">Assertion Authors should represent useful
|
|
additive information necessary for engaging the behavior
|
|
represented by a policy assertion as assertion parameters.</p>
|
|
</div>
|
|
<p>In the example below, <code>sp:Body</code> and
|
|
<code>sp:Header</code> 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). These two
|
|
parameters identify the parts of a wire message that should be
|
|
protected. These parameters carry additional useful information for
|
|
engaging the behavior.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-9.</span> Policy Assertion with Assertion Parameters</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<sp:SignedParts>
|
|
<sp:Body/>
|
|
<sp:Header/>
|
|
</sp:SignedParts>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="nested-assertions" id="nested-assertions"></a>5.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. In particular,
|
|
when assertion authors define an assertion type that allows nested
|
|
policy expression, it is important to also define the semantics of
|
|
that assertion when it contains an empty nested policy expression
|
|
(for example:
|
|
<wsam:Addressing><wsp:Policy/></wsam:Addressing>).</p>
|
|
<p>The following design questions below can help to determine when
|
|
to use nested policy expressions:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Are these assertions designed for the same policy subject?</p>
|
|
</li>
|
|
<li>
|
|
<p>Do these assertions represent dependent behaviors?</p>
|
|
</li>
|
|
</ul>
|
|
<p>If the answers are yes to both of these questions then
|
|
leveraging nested policy expressions is something to consider. Keep
|
|
in mind that a nested policy expression participates in the policy
|
|
intersection algorithm. If a requester uses policy intersection to
|
|
select a compatible policy alternative then the assertions in a
|
|
nested policy expression play a first class role in the outcome. If
|
|
there is a nested policy expression, an assertion description
|
|
should declare it and enumerate the nested policy assertions that
|
|
are allowed. There is one caveat to watch out for: policy
|
|
assertions with deeply nested policy can greatly increase the
|
|
complexity of a policy and should be avoided when they are not
|
|
needed.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-dependent-behaviors" id=
|
|
"bp-dependent-behaviors"></a><span class="practicelab">Best
|
|
Practice 14: Use Nested Assertions for Dependent
|
|
Behaviors</span></p>
|
|
<p class="practice">Assertion Authors should represent dependent
|
|
behaviors that are relevant to a compatibility test and apply to
|
|
the same policy subject using nested policy assertions.</p>
|
|
</div>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-declare-nested-assertions" id=
|
|
"bp-declare-nested-assertions"></a><span class="practicelab">Best
|
|
Practice 15: Enumerate Nested Assertions</span></p>
|
|
<p class="practice">If there is a nested policy expression, then
|
|
the Assertion Authors should enumerate the nested policy assertions
|
|
that are allowed.</p>
|
|
</div>
|
|
<p>Assertion Authors should recognize that the framework can yield
|
|
multiple assertions of the same type. The <em>QName</em> of the
|
|
assertion is the only vehicle for the framework to match a specific
|
|
assertion, NOT the contents of the element. If the assertion is a
|
|
parameterized assertion the authors must understand that this type
|
|
of assertion will require additional processing by consumers in
|
|
order to disambiguate the assertions or to understand the semantics
|
|
of the name value pairs, complex content, attribute values
|
|
contribution to the processing. The tradeoff is the generality vs.
|
|
the flexibility and complexity of the comparison expected for a
|
|
domain.</p>
|
|
<p>If the assertion authors want to delegate the processing to the
|
|
framework, utilizing nesting should be considered. Otherwise,
|
|
domain specific comparison algorithms may need to be devised and be
|
|
delegated to the specific domain handlers that are not visible to
|
|
the WS-Policy framework. However, domain specific intersection
|
|
processing reduces interop and increases the burden to implement an
|
|
assertion.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-discourage-domain-specific-intersection" id=
|
|
"bp-discourage-domain-specific-intersection"></a><span class=
|
|
"practicelab">Best Practice 16: Discourage Domain Specific
|
|
Intersection</span></p>
|
|
<p class="practice">Assertion authors should only specify domain
|
|
specific intersection semantics when policy intersection is
|
|
insufficient.</p>
|
|
</div>
|
|
<p>We will use the WS-SecurityPolicy to illustrate the use of
|
|
nested assertions.</p>
|
|
<p>Securing messages is a complex usage scenario. The
|
|
WS-SecurityPolicy Assertion Authors have defined 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 protecting
|
|
messages is not sufficient. To successfully interact with a Web
|
|
service, the consumer must know not only that transport-level
|
|
security is required, but also the transport token to use, the
|
|
secure transport to use, the algorithm suite to use for performing
|
|
cryptographic operations, etc. The <code>sp:TransportBinding</code>
|
|
policy assertion can represent these dependent behaviors.</p>
|
|
<p>A policy assertion like the <code>sp:TransportBinding</code>
|
|
identifies a visible behavior that is a requirement. A nested
|
|
policy expression can be used to enumerate the dependent behaviors
|
|
on the Transport binding. A nested policy expression is a policy
|
|
expression that is a child element of another policy assertion
|
|
element. A nested policy expression further qualifies the behavior
|
|
of its parent policy assertion.</p>
|
|
<p>In the example below, the child Policy element is a nested
|
|
policy expression and further qualifies the behavior of the
|
|
<code>sp:TransportBinding</code> policy assertion. The
|
|
<code>sp:TransportToken</code> is a nested policy assertion of 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
|
|
5-10.</span> Transport Security Policy Assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<sp:TransportBinding>
|
|
<Policy>
|
|
<sp:TransportToken>
|
|
<Policy>
|
|
<sp:HttpsToken>
|
|
<wsp:Policy/>
|
|
</sp:HttpsToken>
|
|
</Policy>
|
|
</sp:TransportToken>
|
|
<sp:AlgorithmSuite>
|
|
<Policy>
|
|
<sp:Basic256Rsa15/>
|
|
</Policy>
|
|
</sp:AlgorithmSuite>
|
|
</Policy>
|
|
</sp:TransportBinding>
|
|
</pre></div>
|
|
</div>
|
|
<p>The <code>sp:AlgorithmSuite</code> is a nested policy assertion
|
|
of the <code>sp:TransportBinding</code> policy assertion. The
|
|
<code>sp:AlgorithmSuite</code> assertion requires the use of the
|
|
algorithm suite identified by its nested policy assertion
|
|
(<code>sp:Basic256Rsa15</code> <em>in the example above</em>) and
|
|
further qualifies the behavior of the
|
|
<code>sp:TransportBinding</code> policy assertion.</p>
|
|
<p>Setting aside the details of using transport-level security, a
|
|
policy-aware client that recognizes this policy assertion can
|
|
engage transport-level security and its dependent behaviors
|
|
automatically. This means the complexity of security usage is
|
|
absorbed by a policy-aware client and hidden from Web service
|
|
application developers.</p>
|
|
<p>Assertion Authors should note the effect of nested policy
|
|
expressions on policy intersection in their nested policy design.
|
|
The result of intersecting an assertion that contains an empty
|
|
nested policy expression with an assertion of the same type without
|
|
a nested policy expression is that the assertions are not
|
|
compatible. Therefore, when providers require dependent behaviors
|
|
these behaviors should be explicitly specified as assertions in a
|
|
nested policy expression. When the definition of an assertion
|
|
allows for nested dependent behaviors, but the use of the assertion
|
|
only contains an empty nested policy expression, this specific use
|
|
indicates the specification of no nested dependent behaviors. This
|
|
use must not be interpreted as being compatible with "any" of the
|
|
nested dependent behaviors that are allowed by the assertion,
|
|
unless otherwise specified by the assertion definition.</p>
|
|
<p>As an example, WS-Security Policy defines
|
|
<code>sp:HttpToken</code> assertion to contain three possible
|
|
nested elements, <code>sp:HttpBasicAuthentication</code>,
|
|
<code>sp:HttpDigestAuthentication</code> and
|
|
<code>sp:RequireClientCertificate</code>. When the
|
|
<code>HttpToken</code> is used with an empty nested policy in a
|
|
policy expression by a provider, it will indicate that none of the
|
|
dependent behaviors namely authentication or client certificate is
|
|
required.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-11.</span> Empty Nested Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<sp:TransportToken>
|
|
<wsp:Policy>
|
|
<sp:HttpsToken>
|
|
<wsp:Policy/>
|
|
</sp:HttpsToken>
|
|
</wsp:Policy>
|
|
</sp:TransportToken>
|
|
</pre></div>
|
|
</div>
|
|
<p>A non-anonymous client who requires authentication or client
|
|
certificate will not be able to use this provider solely on the
|
|
basis of intersection algorithm alone.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating
|
|
Ignorable Behavior</h3>
|
|
<div class="div3">
|
|
<h4><a name="d3e882" id="d3e882"></a>5.5.1 Ignorable behavior in
|
|
authoring</h4>
|
|
<p>The Policy Framework provides an intersection algorithm that has
|
|
two defined modes for processing (lax and strict). The Framework
|
|
also defines an attribute (wsp:Ignorable) that can be used to
|
|
influence whether assertions are part of the compatibility
|
|
assessment between two alternatives. [see <cite><a href=
|
|
"#WS-Policy">Web Services Policy Framework</a></cite> and
|
|
<cite><a href="#WS-Policy-Primer">Web Services Policy
|
|
Primer</a></cite>]. Assertion authors should consider whether the
|
|
behavior represented by the Assertion they are defining can be
|
|
safely ignored for the purposes of intersection, and should follow
|
|
<a href="#DefineIgnorable"><b>8. Document Ignorable
|
|
Behavior</b></a> and <a href="#ignorableAssertions"><b>9. Document
|
|
Use of the Ignorable Attribute in XML</b></a> to include this
|
|
guidance in the assertion's definition.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="d3e895" id="d3e895"></a>5.5.2 Ignorable behavior at
|
|
runtime</h4>
|
|
<p>Regardless of whether the assertion allows the ignorable
|
|
attribute, assertion authors should indicate the semantic of the
|
|
runtime behavior in the description of the assertion.</p>
|
|
<p>As said in <a href=
|
|
"http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112#strict-lax-policy-intersection">
|
|
section 3.4.1 Strict and Lax Policy Intersection</a> in
|
|
<cite><a href="#WS-Policy-Primer">Web Services Policy
|
|
Primer</a></cite>, "Regardless of the chosen intersection mode,
|
|
ignorable assertions do not express any wire-level requirements on
|
|
the behavior of consumers - in other words, a consumer could choose
|
|
to ignore any such assertions that end up in the resulting policy
|
|
after intersection, with no adverse effects on runtime
|
|
interactions." Therefore, any assertion that is marked with
|
|
ignorable should not impose any wire-level requirements on the part
|
|
of consumers. Assertion Authors are reminded that regardless of
|
|
whether an assertion is marked as ignorable, policy consumers using
|
|
strict intersection will not 'ignore' the assertion.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="optional-policy-assertion" id=
|
|
"optional-policy-assertion"></a>5.6 Designating Optional
|
|
Behaviors</h3>
|
|
<div class="div3">
|
|
<h4><a name="d3e910" id="d3e910"></a>5.6.1 Optional behavior at
|
|
runtime</h4>
|
|
<p>The target scope of an assertion is an important factor for
|
|
Assertion Authors to consider as it determines the
|
|
<em>granularity</em> of the scope for which the behavior is to be
|
|
engaged. For example, if an assertion has a scope of endpoint
|
|
policy subject the behavior indicated by that assertion applies to
|
|
all , messages exchanged in both directions (e.g. both request and
|
|
response messages) with the specific endpoint to which the policy
|
|
alternative including that assertion is attached.</p>
|
|
<p>Certain behaviors might provide in their specification for the
|
|
optional use of that behavior in the context of a subset of a given
|
|
interaction. When such optional behaviors are indicated by
|
|
attaching assertions with only one side of an interaction, such as
|
|
an inbound message of a request-response, the engagement in the
|
|
context of the rest of the interaction such as the outbound
|
|
message, will be undefined. Therefore, the Assertion Authors are
|
|
encouraged to consider the implications of attachment of an
|
|
assertion that indicates such optional behavior at a message policy
|
|
subject on the interaction as a whole. For example, if reliable
|
|
messaging (RM) is applied to a request message because the policy
|
|
attached to the inbound message in a request-response operation had
|
|
an alternative that incldued RM in its assertions, is the
|
|
application of RM to the outbound message permitted, even if there
|
|
is no policy attached to that subject? Leaving the semantics either
|
|
unspecified or incompletely specified may result in implementations
|
|
making assumptions that might have undesireable consequences. This
|
|
is especially important if the assertion is applicable to more than
|
|
one specific policy subject. The approach taken by WS-RM Policy
|
|
[<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging
|
|
Policy Assertion</a></cite>] is to provide for an RM assertion to
|
|
be attached at either or both message and endpoint policy subjects.
|
|
In order to eliminate the ambiguity associated with only using a
|
|
message policy subject, the WS-RM Policy requires a policy to be
|
|
attached to an endpoint policy subject as well as a message policy
|
|
subject whenever a policy is attached to a message policy subject.
|
|
The combination directly addresses the unstated semantic that if RM
|
|
is used for inbound messages, that it MAY be used for outbound
|
|
messages, even if the assertion is not attached to the outbound
|
|
message (and vice-versa).</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-entire-mep-for-optional" id=
|
|
"bp-entire-mep-for-optional"></a><span class="practicelab">Best
|
|
Practice 17: Consider entire message exchange pattern when
|
|
specifying Assertions that represent optional behavior related to a
|
|
subset of that message exchange pattern when considering
|
|
appropriate policy subject attachment points</span></p>
|
|
<p class="practice">Assertion Authors should associate assertions
|
|
that represent optional behavior with the appropriate policy
|
|
subject and use the smallest possible granularity (See Best
|
|
Practice 28) to limit the degree to which optional behavior
|
|
applies.</p>
|
|
</div>
|
|
<p>Behaviors that must be engaged in the context of an interaction
|
|
must not be marked with wsp:Optional="true". since this creates two
|
|
alternatives; one with and one without that assertion. This would
|
|
allow the policy consumer to select the policy alternative that
|
|
does not contain that assertion, and thus result in an interaction
|
|
that did not engage the required behavior that was indicated by
|
|
that assertion.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-limitoptional-assertion-use" id=
|
|
"bp-limitoptional-assertion-use"></a><span class="practicelab">Best
|
|
Practice 18: Limit use of an Optional Assertion</span></p>
|
|
<p class="practice">Assertion Authors should disallow the use of
|
|
the wsp:Optional attribute on assertions that represent behaviors
|
|
that must be engaged.</p>
|
|
</div>
|
|
<p>Behaviors must be engaged with respect to messages that are
|
|
targeted to the provider so that the provider can determine that
|
|
the optional behavior is engaged. In ohter words, the need for self
|
|
describing messages [<a href="#self-describing"><b>5.3.3 Self
|
|
Describing Messages</b></a> ]should not be forgotten. An explicit,
|
|
out of band mechanism might be necessary to enable a client to
|
|
indicate that the optional behavior is engaged. (Such an out of
|
|
band mechanism is outside the scope of the WS-Policy
|
|
Framework).</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-indicate-optional-assertion-use" id=
|
|
"bp-indicate-optional-assertion-use"></a><span class=
|
|
"practicelab">Best Practice 19: Indicate use of an Optional
|
|
Assertion</span></p>
|
|
<p class="practice">When a given behavior may be optional, it must
|
|
be possible for both message participants to determine that the
|
|
assertion has been selected by both parties, either out of band or
|
|
as reflected by the message content.</p>
|
|
</div>
|
|
<p>The <cite><a href="#WS-Policy-Primer">Web Services Policy
|
|
Primer</a></cite> document contains an example that outlines the
|
|
use of <cite><a href="#MTOM">MTOM</a></cite> as an optional
|
|
behavior that can be engaged by a consumer. Related to this
|
|
behavior is an assertion that identifies the use of MIME
|
|
Multipart/Related serialization [<cite><a href=
|
|
"#MTOMPolicy">MTOMPolicy</a></cite>]. Policy-aware clients that
|
|
recognize and engage this policy assertion will use Optimized MIME
|
|
Serialization for messages.</p>
|
|
<p>The semantics of the MTOM assertion declare that the behavior
|
|
must be reflected in messages by requiring that they use an obvious
|
|
wire format (MIME Multipart/Related serialization). Thus, this
|
|
optional behavior is self describing. For example, an inbound
|
|
message to a web service that requires MTOM must adhere to
|
|
Optimized MIME Serialization. By examining the message, the
|
|
provider can determine whether the policy alternate that contains
|
|
the MTOM assertion is being obeyed ( <a href=
|
|
"#bp-indicate-optional-assertion-use">Best Practice: Indicate use
|
|
of an Optional Assertion</a>).</p>
|
|
<p>Note that if a MTOM assertion were only bound to the policy
|
|
subject representing the inbound message, then it would not be
|
|
clear to the service provider whether the outbound whether the
|
|
outbound messages generated by that provider should also utilize
|
|
that behavior. Thus this assertion should be associated at the
|
|
granularity of an entire message exchange. The semantics of the
|
|
assertion should specify this to avoid inappropriate assumptions by
|
|
implementations.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="levels-of-abstraction" id=
|
|
"levels-of-abstraction"></a>5.7 Considerations for Policy
|
|
Attachment</h3>
|
|
<div class="div3">
|
|
<h4><a name="general-attachment-guidelines" id=
|
|
"general-attachment-guidelines"></a>5.7.1 General Guidelines</h4>
|
|
<p>Although a policy assertion may be constrained to a specific set
|
|
of policy subjects by Assertion Authors, its semantics should not
|
|
be dependent upon the mechanism by which the policy expression is
|
|
attached to a given policy subject. For instance, an assertion
|
|
"Foo" has the same semantics when attached to an operation policy
|
|
subject regardless of whether it was attached using XML element
|
|
policy attachment or the external URI attachment mechanism.
|
|
Independence from a specific attachment mechanism allows policy
|
|
tools to choose the most appropriate mechanism to attach a policy
|
|
without having to analyze the contents of the policy.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-assertion-semantics" id=
|
|
"bp-assertion-semantics"></a><span class="practicelab">Best
|
|
Practice 20: Semantics Independent of Attachment
|
|
Mechanisms</span></p>
|
|
<p class="practice">The semantics of a policy assertion should not
|
|
depend on the attachment mechanism used.</p>
|
|
</div>
|
|
<p>For example, a security policy expression can be assigned a key
|
|
reference and be attached to a UDDI binding or can be embedded in a
|
|
WSDL document.</p>
|
|
<p>Since multiple attachment mechanisms may be used, a policy
|
|
alternative created during the process of calculating an effective
|
|
policy can contain multiple instances of the same policy assertion
|
|
type ( i.e., the SignedParts assertion). It is therefore also
|
|
important for the policy authors to define what it means if
|
|
multiple assertions are present.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-semantics-multiple-same-type" id=
|
|
"bp-semantics-multiple-same-type"></a><span class=
|
|
"practicelab">Best Practice 21: Describe Semantics of Multiple
|
|
Assertions of Same Type</span></p>
|
|
<p class="practice">Assertion Authors should specify the semantics
|
|
of multiple instances of the same policy assertion type in the same
|
|
policy alternative and the semantics of parameters and nested
|
|
policy (if any) when there are multiple instances of a policy
|
|
assertion type in the same policy alternative regardless of the
|
|
mechanism used to attach them to a policy subject.</p>
|
|
</div>
|
|
<p>Assertion authors should review sections 3.2 and 4.5 of the
|
|
Policy Framework <cite><a href="#WS-Policy">Web Services Policy
|
|
Framework</a></cite> for more detail on the processing for multiple
|
|
assertions of the same type.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-leverage-defined-attachment-mechanisms" id=
|
|
"bp-leverage-defined-attachment-mechanisms"></a><span class=
|
|
"practicelab">Best Practice 22: Leverage Defined Attachment
|
|
Mechanisms</span></p>
|
|
<p class="practice">Assertion Authors should leverage defined
|
|
attachment models when possible to document the use of the policy
|
|
assertions they author and ensure that there are no additional
|
|
semantics implied by the defined attachment models for their
|
|
assertions.</p>
|
|
</div>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-use-defined-policy-subjects" id=
|
|
"bp-use-defined-policy-subjects"></a><span class="practicelab">Best
|
|
Practice 23: Use Defined Policy Subjects</span></p>
|
|
<p class="practice">Assertion Assertion Authors should leverage
|
|
defined policy subjects when possible to facilitate the deployment
|
|
of their policy assertions. Common Policy subjects have been
|
|
defined and used by other policy assertion authors and new policy
|
|
assertions that leverage these existing subjects will be easier to
|
|
define and group.</p>
|
|
</div>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-identify-policy-subjects" id=
|
|
"bp-identify-policy-subjects"></a><span class="practicelab">Best
|
|
Practice 24: Identify Policy Subjects</span></p>
|
|
<p class="practice">Policy assertion authors should unambiguously
|
|
identify the appropriate policy subjects for their assertions. 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.</p>
|
|
</div>
|
|
<p>Assertion Authors should review the policy subjects defined in
|
|
WS-PolicyAttachments and identify which of the existing policy
|
|
subjects can be used with the assertions they define. That
|
|
identification will facilitate the deployment of their policy
|
|
assertions.</p>
|
|
<p>An example of this practice is the Reliable Messaging Policy
|
|
Assertion document [<cite><a href="#WS-RM-Policy">Web Services
|
|
Reliable Messaging Policy Assertion</a></cite>]. In the Sequence
|
|
STR Assertion (section 2.5.1) the Reliable Messaging Policy
|
|
Assertion authors state that "The STR assertion defines the
|
|
requirement that an RM Sequence MUST be bound to an explicit token
|
|
that is referenced from a <code>wsse:SecurityTokenReference</code>
|
|
in the CreateSequence message. This assertion MUST apply to
|
|
[Endpoint Policy Subject]. This assertion MUST NOT be used for an
|
|
endpoint that does not also use the RM assertion". This is
|
|
illustrative of how the domain assertion author can specify
|
|
additional constraints and assumptions for attachment and
|
|
engagement of behavior in addition to the capabilities specified in
|
|
Web Services Policy 1.5 - Attachment [<cite><a href=
|
|
"#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>].
|
|
Such additional constraints must be clearly specified by the
|
|
assertion authors.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="wsdl-attachment-guidelines" id=
|
|
"wsdl-attachment-guidelines"></a>5.7.2 Considerations for Policy
|
|
Attachment in WSDL</h4>
|
|
<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 should specify a WSDL policy
|
|
subject.</p>
|
|
<p>The specific WSDL policy subject is determined with respect to a
|
|
behavior as follows:</p>
|
|
<ul>
|
|
<li>
|
|
<p>If the behavior applies to any message exchange using any of the
|
|
endpoints offered by a service then the subject is the service
|
|
policy subject.</p>
|
|
</li>
|
|
<li>
|
|
<p>If the behavior applies to any message exchange made using an
|
|
endpoint then the subject is the endpoint policy subject.</p>
|
|
</li>
|
|
<li>
|
|
<p>If the behavior applies to any message exchange defined by an
|
|
operation then the subject is the operation policy subject.</p>
|
|
</li>
|
|
<li>
|
|
<p>If the behavior applies to an input message then the subject is
|
|
the message policy subject - similarly for output and fault message
|
|
WSDL policy subjects.</p>
|
|
</li>
|
|
</ul>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-WSDL-policy-subject" id=
|
|
"bp-WSDL-policy-subject"></a><span class="practicelab">Best
|
|
Practice 25: Specify WSDL Policy Subject(s)</span></p>
|
|
<p class="practice">Assertion Authors should specify the set of
|
|
relevant WSDL policy subjects with which the assertion may be
|
|
associated.</p>
|
|
</div>
|
|
<p>Assertion Authors that utilize WSDL policy subjects need to
|
|
understand how the assertions will be processed in intersection and
|
|
merging, and the specific implications of the processing for a
|
|
specific attachment point and policy subject. This topic is
|
|
considered in detail in <cite><a href="#WS-Policy-Primer">Web
|
|
Services Policy Primer</a></cite></p>
|
|
<p>For a given WSDL policy subject, there may be several attachment
|
|
points. For example, there are three attachment points for the
|
|
endpoint policy subject: the port, binding and portType element.
|
|
Assertion Authors should identify the relevant attachment point
|
|
when defining a new assertion.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-WSDL-consider-scope" id=
|
|
"bp-WSDL-consider-scope"></a><span class="practicelab">Best
|
|
Practice 26: Consider Scope of Attachment Points</span></p>
|
|
<p class="practice">To determine the relevant attachment points,
|
|
Assertion Authors should consider the scope of the attachment
|
|
point.</p>
|
|
</div>
|
|
<p>For example, an assertion should only be allowed in the portType
|
|
element if the assertion reasonably applies to any endpoint that
|
|
ever references that portType. Most of the known policy assertions
|
|
are designed for the endpoint, operation or message policy
|
|
subject.</p>
|
|
<p>In using WSDL attachment, it should be noted that the service
|
|
policy subject is a collection of endpoint policy subjects. The
|
|
endpoint policy subject is a collection of operation WSDL policy
|
|
subjects and so on. As a result, the WSDL policy subjects compose
|
|
naturally. It is quite tempting to associate the identified
|
|
behavior to a broader policy subject than to a fine granular policy
|
|
subject. For instance, it is convenient to attach a supporting
|
|
token assertion (defined by the Web Services Security Policy
|
|
specification) to an endpoint policy subject instead of a message
|
|
policy subject. The best practice is to choose the most granular
|
|
WSDL policy subject to which the behavior represented by a policy
|
|
assertion applies.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-WSDL-policy-subject-Granularity" id=
|
|
"bp-WSDL-policy-subject-Granularity"></a><span class=
|
|
"practicelab">Best Practice 27: Choose the Most Granular WSDL
|
|
Policy Subject</span></p>
|
|
<p class="practice">Assertion Authors should choose the most
|
|
granular WSDL policy subject to which the behavior represented by a
|
|
policy assertion applies.</p>
|
|
</div>
|
|
<p>For authoring convenience, Assertion Authors may allow the
|
|
association of an assertion to multiple WSDL policy subjects within
|
|
the same context of use (e.g in the same WSDL description). If an
|
|
assertion is allowed to be associated with multiple WSDL policy
|
|
subjects as is possible with WSDL, then the Assertion Authors have
|
|
the burden to describe the rules when multiple instances of the
|
|
same assertion are attached to different WSDL policy subjects in
|
|
order to avoid non-interoperable behavior.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-WSDL-multiple-policy-subjects" id=
|
|
"bp-WSDL-multiple-policy-subjects"></a><span class=
|
|
"practicelab">Best Practice 28: Define Rules for Attachment of an
|
|
Assertion type to Multiple WSDL policy subjects</span></p>
|
|
<p class="practice">If an assertion is allowed to be associated
|
|
with multiple WSDL policy subjects, the assertion author should
|
|
describe the rules for multiple instances of the same assertion
|
|
attached to multiple WSDL policy subjects in the same context.</p>
|
|
</div>
|
|
<p>To give one example, section 2.3 of the Web Services Reliable
|
|
Messaging Policy Assertion specification [<cite><a href=
|
|
"#WS-RM-Policy">Web Services Reliable Messaging Policy
|
|
Assertion</a></cite>] gives rules on which WSDL policy subjects may
|
|
be associated with the RM Policy assertion, and which WSDL 1.1
|
|
elements may have RM Policy assertions attached.</p>
|
|
<p>If the behavior indicated by an assertion varies when attached
|
|
to different policy subjects the Assertion Authors should consider
|
|
the following:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Decompose the semantics with several assertions.</p>
|
|
</li>
|
|
<li>
|
|
<p>Rewrite a single assertion targeting a specific policy
|
|
subject.</p>
|
|
</li>
|
|
</ul>
|
|
<p>Since many attachment points are available in WSDL, it would be
|
|
necessary for Assertion Authors to recommend a preferred attachment
|
|
point. One approach would be to identify different attachment
|
|
points in a policy subject, choose the most granular policy subject
|
|
that the behavior applies to and specify that as a preferred
|
|
attachment point. However, this approach only works if the policy
|
|
subject is a true WSDL construct other than some other protocol
|
|
concept that is layered over WSDL message exchanges. For example,
|
|
as described previously the WS-RM Policy is a capability that
|
|
governs a target endpoint's capability to accept message sequences
|
|
that are beyond single message exchange. Therefore, its semantics
|
|
encompass the cases when message level WSDL policy subjects may be
|
|
used as attachment but also considers the case when sequences are
|
|
present. In addition, when the policy assertions do not target
|
|
wire-level behaviors but rather abstract requirements, this
|
|
technique does not apply.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-WSDL-preferred-attachment-point" id=
|
|
"bp-WSDL-preferred-attachment-point"></a><span class=
|
|
"practicelab">Best Practice 29: Specify Preferred WSDL Attachment
|
|
Point</span></p>
|
|
<p class="practice">If an assertion can be attached at multiple
|
|
attachment points within a policy subject, Assertion Authors should
|
|
specify a preferred attachment point for the chosen policy
|
|
subject.</p>
|
|
</div>
|
|
<p>Assertion Authors that utilize WSDL policy subjects need to
|
|
understand how the assertions will be processed in merging and the
|
|
specific implications of a result where multiple assertions of the
|
|
assertion type are in an alternative, in the merged policy. For
|
|
example, consider the SignedParts assertion defined in
|
|
WS-SecurityPolicy 1.2. The definition of SignedParts assertion
|
|
explicitly permits multiple SignedParts assertions to be present
|
|
within a policy alternative, and declares it to be equivalent to a
|
|
single SignedParts assertion containing the union of all specified
|
|
message parts. So, if a SignedParts assertion is specified in a
|
|
WSDL binding at the input message level and subsequently an
|
|
additional SignedParts assertion is specified at the WSDL endpoint
|
|
policy subject level, then the effective policy at the endpoint
|
|
could have more than one SignedParts assertion in the same
|
|
alternative. However, the clear semantics defined by the
|
|
SignedParts assertion enable processing of the multiple occurrences
|
|
properly.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="UDDI-attachment-guidelines" id=
|
|
"UDDI-attachment-guidelines"></a>5.7.3 Considerations for Policy
|
|
Attachment in UDDI</h4>
|
|
<p>In general, UDDI protocol messages can be used to save TModel,
|
|
businessEntity, businessService and bindingTemplate definitions
|
|
with policies attached. These definitions can also be the target of
|
|
a "find" protocol message, thus allowing authors to store and
|
|
retrieve policy assertions. There are two ways to associate policy
|
|
expressions with UDDI definitions: direct referece, and registering
|
|
policy as a UDDI TModel. Assertion Authors defining new assertions
|
|
should consider each approach.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-UDDI-tmodels" id="bp-UDDI-tmodels"></a><span class=
|
|
"practicelab">Best Practice 30: Use defined tModels when
|
|
appropriate</span></p>
|
|
<p class="practice">UDDI defines the following policy subjects:
|
|
Service Provider Policy, Service Policy subject and Endpoint Policy
|
|
subject.</p>
|
|
</div>
|
|
<p>When defining assertions and recommending a service provider
|
|
policy subject [uddi:BusinessEntity], or a service policy subject
|
|
[uddi:buisnessService], assertion authors are scoping the behaviors
|
|
to the service provider as a whole. When defining assertions and
|
|
recommending an endpoint policy subject [uddi:bindingTemplate,
|
|
uddi:tModel], assertion authors are scoping behaviors to a deployed
|
|
endpoint.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="interrelated-domains" id=
|
|
"interrelated-domains"></a>5.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.
|
|
Assertion Authors should not duplicate existing 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 class="boxedtext">
|
|
<p><a name="bp-specify-composition" id=
|
|
"bp-specify-composition"></a><span class="practicelab">Best
|
|
Practice 31: Specify Composition with Related Assertions</span></p>
|
|
<p class="practice">Assertion authors should clearly specify how an
|
|
assertion may compose with other related assertions, if any.</p>
|
|
</div>
|
|
<p>A classic example of such an interrelated domain is security,
|
|
because security tends to cut across all aspects of a solution. Web
|
|
Services Reliable Messaging Policy Assertions [<cite><a href=
|
|
"#WS-RM-Policy">Web Services Reliable Messaging Policy
|
|
Assertion</a></cite>] defines additional assertions related to
|
|
[<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>],
|
|
an interrelated security domain. One such additional assertion
|
|
specifies the use of transport security to protect a message
|
|
sequence, for example.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
5-12.</span> Reliable Message Sequence Security</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... />
|
|
</pre></div>
|
|
</div>
|
|
<p>The Reliable Message Policy specification states "This assertion
|
|
is effectively meaningless unless it occurs in conjunction with the
|
|
<code>RMAssertion</code> and a <code>sp:TransportBinding</code>
|
|
assertion that requires the use of some transport-level security
|
|
mechanism (e.g. <code>sp:HttpsToken</code>)".</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="versioning-policy-assertions" id=
|
|
"versioning-policy-assertions"></a>6. Versioning Policy
|
|
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 to
|
|
versioning policy assertions:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Assertion Extensibility. Assertion authors should allow for
|
|
extensibility (see best practice 5. Start with a Simple
|
|
Assertion)</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 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>Supporting New Policy Subjects (see Section <a href=
|
|
"#supporting-new-policy-subjects"><b>6.3 Supporting New Policy
|
|
Subjects</b></a>).</p>
|
|
</li>
|
|
</ul>
|
|
<div class="div2">
|
|
<h3><a name="Referencing_Policy_Expressions" id=
|
|
"Referencing_Policy_Expressions"></a>6.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. Reuse may also be useful for
|
|
domain Assertion Authors, especially those defining complex
|
|
assertions utilizing references to policy expressions by nesting.
|
|
Statically available parameterized content may also be reused by
|
|
different assertions. However, such referencing mechanism is
|
|
outside the scope of WS-Policy naming and referencing framework and
|
|
other mechanisms could be used. As an example, in <cite><a href=
|
|
"#WS-Policy-Primer">Web Services Policy Primer</a></cite> Section
|
|
4.2, the <code>sp:issuedToken</code> assertion utilizes the
|
|
<code>sp:RequestSecurityTokenTemplate</code> parameter that
|
|
contains necessary information to request a security token. The
|
|
contents of the parameter are static and may be reused in different
|
|
security scenarios using other referencing mechanisms (these are
|
|
outside the scope of the WS-Policy Framework).</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="extending-assertions" id=
|
|
"extending-assertions"></a>6.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.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-independent-assertions" id=
|
|
"bp-independent-assertions"></a><span class="practicelab">Best
|
|
Practice 32: Independent Assertions for Different Versions of a
|
|
Behavior</span></p>
|
|
<p class="practice">Assertion Authors should use independent
|
|
assertions for modeling different versions of a behavior.</p>
|
|
</div>
|
|
<p>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
|
|
6-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
|
|
6-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>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="supporting-new-policy-subjects" id=
|
|
"supporting-new-policy-subjects"></a>6.3 Supporting New Policy
|
|
Subjects</h3>
|
|
<p>The best practice <a href="#bp-WSDL-policy-subject"><b>25.
|
|
Specify WSDL Policy Subject(s)</b></a> specifies that policy
|
|
authors should define the set of policy subjects to which policy
|
|
assertions can be attached. Over time, new policy subjects may need
|
|
to be defined. When this occurs, policy Assertion Authors may
|
|
update the list of policy subjects supported by an assertion.</p>
|
|
<p>When the assertion's semantics do not change to invalidate any
|
|
of the original policy subjects but new policy subjects need to be
|
|
added, it may be possible to use the same assertion to designate
|
|
the additional policy subjects without a namespace change. For
|
|
example, a policy assertion for a protocol that is originally
|
|
designed for endpoint policy subject may add message policy subject
|
|
to indicate finer granularity in the attachment provided that
|
|
endpoint policy subject is also retained in its design. When new
|
|
policy subjects are added it is incumbent on the authors to retain
|
|
the semantic of the policy assertion.</p>
|
|
<div class="boxedtext">
|
|
<p><a name="bp-policy-subject-change" id=
|
|
"bp-policy-subject-change"></a><span class="practicelab">Best
|
|
Practice 33: Document changes to policy subject</span></p>
|
|
<p class="practice">If the policy subjects change over time, the
|
|
assertion description should also be versioned to reflect this
|
|
change.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="back">
|
|
<div class="div1">
|
|
<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" id="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">
|
|
<code>http://www.w3.org/2003/05/soap-envelope</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href="#SOAP12">SOAP 1.2
|
|
Messaging Framework (Second Edition)</a></cite>]</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>sp</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702</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>wsa</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://www.w3.org/2005/08/addressing</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href=
|
|
"#WS-Addressing">WS-Addressing Core</a></cite>]</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>wsam</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://www.w3.org/2007/05/addressing/metadata</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href=
|
|
"#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>]</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>wsdl</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://schemas.xmlsoap.org/wsdl/</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href="#WSDL11">WSDL
|
|
1.1</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">[<cite><a href="#WS-Policy">Web
|
|
Services Policy Framework</a></cite>, <cite><a href=
|
|
"#WS-PolicyAttachment">Web Services Policy
|
|
Attachment</a></cite>]</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>wsrmp</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://docs.oasis-open.org/ws-rx/wsrmp/200702</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href="#WS-RM-Policy">Web
|
|
Services Reliable Messaging Policy Assertion</a></cite>]</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><code>wss</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href=
|
|
"#WS-Security2004">WS-Security 2004</a></cite>]</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-Security2004">WS-Security 2004</a></cite>]</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<br /></div>
|
|
<div class="div1">
|
|
<h2><a name="references" id="references"></a>C. References</h2>
|
|
<dl>
|
|
<dt class="label"><a name="MTOM" id="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 is
|
|
http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. The <a href=
|
|
"http://www.w3.org/TR/soap12-mtom/">latest version of SOAP Message
|
|
Transmission Optimization Mechanism</a> is available at
|
|
http://www.w3.org/TR/soap12-mtom/.</dd>
|
|
<dt class="label"><a name="MTOMPolicy" id=
|
|
"MTOMPolicy"></a>[MTOMPolicy]</dt>
|
|
<dd><cite><a href=
|
|
"http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/optimizedmimeserialization-policy.pdf">
|
|
MTOM Serialization Policy Assertion (WS-MTOMPolicy)</a></cite>, C
|
|
Ferris, K Gavrylyuk, J Marsh , J Schlimmer, Authors. September
|
|
2006. Version 1.0 at
|
|
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/optimizedmimeserialization-policy.pdf.</dd>
|
|
<dt class="label"><a name="SOAP11" id="SOAP11"></a>[SOAP 1.1]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object
|
|
Access Protocol (SOAP) 1.1</a></cite>, D. Box, et al, Editors.
|
|
World Wide Web Consortium, 8 May 2000. Available at
|
|
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.</dd>
|
|
<dt class="label"><a name="SOAP12" id="SOAP12"></a>[SOAP 1.2
|
|
Messaging Framework (Second Edition)]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-soap12-part1-20070427/">SOAP Version
|
|
1.2 Part 1: Messaging Framework (Second Edition)</a></cite>, M.
|
|
Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen,
|
|
A. Karmarkar, and Y. Lafon, Editors. World Wide Web Consortium, 27
|
|
April 2007. This version of the SOAP Version 1.2 Part 1: Messaging
|
|
Framework Recommendation is
|
|
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. The <a href=
|
|
"http://www.w3.org/TR/soap12-part1/">latest version of SOAP Version
|
|
1.2 Part 1: Messaging Framework</a> is available at
|
|
http://www.w3.org/TR/soap12-part1/.</dd>
|
|
<dt class="label"><a name="XOP" id="XOP"></a>[XOP]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2005/REC-xop10-20050125/">XML-binary
|
|
Optimized Packaging</a></cite>, M. Gudgin, N. Mendelsohn, M.
|
|
Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25
|
|
January 2005. This version of the XML-binary Optimized Packaging
|
|
Recommendation is http://www.w3.org/TR/2005/REC-xop10-20050125/.
|
|
The <a href="http://www.w3.org/TR/xop10/">latest version of
|
|
XML-binary Optimized Packaging</a> is available at
|
|
http://www.w3.org/TR/xop10/.</dd>
|
|
<dt class="label"><a name="WS-Addressing" id=
|
|
"WS-Addressing"></a>[WS-Addressing Core]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/">Web Services
|
|
Addressing 1.0 - Core</a></cite>, M. Gudgin, M. Hadley, and T.
|
|
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This
|
|
version of the Web Services Addressing 1.0 - Core Recommendation is
|
|
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href=
|
|
"http://www.w3.org/TR/ws-addr-core/">latest version of Web Services
|
|
Addressing 1.0 - Core</a> is available at
|
|
http://www.w3.org/TR/ws-addr-core.</dd>
|
|
<dt class="label"><a name="WS-AddressingMetadata" id=
|
|
"WS-AddressingMetadata"></a>[WS-Addressing Metadata]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/">Web
|
|
Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M.
|
|
Hadley, T. Rogers and Ü. Yalçinalp, Editors. World Wide Web
|
|
Consortium, 4 September 2007. This version of Web Services
|
|
Addressing 1.0 - Metadata W3C Recommendation is
|
|
http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. The
|
|
<a href="http://www.w3.org/TR/ws-addr-metadata">latest version of
|
|
Web Services Addressing 1.0 - Metadata</a> is available at
|
|
http://www.w3.org/TR/ws-addr-metadata.</dd>
|
|
<dt class="label"><a name="WSDL11" id="WSDL11"></a>[WSDL 1.1]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services
|
|
Description Language (WSDL) 1.1</a></cite>, E. Christensen, et al,
|
|
Authors. World Wide Web Consortium, March 2001. Available at
|
|
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.</dd>
|
|
<dt class="label"><a name="WSDL20" id="WSDL20"></a>[WSDL 2.0 Core
|
|
Language]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626/">Web Services
|
|
Description Language (WSDL) Version 2.0 Part 1: Core
|
|
Language</a></cite>, R. Chinnici, J. J. Moreau, A. Ryman, S.
|
|
Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This
|
|
version of the WSDL 2.0 specification is
|
|
http://www.w3.org/TR/2007/REC-wsdl20-20070626/. The <a href=
|
|
"http://www.w3.org/TR/wsdl20/">latest version of WSDL 2.0</a> is
|
|
available at http://www.w3.org/TR/wsdl20.</dd>
|
|
<dt class="label"><a name="WS-Policy" id="WS-Policy"></a>[Web
|
|
Services Policy Framework]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-ws-policy-20070904/">Web Services
|
|
Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F.
|
|
Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors.
|
|
World Wide Web Consortium, 4 September 2007. This version of the
|
|
Web Services Policy 1.5 - Framework specification is at
|
|
http://www.w3.org/TR/2007/REC-ws-policy-20070904/. The <a href=
|
|
"http://www.w3.org/TR/ws-policy/">latest version of Web Services
|
|
Policy 1.5 - Framework</a> is available at
|
|
http://www.w3.org/TR/ws-policy/.</dd>
|
|
<dt class="label"><a name="WS-PolicyAttachment" id=
|
|
"WS-PolicyAttachment"></a>[Web Services Policy Attachment]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/">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, 4 September 2007.
|
|
This version of the Web Services Policy 1.5 - Attachment
|
|
specification is at
|
|
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/. The
|
|
<a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
|
|
Web Services Policy 1.5 - Attachment</a> is available at
|
|
http://www.w3.org/TR/ws-policy-attach/.</dd>
|
|
<dt class="label"><a name="WS-Policy-Primer" id=
|
|
"WS-Policy-Primer"></a>[Web Services Policy Primer]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/WD-ws-policy-primer-20070810/">Web
|
|
Services Policy 1.5 - Primer</a></cite>, A. S. Vedamuthu, D.
|
|
Orchard, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü.
|
|
Yalçinalp, Editors. World Wide Web Consortium, 10 August 2007. This
|
|
version of Web Services Policy 1.5 - Primer specification is
|
|
http://www.w3.org/TR/2007/WD-ws-policy-primer-20070810/. The
|
|
<a href="http://www.w3.org/TR/ws-policy-primer/">latest version of
|
|
Web Services Policy 1.5 - Primer</a> is available at
|
|
http://www.w3.org/TR/ws-policy-primer/.</dd>
|
|
<dt class="label"><a name="WS-RM" id="WS-RM"></a>[Web Services
|
|
Reliable Messaging]</dt>
|
|
<dd><cite><a href=
|
|
"http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.html">
|
|
Web Services Reliable Messaging (WS-ReliableMessaging)</a></cite>,
|
|
D. Davis, A. Karmarkar G. Pilz, S. Winkler, Ü. Yalçinalp, Editors.
|
|
Organization for the Advancement of Structured Information
|
|
Standards, 14 June 2007, available at:
|
|
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.html.
|
|
Namespace document is available at <a href=
|
|
"http://docs.oasis-open.org/ws-rx/wsrm/200702">http://docs.oasis-open.org/ws-rx/wsrm/200702</a>.</dd>
|
|
<dt class="label"><a name="WS-RM-Policy" id="WS-RM-Policy"></a>[Web
|
|
Services Reliable Messaging Policy Assertion]</dt>
|
|
<dd><cite><a href=
|
|
"http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf">
|
|
Web Services Reliable Messaging Policy Assertion (WS-RM Policy)
|
|
Version 1.1</a></cite>, D. Davis, A. Kamarkar, G. Pilz, and Ü.
|
|
Yalçinalp, Editors. Organization for the Advancement of Structured
|
|
Information Standards, OASIS Standard, 14 June 2007. This version
|
|
available at
|
|
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf.
|
|
Namespace document is available at <a href=
|
|
"http://docs.oasis-open.org/ws-rx/wsrmp/200702">http://docs.oasis-open.org/ws-rx/wsrmp/200702</a>.</dd>
|
|
<dt class="label"><a name="WS-Security2004" id=
|
|
"WS-Security2004"></a>[WS-Security 2004]</dt>
|
|
<dd><cite><a href=
|
|
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">
|
|
Web Services Security: SOAP Message Security 1.0</a></cite>, A.
|
|
Nadalin, C. Kaler, P. Hallam-Baker and R. Monzillo, Editors.
|
|
Organization for the Advancement of Structured Information
|
|
Standards, March 2004. Available at
|
|
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.</dd>
|
|
<dt class="label"><a name="WS-SecurityPolicy" id=
|
|
"WS-SecurityPolicy"></a>[WS-SecurityPolicy]</dt>
|
|
<dd><cite><a href=
|
|
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf">
|
|
WS-SecurityPolicy v1.2</a></cite>, A. Nadalin, M. Goodner, M.
|
|
Gudgin, A. Barbir, and H. Granqvist, Editors. Organization for the
|
|
Advancement of Structured Information Standards, 1 July 2007.
|
|
Available at
|
|
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf.
|
|
Namespace document available at
|
|
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702.</dd>
|
|
<dt class="label"><a name="WS-Trust" id=
|
|
"WS-Trust"></a>[WS-Trust]</dt>
|
|
<dd><cite><a href=
|
|
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf">
|
|
Web Services Atomic Transaction (WS-AtomicTransaction) Version
|
|
1.1</a></cite>, M. Little, A. Wilkinson, Editors. Organization for
|
|
the Advancement of Structured Information Standards, OASIS
|
|
Standard, 16 April 2007. This version available at
|
|
http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-os/wstx-wsat-1.1-spec-os.html.
|
|
Namespace document is available at <a href=
|
|
"http://docs.oasis-open.org/ws-tx/wsat/2006/06">http://docs.oasis-open.org/ws-tx/wsat/2006/06</a>.</dd>
|
|
<dt class="label"><a name="UDDIAPI20" id="UDDIAPI20"></a>[UDDI API
|
|
2.0]</dt>
|
|
<dd><cite><a href=
|
|
"http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm">UDDI
|
|
Version 2.04 API</a></cite>, T. Bellwood, Editor. Organization for
|
|
the Advancement of Structured Information Standards, 19 July 2002.
|
|
This version of UDDI Version 2.0 API is
|
|
http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm.
|
|
The <a href="http://uddi.org/pubs/ProgrammersAPI_v2.htm">latest
|
|
version of the UDDI 2.0 API</a> is available at
|
|
http://uddi.org/pubs/ProgrammersAPI_v2.htm.</dd>
|
|
<dt class="label"><a name="UDDIDataStructure20" id=
|
|
"UDDIDataStructure20"></a>[UDDI Data Structure 2.0]</dt>
|
|
<dd><cite><a href=
|
|
"http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm">UDDI
|
|
Version 2.03 Data Structure Reference</a></cite>, C. von Riegen,
|
|
Editor. Organization for the Advancement of Structured Information
|
|
Standards, 19 July 2002. This version of UDDI Version 2.0 Data
|
|
Structures is
|
|
http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm.
|
|
The <a href="http://uddi.org/pubs/DataStructure_v2.htm">latest
|
|
version of the UDDI 2.0 Data Structures</a> is available at
|
|
http://uddi.org/pubs/DataStructure_v2.htm.</dd>
|
|
<dt class="label"><a name="UDDI30" id="UDDI30"></a>[UDDI 3.0]</dt>
|
|
<dd><cite><a href=
|
|
"http://uddi.org/pubs/uddi-v3.0.2-20041019.htm">UDDI Version
|
|
3.0.2</a></cite>, L. Clément, A. Hately, C. von Riegen, and T.
|
|
Rogers, Editors. Organization for the Advancement of Structured
|
|
Information Standards, 19 October 2004. This version of the UDDI
|
|
Version 3.0 is http://uddi.org/pubs/uddi-v3.0.2-20041019.htm. The
|
|
<a href="http://uddi.org/pubs/uddi_v3.htm">latest version of the
|
|
UDDI 3.0</a> specification is available at
|
|
http://uddi.org/pubs/uddi_v3.htm.</dd>
|
|
<dt class="label"><a name="SAWSDL" id="SAWSDL"></a>[SAWSDL]</dt>
|
|
<dd><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, 28 Augusty 2007. This
|
|
is a W3C recommendation and the specification can be found at
|
|
http://www.w3.org/TR/2007/REC-sawsdl-20070828/. 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>
|
|
<dt class="label"><a name="XMLSchemaPart2" id=
|
|
"XMLSchemaPart2"></a>[XML Schema Datatypes]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema
|
|
Part 2: Datatypes Second Edition</a></cite>, P. Byron and A.
|
|
Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised
|
|
28 October 2004. This version of the XML Schema Part 2
|
|
Recommendation is
|
|
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The <a href=
|
|
"http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
|
|
Part 2</a> is available at http://www.w3.org/TR/xmlschema-2.</dd>
|
|
<dt class="label"><a name="XMLSchemaPart1" id=
|
|
"XMLSchemaPart1"></a>[XML Schema Structures]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
|
|
Part 1: Structures Second Edition</a></cite>, H. Thompson, D.
|
|
Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web
|
|
Consortium, 2 May 2001, revised 28 October 2004. This version of
|
|
the XML Schema Part 1 Recommendation is
|
|
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href=
|
|
"http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema
|
|
Part 1</a> is available at http://www.w3.org/TR/xmlschema-1.</dd>
|
|
</dl>
|
|
</div>
|
|
<div class="div1">
|
|
<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), Symon Chang (BEA Systems, Inc.),
|
|
Paul Cotton (Microsoft Corporation), Doug Davis (IBM Corporation),
|
|
Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2),
|
|
Christopher Ferris (IBM Corporation), William Henry (IONA
|
|
Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM
|
|
Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones
|
|
(Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul
|
|
Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark
|
|
Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation),
|
|
Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Arnaud
|
|
Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation),
|
|
Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation),
|
|
David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula
|
|
Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel
|
|
Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka
|
|
Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA),
|
|
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: Jeffrey Crump, Glen
|
|
Daniels, Jong Lee, Monica Martin, Bob Natale, Eugene Osovetsky,
|
|
Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.</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" id="change-description"></a>E.
|
|
Changes in this Version of the Document (Non-Normative)</h2>
|
|
<p>A list of major changes since the Working Draft dated 28
|
|
September, 2007 is below:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Clarified the target audience for this document (see <a href=
|
|
"#introduction"><b>1. Introduction</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>Moved <a href="#bp-assertion-semantics"><b>20. Semantics
|
|
Independent of Attachment Mechanisms</b></a> from section <a href=
|
|
"#assertion-target"><b>5.1 Assertions and Their Target Use</b></a>
|
|
to section <a href="#general-attachment-guidelines"><b>5.7.1
|
|
General Guidelines</b></a>.</p>
|
|
</li>
|
|
<li>
|
|
<p>Added a new section: <a href="#order-of-behaviors"><b>5.3.5
|
|
Order of Behaviors</b></a>.</p>
|
|
</li>
|
|
<li>
|
|
<p>Dropped an incorrect ignorable example in section <a href=
|
|
"#QName_and_XML_Information_Set_representation"><b>5.3.2 QName and
|
|
XML Information Set representation</b></a>.</p>
|
|
</li>
|
|
<li>
|
|
<p>Rewrote section: <a href="#optional-policy-assertion"><b>5.6
|
|
Designating Optional Behaviors</b></a>.</p>
|
|
</li>
|
|
<li>
|
|
<p>Updated <a href="#references"><b>C. References</b></a>.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div1">
|
|
<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" id=
|
|
"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" 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>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061128</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Replaced section in Lifecycle with
|
|
pointer to the text in the primer: related to action 77</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061129</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Editorial revision (editorial actions
|
|
<a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/84">84</a>
|
|
and <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90">90</a>)
|
|
- includes suggestions from Asir: <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0129.html">
|
|
Part 1</a> and <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0134.html">
|
|
Part 2</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061129</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Formatted examples in <a href=
|
|
"#extending-assertions"><b>6.2 Evolution of Assertions (Versioning
|
|
and Compatibility)</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061218</td>
|
|
<td rowspan="1" colspan="1">FS</td>
|
|
<td rowspan="1" colspan="1">Formatted examples in <a href=
|
|
"#compact-full"><b>5.2 Authoring Styles</b></a> and scenario
|
|
section.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061219</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Editorial revision: most parts of
|
|
editorial action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</a>.
|
|
Remaining editorials to be reviewed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061220</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Editorial revision: completed missing
|
|
parts of editorial action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</a>
|
|
after editorial reviews by co-editors.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061226</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Editorial revision: reconciled terms
|
|
related to "Assertion Authors" <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/106">106</a>
|
|
and bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=3983</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070104</td>
|
|
<td rowspan="1" colspan="1">UY</td>
|
|
<td rowspan="1" colspan="1">Resolution of Issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3982">3982</a> Based
|
|
on <a href=
|
|
"http://www.w3.org/2006/12/06-ws-policy-irc#T18-55-00">Minutes for
|
|
resolution</a>, Minor formatting for consistent use of the term
|
|
"Assertion Author"</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070104</td>
|
|
<td rowspan="1" colspan="1">UY</td>
|
|
<td rowspan="1" colspan="1">Resolution of Issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3980">3980</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070108</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Reset Section <a href=
|
|
"#change-description"><b>E. Changes in this Version of the
|
|
Document</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070122</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Completed action item: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/127">127</a>
|
|
Resolution for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4197">4197</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070130</td>
|
|
<td rowspan="1" colspan="1">UY</td>
|
|
<td rowspan="1" colspan="1">Completed action item: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/144">144</a>.
|
|
Resolution for issues <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3985">3985</a> and
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3986">3986</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070130</td>
|
|
<td rowspan="1" colspan="1">UY</td>
|
|
<td rowspan="1" colspan="1">Completed action item: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/137">137</a>.
|
|
Resolution for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198">4198</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070130</td>
|
|
<td rowspan="1" colspan="1">UY</td>
|
|
<td rowspan="1" colspan="1">Completed action item: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/119">119</a>.
|
|
Resolution for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4141">4141</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070130</td>
|
|
<td rowspan="1" colspan="1">UY</td>
|
|
<td rowspan="1" colspan="1">Completed action item: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/126">126</a>.
|
|
Resolution for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4188">4188</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070130</td>
|
|
<td rowspan="1" colspan="1">UY</td>
|
|
<td rowspan="1" colspan="1">Fixed SAWSDL ref name</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070131</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Fixed numerous spelling and typo
|
|
errors. Implement resolution for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953">3953</a> as
|
|
noted in message <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0090.html">
|
|
90</a> and amended as noted in message <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0217.html">
|
|
217</a>. Changes correspond to editor's action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/152">152</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070221</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Partial implementation for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072">4072</a> in
|
|
response to editor's action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/154">154</a>
|
|
. NOTE ALSO- I needed to put back in the "prefix" entity defintion
|
|
[line7] to get the build to work.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070306</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented partial <a href=
|
|
"http://www.w3.org/2007/01/31-ws-policy-minutes.html#item10">resolution</a>
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3987">3987</a>.
|
|
Related editorial action is <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/153">153</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070308</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Changed "lifecycle" spec references to
|
|
versioning to fix build.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070314</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented <a href=
|
|
"http://www.w3.org/2007/03/14-ws-policy-irc#T18-14-48">resolution</a>
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072">4072</a> as
|
|
outlined in <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0103.html">
|
|
proposal</a>. Editorial action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/204">204</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070314</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented <a href=
|
|
"http://www.w3.org/2007/03/14-ws-policy-irc#T18-07-08">resolution</a>
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3987">3987</a> as
|
|
outlined in <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0096.html">
|
|
proposal</a>. Editorial action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/203">203</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070315</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979#c1">resolution</a>
|
|
for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979">issue
|
|
3979</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/198">198</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070315</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0000.html">
|
|
resolution</a> for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3981">issue
|
|
3981</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/205">205</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070315</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented <a href=
|
|
"http://www.w3.org/2007/03/13-ws-policy-irc#T23-08-08">resolution</a>
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4035">4035</a> as
|
|
outlined in <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0169.html">
|
|
proposal</a>. Editorial action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197">197</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070319</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Implemented resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4073">4073</a> in
|
|
response to editor's action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/199">199</a>
|
|
as outlined in <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0093.html">
|
|
proposal</a> .</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070320</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319#c1">resolution</a>
|
|
for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319">issue
|
|
4319</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/206">206</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070320</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990#c1">resolution</a>
|
|
for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990">issue
|
|
3990</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/210">210</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070320</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212#c1">resolution</a>
|
|
for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212">issue
|
|
4212</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/207">207</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070321</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Updated section <a href=
|
|
"#change-description"><b>E. Changes in this Version of the
|
|
Document</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070329</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Changed all <p>Best Practice: to
|
|
<p role="practice"></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070416</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Updated 6.2 and 6.3 for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
|
|
3989</a>. Note, removed one best practice that was a dup.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070423</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Updated 5.5 Designating Optional
|
|
Behaviors for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
|
|
3989</a>. Added informative reference for MTOMPolicy. Added two
|
|
best practices, one is similar to G16 but focused on optional.
|
|
Revised practice that was there.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070425</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Updated 5.3 "Considerations when
|
|
Modeling New Assertions" related to <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
|
|
3989</a>. [Editorial Action 229] Restructured text to follow
|
|
examples</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070425</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Updated 5.2 Authoring Styles for
|
|
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
|
|
3989</a> and editors' action item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227">227</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070426</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Editorial changes to align with the
|
|
OASIS WS-SecurityPolicy specification. For <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4318">issue
|
|
4318</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/245">245</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070427</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Updated 5.5.1 Optional behavior in
|
|
Compact authoring adding G7 and G8 for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
|
|
and editors' action item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/250">250</a>
|
|
as noted in <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0069.html">
|
|
message 69</a>. Also replaced TBD in section 2 with descriptive
|
|
text."</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070501</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Reset Section <a href=
|
|
"#change-description"><b>E. Changes in this Version of the
|
|
Document</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070507</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Updated 5.6 WSDL guidelines section, to
|
|
follow the new format and added G15, G16, G17 and G18. Accounts for
|
|
parts of resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
|
|
corresponding to editors' action items <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">232</a>,
|
|
<a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">253</a>,
|
|
and <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070507</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Updated 5.1 Assertions and their Target
|
|
Use for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
|
|
and editors' action item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227">227</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070508</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Updated Section 5 for adding guidelines
|
|
G9, G10 on ignorable, and G5 , G6 (general) to address editors'
|
|
action items <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/251">251</a>.
|
|
<a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/256">256</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070511</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Updated 5.6 WSDL guidelines section to
|
|
add G19 identified in AI 256 (now G24). Accounts for parts of
|
|
resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
|
|
corresponding to editors' action item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</a>
|
|
- now complete.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070513</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Updated Section 5.4.1 to use the new
|
|
format re issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
|
|
3989</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/230">230</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070514</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Updated Section 5.4.2 to use the new
|
|
format re issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
|
|
3989</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/230">230</a>.
|
|
Collapsed Section 5.4.2 and 5.4.3.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070514</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Added G11 and G13 to Section 5.4.1 and
|
|
5.4.2 re issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
|
|
3989</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/252">252</a>
|
|
and <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/255">255</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070516</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Editorial change to section 5.7 to
|
|
place best practices after the associated explanatory text and to
|
|
fix grammar.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070518</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Ensured Best Practices G1, G3 and G20
|
|
of <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">
|
|
original IBM/MS Contribution</a> are reflected.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070518</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Updated Appendix E, Changes in this
|
|
Version of the Document (<a href="#change-description"><b>E.
|
|
Changes in this Version of the Document</b></a>).</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070520</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Added Best Practice <a href=
|
|
"#bp-specify-composition"><b>31. Specify Composition with Related
|
|
Assertions</b></a> (from the <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">
|
|
IBM and MS Contribution</a> to <a href=
|
|
"#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added
|
|
an ed note that Section <a href="#interrelated-domains"><b>5.8
|
|
Interrelated domains</b></a> needs to be re-structured.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070520</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Added Best Practice <a href=
|
|
"#bp-not-necessary-to-understand-a-message"><b>11. Assertions
|
|
should not describe message semantics</b></a> (from the <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">
|
|
IBM and MS Contribution</a> to <a href="#self-describing"><b>5.3.3
|
|
Self Describing Messages</b></a> .</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070520</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Added an ed note that Section <a href=
|
|
"#Ignorable"><b>5.5 Designating Ignorable Behavior</b></a> looks
|
|
incomplete.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070520</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Fixed typos.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070520</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Added an ed note in Section <a href=
|
|
"#assertion-target"><b>5.1 Assertions and Their Target Use</b></a>
|
|
that there is an open issue against Best Practice G2.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070524</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Editorial changes to align with the W3C
|
|
WS-Addressing Metadata specification. For <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4375">issue
|
|
4375</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/284">284</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070529</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4573">issue
|
|
4573</a>. Apply "Best Practices" consistently.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070529</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/290">290</a>.
|
|
Consistent use of Assertion Authors.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070529</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/291">291</a>.
|
|
Consistent use of should in place of must in the best practice
|
|
statements.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070529</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/294">294</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070530</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/303">303</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070530</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/304">304</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070530</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/305">305</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070530</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/306">306</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070530</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/307">307</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070530</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/3087">308</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070601</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
actions <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/310">310</a>
|
|
and <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/311">311</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">200706013</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
|
|
actions <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/292">292</a>
|
|
and <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/293">293</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">200706016</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/289">289</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070616</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4074">4074</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/286">286</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">200706018</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/295">295</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">200706018</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented place holder for Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/249">249</a>
|
|
for locking the document.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070713</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Restructured and updated <a href=
|
|
"#interrelated-domains"><b>5.8 Interrelated domains</b></a> to use
|
|
Architecture of WWW format and add example, according to Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/309">309</a>.
|
|
Updated the WSDL 20 reference [<cite><a href="#WSDL20">WSDL 2.0
|
|
Core Language</a></cite>] and WS-SecurityPolicy reference
|
|
[<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4831">4831</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/326">326</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070717</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4853">4853</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/333">333</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070717</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4852">4852</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070717</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Implemented partial resolution, section
|
|
5.5 updates, for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4662">4662</a>,
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</a>
|
|
#2.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3988">3988</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/338">338</a>,
|
|
drop <a href=
|
|
"http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#scenario">
|
|
Section 7 Scenario and a worked example</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3978">3978</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/339">339</a>,
|
|
drop <a href=
|
|
"http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#best-practices-attachment">
|
|
Section 6 Applying Best Practices for Policy Attachment</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4661">4661</a>,
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4662">4662</a>,
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4861">4861</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</a>,
|
|
<a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/346">346</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4664">4664</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/343">343</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4566">4566</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/249">249</a>,
|
|
<a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/328">328</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4862">4862</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/348">348</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4654">4654</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/340">340</a>.
|
|
Add new section <a href="#general-attachment-guidelines"><b>5.7.1
|
|
General Guidelines</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Updated Web Services Reliable Messaging
|
|
Policy reference [<cite><a href="#WS-RM-Policy">Web Services
|
|
Reliable Messaging Policy Assertion</a></cite>] and WS-Addressing
|
|
Metadata reference [<cite><a href=
|
|
"#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>].
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/331">331</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070719</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4859">4859</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/335">335</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070727</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4660">4660</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070727</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4695">4695</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">347</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070727</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Updated Section <a href=
|
|
"#change-description"><b>E. Changes in this Version of the
|
|
Document</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070806</td>
|
|
<td rowspan="1" colspan="1">FS</td>
|
|
<td rowspan="1" colspan="1">Updated references for draft
|
|
publication.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070912</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5041">5041</a>.
|
|
Editors' action: <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">356</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070912</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5043">5043</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/357">357</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070913</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4861">4861</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/353">353</a>
|
|
with the caveats and clarifications expressed in message <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2007Sep/0002.html">
|
|
2007Sep-0002</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070921</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5044">5044</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/358">358</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070921</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Updated references [<cite><a href=
|
|
"#WS-Policy">Web Services Policy Framework</a></cite>] and
|
|
[<cite><a href="#WS-PolicyAttachment">Web Services Policy
|
|
Attachment</a></cite>].</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070921</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Reset Section <a href=
|
|
"#change-description"><b>E. Changes in this Version of the
|
|
Document</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071017</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5128">5128</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/371">371</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071017</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5185">5185</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/373">373</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071024</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5184">5184</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/372">372</a>.
|
|
Implemented as originally proposed b,c,e,f,h,j. Implemented as
|
|
amended a, k,l. Did not implement g which was not processed by
|
|
WG.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071024</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5186">5186</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/374">374</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5206">5206</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/379">379</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5189">5189</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/381">381</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Fixed typos (re <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5206">5206</a> and
|
|
editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/379">379</a>).
|
|
s/Example 1/SignBeforeEncrypting assertion/ and s/Example
|
|
2/EncryptBeforeSigning assertion/ in <a href=
|
|
"#order-of-behaviors"><b>5.3.5 Order of Behaviors</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Fixed incorrect changes (re <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5184">5184</a> and
|
|
editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/372">372</a>).
|
|
a) s/Supporting New Policy Subjects/(see Section 6.3 Supporting New
|
|
Policy Subjects)/ and b) s/6.3 Supporting New Policy Subjects (see
|
|
Section 6.3 Supporting New Policy Subjects)/6.3 Supporting New
|
|
Policy Subjects/.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Applied missed changes (re <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5186">5186</a> and
|
|
editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/374">374</a>)
|
|
to <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> and
|
|
<a href="#references"><b>C. References</b></a>. Fixed SOAP 1.2, Web
|
|
Services Reliable Messaging, Web Services Reliable Messaging Policy
|
|
Assertion, WS-SecurityPolicy and WS-Trust references.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Updated <a href=
|
|
"#change-description"><b>E. Changes in this Version of the
|
|
Document</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071029</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Incorporated Chris' proposed resolution
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5218">5218</a>: drop
|
|
the second sentence in <a href=
|
|
"#bp-semantics-multiple-same-type"><b>21. Describe Semantics of
|
|
Multiple Assertions of Same Type</b></a>, "If there are multiple
|
|
instances of a policy assertion type in the same policy alternative
|
|
without parameters and nested policies, these have the same meaning
|
|
as a single assertion of the type within the policy alternative."
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/384">384</a>.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<br /></div>
|
|
</div>
|
|
</body>
|
|
</html>
|