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.
3774 lines
164 KiB
3774 lines
164 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 - Primer</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 -
|
|
Primer</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-primer-20071112">http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/ws-policy-primer">http://www.w3.org/TR/ws-policy-primer</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2007/WD-ws-policy-primer-20070928">http://www.w3.org/TR/2007/WD-ws-policy-primer-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-primer.pdf">PDF</a>, <a href=
|
|
"ws-policy-primer.ps">PostScript</a>, <a href=
|
|
"ws-policy-primer.xml">XML</a>, and <a href=
|
|
"ws-policy-primer.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 - Primer</em> is an introductory
|
|
description of the Web Services Policy language. This document
|
|
describes the policy language features using numerous examples. The
|
|
associated Web Services Policy 1.5 - Framework and Web Services
|
|
Policy 1.5 - Attachment specifications provide the complete
|
|
normative description of the Web Services Policy language.</p>
|
|
</div>
|
|
<div>
|
|
<h2><a name="status" 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 - Primer
|
|
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-primer-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-primer].</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="#basic-concepts-policy-expression">Basic Concepts:
|
|
Policy Expression</a><br />
|
|
2.1 <a href="#web-services-policy">Web
|
|
Services Policy</a><br />
|
|
2.2 <a href="#simple-message">Simple
|
|
Message</a><br />
|
|
2.3 <a href="#secure-message">Secure
|
|
Message</a><br />
|
|
2.4 <a href="#other-assertions">Other
|
|
Assertions</a><br />
|
|
2.5 <a href=
|
|
"#combining-policy-assertions">Combining Policy
|
|
Assertions</a><br />
|
|
2.6 <a href=
|
|
"#optional-policy-assertion">Optional Policy Assertion</a><br />
|
|
2.7 <a href=
|
|
"#ignorable-policy-assertions">Ignorable Policy
|
|
Expressions</a><br />
|
|
2.8 <a href=
|
|
"#Both-Optional-Ignorable">Marking Assertions both Optional and
|
|
Ignorable</a><br />
|
|
2.9 <a href=
|
|
"#nested-policy-expressions">Nested Policy Expressions</a><br />
|
|
2.10 <a href=
|
|
"#Referencing_Policy_Expressions">Referencing Policy
|
|
Expressions</a><br />
|
|
2.11 <a href=
|
|
"#attaching-policy-expressions-to-wsdl">Attaching Policy
|
|
Expressions to WSDL</a><br />
|
|
2.12 <a href=
|
|
"#policy-automates-web-services-interaction">Policy Automates Web
|
|
Services Interaction</a><br />
|
|
3. <a href="#advanced-concepts-policy-expression">Advanced
|
|
Concepts: Policy Expression</a><br />
|
|
3.1 <a href="#policy-expression">Policy
|
|
Expression</a><br />
|
|
3.2 <a href=
|
|
"#normal-form-for-policy-expressions">Normal Form for Policy
|
|
Expressions</a><br />
|
|
3.3 <a href="#policy-data-model">Policy
|
|
Data Model</a><br />
|
|
3.4 <a href=
|
|
"#compatible-policies">Compatible Policies</a><br />
|
|
3.4.1 <a href=
|
|
"#strict-lax-policy-intersection">Strict and Lax Policy
|
|
Intersection</a><br />
|
|
3.5 <a href=
|
|
"#attaching-policy-expressions-to-wsdl2">Attaching Policy
|
|
Expressions to WSDL</a><br />
|
|
3.6 <a href="#policy-retrieval">Policy
|
|
Retrieval</a><br />
|
|
3.7 <a href="#combine-policies">Combine
|
|
Policies</a><br />
|
|
3.8 <a href=
|
|
"#extensibility-and-versioning">Extensibility and
|
|
Versioning</a><br />
|
|
3.8.1 <a href=
|
|
"#ext-vers-policylanguage">Policy Language</a><br />
|
|
3.8.2 <a href=
|
|
"#d3e1496">Policy Expressions</a><br />
|
|
3.8.3 <a href=
|
|
"#ignorable-and-versioning">Use of Ignorable attribute and an
|
|
alternative Versioning Scenario</a><br />
|
|
3.8.4 <a href=
|
|
"#ignorable-and-optional-and-versioning">Use of Ignorable and
|
|
Optional attributes</a><br />
|
|
3.9 <a href=
|
|
"#parts-of-a-policy-assertion">Parts of a Policy
|
|
Assertion</a><br />
|
|
4. <a href="#versioning-policy-language">Versioning Policy
|
|
Language</a><br />
|
|
4.1 <a href=
|
|
"#versioning-policy-framework">Policy Framework</a><br />
|
|
4.2 <a href=
|
|
"#versioning-policy-attachment">Policy Attachment</a><br />
|
|
5. <a href="#conclusion">Conclusion</a><br /></p>
|
|
<h3><a name="appendices" id="appendices"></a>Appendices</h3>
|
|
<p class="toc">A. <a href="#security-considerations">Security
|
|
Considerations</a><br />
|
|
B. <a href="#xml-namespaces">XML Namespaces</a><br />
|
|
C. <a href="#references">References</a><br />
|
|
D. <a href="#acknowledgments">Acknowledgements</a>
|
|
(Non-Normative)<br />
|
|
E. <a href="#change-description">Changes in this Version of the
|
|
Document</a> (Non-Normative)<br />
|
|
F. <a href="#change-log">Web Services Policy 1.5 - Primer Change
|
|
Log</a> (Non-Normative)<br /></p>
|
|
</div>
|
|
<hr />
|
|
<div class="body">
|
|
<div class="div1">
|
|
<h2><a name="introduction" id="introduction"></a>1.
|
|
Introduction</h2>
|
|
<p>This document, <em>Web Services Policy 1.5 - Primer</em>,
|
|
provides an introductory description of the Web Services Policy
|
|
language and should be read alongside the formal descriptions
|
|
contained in the WS-Policy and WS-PolicyAttachment
|
|
specifications.</p>
|
|
<p>This document is:</p>
|
|
<ul>
|
|
<li>
|
|
<p>for policy expression authors who need to understand the syntax
|
|
of the language and understand how to build consistent policy
|
|
expressions,</p>
|
|
</li>
|
|
<li>
|
|
<p>for policy implementers whose software modules read and write
|
|
policy expressions and</p>
|
|
</li>
|
|
<li>
|
|
<p>for policy assertion authors who need to know the features of
|
|
the language and understand the requirements for describing policy
|
|
assertions.</p>
|
|
</li>
|
|
</ul>
|
|
<p>This document assumes a basic understanding of XML 1.0,
|
|
Namespaces in XML, WSDL 1.1 and SOAP.</p>
|
|
<p>Each major section of this document introduces the features of
|
|
the policy language and describes those features in the context of
|
|
concrete examples.</p>
|
|
<p><a href="#basic-concepts-policy-expression"><b>2. Basic
|
|
Concepts: Policy Expression</b></a> covers the basic mechanisms of
|
|
Web Services Policy. It describes how to declare and combine
|
|
capabilities and requirements of a Web service as policy
|
|
expressions, attach policy expressions to WSDL constructs such as
|
|
endpoint and message, and re-use policy expressions.</p>
|
|
<p><a href="#advanced-concepts-policy-expression"><b>3. Advanced
|
|
Concepts: Policy Expression</b></a> this is the advanced section
|
|
that provides more in-depth materials for policy implementers and
|
|
assertion authors. It explains the basics of normalizing policy
|
|
expressions, merging policies, determining the compatibility
|
|
(intersection) of policies, the policy data model, the policy
|
|
expression and the extensibility points built into the Web Services
|
|
Policy language.</p>
|
|
<p><a href="#versioning-policy-language"><b>4. Versioning Policy
|
|
Language</b></a> provides examples and best practices on versioning
|
|
of the policy language itself, mostly intended for policy
|
|
implementers.</p>
|
|
<p>The Web Services Policy 1.5 - Guidelines for Policy Assertion
|
|
Authors specification provides guidelines for designing policy
|
|
assertions and enumerates the minimum requirements for describing
|
|
policy assertions in specifications.</p>
|
|
<p>This is a non-normative document and does not provide a
|
|
definitive specification of the Web Services Policy language.
|
|
<a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all
|
|
the namespaces that are used in this document. (XML elements
|
|
without a namespace prefix are from the Web Services Policy XML
|
|
Namespace.)</p>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="basic-concepts-policy-expression" id=
|
|
"basic-concepts-policy-expression"></a>2. Basic Concepts: Policy
|
|
Expression</h2>
|
|
<div class="div2">
|
|
<h3><a name="web-services-policy" id="web-services-policy"></a>2.1
|
|
Web Services Policy</h3>
|
|
<p>Web services are being successfully used for interoperable
|
|
solutions across various industries. One of the key reasons for
|
|
interest and investment in Web services is that they are
|
|
well-suited to enable service-oriented systems. XML-based
|
|
technologies such as SOAP, XML Schema and WSDL provide a
|
|
broadly-adopted foundation on which to build interoperable Web
|
|
services. The WS-Policy and WS-PolicyAttachment specifications
|
|
extend this foundation and offer mechanisms to represent the
|
|
capabilities and requirements of Web services as Policies.</p>
|
|
<p>Service metadata is an expression of the visible aspects of a
|
|
Web service, and consists of a mixture of machine- and
|
|
human-readable languages. Machine-readable languages enable
|
|
tooling. For example, tools that consume service metadata can
|
|
automatically generate client code to call the service. Service
|
|
metadata can describe different parts of a Web service and thus
|
|
enable different levels of tooling support.</p>
|
|
<p>First, service metadata can describe the format of the payloads
|
|
that a Web service sends and receives. Tools can use this metadata
|
|
to automatically generate and validate data sent to and from a Web
|
|
service. The XML Schema language is frequently used to describe the
|
|
message interchange format within the SOAP message construct, i.e.
|
|
to represent SOAP Body children and SOAP Header blocks.</p>
|
|
<p>Second, service metadata can describe the ‘how’ and ‘where’ a
|
|
Web service exchanges messages, i.e. how to represent the concrete
|
|
message format, what headers are used, the transmission protocol,
|
|
the message exchange pattern and the list of available endpoints.
|
|
The Web Services Description Language is currently the most common
|
|
language for describing the ‘how’ and ‘where’ a Web service
|
|
exchanges messages. WSDL has extensibility points that can be used
|
|
to expand on the metadata for a Web service.</p>
|
|
<p>Third, service metadata can describe the capabilities and
|
|
requirements of a Web service, i.e. representing whether and how a
|
|
message must be secured, whether and how a message must be
|
|
delivered reliably, whether a message must flow a transaction, etc.
|
|
Exposing this class of metadata about the capabilities and
|
|
requirements of a Web service enables tools to generate code
|
|
modules for engaging these behaviors. Tools can use this metadata
|
|
to check the compatibility of requesters and providers. Web
|
|
Services Policy can be used to represent the capabilities and
|
|
requirements of a Web service.</p>
|
|
<p>Web Services Policy is a machine-readable language for
|
|
representing the capabilities and requirements of a Web service.
|
|
These are called ‘policies’. Web Services Policy offers mechanisms
|
|
to represent consistent combinations of capabilities and
|
|
requirements, to determine the compatibility of policies, to name
|
|
and reference policies and to associate policies with Web service
|
|
metadata constructs such as service, endpoint and operation. Web
|
|
Services Policy is a simple language that has four elements -
|
|
<code>Policy, All</code>, <code>ExactlyOne</code> and
|
|
<code>PolicyReference</code> - and two attributes -
|
|
<code>wsp:Optional</code> and <code>wsp:Ignorable</code>.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="simple-message" id="simple-message"></a>2.2 Simple
|
|
Message</h3>
|
|
<p>Let us start by considering a SOAP Message in the example
|
|
below.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-1.</span> SOAP Message</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<soap:Envelope>
|
|
<soap:Header>
|
|
<wsa:To>http://x.example.com/realquote</wsa:To>
|
|
<wsa:Action>http://x.example.com/GetRealQuote</wsa:Action>
|
|
</soap:Header>
|
|
<soap:Body>…</soap:Body>
|
|
</soap:Envelope>
|
|
</pre></div>
|
|
</div>
|
|
<p>This message uses message addressing headers. The
|
|
<code>wsa:To</code> and <code>wsa:Action</code> header blocks
|
|
identify the destination and the semantics implied by this message
|
|
respectively. (The prefix <code>wsa</code> is used here to denote
|
|
the Web Services Addressing XML Namespace. <a href=
|
|
"#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the
|
|
namespaces and prefixes that are used in this document.)</p>
|
|
<p>Let us look at a fictitious scenario used in this document to
|
|
illustrate the features of the policy language. A Web service
|
|
developer is building a client application that retrieves real time
|
|
stock quote information from Company-X, Ltd. Company-X supplies
|
|
real time data using Web services. The developer has Company-X’s
|
|
advertised WSDL description of these Web services. Company-X
|
|
requires the use of addressing headers for messaging. Just the WSDL
|
|
description is not sufficient for the developer to enable the
|
|
interaction between her client and these Web services. WSDL
|
|
constructs do not indicate requirements such as the use of
|
|
addressing.</p>
|
|
<p>(<em>The example companies, organizations, products, domain
|
|
names, e-mail addresses, logos, people, places, and events depicted
|
|
herein are fictitious. No association with any real company,
|
|
organization, product, domain name, email address, logo, person,
|
|
places, or events is intended or should be inferred.</em>)</p>
|
|
<p>Providers have the option to convey requirements, such as the
|
|
use of addressing, through word-of-mouth and documentation – as
|
|
they always have. To interact successfully with this service, the
|
|
developer may have to read any related documentation, call someone
|
|
at Company-X to understand the service metadata, or look at sample
|
|
SOAP messages and infer such requirements or behaviors.</p>
|
|
<p>Web Services Policy is a machine-readable language for
|
|
representing these Web service capabilities and requirements as
|
|
policies. Policy makes it possible for providers to represent such
|
|
capabilities and requirements in a machine-readable form. For
|
|
example, Company-X may augment the service WSDL description with a
|
|
policy that requires the use of addressing. The client application
|
|
developer can use a policy-aware client that understands this
|
|
policy and engages addressing automatically.</p>
|
|
<p>How does Company-X use policy to represent the use of
|
|
addressing? The example below illustrates a policy expression that
|
|
requires the use of addressing.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-2.</span> Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The policy expression in the above example consists of a Policy
|
|
main element and a child element wsam:Addressing. Child elements of
|
|
the Policy element that are not from the Policy namespace are
|
|
policy assertions. Company-X attaches the above policy expression
|
|
to a WSDL binding description.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-3.</span> Policy Expression Attached to Binding</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" >
|
|
<Policy>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
…
|
|
</wsdl:binding>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>Policies can also be attached to WSDL using references (See
|
|
<a href="#Referencing_Policy_Expressions"><b>2.10 Referencing
|
|
Policy Expressions</b></a>.)</p>
|
|
<p>The <code>wsam:Addressing</code> element is a policy assertion.
|
|
(The prefix <code>wsam</code> is used here to denote the Web
|
|
Services Addressing – Metadata XML Namespace.) This assertion
|
|
identifies the use of Web Services Addressing information headers.
|
|
A policy-aware client can recognize this policy assertion, engage
|
|
addressing automatically, and use headers such as
|
|
<code>wsa:To</code> and <code>wsa:Action</code> in SOAP
|
|
Envelopes.</p>
|
|
<p>It is important to understand the association between the SOAP
|
|
message and policy expression in the above example. As you can see
|
|
by careful examination of the message, there is no reference to any
|
|
policy expression. Just as WSDL does not require a message to
|
|
reference WSDL constructs (such as port, binding and portType), Web
|
|
Services Policy does not require a message to reference a policy
|
|
expression though the policy expression describes the message.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="secure-message" id="secure-message"></a>2.3 Secure
|
|
Message</h3>
|
|
<p>In addition to requiring the use of addressing, Company-X
|
|
requires the use of transport-level security for protecting
|
|
messages.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-4.</span> Secure Message</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<soap:Envelope>
|
|
<soap:Header>
|
|
<wss:Security soap:mustUnderstand="1" >
|
|
<wsu:Timestamp wsu:Id="_0">
|
|
<wsu:Created>2006-01-19T02:49:53.914Z</u:Created>
|
|
<wsu:Expires>2006-01-19T02:54:53.914Z</u:Expires>
|
|
</wsu:Timestamp>
|
|
</wss:Security>
|
|
<wsa:To>http://x.example.com/quote</wsa:To>
|
|
<wsa:Action>http://x.example.com/GetRealQuote</wsa:Action>
|
|
</soap:Header>
|
|
<soap:Body>…</soap:Body>
|
|
</soap:Envelope>
|
|
</pre></div>
|
|
</div>
|
|
<p>The SOAP message in the example above includes security
|
|
timestamps that express creation and expiration times of this
|
|
message. Company-X requires the use of security timestamps and
|
|
transport-level security - such as <code>HTTPS</code> – for
|
|
protecting messages. (The prefixes <code>wss</code> and
|
|
<code>wsu</code> are used here to denote the Web Services Security
|
|
and Utility namespaces.)</p>
|
|
<p>Similar to the use of addressing, Company-X indicates the use of
|
|
transport-level security using a policy expression. The example
|
|
below illustrates a policy expression that requires the use of
|
|
addressing and transport-level security for securing messages.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-5.</span> Addressing and Security Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The <code>sp:TransportBinding</code> element is a policy
|
|
assertion. (The prefix <code>sp</code> is used here to denote the
|
|
Web Services Security Policy XML Namespace.) This assertion
|
|
identifies the use of transport-level security – such as
|
|
<code>HTTPS</code> - for protecting messages. Policy-aware clients
|
|
can recognize this policy assertion, engage transport-level
|
|
security for protecting messages and include security timestamps in
|
|
SOAP Envelopes.</p>
|
|
<p>The client application developer can use a policy-aware client
|
|
that recognizes this policy expression and engages both addressing
|
|
and transport-level security automatically.</p>
|
|
<p>For the moment, let us set aside the contents of the
|
|
<code>sp:TransportBinding</code> policy assertion and consider its
|
|
details in a later section.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="other-assertions" id="other-assertions"></a>2.4 Other
|
|
Assertions</h3>
|
|
<p>Thus far, we explored how Company-X uses policy expressions and
|
|
assertions for representing behaviors that must be engaged for a
|
|
Web service interaction. What is a policy assertion? What role does
|
|
it play? In brief, a policy assertion is a piece of service
|
|
metadata, and it identifies a domain (such as messaging, security,
|
|
reliability and transaction) specific behavior that is a
|
|
requirement. Company-X uses a policy assertion to convey a
|
|
condition under which they offer a Web service. A policy-aware
|
|
client can recognize policy assertions and engage these behaviors
|
|
automatically.</p>
|
|
<p>Providers, like Company-X, have the option to combine behaviors
|
|
for an interaction from domains such as messaging, security,
|
|
reliability and transactions. Using policy assertions, providers
|
|
can represent these behaviors in a machine-readable form. Web
|
|
service developers can use policy-aware clients that recognize
|
|
these assertions and engage these behaviors automatically.</p>
|
|
<p>Who defines policy assertions? Where are they? Policy assertions
|
|
are defined by Web services developers, product designers, protocol
|
|
authors and users. Like XML Schema libraries, policy assertions are
|
|
a growing collection. Several WS-* protocol specifications and
|
|
applications define policy assertions:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Web Services Security Policy [<cite><a href=
|
|
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]</p>
|
|
</li>
|
|
<li>
|
|
<p>Web Services Reliable Messaging Policy [<cite><a href=
|
|
"#WS-RM-Policy">Web Services Reliable Messaging Policy
|
|
Assertion</a></cite>]</p>
|
|
</li>
|
|
<li>
|
|
<p>Web Services Atomic Transaction [<cite><a href="#WS-Atomic">Web
|
|
Services Atomic Transaction</a></cite>]</p>
|
|
</li>
|
|
<li>
|
|
<p>Web Services Business Activity Framework [<cite><a href=
|
|
"#WS-BA">Web Services Business Activity Framework</a></cite>]</p>
|
|
</li>
|
|
<li>
|
|
<p>Devices Profile for Web Services [<cite><a href=
|
|
"#WS-Device">Devices Profile for Web Services</a></cite>]</p>
|
|
</li>
|
|
<li>
|
|
<p>…</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="combining-policy-assertions" id=
|
|
"combining-policy-assertions"></a>2.5 Combining Policy
|
|
Assertions</h3>
|
|
<p>Policy assertions can be combined in different ways to express
|
|
consistent combinations of behaviors (capabilities and
|
|
requirements). There are three policy operators for combining
|
|
policy assertions: <code>Policy</code>, <code>All</code> and
|
|
<code>ExactlyOne</code> (the <code>Policy</code> operator is a
|
|
synonym for <code>All).</code></p>
|
|
<p>Let us consider the <code>All</code> operator first. The policy
|
|
expression in the example below requires the use of addressing and
|
|
transport-level security. There are two policy assertions. These
|
|
assertions are combined using the <code>All</code> operator.
|
|
Combining policy assertions using the <code>Policy</code> or
|
|
<code>All</code> operator means that all the behaviors represented
|
|
by these assertions are required.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-6.</span> Addressing and Security Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<All>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
</pre></div>
|
|
</div>
|
|
<p>In addition to requiring the use of addressing, Company-X allows
|
|
either the use of transport- or message-level security for
|
|
protecting messages. Web Services Policy language can indicate this
|
|
choice of behaviors in a machine-readable form. To indicate the use
|
|
of message-level security for protecting messages, Company-X uses
|
|
the <code>sp:AsymmetricBinding</code> policy assertion (see the
|
|
example below).</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-7.</span> Asymmetric Binding Security Policy Assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
|
|
</pre></div>
|
|
</div>
|
|
<p>The <code>sp:AsymmetricBinding</code> element is a policy
|
|
assertion. (The prefix <code>sp</code> is used here to denote the
|
|
Web Services Security Policy namespace.) This assertion identifies
|
|
the use of message-level security – such as <em>WS-Security
|
|
1.0</em> - for protecting messages. Policy-aware clients can
|
|
recognize this policy assertion, engage message-level security for
|
|
protecting messages and use headers such as
|
|
<code>wss:Security</code> in SOAP Envelopes.</p>
|
|
<p>To allow the use of either transport- or message-level security,
|
|
Company-X uses the <code>ExactlyOne</code> policy operator. Policy
|
|
assertions combined using the <code>ExactlyOne</code> operator
|
|
requires exactly one of the behaviors represented by the
|
|
assertions. The policy expression in the example below requires the
|
|
use of either transport- or message-level security for protecting
|
|
messages.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-8.</span> Transport- or Message-Level Security Policy
|
|
Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
|
|
</ExactlyOne>
|
|
</pre></div>
|
|
</div>
|
|
<p>Company-X requires the use of addressing and requires the use of
|
|
either transport- or message-level security for protecting
|
|
messages. They represent this combination using the
|
|
<code>All</code> and <code>ExactlyOne</code> operators. Policy
|
|
operators can be mixed to represent different combinations of
|
|
behaviors (capabilities and requirements). The policy expression in
|
|
the example below requires the use of addressing and one of
|
|
transport- or message-level security for protecting messages.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-9.</span> Addressing and Transport- OR Message-Level Security
|
|
Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<All>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
|
|
</ExactlyOne>
|
|
</All>
|
|
</pre></div>
|
|
</div>
|
|
<p>Using this policy expression, Company-X gives the choice of
|
|
mechanisms for protecting messages to clients (or requesters).</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="optional-policy-assertion" id=
|
|
"optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3>
|
|
<p>Through a customer survey program, Company-X learns that a
|
|
significant number of their customers prefer to use the Optimized
|
|
MIME Serialization (as defined in the MTOM specification) for
|
|
sending and receiving messages. Company-X adds optional support for
|
|
the Optimized MIME Serialization and expresses this optional
|
|
behavior in a machine-readable form.</p>
|
|
<p>To indicate the use of optimization using the Optimized MIME
|
|
Serialization, Company-X uses the
|
|
<code>mtom:OptimizedMimeSerialization</code> policy assertion (see
|
|
the example below).</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-10.</span> Optimized MIME Serialization Policy Assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<mtom:OptimizedMimeSerialization />
|
|
</pre></div>
|
|
</div>
|
|
<p>The <code>mtom:OptimizedMimeSerialization</code> element is a
|
|
policy assertion. (The prefix <code>mtom</code> is used here to
|
|
denote the Optimized MIME Serialization Policy namespace.) This
|
|
assertion identifies the use of MIME Multipart/Related
|
|
serialization as required for request and response messages.
|
|
Policy-aware clients can recognize this policy assertion and engage
|
|
Optimized MIME Serialization for messages. The semantics of this
|
|
assertion are reflected in messages: they use an optimized wire
|
|
format (MIME Multipart/Related serialization).</p>
|
|
<p>Like Company-X’s optional support for Optimized MIME
|
|
Serialization, there are behaviors that may be engaged (in contrast
|
|
to must be engaged) for a Web service interaction. A service
|
|
provider will not fault if these behaviors are not engaged. Policy
|
|
assertions can be marked optional to represent behaviors that may
|
|
be engaged for an interaction. A policy assertion is marked as
|
|
optional using the <code>wsp:Optional</code> attribute. Optional
|
|
assertions represent the capabilities of the service provider as
|
|
opposed to the requirements of the service provider.</p>
|
|
<p>In the example below, the Optimized MIME Serialization policy
|
|
assertion is marked optional. This policy expression allows the use
|
|
of optimization and requires the use of addressing and one of
|
|
transport- or message-level security. If a client sends an
|
|
optimized (MTOM) message, this will be indicated by characteristics
|
|
associated by using such an optimized message, including a wire
|
|
format that is a Multipart/Related message and a content-type
|
|
header of "application/xop+xml" for the outer package. In this
|
|
case, the response message will also be optimized, also having a
|
|
Multipart/Related message and content-type header of
|
|
"application/xop+xml". Note that when optimized messages are used,
|
|
the Multipart/Related message can have a single part containing the
|
|
primary SOAP envelope.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-11.</span> Optional MIME Serialization, Addressing and Transport-
|
|
OR Message-Level Security Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<All>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
|
|
</ExactlyOne>
|
|
</All>
|
|
</pre></div>
|
|
</div>
|
|
<p>Company-X is able to meet their customer needs by adding
|
|
optional support for the Optimized MIME Serialization. Optional
|
|
support is outlined in section 3.4 Web Services Policy 1.5 -
|
|
Framework and detailed in section 4.5.2, Web Services Policy 1.5 -
|
|
Guidelines for Policy Assertion Authors, specifically for Optimized
|
|
MIME Serialization. An optional policy assertion represents a
|
|
behavior that may be engaged. When that policy assertion is absent
|
|
from a policy alternative (See section 3.2, Web Services Policy 1.5
|
|
- Framework), a policy-aware client should not conclude anything
|
|
(other than ‘no claims’) about the absence of that policy
|
|
assertion. See section <a href=
|
|
"#attaching-policy-expressions-to-wsdl"><b>2.11 Attaching Policy
|
|
Expressions to WSDL</b></a> on the absence of policy
|
|
expressions.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="ignorable-policy-assertions" id=
|
|
"ignorable-policy-assertions"></a>2.7 Ignorable Policy
|
|
Expressions</h3>
|
|
<p>Suppose Company-X decides that it will log SOAP messages sent
|
|
and received in an exchange. This behavior has no direct impact on
|
|
the messages sent on the wire, and does not affect
|
|
interoperability. Some parties might have a concern about such
|
|
logging and might decide not to interact with Company-X knowing
|
|
that such logging is performed. To address this concern, Company-X
|
|
includes a Logging assertion in its policy to enable such parties
|
|
to be aware of logging. By marking the Logging assertion with the
|
|
<code>wsp:Ignorable</code> attribute with a value of "true"
|
|
Company-X indicates that a requester may choose to either ignore
|
|
such assertions or to consider them as part of policy intersection.
|
|
An assertion that may be ignored for policy intersection is called
|
|
an ignorable assertion.</p>
|
|
<p>The <code>wsp:Ignorable</code> attribute allows providers to
|
|
clearly indicate which policy assertions indicate behaviors that
|
|
don’t manifest on the wire and may not be of concern to a requester
|
|
when determining policy compatibility. Using the
|
|
<code>wsp:Optional</code> attribute would be incorrect in this
|
|
scenario, since it would indicate that the behavior would not occur
|
|
if the alternative without the assertion were selected.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-12.</span> Ignorable Logging Policy Assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<log:Logging wsp:Ignorable="true" />
|
|
</pre></div>
|
|
</div>
|
|
<p>(The log: prefix is used here to denote a hypothetical example
|
|
namespace for this example logging policy assertion.)</p>
|
|
<p>The attribute <code>wsp:Ignorable</code> is of type
|
|
<em>xs:boolean</em>. Omitting this attribute is semantically
|
|
equivalent to including it with a value of "false".</p>
|
|
<p>The use of the <code>wsp:Ignorable</code> attribute has no
|
|
impact on normalization. Assertions marked with the
|
|
<code>wsp:Ignorable</code> attribute remain marked with the
|
|
<code>wsp:Ignorable</code> attribute after normalization. Please
|
|
note that the impact of the ignorable attribute is at the
|
|
discretion of policy consumers through selection of "lax" or
|
|
"strict" mode (See <a href=
|
|
"#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy
|
|
Intersection</b></a>). Therefore ignorable assertions may have an
|
|
effect on determining compatibility of provider and consumer
|
|
policies.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="Both-Optional-Ignorable" id=
|
|
"Both-Optional-Ignorable"></a>2.8 Marking Assertions both Optional
|
|
and Ignorable</h3>
|
|
<p>As described in the sections above and in Section <a href=
|
|
"#strict-lax-policy-intersection"><b>3.4.1 Strict and Lax Policy
|
|
Intersection</b></a>, the WS-Policy 1.5 specification defines two
|
|
attributes that can be used to mark an assertion: wsp:Optional and
|
|
wsp:Ignorable.</p>
|
|
<p>The WS-Policy Framework allows a policy assertion to be marked
|
|
with both "Optional" and "Ignorable" attributes simultaneously. The
|
|
presence of "@wsp:optional=true" on an assertion is a syntactic
|
|
compact form for two alternatives in normal form, one with the
|
|
assertion and the other without the assertion. Hence syntactically
|
|
marking an assertion "A" with both the @wsp:Optional and
|
|
@wsp:Ignorable with the value of "true" for both, is equivalent to
|
|
two alternatives; one where the assertion A exists with
|
|
@wsp:Ignorable=true and the second where the assertion A does not
|
|
exist.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="nested-policy-expressions" id=
|
|
"nested-policy-expressions"></a>2.9 Nested Policy Expressions</h3>
|
|
<p>In the previous sections, we considered two security policy
|
|
assertions. In this section, let us look at one of the security
|
|
policy assertions in a little more detail.</p>
|
|
<p>As you would expect, securing messages is a complex usage
|
|
scenario. Company-X uses the <code>sp:TransportBinding</code>
|
|
policy assertion to indicate the use of transport-level security
|
|
for protecting messages. Just indicating the use of transport-level
|
|
security for protecting messages is not sufficient. To successfully
|
|
interact with Company-X’s Web services, the developer must also
|
|
know what transport token to use, what particular secure transport
|
|
to use, what specific algorithm suite to use for performing
|
|
cryptographic operations, etc. The <code>sp:TransportBinding</code>
|
|
policy assertion can represent these dependent behaviors. In this
|
|
section, let us look at how to capture these dependent behaviors in
|
|
a machine-readable form.</p>
|
|
<p>A policy assertion – like the <code>sp:TransportBinding</code> -
|
|
identifies a visible domain specific behavior that is a
|
|
requirement. Given an assertion, there may be other dependent
|
|
behaviors that need to be enumerated for a Web Service interaction.
|
|
In the case of the <code>sp:TransportBinding</code> policy
|
|
assertion, Company-X needs to identify the use of a transport
|
|
token, a secure transport, an algorithm suite for performing
|
|
cryptographic operations, etc. A nested policy expression can be
|
|
used to enumerate such dependent behaviors.</p>
|
|
<p>What is a nested policy expression? A nested policy expression
|
|
is a policy expression that is a child element of a policy
|
|
assertion element. A nested policy expression further qualifies the
|
|
behavior of its parent policy assertion.</p>
|
|
<p>In the example below, the child <code>Policy</code> 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
|
|
2-13.</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, Web
|
|
service developers can use a policy-aware client that recognizes
|
|
this policy assertion and engages transport-level security and its
|
|
dependent behaviors automatically. That is, the complexity of
|
|
security usage is absorbed by a policy-aware client and hidden from
|
|
these Web service developers.</p>
|
|
<p>In another example, WS-Security Policy defines a sp:HttpToken
|
|
assertion to contain three possible nested elements,
|
|
sp:HttpBasicAuthentication, sp:HttpDigestAuthentication and
|
|
sp:RequireClientCertificate. When the HttpToken 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. A non-anonymous client who
|
|
requires authentication or client certificate will not be able to
|
|
use this provider solely on the basis of policy intersection
|
|
algorithm alone.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-14.</span> Empty Nested Assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<sp:TransportToken>
|
|
<wsp:Policy>
|
|
<sp:HttpsToken>
|
|
<wsp:Policy/>
|
|
</sp:HttpsToken>
|
|
</wsp:Policy>
|
|
</sp:TransportToken>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="Referencing_Policy_Expressions" id=
|
|
"Referencing_Policy_Expressions"></a>2.10 Referencing Policy
|
|
Expressions</h3>
|
|
<p>Company-X has numerous Web service offerings that provide
|
|
different kinds of real-time quotes and book information on
|
|
securities such as <code>GetRealQuote</code>,
|
|
<code>GetRealQuotes</code> and <code>GetExtendedRealQuote</code>.
|
|
To accommodate the diversity of Company-X’s customers, Company-X
|
|
supports multiple WSDL bindings for these Web services. Company-X
|
|
provides consistent ways to interact with their services and wants
|
|
to represent these capabilities and requirements consistently
|
|
across all of their offerings without duplicating policy
|
|
expressions multiple times. How? It is simple - a policy expression
|
|
can be named and referenced for re-use.</p>
|
|
<p>Section <a href="#simple-message"><b>2.2 Simple Message</b></a>,
|
|
showed how a policy expression can be attached directly to a
|
|
binding inline. A single policy expression may be used in several
|
|
parts of a WSDL document. In this case it is desirable to use
|
|
references to the policy expression rather than to directly inline
|
|
the policy expression.</p>
|
|
<p>A policy expression may be identified by an IRI and referenced
|
|
for re-use as a standalone policy or within another policy
|
|
expression. There are three mechanisms to identify a policy
|
|
expression: the <code>wsu:Id</code>, <code>xml:id</code> and
|
|
<code>Name</code> attributes. A <code>PolicyReference</code>
|
|
element can be used to reference a policy expression identified
|
|
using either of these mechanisms.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-15.</span> Common Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy wsu:Id=”common”>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>In the example above, the <code>wsu:Id</code> attribute is used
|
|
to identify a policy expression. The value of the
|
|
<code>wsu:Id</code> attribute is an XML ID. The relative IRI for
|
|
referencing this policy expression (within the same document) is
|
|
<code>#common</code>. If the policy document IRI is
|
|
<code>http://x.example.com/policy.xml</code> then the absolute IRI
|
|
for referencing this policy expression is
|
|
<code>http://x.example.com/policy.xml#common. (</code>The absolute
|
|
IRI is formed by combining the document IRI, <code>#</code> and the
|
|
value of the <code>wsu:Id</code> attribute.)</p>
|
|
<p>In addition to the Example 2-12, Company-X could have used
|
|
either the xml:id or wsu:Id. An example of the use of xml:id
|
|
similar to that of wsu:Id is shown in Example 2-13.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-16.</span> Common Policy Expression [xml:id]</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy xml:id=”common”>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>Conditions and constraints on the use of the |xml:id| attribute
|
|
in conjunction with Canonical XML 1.0 are specified in Appendix C
|
|
of <cite><a href="#XMLID">XML ID</a></cite> and are further
|
|
detailed in <cite><a href="#C14NNOTE">C14N 1.0 Note</a></cite>.
|
|
Significant care is suggested in the use of xml:id.</p>
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
<p>Note: Canonical XML 1.1 [<cite><a href=
|
|
"#C14N11">C14N11</a></cite>] is intended to address the issues that
|
|
occur with Canonical XML 1.0 with regards to <code>xml:id</code>.
|
|
The W3C XML Security Specifications Maintenance WG has been
|
|
chartered to address how to integrate Canonical XML 1.1 with XML
|
|
Security, including XML Signature [<cite><a href=
|
|
"#SecSpecMaintWG">SecSpecMaintWG</a></cite>] (See
|
|
http://www.w3.org/2007/xmlsec/.)</p>
|
|
</div>
|
|
<p>For re-use, a <code>PolicyReference</code> element can be used
|
|
to reference a policy expression as a standalone policy or within
|
|
another policy expression. The example below is a policy expression
|
|
that re-uses the common policy expression above.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-17.</span> PolicyReference to Common Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<PolicyReference URI="#common"/>
|
|
</pre></div>
|
|
</div>
|
|
<p>For referencing a policy expression within the same XML
|
|
document, Company-X uses the <code>wsu:Id</code> attribute for
|
|
identifying a policy expression and an IRI to this ID value for
|
|
referencing this policy expression using a
|
|
<code>PolicyReference</code> element.</p>
|
|
<p>The example below is a policy expression that re-uses the common
|
|
policy expression within another policy expression. This policy
|
|
expression requires the use of addressing, one of transport- or
|
|
message-level security for protecting messages and allows the use
|
|
of optimization.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-18.</span> Secure Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy wsu:Id=”secure”>
|
|
<All>
|
|
<PolicyReference URI="#common"/>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
|
|
</ExactlyOne>
|
|
</All>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The <code>Name</code> attribute is an alternate mechanism to
|
|
identify a policy expression. The value of the <code>Name</code>
|
|
attribute is an absolute IRI and is independent of the location of
|
|
the XML document where the identified policy expression resides in.
|
|
As such, referencing a policy expression using the Name attribute
|
|
relies on additional out of band information and is outside the
|
|
scope of the Web Services Policy Framework and Attachment (See
|
|
<a href="#policy-retrieval"><b>3.6 Policy Retrieval</b></a>). In
|
|
the example below, the <code>Name</code> attribute identifies the
|
|
policy expression. The IRI of this policy expression is
|
|
<code>http://x.example.com/policy/common</code>.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-19.</span> Common Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy Name=”http://x.example.com/policy/common”>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The example below is a policy expression that re-uses the common
|
|
policy expression above.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-20.</span> PolicyReference to Common Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<PolicyReference URI="http://x.example.com/policy/common"/>
|
|
</pre></div>
|
|
</div>
|
|
<p>The following example shows a policy expression identified using
|
|
a UDDI key, which may refer to a tModel that references the
|
|
reusable policy expression as described in section 6.3 of
|
|
<cite><a href="#WS-PolicyAttachment">Web Services Policy
|
|
Attachment</a></cite>.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-21.</span> PolicyReference to Reusable Policy Expression in
|
|
UDDI</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<PolicyReference URI="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c"/>
|
|
</pre></div>
|
|
</div>
|
|
<p>The reusable policy expression could be registered in UDDI using
|
|
a tModel as shown below</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-22.</span> UDDI tModel for a Reusable Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<tModel tModelKey="uddi:3bed4710-1f46-11dc-899e-391cf3b1899c">
|
|
<name>…</name>
|
|
<description xml:lang="EN">
|
|
Policy Expression for example's Web services
|
|
</description>
|
|
<overviewDoc>
|
|
<description xml:lang="EN">Web Services Policy Expression</description>
|
|
<overviewURL>http://repository.example.com/policy/common</overviewURL>
|
|
</overviewDoc>
|
|
<categoryBag>
|
|
<keyedReference
|
|
keyName="Reusable policy Expression"
|
|
keyValue="policy"
|
|
tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:policytypes" />
|
|
<keyedReference
|
|
keyName="Policy Expression for example's Web services"
|
|
keyValue="http://x.example.com/policy/common"
|
|
tModelKey="uddi:w3.org:ws-policy:v1.5:attachment:remotepolicyreference" />
|
|
</categoryBag>
|
|
</tModel>
|
|
</pre></div>
|
|
</div>
|
|
<p>As policy expressions are composed from other policy expressions
|
|
and assertions from different domains are used in a policy
|
|
expression, complex expressions will emerge. Naming parts of
|
|
complex expressions for reuse and building more complex policies
|
|
through referencing enables building more complicated policy
|
|
scenarios easily. This approach enables the association of
|
|
additional policy subjects to identified policy expressions. It
|
|
also promotes manageability of the expressions as they are uniquely
|
|
identified and allows profiles for common scenarios to be
|
|
developed. Note that when a named expression has assertions that
|
|
contains parameterized expressions, care must be given to ensure
|
|
that the parameterized content is statically available to enable
|
|
reuse.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="attaching-policy-expressions-to-wsdl" id=
|
|
"attaching-policy-expressions-to-wsdl"></a>2.11 Attaching Policy
|
|
Expressions to WSDL</h3>
|
|
<p>A majority of Company-X’s customers use WSDL for building their
|
|
client applications. Company-X leverages this usage by attaching
|
|
policy expressions to the WSDL binding descriptions.</p>
|
|
<p>In the example below, the <code>SecureBinding</code> WSDL
|
|
binding description defines a binding for an interface that
|
|
provides real-time quotes and book information on securities. (The
|
|
prefixes <code>wsdl</code> and <code>tns</code> are used here to
|
|
denote the Web Services Description language XML namespace and
|
|
target namespace of this WSDL document.) To require the use of
|
|
security for these offerings, Company-X attaches the secure policy
|
|
expression in the previous section to this binding description. The
|
|
WSDL <code>binding</code> element is a common policy attachment
|
|
point. The secure policy expression attached to the
|
|
<code>SecureBinding</code> WSDL binding description applies to any
|
|
message exchange associated with any <code>port</code> that
|
|
supports this binding description. This includes all the message
|
|
exchanges described by operations in the
|
|
<code>RealTimeDataInterface</code>.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-23.</span> Secure Policy Expression Attached to WSDL
|
|
Binding</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
|
|
<PolicyReference URI="#secure" />
|
|
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
|
|
…
|
|
</wsdl:binding>
|
|
</pre></div>
|
|
</div>
|
|
<p>In addition to providing real-time quotes and book information
|
|
on securities, Company-X provides other kinds of data through Web
|
|
services such as quotes delayed by 20 minutes and security symbols
|
|
through Web services (for example <code>GetDelayedQuote</code>,
|
|
<code>GetDelayedQuotes,</code> <code>GetSymbol</code> and
|
|
<code>GetSymbols</code>). Company-X does not require the use of
|
|
security for these services, but requires the use of addressing and
|
|
allows the use of optimization.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
2-24.</span> Open Policy Expression Attached to WSDL
|
|
Binding</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" >
|
|
<PolicyReference URI="#common" />
|
|
<wsdl:operation name="GetDelayedQuote">…</wsdl:operation>
|
|
…
|
|
</wsdl:binding>
|
|
</pre></div>
|
|
</div>
|
|
<p>In the example above, the <code>OpenBinding</code> WSDL binding
|
|
description defines a binding for an interface that provides other
|
|
kinds of data such as quotes delayed by 20 minutes and security
|
|
symbols. To require the use of addressing and allow the use of
|
|
optimization, Company-X attaches the common policy expression in
|
|
the previous section to this binding description. As we have seen
|
|
in the <code>SecureBinding</code> case, the common policy
|
|
expression attached to the <code>OpenBinding</code> WSDL binding
|
|
description applies to any message exchange associated with any
|
|
<code>port</code> that supports this binding description. This
|
|
includes all the message exchanges described by operations in the
|
|
<code>DelayedDataInterface</code>.</p>
|
|
<p>As mentioned earlier, providers have the option to convey
|
|
requirements, such as the use of addressing or security, through
|
|
word-of-mouth and documentation – as they always have. The absence
|
|
of policy expressions, for example, in a WSDL document does not
|
|
indicate anything about the capabilities and requirements of a
|
|
service. The service may have capabilities and requirements that
|
|
can be expressed as policy expressions, such as the use of
|
|
addressing, security and optimization. Or, the service may not have
|
|
such capabilities and requirements. A policy aware client should
|
|
not conclude anything about the absence of policy expressions.</p>
|
|
<p>Service providers, like Company-X, can preserve and leverage
|
|
their investments in WSDL and represent the capabilities and
|
|
requirements of a Web service as policies. A WSDL document may
|
|
specify varying behaviors across Web service endpoints. Web service
|
|
developers can use a policy-aware client that recognizes these
|
|
policy expressions in WSDL documents and engages behaviors
|
|
automatically for each of these endpoints. Any complexity of
|
|
varying behaviors across Web service endpoints is absorbed by a
|
|
policy-aware client or tool and hidden from these Web service
|
|
developers.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="policy-automates-web-services-interaction" id=
|
|
"policy-automates-web-services-interaction"></a>2.12 Policy
|
|
Automates Web Services Interaction</h3>
|
|
<p>As you have seen, Web Services Policy is a simple language that
|
|
has four elements - <code>Policy, All</code>,
|
|
<code>ExactlyOne</code> and <code>PolicyReference</code> - and two
|
|
attributes - <code>wsp:Optional</code> and
|
|
<code>wsp:Ignorable</code>. In practice, service providers, like
|
|
Company-X, use policy expressions to represent combinations of
|
|
capabilities and requirements. Web service developers use
|
|
policy-aware clients that understand policy expressions and engage
|
|
the behaviors represented by providers automatically. A sizable
|
|
amount of complexity is absorbed by policy-aware clients (or tools)
|
|
and is invisible to these Web service developers.</p>
|
|
<p>Web Services Policy extends the foundation on which to build
|
|
interoperable Web services, hides complexity from developers and
|
|
automates Web service interactions.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="advanced-concepts-policy-expression" id=
|
|
"advanced-concepts-policy-expression"></a>3. Advanced Concepts:
|
|
Policy Expression</h2>
|
|
<p>In <a href="#basic-concepts-policy-expression"><b>2. Basic
|
|
Concepts: Policy Expression</b></a>, we covered the basics of Web
|
|
Services Policy language. This is the advanced section that
|
|
provides more in-depth materials for Web Services Policy
|
|
implementers and assertion authors. This section covers the
|
|
following topics:</p>
|
|
<ul>
|
|
<li>
|
|
<p>What is a policy expression?</p>
|
|
</li>
|
|
<li>
|
|
<p>What is the normal form of a policy expression and how to
|
|
normalize policy expressions?</p>
|
|
</li>
|
|
<li>
|
|
<p>What is the policy data model?</p>
|
|
</li>
|
|
<li>
|
|
<p>How to select a compatible policy alternative?</p>
|
|
</li>
|
|
<li>
|
|
<p>How to attach policy expressions to WSDL constructs?</p>
|
|
</li>
|
|
<li>
|
|
<p>How to combine policies?</p>
|
|
</li>
|
|
<li>
|
|
<p>What are the extensibility points?</p>
|
|
</li>
|
|
<li>
|
|
<p>What are the parts of a policy assertion?</p>
|
|
</li>
|
|
</ul>
|
|
<div class="div2">
|
|
<h3><a name="policy-expression" id="policy-expression"></a>3.1
|
|
Policy Expression</h3>
|
|
<p>A policy expression is the XML representation and interoperable
|
|
form of a Web Services Policy. A policy expression consists of a
|
|
<code>Policy</code> wrapper element and a variety of child and
|
|
descendant elements. Child and descendent elements from the policy
|
|
language are <code>Policy, All</code>, <code>ExactlyOne</code> and
|
|
<code>PolicyReference</code>. Other child elements of
|
|
<code>Policy</code>, <code>All</code> and <code>ExactlyOne</code>
|
|
are policy assertions. (The <code>Policy</code> element plays two
|
|
roles: wrapper element and operator.) Policy assertions can contain
|
|
a nested policy expression. Policy assertions can also be marked
|
|
optional to represent behaviors that may be engaged (capabilities)
|
|
for an interaction. The optional marker is the
|
|
<code>wsp:Optional</code> attribute which is placed on a policy
|
|
assertion element.</p>
|
|
<p>Let us take a closer look at Company-X’s policy expression (see
|
|
below) from the previous section.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-1.</span> Company-X’s Secure Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<All>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
|
|
</ExactlyOne>
|
|
</All>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The <code>Policy</code> element is the wrapper element. The
|
|
<code>All</code> and <code>ExactlyOne</code> elements are the
|
|
policy operators. All other child elements of the <code>All</code>
|
|
and <code>ExactlyOne</code> elements are policy assertions from
|
|
domains such as messaging, addressing, security, reliability and
|
|
transactions.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="normal-form-for-policy-expressions" id=
|
|
"normal-form-for-policy-expressions"></a>3.2 Normal Form for Policy
|
|
Expressions</h3>
|
|
<p>Web Services Policy language defines two forms of policy
|
|
expressions: compact and normal form. Up to this point, we have
|
|
used the compact form. The compact form is less verbose than the
|
|
normal form. The compact form is useful for authoring policy
|
|
expressions. The normal form is an intuitive representation of the
|
|
policy data model. We will look into the policy data model in the
|
|
next section.</p>
|
|
<p>The normal form uses a subset of constructs used in the compact
|
|
form and follows a simple outline for its XML representation:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-2.</span> Normal Form for Policy Expressions</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All>
|
|
<x:AssertionA>…</x:AssertionA>
|
|
<y:AssertionB>…</y:AssertionB>
|
|
…
|
|
</All>
|
|
<All>
|
|
<x:AssertionA>…</x:AssertionA>
|
|
<z:AssertionC>…</z:AssertionC>
|
|
…
|
|
</All>
|
|
…
|
|
</ExactlyOne>
|
|
<Policy/>
|
|
</pre></div>
|
|
</div>
|
|
<p>The normal form consists of a <code>Policy</code> wrapper
|
|
element and has one child <code>ExactlyOne</code> element. This
|
|
<code>ExactlyOne</code> element has zero or more <code>All</code>
|
|
child elements. Each of these <code>All</code> elements has zero or
|
|
more policy assertions. The <code>PolicyReference</code> element
|
|
and <code>wsp:Optional</code> attribute are not used in the normal
|
|
form. And, a nested policy expression in the normal form has at
|
|
most one policy alternative.</p>
|
|
<p>The normal form represents a policy as a collection of policy
|
|
alternatives and a policy alternative as a collection of policy
|
|
assertions in a straight-forward manner.</p>
|
|
<p>The example below is a policy expression in the normal form.
|
|
This expression contains two policy alternatives: one that requires
|
|
the use of transport-level security and the other that requires the
|
|
use of message-level security for protecting messages.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-3.</span> Transport- or Message-Level Security Policy Expression
|
|
in Normal Form</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
<All>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
|
|
</All>
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>A policy expression in the compact form can be converted to the
|
|
normal form. Web Services Policy language describes the algorithm
|
|
for this conversion.</p>
|
|
<p>Let us re-consider Company-X’s policy expression (see the
|
|
example below). Company-X requires the use of addressing and either
|
|
transport- or message-level security and allows the use of
|
|
optimization. This policy expression is in the compact form and has
|
|
four policy alternatives for requesters:</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p>Requires the use of addressing and transport-level security</p>
|
|
</li>
|
|
<li>
|
|
<p>Requires the use of addressing and message-level security</p>
|
|
</li>
|
|
<li>
|
|
<p>Requires the use of optimization, addressing and transport-level
|
|
security and</p>
|
|
</li>
|
|
<li>
|
|
<p>Requires the use of optimization, addressing and message-level
|
|
security.</p>
|
|
</li>
|
|
</ol>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-4.</span> Company-X’s Secure Policy Expression in Compact
|
|
Form</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy wsu:Id=”secure”>
|
|
<All>
|
|
<PolicyReference URI=”#common”/>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
|
|
</ExactlyOne>
|
|
</All>
|
|
</Policy>
|
|
|
|
<Policy wsu:Id=”common”>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>Let us look at the normal form for this policy expression. The
|
|
example below is Company-X’s policy expression in the normal form.
|
|
As you can see, the compact form is less verbose than the normal
|
|
form. The normal form represents a policy as a collection of policy
|
|
alternatives. Each of the <code>All</code> operators is a policy
|
|
alternative. There are four policy alternatives in the normal form.
|
|
These alternatives map to list items (1) through (4) above.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-5.</span> Company-X’s Policy Expression in Normal Form</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All> <!-- - - - - - - - - - - - - - Policy Alternative (a) -->
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
<All> <!-- - - - - - - - - - - - - - Policy Alternative (b) -->
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
|
|
</All>
|
|
<All> <!-- - - - - - - - - - - - - - Policy Alternative (c) -->
|
|
<mtom:OptimizedMimeSerialization />
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
<All> <!-- - - - - - - - - - - - - - Policy Alternative (d) -->
|
|
<mtom:OptimizedMimeSerialization />
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
|
|
</All>
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The <code>wsp:Optional</code> attribute, nested policy
|
|
expression and <code>Policy</code><code>Reference</code> element
|
|
are converted to their corresponding normal form. The
|
|
<code>wsp:Optional</code> attribute converts to two alternatives,
|
|
one with and the other without the assertion. A policy alternative
|
|
containing an assertion with a nested policy expression that has
|
|
multiple policy alternatives converts to multiple policy
|
|
alternatives where the assertion contains a nested policy
|
|
expression that has at most one policy alternative.</p>
|
|
<p>The <code>PolicyReference</code> element is replaced with its
|
|
referenced policy expression. See section <a href=
|
|
"#policy-retrieval"><b>3.6 Policy Retrieval</b></a> for more
|
|
details on how to retrieve referenced policy expressions.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="policy-data-model" id="policy-data-model"></a>3.3
|
|
Policy Data Model</h3>
|
|
<p>In the previous section, we considered the normal form for
|
|
policy expressions. As we discussed, the normal form represents a
|
|
policy as a collection of policy alternatives. In this section, let
|
|
us look at the policy data model.</p>
|
|
<p>Company-X uses a policy to convey the conditions for an
|
|
interaction. Policy-aware clients, like the one used by the
|
|
developer in our example (as explained earlier in <a href=
|
|
"#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy
|
|
Expression</b></a>), view a policy as an unordered collection of
|
|
zero or more policy alternatives. A policy alternative is an
|
|
unordered collection of zero or more policy assertions. A policy
|
|
alternative represents a collection of behaviors or requirements or
|
|
conditions for an interaction. In simple words, each policy
|
|
alternative represents a set of conditions for an interaction. The
|
|
diagram below describes the policy data model.</p>
|
|
<div class="figure" style="text-align: center"><br />
|
|
<img src="ws-policy-data-model.jpg" alt="WS-Policy Data Model" />
|
|
<p style="text-align:left"><i><span>Figure 3-1.</span> WS-Policy
|
|
Data Model</i></p>
|
|
<br /></div>
|
|
<p>A policy-aware client uses a policy to determine whether one of
|
|
these policy alternatives (i.e. the conditions for an interaction)
|
|
can be met in order to interact with the associated Web Service.
|
|
Such clients may choose any of these policy alternatives and must
|
|
choose exactly one of them for a successful Web service
|
|
interaction. Clients may choose a different policy alternative for
|
|
a subsequent interaction. It is important to understand that a
|
|
policy is a useful piece of metadata in machine-readable form that
|
|
enables tooling, yet is not required for a successful Web service
|
|
interaction. Why? Web service developers could use the
|
|
documentation, talk to the service providers, or look at message
|
|
traces to infer these conditions for an interaction. Developers
|
|
continue to have these options, as they always had.</p>
|
|
<p>As we discussed, a policy assertion identifies a domain specific
|
|
behavior or requirement or condition. A policy assertion has a
|
|
QName that identifies its behavior or requirement or condition. In
|
|
the XML representation, the QName of the assertion element is the
|
|
QName of the policy assertion. A policy assertion may contain
|
|
assertion parameters and a nested policy.</p>
|
|
<p>The assertion parameters are the opaque payload of an assertion.
|
|
Parameters carry additional useful pieces of information necessary
|
|
for engaging the behavior described by an assertion. In the XML
|
|
representation, the child elements and attributes of an assertion
|
|
excluding the child elements and attributes from the WS-Policy
|
|
language XML namespace name, are the assertion parameters. For
|
|
example @wsp:Optional and @wsp:Ignorable are not assertion
|
|
parameters.</p>
|
|
<p>We considered nested policy expressions in the context of a
|
|
security usage scenario. Let us look at its shape in the policy
|
|
data model. A nested policy expression is a policy expression that
|
|
is a child element of an assertion. In the normal form, a nested
|
|
policy expression has at most one policy alternative. The policy
|
|
alternative in a nested policy expression represents a collection
|
|
of associated or dependent behaviors, requirements or conditions
|
|
that qualify its parent policy assertion.</p>
|
|
<p>A policy-aware client supports a policy assertion if the client
|
|
engages the behavior or requirement or condition indicated by the
|
|
assertion. A policy-aware client supports a policy alternative if
|
|
the client engages the behaviors represented by all the assertions
|
|
in the alternative. A policy-aware client supports a policy if the
|
|
client engages the behaviors represented by at least one of the
|
|
policy alternatives.</p>
|
|
<p>In the previous section, we saw how the normal form of a policy
|
|
expression represents a policy as a collection of policy
|
|
alternatives. By policy language design, the normal form of a
|
|
policy expression directly maps to the policy data model:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Each child element of <code>Policy/ExactlyOne/All</code> maps to
|
|
a policy assertion.</p>
|
|
</li>
|
|
<li>
|
|
<p>Each <code>Policy/ExactlyOne/All</code> element and policy
|
|
assertions which correspond to its children map to a policy
|
|
alternative.</p>
|
|
</li>
|
|
<li>
|
|
<p>The <code>Policy/ExactlyOne</code> element maps to a collection
|
|
of policy alternatives.</p>
|
|
</li>
|
|
<li>
|
|
<p>The <code>Policy</code> wrapper element and policy alternatives
|
|
which correspond to the <code>Policy/ExactlyOne</code> element map
|
|
to a policy.</p>
|
|
</li>
|
|
</ul>
|
|
<p>The diagram below describes this mapping from the normal form of
|
|
a policy expression to the policy data model.</p>
|
|
<div class="figure" style="text-align: center"><br />
|
|
<img src="normal-form-2-data-model.jpg" alt=
|
|
"Mapping from Normal Form to Policy Data Model" />
|
|
<p style="text-align:left"><i><span>Figure 3-2.</span> Mapping from
|
|
Normal Form to Policy Data Model</i></p>
|
|
<br /></div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="compatible-policies" id="compatible-policies"></a>3.4
|
|
Compatible Policies</h3>
|
|
<p>A provider, like Company-X, and a requester, like the
|
|
policy-aware client used in our example, may represent their
|
|
capabilities and requirements for an interaction as policies and
|
|
want to limit their message exchanges to mutually compatible
|
|
policies. Web Services Policy defines an intersection mechanism for
|
|
selecting compatible policy alternatives when there are two or more
|
|
policies.</p>
|
|
<p>The example below is a copy of Company-X’s policy expression
|
|
(from <a href="#normal-form-for-policy-expressions"><b>3.2 Normal
|
|
Form for Policy Expressions</b></a>). As we saw before, Company-X
|
|
offers four policy alternatives. Of them, one of the policy
|
|
alternatives requires the use of addressing and transport-level
|
|
security.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-6.</span> Company-X’s Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All> <!-- - - - - - - - - - Company-X’s Policy Alternative (a) -->
|
|
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) -->
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) -->
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
…
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The client application developer's organization requires the use
|
|
of addressing and transport-level security for any interaction with
|
|
Company-X’s Web services. The developer represents these behaviors
|
|
using a policy expression illustrated in the example below in
|
|
normal form. This policy expression contains one policy alternative
|
|
that requires the use of addressing and transport-level
|
|
security.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-7.</span> The Client Application's Policy Expression in Normal
|
|
Form</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All> <!-- - - - - - - - - - - - - - Client’s Policy Alternative -->
|
|
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (t1) -->
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (t2) -->
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</All>
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The developer lets her policy-aware client select a compatible
|
|
policy alternative in Company-X’s policy. How does this client
|
|
select a compatible policy alternative? It is simple – it uses the
|
|
policy intersection. That is, the policy-aware client uses these
|
|
two policy expressions (the client’s and Company-X’s) and the
|
|
policy intersection to select a compatible policy alternative for
|
|
this interaction. Let us look at the details of policy
|
|
intersection.</p>
|
|
<p>For two policy assertions to be compatible they must have the
|
|
same QName. And, if either assertion has a nested policy, both
|
|
assertions must have a nested policy and the nested policies must
|
|
be compatible. For example, policy assertions (c2) and (t1) have
|
|
the same QName, <code>sp:TransportBinding</code>. For this
|
|
discussion, let us assume that these two assertions have compatible
|
|
nested policies. These two assertions are compatible because they
|
|
have the same QName and their nested policies are compatible.</p>
|
|
<p>Two policy alternatives are compatible if each policy assertion
|
|
in one alternative is compatible with a policy assertion in the
|
|
other and vice-versa. For instance in Examples 3.6 and 3.7, policy
|
|
assertions (c1) and (c2) in Company-X’s policy alternative are
|
|
compatible with policy assertions (t2) and (t1) in the client’s
|
|
policy alternative. Company-X’s policy alternative (a) and the
|
|
client’s policy alternative are compatible because assertions in
|
|
these two alternatives are compatible.</p>
|
|
<p>Two policies are compatible if a policy alternative in one is
|
|
compatible with a policy alternative in the other. For example,
|
|
Company-X’s policy alternative (a) is compatible with the client’s
|
|
policy alternative. Company-X’s policy and the client’s policy are
|
|
compatible because one of Company-X’s policy alternative is
|
|
compatible with the client’s policy alternative.</p>
|
|
<p>For this interaction, the developer’s policy-aware client can
|
|
use policy alternative (a) to satisfy Company-X’s conditions or
|
|
requirements.</p>
|
|
<p>Similarly, policy intersection can be used to check if providers
|
|
expose endpoints that conform to a standard policy. For example, a
|
|
major retailer might require all their supplier endpoints to be
|
|
compatible with an agreed upon policy.</p>
|
|
<p>Consider a similar scenario between Company X and the client
|
|
where nested policy expressions exist in the policy alternatives.
|
|
The nested policy expressions are compared for compatibility in the
|
|
context of their parent policy assertions during policy
|
|
intersection. For example, take these two incompatible policies in
|
|
Examples 3.8 and 3.9:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-8.</span> Company X Nested incompatible policy example</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
Company X
|
|
(P001)<wsp:Policy wsu:Id="..." >
|
|
(P002) <wsp:ExactlyOne>
|
|
(P003) <wsp:All>
|
|
(P004) <sp:EndorsingSupportingTokens
|
|
(P005) xmlns:sp="..."> <!-- parent policy assertion a -->
|
|
(P006) <wsp:Policy> <!-- nested policy a1 -->
|
|
(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
|
|
(P008) <wsp:Policy>
|
|
(P009) <sp:RequireThumbprintReference />
|
|
(P010) <sp:WssX509V3Token10 />
|
|
(P011) </wsp:Policy>
|
|
(P012) </sp:X509Token>
|
|
(P013) </wsp:Policy>
|
|
(P014) </sp:EndorsingSupportingTokens>...
|
|
(P015) </wsp:All>
|
|
(P016) </wsp:ExactlyOne>
|
|
(P017)</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-9.</span> Client Nested incompatible policy example</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
Client
|
|
(P001)<wsp:Policy wsu:Id="..." >
|
|
(P002) <wsp:ExactlyOne>
|
|
(P003) <wsp:All>
|
|
(P004) <sp:SignedSupportingTokens
|
|
(P005) xmlns:sp="..."> <!-- parent policy assertion b -->
|
|
(P006) <wsp:Policy> <!-- nested policy b1 -->
|
|
(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
|
|
(P008) <wsp:Policy>
|
|
(P009) <sp:RequireThumbprintReference />
|
|
(P010) <sp:WssX509V3Token10 />
|
|
(P011) </wsp:Policy>
|
|
(P012) </sp:X509Token>
|
|
(P013) </wsp:Policy>
|
|
(P014) </sp:SignedSupportingTokens>...
|
|
(P015) </wsp:All>
|
|
(P016) </wsp:ExactlyOne>
|
|
(P017)</wsp:Policy>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>In this scenario as illustrated in Examples 3.8 and 3.9, the
|
|
EndorsingSupportingTokens and SignedSupportingTokens assertions are
|
|
incompatible even though their nested policy expressions are
|
|
compatible. This is because the parent policy assertions
|
|
EndorsingSupportingTokens and SignedSupportingTokens have different
|
|
QNames.</p>
|
|
<div class="div3">
|
|
<h4><a name="strict-lax-policy-intersection" id=
|
|
"strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy
|
|
Intersection</h4>
|
|
<p>The previous sections outlined how the normal-form of a policy
|
|
expression relates to the policy data model and how the
|
|
compatibility of requester and provider policies may be determined.
|
|
This section outlines how ignorable assertions may impact the
|
|
process of determining compatibility.</p>
|
|
<p>In order to determine compatibility of its policy expression
|
|
with a provider policy expression, a requester may use either a
|
|
"lax" or "strict" mode of the intersection algorithm.</p>
|
|
<p>In the strict intersection mode two policy alternatives are
|
|
compatible when each assertion in one is compatible with an
|
|
assertion in the other, and vice versa (See section 4.5, Web
|
|
Services Policy 1.5 - Framework). For this to be possible they must
|
|
contain the same policy assertion types. The strict intersection
|
|
mode is the mode of intersection discussed in the previous sections
|
|
of this document.</p>
|
|
<p>When using the strict intersection mode compatibility is
|
|
computed for all assertions that are part of the policy
|
|
alternative, including those marked with
|
|
<code>wsp:Ignorable</code>. Thus the <code>wsp:Ignorable</code>
|
|
attribute does not impact the intersection result even when its
|
|
attribute value is “true”.</p>
|
|
<p>If a requester wishes to ignore ignorable assertions in a
|
|
provider's policy, then the requester should use the lax
|
|
intersection mode. In the lax intersection mode all ignorable
|
|
assertions (i.e. with the value "true" for the
|
|
<code>wsp:Ignorable</code> attribute) are to be ignored by the
|
|
intersection algorithm. Thus in the lax intersection mode two
|
|
policy alternatives are compatible when each non-ignorable
|
|
assertion in one is compatible with an assertion in the other, and
|
|
vice versa. For this to be possible the two policy alternatives
|
|
must contain the same policy assertion types for all
|
|
“non-ignorable” assertions.</p>
|
|
<p>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.</p>
|
|
<p>Domain-specific processing could take advantage of any
|
|
information from the policy data model, such as the ignorable
|
|
property of a policy assertion.</p>
|
|
<p>A requester can decide how to process a provider's policy to
|
|
determine if and how the requester will interact with the provider.
|
|
The requester can have its own policy that expresses its own
|
|
capabilities and requirements, and can make one or more attempts at
|
|
policy intersection in order to determine a compatible alternative
|
|
and/or isolate the cause of an empty intersection result. The
|
|
requester can use and analyze the result(s) of policy intersection
|
|
to select a compatible alternative or trigger other domain-specific
|
|
processing options. For example, a requester can at first attempt
|
|
strict mode intersection, and then lax mode as another choice, if
|
|
the previous attempt returns an empty intersection result.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="attaching-policy-expressions-to-wsdl2" id=
|
|
"attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy
|
|
Expressions to WSDL</h3>
|
|
<p>In <a href="#basic-concepts-policy-expression"><b>2. Basic
|
|
Concepts: Policy Expression</b></a>, we looked into how Company-X
|
|
attached their policy expressions to the WSDL <code>binding</code>
|
|
element. In addition to the WSDL <code>binding</code> element, a
|
|
policy expression can be attached to other WSDL elements such as
|
|
<code>service</code>, <code>port</code>, <code>operation</code> and
|
|
<code>message</code>. These elements are the WSDL policy attachment
|
|
points in a WSDL document.</p>
|
|
<p>The WSDL attachment points are partitioned (as illustrated
|
|
below) into four policy subjects: message, operation, endpoint and
|
|
service. When attached, capabilities and requirements represented
|
|
by a policy expression apply to a message exchange or message
|
|
associated with (or described by) a policy subject.</p>
|
|
<div class="figure" style="text-align: center"><br />
|
|
<img src="policy-subjects-in-wsdl.jpg" alt=
|
|
"Policy Subjects and Effective Policy in WSDL" />
|
|
<p style="text-align:left"><i><span>Figure 3-3.</span> Policy
|
|
Subjects and Effective Policy in WSDL</i></p>
|
|
<br /></div>
|
|
<p>The WSDL <code>service</code> element represents the service
|
|
policy subject. Policy expressions associated with a service policy
|
|
subject apply to any message exchange using any of the endpoints
|
|
offered by that service.</p>
|
|
<p>The WSDL <code>port</code>, <code>binding</code> and
|
|
<code>portType</code> elements collectively represent the endpoint
|
|
policy subject. Policy expressions associated with an endpoint
|
|
policy subject apply to any message exchange made using that
|
|
endpoint.</p>
|
|
<p>The WSDL <code>binding/operation</code> and
|
|
<code>portType/operation</code> elements collectively represent the
|
|
operation policy subject. Policy expressions associated with an
|
|
operation policy subject apply to the message exchange defined by
|
|
that operation.</p>
|
|
<p>The WSDL <code>binding/operation/input</code>,
|
|
<code>portType/operation/input</code>, and <code>message</code>
|
|
element collectively represent the message policy subject for the
|
|
input message. The WSDL <code>binding/operation/output</code>,
|
|
<code>portType/operation/output</code>, and <code>message</code>
|
|
element collectively represent the message policy subject for the
|
|
output message. The WSDL <code>binding/operation/fault</code>,
|
|
<code>portType/operation/fault</code>, and <code>message</code>
|
|
element collectively represent the message policy subject for the
|
|
fault message. Policy expressions associated with a message policy
|
|
subject apply only to that message.</p>
|
|
<p>In the example below, the policy expression is attached to an
|
|
endpoint policy subject.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-10.</span> Company-X’s Policy Expression Attached to WSDL binding
|
|
Element</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
|
|
<PolicyReference URI="#secure" />
|
|
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
|
|
…
|
|
</wsdl:binding>
|
|
</pre></div>
|
|
</div>
|
|
<p>If multiple policy expressions are attached to WSDL elements
|
|
that collectively represent a policy subject then the effective
|
|
policy of these policy expressions applies. The effective policy is
|
|
the combination of the policy expressions that are attached to the
|
|
same policy subject. For example, the effective policy of an
|
|
endpoint policy subject is the combination of policy expressions
|
|
attached to a WSDL <code>port</code> element, policy expressions
|
|
attached to the <code>binding</code> element referenced by this
|
|
port, and policy expressions attached to the <code>portType</code>
|
|
element that is supported by this port. Let us consider how to
|
|
combine policy expressions in the next section.</p>
|
|
<p>Most of the policy assertions are designated for the endpoint,
|
|
operation or message policy subject. The commonly used WSDL
|
|
attachment points are:</p>
|
|
<a name="Table2" id="Table2"></a>
|
|
<table border="1" cellspacing="0" cellpadding="5">
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Policy Subject</th>
|
|
<td rowspan="1" colspan="1">Commonly used attachment point (s)</td>
|
|
</tr>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Endpoint</th>
|
|
<td rowspan="1" colspan="1"><code>binding</code> element</td>
|
|
</tr>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Operation</th>
|
|
<td rowspan="1" colspan="1"><code>binding/operation</code>
|
|
element</td>
|
|
</tr>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Message</th>
|
|
<td rowspan="1" colspan="1"><code>binding/operation/input</code>
|
|
and <code>binding/operation/output</code> elements</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<br /></div>
|
|
<div class="div2">
|
|
<h3><a name="policy-retrieval" id="policy-retrieval"></a>3.6 Policy
|
|
Retrieval</h3>
|
|
<p>Just as other service metadata languages, Web Services Policy
|
|
does not mandate any specific policy retrieval mechanism. Any
|
|
combination of any retrieval mechanisms in any order may be used
|
|
for referencing policy expressions. Example retrieval mechanisms
|
|
are:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Do nothing. A policy expression with the referenced IRI is
|
|
already known to be available in a local cache or chip (embedded
|
|
systems).</p>
|
|
</li>
|
|
<li>
|
|
<p>Use the referenced IRI and retrieve an existing policy
|
|
expression from the containing XML document: a policy element with
|
|
an XML ID.</p>
|
|
</li>
|
|
<li>
|
|
<p>Use the referenced IRI and retrieve a policy expression from
|
|
some policy repository (local or remote), registry or catalog.
|
|
Policy tools or policy-aware clients may use any protocols (say
|
|
UDDI or Web Services Metadata Exchange) for such metadata
|
|
retrieval. These protocols may require additional out of band
|
|
information.</p>
|
|
</li>
|
|
<li>
|
|
<p>Attempt to resolve the referenced IRI on the Web. This may
|
|
resolve to a policy element or a resource that contains a policy
|
|
element.</p>
|
|
</li>
|
|
</ul>
|
|
<p>If the referenced policy expression is in the same XML document
|
|
as the reference, then the policy expression should be identified
|
|
using the <code>wsu:Id|xml:id</code> (XML ID) attribute and
|
|
referenced using an IRI reference to this XML ID value.</p>
|
|
<p>WSDL 1.1 [<cite><a href="#WSDL11">WSDL 1.1</a></cite>] section
|
|
2.1 and WSDL 2.0 [<cite><a href="#WSDL20">WSDL 2.0 Core
|
|
Language</a></cite>] chapter 4 allow to import or include WSDL
|
|
documents into another WSDL document with the wsdl11:import,
|
|
wsdl20:import, and wsdl20:include statements. The importing and
|
|
imported WSDL documents constitute separate XML documents each. If
|
|
e.g. the importing WSDL document references a policy in the
|
|
imported WSDL document, the rules for policy references between
|
|
separate XML documents apply as described in <a href=
|
|
"#Referencing_Policy_Expressions"><b>2.10 Referencing Policy
|
|
Expressions</b></a>.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="combine-policies" id="combine-policies"></a>3.7
|
|
Combine Policies</h3>
|
|
<p>Multiple policy expressions may be attached to WSDL constructs.
|
|
Let us consider how Company-X could have used multiple policy
|
|
expressions in a WSDL document. In the example below, there are two
|
|
policy expressions <code>#common2</code> and <code>#secure2</code>
|
|
attached to the <code>SecureBinding</code> WSDL binding and
|
|
<code>RealTimeDataPort</code> WSDL port descriptions.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-11.</span> Multiple Policy Expressions Attached to Endpoint
|
|
Policy Subject</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy wsu:Id=”common2”>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
<Policy wsu:Id=”secure2”>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
|
|
</ExactlyOne>
|
|
</Policy>
|
|
<wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
|
|
<PolicyReference URI="#secure2" />
|
|
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
|
|
…
|
|
</wsdl:binding>
|
|
<wsdl:service name=”RealTimeDataService”>
|
|
<wsdl:port name=”RealTimeDataPort” binding=”tns:SecureBinding”>
|
|
<PolicyReference URI="#common2"/>
|
|
…
|
|
</wsdl:port>
|
|
</wsdl:service>
|
|
</pre></div>
|
|
</div>
|
|
<p>As we discussed before, the WSDL <code>port</code>,
|
|
<code>binding</code> and <code>portType</code> elements
|
|
collectively represent the endpoint policy subject. In the example
|
|
above, the <code>#common2</code> and <code>#secure2</code> policy
|
|
expressions attached to the <code>SecureBinding</code> WSDL binding
|
|
and <code>RealTimeDataPort</code> WSDL port descriptions
|
|
collectively apply to any message exchange associated with the
|
|
<code>RealTimeDataPort</code> WSDL port.</p>
|
|
<p>As in the example above, multiple policy expressions may be
|
|
attached to Web service constructs that collectively represent a
|
|
single policy subject. When there are multiple policy expressions
|
|
attached to the same policy subject then the effective policy or
|
|
combination of these policy expressions apply to the associated
|
|
policy subject.</p>
|
|
<p>The effective policy is the combination of two or more policy
|
|
expressions attached to the same policy subject. The combination of
|
|
two policy expressions, also known as the merged policy expression,
|
|
is a new policy expression that combines these two policy
|
|
expressions using the <code>All</code> policy operator.</p>
|
|
<p>The policy expression below is the combination of the two policy
|
|
expressions attached to the <code>SecureBinding</code> WSDL binding
|
|
and <code>RealTimeDataPort</code> WSDL port descriptions. The
|
|
<code>#common2</code> policy expression has two policy
|
|
alternatives. The <code>#secure2</code> policy expression has two
|
|
policy alternatives. The combination of these two policies is
|
|
equivalent to Company-X’s secure policy in <a href=
|
|
"#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy
|
|
Expression</b></a> and has four policy alternatives. In other
|
|
words, the combination of two policies is the cross product of
|
|
alternatives in these two policies.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-12.</span> Effective Policy of the Endpoint Policy Subject in the
|
|
Previous Example</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<All>
|
|
<Policy>
|
|
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
</Policy>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</All>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>Of course, the above policy expression can be normalized. There
|
|
are four policy alternatives in the normal form. As we have seen in
|
|
the policy data model, a policy is an unordered collection of
|
|
policy alternatives. That is, the order of policy alternatives is
|
|
insignificant. Therefore, the order of combining these policy
|
|
expressions is insignificant.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="extensibility-and-versioning" id=
|
|
"extensibility-and-versioning"></a>3.8 Extensibility and
|
|
Versioning</h3>
|
|
<div class="div3">
|
|
<h4><a name="ext-vers-policylanguage" id=
|
|
"ext-vers-policylanguage"></a>3.8.1 Policy Language</h4>
|
|
<p>Web Services Policy language is an extensible language by
|
|
design. The <code>Policy</code>, <code>ExactlyOne</code>,
|
|
<code>All</code> and <code>wsp:PolicyReference</code> elements are
|
|
extensible. The <code>Policy</code> element allows child element
|
|
and attribute extensibility, while the <code>ExactlyOne</code> and
|
|
<code>All</code> elements allow child element extensibility. The
|
|
<code>PolicyReference</code> child element allows element and
|
|
attribute extensibility. Extensions must not use the policy
|
|
language XML namespace name. A consuming processor processes known
|
|
attributes and elements, ignores unknown attributes and treats
|
|
unknown children of the <code>Policy</code>,
|
|
<code>ExactlyOne</code>, <code>All</code> elements as policy
|
|
assertions. The child elements of <code>wsp:PolicyReference</code>
|
|
are ignored.</p>
|
|
<p>The <code>PolicyReference</code> element allows element and
|
|
attribute extensibility.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="d3e1496" id="d3e1496"></a>3.8.2 Policy
|
|
Expressions</h4>
|
|
<p>Services that use the Web Services Policy language for policy
|
|
expression enable simple versioning practices that allow requesters
|
|
to continue the use of older policy alternatives in a backward
|
|
compatible manner. This versioning practice allows service
|
|
providers, like Company-X, to deploy new behaviors using additional
|
|
(or new) policy assertions without breaking compatibility with
|
|
clients that rely on any older policy alternatives. We use examples
|
|
below to illustrate how versioning might be done.</p>
|
|
<p>The example below represents a Company-X version 1 policy
|
|
expression. This expression requires the use of addressing and
|
|
transport-level security for protecting messages.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-13.</span> Company-X’s Version 1 Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>Over time, Company-X adds support for advanced behaviors:
|
|
requiring the use of addressing and message-level security for
|
|
protecting messages. They would like to add this advanced support
|
|
without breaking compatibility with requesters that rely on
|
|
addressing and transport-level security. The example below is
|
|
Company-X’s version 2 policy expression. In this version, Company-X
|
|
adds a new policy alternative that requires the use of addressing
|
|
and message-level security. The clients that rely on addressing and
|
|
transport-level security may continue to interact with Company-X’s
|
|
using the old policy alternative. Of course, these clients have the
|
|
option to migrate from using old policy alternatives to new policy
|
|
alternatives.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-14.</span> Company-X’s Version 2 Policy Expression</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
<All> <!-- - - - - - - - - - - - - - - - NEW Policy Alternative -->
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:AsymmetricBinding>…</sp: AsymmetricBinding >
|
|
</All>
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>When Company-X added support for advanced behaviors, they spent
|
|
time to plan for the continued support for existing clients, the
|
|
smooth migration from using current to advanced behaviors, and the
|
|
switch to use only the advanced behaviors in the near future (i.e.
|
|
sun-setting current behaviors). In this versioning scenario, a
|
|
policy expression with multiple alternatives was used to represent
|
|
current and advanced behaviors in a non-disruptive manner: no
|
|
immediate changes to existing clients are required and these
|
|
clients can smoothly migrate to new functionality when they choose
|
|
to. This level of versioning support in a policy expression enables
|
|
the same class of versioning best practices built into WSDL
|
|
constructs such as service, port and binding.</p>
|
|
<p>Let us look at tooling for unknown policy assertions. As service
|
|
providers, like Company-X, incrementally deploy advanced behaviors,
|
|
some requesters may not recognize these new policy assertions. As
|
|
discussed before, these requesters may continue to interact using
|
|
old policy alternatives. New policy assertions will emerge to
|
|
represent new behaviors and slowly become part of everyday
|
|
interoperable interaction between requesters and providers. For
|
|
example, most tools use a practical tolerant strategy to process
|
|
new or unrecognized policy assertions. These tools consume such
|
|
unrecognized assertions and designate these for user intervention.
|
|
As you would recognize, there is nothing new in this practice. This
|
|
is similar to how a proxy generator that generates code from WSDL
|
|
creates code for all the known WSDL constructs and allows Web
|
|
service developers to fill in code for custom or unknown constructs
|
|
in the WSDL.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="ignorable-and-versioning" id=
|
|
"ignorable-and-versioning"></a>3.8.3 Use of Ignorable attribute and
|
|
an alternative Versioning Scenario</h4>
|
|
<p>One potential use of the wsp:Ignorable attribute is to mark
|
|
versioning related information by creating a new policy assertion
|
|
within a policy expression. The new assertion is added to the
|
|
original policy expression and then the service can update the
|
|
assertion parameter values when the service expires.</p>
|
|
<p>One scenario that illustrates this is a service which will
|
|
support a particular version of a service until a certain point in
|
|
time. After that time, the service will not be supported. In this
|
|
scenario, the expiry date and time of the service would be a new
|
|
policy assertion [see Guidelines section 4] that the service
|
|
provider defines . This hypothetical EndOfLife policy assertion is
|
|
then included in the original policy expression, but it could be
|
|
marked as ignorable. The service, in this case, wants to inform the
|
|
consumers it does have an expiry time, and so it is useful to
|
|
convey this information from the beginning to help smooth the
|
|
versioning process.</p>
|
|
<p>Company-X could specify that one policy alternative will expire
|
|
at a certain point in time using the hypothetical ignorable
|
|
Company-X expiry assertion. The example below shows how Company-X
|
|
can create a new version 2 policy expression with a second
|
|
hypothetical ignorable EndOfLife Assertion with a different date
|
|
and time.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
3-15.</span> Company-X's Version 2 Policy Expression with
|
|
hypothetical ignorable EndOfLife Assertion</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<Policy>
|
|
<ExactlyOne>
|
|
<All>
|
|
<company-x:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</company-x:EndOfLife>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:TransportBinding>…</sp:TransportBinding>
|
|
</All>
|
|
|
|
<!-- NEW Policy Alternative -->
|
|
<All>
|
|
<company-x:EndOfLife wsp:Ignorable="true">Mar-31-2999</company-x:EndOfLife>
|
|
<wsam:Addressing>…</wsam:Addressing>
|
|
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
|
|
</All>
|
|
</ExactlyOne>
|
|
</Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>In this variant of the versioning scenario, the use of ignorable
|
|
allows versioning related information to be conveyed and used where
|
|
understood.</p>
|
|
<p>In a scenario such as this, CompanyX is acting as both a policy
|
|
assertion author and a policy expression author. As a policy
|
|
expression author, when an assertion type is tagged as ignorable
|
|
information, the use of strict or lax mode and presence or absence
|
|
of the assertion type in the first version are important
|
|
decisions.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="ignorable-and-optional-and-versioning" id=
|
|
"ignorable-and-optional-and-versioning"></a>3.8.4 Use of Ignorable
|
|
and Optional attributes</h4>
|
|
<p>If Company-X knows about the hypothetical EndOfLife Policy
|
|
assertion, it may or may not mark that assertion with
|
|
wsp:Optional="true" in the first version. If it does include the
|
|
assertion, marks the assertion with wsp:Ignorable="true" and
|
|
wsp:Optional="false", then a client that:</p>
|
|
<ul>
|
|
<li>
|
|
<p>does not know about the assertion and using lax intersection
|
|
will produce an intersection.</p>
|
|
</li>
|
|
<li>
|
|
<p>does not know about the assertion and using strict intersection
|
|
will not produce an intersection.</p>
|
|
</li>
|
|
<li>
|
|
<p>does know about the assertion and using strict or lax
|
|
intersection will produce an intersection.</p>
|
|
</li>
|
|
</ul>
|
|
<p>If it does include the assertion, marks the assertion with
|
|
wsp:Ignorable="true" and wsp:Optional="true", then a client
|
|
that:</p>
|
|
<ul>
|
|
<li>
|
|
<p>does or does not know about the assertion and using lax or
|
|
strict intersection will produce an intersection.</p>
|
|
</li>
|
|
</ul>
|
|
<p>The following table summarizes the requester assertion knowledge
|
|
and intersection mode on the left vs provider ignorable and
|
|
optional on the top</p>
|
|
<table summary=
|
|
"Requester assertion knowledge and intersection mode vs provider ignorable and optional"
|
|
border="true">
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">Requester \ Provider</td>
|
|
<td rowspan="1" colspan="1">Required</td>
|
|
<td rowspan="1" colspan="1">Required and Ignorable (for
|
|
intersection)</td>
|
|
<td rowspan="1" colspan="1">Optional</td>
|
|
<td rowspan="1" colspan="1">Optional and Ignorable (for
|
|
intersection)</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">does not know, lax</td>
|
|
<td rowspan="1" colspan="1">No</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">does not know, strict</td>
|
|
<td rowspan="1" colspan="1">No</td>
|
|
<td rowspan="1" colspan="1">No</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">does know, lax</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">does know, strict</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
<td rowspan="1" colspan="1">Yes</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<br />
|
|
<p>If Company-X adds the hypothetical EndOfLife policy assertion
|
|
type to a subsequent Alternative and does not mark the assertion
|
|
with wsp:Optional="true", then after the policy expression has been
|
|
deployed/used the same algorithm holds true, notably that a client
|
|
using strict mode that does not understand the assertion will not
|
|
intersect with the alternative. If CompanyX adds the hypothetical
|
|
EndOfLife policy assertion with an ignorable attribute and does
|
|
mark the assertion with wsp:Optional="true", then clients using
|
|
strict mode who do not understand the hypothetical EndOfLife
|
|
assertion with the ignorable information will still be compatible
|
|
with the alternative that does not contain the hypothetical
|
|
EndOfLife policy assertion as per the intersection rules. When
|
|
wsp:Ignorable="true" is used, clients that are unaware of the
|
|
hypothetical EndOfLife assertion may make more requests for expired
|
|
services. This could result in servers generating Faults if the
|
|
request is received after the expiry date. .</p>
|
|
<p>If Company-X knows about the hypothetical EndOfLife Policy
|
|
assertion, it can guarantee that clients that know or don't know
|
|
about the hypothetical EndOfLife Policy Assertion can intersect
|
|
under any mode by marking the assertion with wsp:Optional="true".
|
|
Clients that know about the hypothetical EndOfLife Policy assertion
|
|
and performing strict intersection can guarantee interaction with
|
|
services that know or don't know about the hypothetical EndOfLife
|
|
Policy assertion by marking the assertion with wsp:Optional="true".
|
|
Clients that know about the hypothetical EndOfLife Policy assertion
|
|
and performing lax intersection can guarantee interaction with
|
|
services that know or don't know about the hypothetical EndOfLife
|
|
Policy assertion by marking the assertion with wsp:Optional="true"
|
|
or marking it with wsp:Ignorable="true".</p>
|
|
<p>Because the actual value of the date/time may not be known when
|
|
the policy expression is first created, a value that is roughly
|
|
infinitely in the future is used. A subsequent policy alternative
|
|
could refine the value and domain specific processing of the
|
|
assertion can differentiate the value. The advantage of adding the
|
|
end of life information through a domain specific assertion is that
|
|
some clients will have a machine processable way of knowing when
|
|
the alternative will no longer be supported by evaluating the
|
|
policy assertions in a policy expression. Without this information
|
|
in a policy expression, the information must be conveyed in some
|
|
other way or it will not be conveyed at all. This can usefully
|
|
smooth the transition between versions of a service.</p>
|
|
<p>The disadvantage of adding the end of life information through a
|
|
domain specific assertion is that clients need to understand the
|
|
semantics of the hypothetical EndOfLife assertion in order to know
|
|
whether a particular alternative is still valid. For example, a
|
|
client that doesn’t know what the parameter “Mar-31-2008” means,
|
|
will not know that the service is no longer available on April 1,
|
|
and may send messages to this service in April, and if the service
|
|
enforces “end of life”, these messages may fail.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="parts-of-a-policy-assertion" id=
|
|
"parts-of-a-policy-assertion"></a>3.9 Parts of a Policy
|
|
Assertion</h3>
|
|
<p>As we discussed, a policy assertion identifies a domain specific
|
|
behavior or requirement or condition. A policy assertion has a
|
|
QName that identifies its behavior or requirement or condition. A
|
|
policy assertion may contain assertion parameters and a nested
|
|
policy.</p>
|
|
<p>Let us look at the anatomy of a policy assertion from the
|
|
security domain. The policy expression in the diagram below uses
|
|
the <code>sp:IssuedToken</code> policy assertion. This assertion
|
|
illustrates the use of assertion parameters and nested policy.</p>
|
|
<div class="figure" style="text-align: center"><br />
|
|
<img src="policy-assertion.jpg" alt=
|
|
"sp:IssuedToken Policy Assertion" />
|
|
<p style="text-align:left"><i><span>Figure 3-4.</span>
|
|
sp:IssuedToken Policy Assertion</i></p>
|
|
<br /></div>
|
|
<p>The <code>sp:IssuedToken</code> element is a policy assertion
|
|
that identifies the use of a security token – such as SAML token -
|
|
issued by a third party for protecting messages. A policy assertion
|
|
is an XML element. The QName of this element represents the
|
|
behavior identified by this policy assertion.</p>
|
|
<p>The <code>sp:IssuedToken</code> policy assertion has three
|
|
parameters: <code>@sp:IncludeToken</code>, <code>sp:Issuer</code>
|
|
and <code>sp:RequestSecurityTokenTemplate</code>.</p>
|
|
<p>The <code>sp:IncludeToken</code> attribute is a parameter that
|
|
contains information on whether a security token should be included
|
|
in messages or an external reference to the key of this security
|
|
token should be used. The <code>sp:Issuer</code> parameter is an
|
|
endpoint reference to a security token issuer. The
|
|
<code>sp:RequestSecurityTokenTemplate</code> parameter contains the
|
|
necessary information to request a security token from the
|
|
specified issuer. Parameters are the opaque payload of a Policy
|
|
Assertion, carry useful information for engaging the behavior
|
|
described by an assertion and are preserved through policy
|
|
processing such as normalize, merge and 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.</p>
|
|
<p>For the <code>sp:Issuer</code> policy assertion parameter, the
|
|
assertion author uses the natural XML structural relationships (the
|
|
child elements and attributes) and encodes the relationship between
|
|
an assertion and its parameters in a machine readable form.
|
|
Assertion parameters may be represented as child XML elements or
|
|
attributes of an assertion. The policy language allows assertion
|
|
authors to strongly tie the relationship between an assertion and
|
|
its parameters using the natural XML structural relationships.</p>
|
|
<p>The <code>sp:IssuedToken</code> policy assertion has a nested
|
|
policy expression. The <code>sp:RequireInternalReference</code>
|
|
element is a nested policy assertion of the
|
|
<code>sp:IssuedToken</code> policy assertion. The
|
|
<code>sp:RequireInternalReference</code> assertion requires the use
|
|
of an internal reference for referencing the issued token. A nested
|
|
policy assertion further qualifies a dependent behavior of its
|
|
parent policy assertion. As mentioned earlier, requesters may use
|
|
policy intersection to select a compatible policy alternative for
|
|
an interaction. Nested policy assertions affect the outcome of
|
|
policy intersection.</p>
|
|
<p>The <code>sp:IssuedToken</code> security policy assertion
|
|
identifies a visible domain specific behavior: the use of a
|
|
security token – such as SAML token - issued by a third party for
|
|
protecting messages. This behavior is relevant to a Web service
|
|
interaction. For the sake of discussion, let us assume that
|
|
Company-X requires the use of a SAML token issued by a third party.
|
|
Service providers, like Company-X, must convey this usage and all
|
|
the necessary information to obtain this security token for Web
|
|
service developers. This is a key piece of metadata for a
|
|
successful interaction with Company-X’s Web services.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="versioning-policy-language" id=
|
|
"versioning-policy-language"></a>4. Versioning Policy Language</h2>
|
|
<p>Over time, the Policy WG or third parties can version or extend
|
|
the Policy Language with new or modified constructs. These
|
|
constructs may be compatible or incompatible with previous
|
|
versions. Some of the possible new constructs that have been
|
|
mentioned previously are: new operators, operator cardinality,
|
|
policy identification, compact syntax, Policy Inclusion, security,
|
|
referencing, attachment points, alternative priority, effective
|
|
dating, negotiation.</p>
|
|
<p>WS-Policy provides extensibility points on 6 elements with a
|
|
combination of attribute and/or element extensibility. The possible
|
|
extensibility points are:</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p>Policy: element from ##other namespace and any attribute</p>
|
|
</li>
|
|
<li>
|
|
<p>PolicyReference: any attribute and any element</p>
|
|
</li>
|
|
<li>
|
|
<p>ExactlyOne, All: element from ##other namespace, no attribute
|
|
extensibility</p>
|
|
</li>
|
|
<li>
|
|
<p>PolicyAttachment: element from ##other namespace and any
|
|
attribute</p>
|
|
</li>
|
|
<li>
|
|
<p>AppliesTo: any element and any attribute</p>
|
|
</li>
|
|
</ol>
|
|
<div class="div2">
|
|
<h3><a name="versioning-policy-framework" id=
|
|
"versioning-policy-framework"></a>4.1 Policy Framework</h3>
|
|
<p>WS-Policy Framework 1.5 specifies that any child element that is
|
|
not known inside a Policy, ExactlyOne or All will be treated as an
|
|
assertion. The default value for wsp:Optional is "false". After
|
|
normalization, such an element will be inside an ExactlyOne/All
|
|
operator.</p>
|
|
<p>Let us show an example with a hypothetical new operator that is
|
|
a Choice with a minOccurs and a maxOccurs attributes, ala
|
|
XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate
|
|
a hypothetical Policy Language 1.6 that is intended to be
|
|
compatible with Policy Language 1.5:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-1.</span> Policy containing 1.5 and 1.6 Policies.</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<wsp:ExactlyOne>
|
|
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
|
|
...
|
|
</wsp16:Choice>
|
|
<wsp:All>
|
|
...
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The normalization rule for wsp:Optional="false" would be applied
|
|
to the wsp16:Choice, yielding the following expression:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-2.</span> Normalized Policy containing 1.5 and 1.6
|
|
Policies</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<wsp:ExactlyOne>
|
|
<wsp:ExactlyOne>
|
|
<wsp:All>
|
|
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
|
|
...
|
|
</wsp16:Choice>
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
<wsp:All>
|
|
...
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>Alternatively, the wsp:Optional could be set to "true" on the
|
|
choice, as in:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-3.</span> Policy containing explicit wsp:Optional="true"</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"
|
|
wsp:Optional="true">
|
|
...
|
|
</wsp16:Choice>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The normalized form will be:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-4.</span> Normalized policy</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<wsp:ExactlyOne>
|
|
<wsp:All>
|
|
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
|
|
...
|
|
</wsp16:Choice>
|
|
</wsp:All>
|
|
<wsp:All/>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>Because the wsp16:Choice alternative isn't understood in either
|
|
normalized form, it will not be chosen as one of the alternatives
|
|
and will effectively be ignored. Policy intersection may be more
|
|
difficult with such compatible extensions. For example, the
|
|
previous will "look" like it has a wsp16:Choice typed assertion. To
|
|
determine intersection with a Policy that does not have the
|
|
wsp16:Choice type assertion, domain specific processing would have
|
|
to be done. However, there is an alternative that does not have the
|
|
wsp16:Choice, so intersection would yield the expected result.</p>
|
|
<p>Best practice: insert new elements in an optional alternative or
|
|
mark with wsp:Optional="true".</p>
|
|
<p>Incompatible versions of the Policy language may be indicated by
|
|
a new namespace name for at least the new and/or incompatible
|
|
elements or attributes. Imagine that the Choice operator is
|
|
required by a future version of Policy, then there will be a new
|
|
namespace for the Policy element. We use the wsp20 prefix to
|
|
indicate a hypothetical Policy Language 2.0 that is intended to be
|
|
incompatible with Policy Language 1.5:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-5.</span> Policy containing 2.0 only Policies.</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp20:Policy>
|
|
<wsp20:ExactlyOne>
|
|
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
|
|
...
|
|
</wsp20:Choice>
|
|
...
|
|
</wsp20:ExactlyOne>
|
|
</wsp20:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>The new Policy operator could be embedded inside an existing
|
|
Policy element:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-6.</span> Policy containing 2.0 (incompatible with 1.5) Policies
|
|
embedded in wsp 1.5 Policy.</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp:Policy>
|
|
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
|
|
...
|
|
</wsp20:Choice>
|
|
...
|
|
</wsp20:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>This will be treated as an Assertion for normalization and
|
|
intersection computation. This will result in only one alternative
|
|
that requires the wsp20:Choice, the intended behaviour for
|
|
incompatible changes.</p>
|
|
<p>Best practice: use a new namespace for new incompatible
|
|
construct and insert inside either: new Policy element OR existing
|
|
All for future incompatible policy extensions.</p>
|
|
<p>A future version of WS-Policy could support the current
|
|
operators in the existing namespace, such as:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-7.</span> Policy containing 1.5 operator in 2.0 Policy</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsp20:Policy>
|
|
<wsp:ExactlyOne>
|
|
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
|
|
...
|
|
</wsp20:Choice>
|
|
...
|
|
</wsp:ExactlyOne>
|
|
</wsp20:Policy>
|
|
</pre></div>
|
|
</div>
|
|
<p>It is difficult to predict whether this functionality would be
|
|
useful. The future version of WS-Policy doesn't appear to be
|
|
precluded from doing this.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="versioning-policy-attachment" id=
|
|
"versioning-policy-attachment"></a>4.2 Policy Attachment</h3>
|
|
<p>Policy attachment provides WSDL 1.1 and UDDI attachment points.
|
|
It appears that exchange of Policy will be in the context of WSDL
|
|
or UDDI. WRT WSDL, the policy model is an extension of the WSDL
|
|
definition. As such, it is likely that future versions of Policy
|
|
will be exchanged as multiple Policy expressions within a WSDL. One
|
|
alternative is that there would be a separate WSDL for each version
|
|
of Policy. The problem of how to specify and query for compound
|
|
documents is very difficult, so it is more likely that each version
|
|
of Policy will be exchanged within a WSDL.</p>
|
|
<p>We show an example of a new version of policy that allows QName
|
|
reference to Policies in the PolicyReference:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-8.</span> WSDL containing 1.5 and 1.6 (compatible with 1.5)
|
|
Policy References.</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
|
|
<wsoap12:binding style="document"
|
|
transport="http://schemas.xmlsoap.org/soap/http" />
|
|
<wsp:Policy>
|
|
<wsp:ExactlyOne>
|
|
<wsp:All>
|
|
<wsp:PolicyReference URI="#RmPolicy"
|
|
wsdl11:required="true" />
|
|
<wsp:PolicyReference URI="#X509EndpointPolicy"
|
|
wsdl11:required="true" />
|
|
</wsp:All>
|
|
<wsp:All>
|
|
<wsp16:PolicyReferenceByQName ref="rmp:RMAssertion"
|
|
wsdl11:required="true" />
|
|
<wsp16:PolicyReferenceByQName ref="sp:AsymmetricBinding"
|
|
wsdl11:required="true" />
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
<wsdl11:operation name="GetLastTradePrice" > ....
|
|
...
|
|
</pre></div>
|
|
</div>
|
|
<p>The PolicyReference element is element or attribute extensible.
|
|
One example of an addition is a list of backup URIs for the
|
|
PolicyReference:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><i><span>Example
|
|
4-9.</span> WSDL containing 1.5 and 1.6 (compatible with 1.5)
|
|
Policy References.</i></p>
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
|
|
<wsoap12:binding style="document"
|
|
transport="http://schemas.xmlsoap.org/soap/http" />
|
|
<wsp:Policy>
|
|
<wsp:ExactlyOne>
|
|
<wsp:All>
|
|
<wsp:PolicyReference URI="" wsp16:alternateURIs="URI*"
|
|
wsdl11:required="true" />
|
|
<wsp:PolicyReference URI="" wsp16:alternateURIs="URI*"
|
|
wsdl11:required="true" />
|
|
</wsp:All>
|
|
</wsp:ExactlyOne>
|
|
</wsp:Policy>
|
|
<wsdl11:operation name="GetLastTradePrice" > ....
|
|
...
|
|
</pre></div>
|
|
</div>
|
|
<p>The policy framework specification says that any unknown
|
|
attributes are ignored. A Policy 1.5 processor will not understand
|
|
the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6
|
|
processor will understand the alternate URIs so it won't be
|
|
ignored.</p>
|
|
<p>PolicyAttachment and AppliesTo also have extensibility points.
|
|
We choose not to illustrate these at this time.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="conclusion" id="conclusion"></a>5. Conclusion</h2>
|
|
<p>Service providers use Web Services Policy to represent
|
|
combinations of behaviors (capabilities and requirements). Web
|
|
service developers use policy-aware clients that understand policy
|
|
expressions and engage the behaviors represented by providers
|
|
automatically. These behaviors may include security, reliability,
|
|
transaction, message optimization, etc. Web Services Policy is a
|
|
simple language, hides complexity from developers, automates Web
|
|
service interactions, and enables secure, reliable and transacted
|
|
Web Services.</p>
|
|
</div>
|
|
</div>
|
|
<div class="back">
|
|
<div class="div1">
|
|
<h2><a name="security-considerations" 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>mtom</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href=
|
|
"#WS-MTOMPolicy">WS-MTOMPolicy</a></cite>]</td>
|
|
</tr>
|
|
<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>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>wst</code></td>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://docs.oasis-open.org/ws-sx/ws-trust/200512</code></td>
|
|
<td rowspan="1" colspan="1">[<cite><a href=
|
|
"#WS-Trust">WS-Trust</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="C14NNOTE" id="C14NNOTE"></a>[C14N 1.0
|
|
Note]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2006/NOTE-C14N-issues-20061220/">Known Issues
|
|
with Canonical XML 1.0 (C14N/1.0)</a></cite>, J. Kahan and K. Lanz,
|
|
Editors. World Wide Web Consortium, 20 December 2006. Available at
|
|
http:/www.w3.org/TR/2006/NOTE-C14N-issues-20061220/>.</dd>
|
|
<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="WS-MTOMPolicy" id=
|
|
"WS-MTOMPolicy"></a>[WS-MTOMPolicy]</dt>
|
|
<dd><cite><a href=
|
|
"http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/">
|
|
MTOM Serialization Policy Assertion (WS-MTOMPolicy)</a></cite>, C.
|
|
Ferris, et al, Authors. International Business Machines Corporation
|
|
and Microsoft Corporation, Inc., September 2006. Available at
|
|
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/</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="SecSpecMaintWG" id=
|
|
"SecSpecMaintWG"></a>[SecSpecMaintWG]</dt>
|
|
<dd><cite><a href="http://www.w3.org/2007/xmlsec">XML Security
|
|
Specifications Maintenance Working Group</a></cite> , See
|
|
http://www.w3.org/2007/xmlsec.</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 the 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="WS-Atomic" id="WS-Atomic"></a>[Web
|
|
Services Atomic Transaction]</dt>
|
|
<dd><cite><a href=
|
|
"http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-os/wstx-wsat-1.1-spec-os.html">
|
|
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="WS-BA" id="WS-BA"></a>[Web Services
|
|
Business Activity Framework]</dt>
|
|
<dd><cite><a href=
|
|
"http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html">
|
|
Web Services Business Activity (WS-BusinessActivity) Version
|
|
1.1</a></cite>, T. Freund, M. Little, 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-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html.
|
|
Namespace document is available at <a href=
|
|
"http://docs.oasis-open.org/ws-tx/wsba/2006/06">http://docs.oasis-open.org/ws-tx/wsba/2006/06</a>.</dd>
|
|
<dt class="label"><a name="WS-Device" id="WS-Device"></a>[Devices
|
|
Profile for Web Services]</dt>
|
|
<dd><cite><a href=
|
|
"http://schemas.xmlsoap.org/ws/2006/02/devprof/">Devices Profile
|
|
for Web Services</a></cite>, S. Chan, et al, Authors. Intel
|
|
Corporation, Lexmark, Inc., Microsoft Corporation, and Richo
|
|
Software, Inc., February 2006. Available at
|
|
http://schemas.xmlsoap.org/ws/2006/02/devprof/.</dd>
|
|
<dt class="label"><a name="WS-MetadataExchange" id=
|
|
"WS-MetadataExchange"></a>[WS-MetadataExchange]</dt>
|
|
<dd><cite><a href="http://schemas.xmlsoap.org/ws/2004/09/mex/">Web
|
|
Services Metadata Exchange (WS-MetadataExchange)</a></cite>, K.
|
|
Ballinger, et al, Authors. BEA Systems Inc., Computer Associates
|
|
International, Inc., International Business Machines Corporation,
|
|
Microsoft Corporation, Inc., SAP AG, Sun Microsystems, and
|
|
webMethods, August 2006. Available at
|
|
http://schemas.xmlsoap.org/ws/2004/09/mex/</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-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="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-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 is available at <a href=
|
|
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702</a>.</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="XMLID" id="XMLID"></a>[XML ID]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2005/REC-xml-id-20050909/">xml:id Version
|
|
1.0</a></cite>, J. Marsh, D. Veillard and N. Walsh, Editors. World
|
|
Wide Web Consortium, 9 September 2005. This version of the xml:id
|
|
Version 1.0 Recommendation is
|
|
http://www.w3.org/TR/2005/REC-xml-id-20050909/. The <a href=
|
|
"http://www.w3.org/TR/xml-id/">latest version of xml:id Version
|
|
1.0</a> is available at http://www.w3.org/TR/xml-id/.</dd>
|
|
<dt class="label"><a name="C14N11" id="C14N11"></a>[C14N11]</dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/xml-c14n11/">Canonical XML
|
|
1.1</a></cite>, J. Boyer and G. Marcy Authors. W3C Candidate
|
|
Recommendation, 21 June 2007. This is a work in progress. This
|
|
version is available at
|
|
http://www.w3.org/TR/2007/CR-xml-c14n11-20070621. The <a href=
|
|
"http://www.w3.org/TR/xml-c14n11/">latest version of Canonical XML
|
|
1.1</a> is available at http://www.w3.org/TR//xml-c14n11/.</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>
|
|
</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 editorial changes since the Working Draft dated 28
|
|
September, 2007 is below:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Added a UDDI example to <a href=
|
|
"#Referencing_Policy_Expressions"><b>2.10 Referencing Policy
|
|
Expressions</b></a>.</p>
|
|
</li>
|
|
<li>
|
|
<p>Dropped the terms policy vocabulary and policy alternative
|
|
vocabulary.</p>
|
|
</li>
|
|
<li>
|
|
<p>Dropped an incorrect wsp:Choice example and changed wsp to wsp16
|
|
prefix in <a href="#versioning-policy-language"><b>4. Versioning
|
|
Policy Language</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 - Primer 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">20060816</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Created first draft per action item
|
|
<a href=
|
|
"http://www.w3.org/2006/07/12-ws-policy-minutes.html#action02">2</a>
|
|
from the Austin F2F. This draft is based on a <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Jul/0001.html">
|
|
contribution</a> from Microsoft.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20060829</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/2006/08/23-ws-policy-minutes.html#action06">resolution</a>
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3561">3561</a>:
|
|
replaced URI with IRI.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20060919</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/26">action
|
|
26</a> to add versioning material to primer.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20060924</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/35">editorial
|
|
action 35</a> to move the Security Considerations section to the
|
|
Framework document.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20060924</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/36">editorial
|
|
action 36</a> to insert a reference to the Security Considerations
|
|
section from the Framework document.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20060926</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Made a first pass at the changes to
|
|
address issues <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">
|
|
reported by Paul Cotton.</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20060928</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Completed making remaining changes to
|
|
address issues <a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0165.html">
|
|
reported by Paul Cotton.</a> Fixing up the Acknowledgements is
|
|
pending</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061020</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented resolution for Issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3827">3827.</a>
|
|
Editors Action Item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/56">56.</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061027</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented resolution for Issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3815">3815.</a>
|
|
Editors Action Item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/55">55.</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061101</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented resolution for Issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3795">3815.</a>
|
|
Editors Action Item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/68">68.</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061101</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=3791">3791.</a>
|
|
Editors Action Item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/67">67.</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061121</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/2006Oct/0216.html">
|
|
resolution</a> for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3809">3809.</a>
|
|
Editors Action Item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/79">79.</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061121</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Implemented the <a href=
|
|
"http://www.w3.org/2006/11/15-ws-policy-minutes.html#item08">resolution</a>
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3966">3966.</a>
|
|
Editors Action Item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/81">81</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061125</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">20061125</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=3792#c2">resolution</a>
|
|
for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3792">3792.</a>
|
|
Editors Action Item <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/80">80:</a>
|
|
moved Sections <a href=
|
|
"http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#parts-of-a-policy-assertion">
|
|
4.2 Parts of a Policy Assertion</a> and <a href=
|
|
"http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#versioning-policy-language">
|
|
4.4.8 Versioning Policy Language</a> into Section <a href=
|
|
"#advanced-concepts-policy-expression"><b>3. Advanced Concepts:
|
|
Policy Expression</b></a>; moved Section <a href=
|
|
"http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#advanced-concepts-2-policy-assertion-design">
|
|
4 Advanced Concepts II: Policy Assertion Design</a> into the
|
|
Guidelines document.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061127</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">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">20061207</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3952">issue 3952</a>
|
|
<a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0018.html">
|
|
as outlined</a> (with editorial correction replacing "for as" with
|
|
"as"), Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/92">92</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20061213</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3965">issue 3965</a>
|
|
<a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0016.html">
|
|
as outlined.</a> Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/94">94</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070104</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4069">issue 4069</a>
|
|
<a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0081.html">
|
|
as outlined.</a> Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/110">110</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">20070118</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4041">issue 4041</a>
|
|
<a href=
|
|
"http://www.w3.org/2007/01/18-ws-policy-irc#T22-09-36">resolution</a>
|
|
corresponding to Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/143">143</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/118">118</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">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">20070131</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Implemented resolution for issue
|
|
<a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4270">4270</a> as
|
|
Resolved on 31 January 2007, closing editors action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/151">151</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070313</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Applied <a href=
|
|
"http://www.w3.org/2007/03/13-ws-policy-irc#T18-27-19">resolution</a>
|
|
to <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4379">issue 4379</a>
|
|
with minor editorial revision (editors action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/181">181</a>).
|
|
Updated references order.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070314</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Applied <a href=
|
|
"http://www.w3.org/2007/03/13-ws-policy-irc#T22-33-55">resolution</a>
|
|
to <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4263">issue 4263</a>
|
|
(editors action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/195">195</a>).</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070315</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Applied <a href=
|
|
"http://www.w3.org/2007/03/13-ws-policy-irc#T22-27-24">the
|
|
resolution</a> to <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4339">issue 4339</a>
|
|
(editors action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/194">194</a>).</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070315</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Applied <a href=
|
|
"http://www.w3.org/2007/03/14-ws-policy-irc#T17-29-32">the
|
|
resolution</a> to <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4262">issue 4262</a>
|
|
(editors action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/201">201</a>).</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070315</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Applied <a href=
|
|
"http://www.w3.org/2007/03/13-ws-policy-irc#T21-39-50">resolution</a>
|
|
to <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4255">issue 4255</a>
|
|
(editors action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/192">192</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=4288#c4">resolution</a>
|
|
for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4288">issue
|
|
4288</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/196">196</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">FJH</td>
|
|
<td rowspan="1" colspan="1">Applied <a href=
|
|
"http://www.w3.org/2007/03/13-ws-policy-irc#T21-39-50">resolution</a>
|
|
to <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4253">issue 4253</a>
|
|
(editors action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/191">191</a>).</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070319</td>
|
|
<td rowspan="1" colspan="1">MH</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4213">issue 4213</a>
|
|
<a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0076.html">
|
|
as outlined.</a> Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/189">189</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070319</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented the resolution for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4103">issue 4103</a>
|
|
<a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html">
|
|
as outlined.</a> Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193">193</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=4300#c1">resolution</a>
|
|
for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issue
|
|
4300</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190">190</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">20070321</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Formatted the example in <a href=
|
|
"#ignorable-and-versioning"><b>3.8.3 Use of Ignorable attribute and
|
|
an alternative Versioning Scenario</b></a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070322</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Deleted residual text in <a href=
|
|
"#versioning-policy-language"><b>4. Versioning Policy
|
|
Language</b></a>; <code>s/The possible extensibility points with
|
|
their current extensibility - including some outstanding issues
|
|
related to extensibility - are:/The possible extensibility points
|
|
are:/</code> ; <code>s/PolicyReference: any attribute and a
|
|
proposal to add any element/PolicyReference: any attribute and any
|
|
element/</code>.</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/244">244</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070430</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Editorial changes for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393">issue
|
|
4393</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.</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">20070502</td>
|
|
<td rowspan="1" colspan="1">TIB</td>
|
|
<td rowspan="1" colspan="1">Further changes for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393">issue
|
|
4393</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070502</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Finished changes for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4414">issue
|
|
4414</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070524</td>
|
|
<td rowspan="1" colspan="1">DBO</td>
|
|
<td rowspan="1" colspan="1">Finished changes for <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4559">issue
|
|
4559</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/281">281</a>,
|
|
and <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4376">issue
|
|
4375</a>. Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/282">282</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070718</td>
|
|
<td rowspan="1" colspan="1">FJH</td>
|
|
<td rowspan="1" colspan="1">Updated the C14N11 reference
|
|
[<cite><a href="#C14N11">C14N11</a></cite>] for issue <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4851">4851</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/337">337</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">20070727</td>
|
|
<td rowspan="1" colspan="1">ASV</td>
|
|
<td rowspan="1" colspan="1">Fixed a typo in Section <a href=
|
|
"#compatible-policies"><b>3.4 Compatible Policies</b></a>. Editors'
|
|
action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/349">349</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=4857">4857</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/350">350</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=5036">5036</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">355</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=4943">4943</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/354">354</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20070919</td>
|
|
<td rowspan="1" colspan="1">PY</td>
|
|
<td rowspan="1" colspan="1">Implemented the Editors' action
|
|
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">
|
|
362</a> to drop the ed-note.</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=5204">5204</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/370">370</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071023</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=5188">5188</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/369">369</a>.</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=5187">5187</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/368">368</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</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=5226">5226</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/377">377</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">20071026</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=5219">5219</a>.
|
|
Editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/378">378</a>.</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=5219">5219</a> and
|
|
editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/378">378</a>)
|
|
to <a href="#policy-retrieval"><b>3.6 Policy Retrieval</b></a>.
|
|
s/(local or remote) or catalog/(local or remote), registry, or
|
|
catalog/ and s/Policy tools may use any/Policy tools or
|
|
policy-aware clients may use any/.</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=5187">5187</a> and
|
|
editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/368">368</a>)
|
|
to <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> and
|
|
<a href="#references"><b>C. References</b></a>. Fixed C14N 1.0
|
|
Note, SOAP 1.2, Web Services Atomic Transaction, Web Services
|
|
Business Activity Framework, 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">Fixed … in <a href=
|
|
"#Referencing_Policy_Expressions"><b>2.10 Referencing Policy
|
|
Expressions</b></a> (re <a href=
|
|
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5219">5219</a> and
|
|
editors' action <a href=
|
|
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/378">378</a>).</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>
|
|
</tbody>
|
|
</table>
|
|
<br /></div>
|
|
</div>
|
|
</body>
|
|
</html>
|