The Web Services Policy 1.5 - Framework provides a general purpose model and corresponding syntax to describe the policies of entities in a Web services-based system.
Web Services Policy Framework defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements and capabilities.
On 28 February 2007, this specification
Publication as a Candidate Recommendation 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. This specification will remain a Candidate Recommendation until at least 30 June 2007.
This Working Draft was produced by the members of the
A list of
The Working Group is tracking all comments via
This document was produced by a group operating under the
Last Modified: $Date: 2007/03/29 12:49:45 $
Web Services Policy 1.5 - Framework defines a framework and a model for expressing policies that refer to domain-specific capabilities, requirements, and general characteristics of entities in a Web services-based system.
A
Web Services Policy 1.5 - Framework does not cover discovery of policy, policy scopes and subjects,
or their respective attachment mechanisms. A
Lines (03-06) represent one policy alternative for signing a message body.
Lines (08-11) represent a second policy alternative for encrypting a message body.
Lines (02-13) illustrate the
This section specifies the notations, namespaces, and terminology used in this specification.
This specification uses the following syntax within normative outlines:
The syntax appears as an XML instance, but values in
Characters are appended to elements and attributes to indicate cardinality:
"?" (0 or 1)
"*" (0 or more)
"+" (1 or more)
The character "|" is used to indicate an exclusive choice between alternatives.
The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
This document relies on the XML Information Set [
XML namespace prefixes (see
The ellipses characters "…" are used to indicate a point of extensibility that allows other Element or Attribute Information Items.
Elements and Attributes defined by this specification are referred to in the text of this document using XPath 1.0 [XPATH 1.0] expressions. Extensibility points are referred to using an extended version of this syntax:
An element extensibility point is referred to using {any} in place of the
element name. This indicates that any element name can be used, from any
namespace, unless specified otherwise such as in Section
An attribute extensibility point is referred to using @{any} in place of the attribute name. This indicates that any attribute name can be used, from any namespace.
Normative text within this specification takes precedence over normative
outlines, which in turn take precedence over the XML Schema [
Within normative outlines, in this specification, ellipses (i.e., "…")
indicate a point of extensibility that allows other Element or Attribute
Information Items. Information Items
This specification uses a number of namespace prefixes throughout; they are
listed in
Prefix | Namespace | Specification |
---|---|---|
sp
|
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy
| [ |
wsp
|
http://www.w3.org/ns/ws-policy
| This specification |
wsu
|
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
| [ |
xs
|
http://www.w3.org/2001/XMLSchema
| [ |
All information items defined by this specification are identified by the XML
namespace URI [http://www.w3.org/ns/ws-policy
. A
It is the intent of the W3C Web Services Policy Working Group that the Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment XML namespace URI will not change arbitrarily with each subsequent revision of the corresponding XML Schema documents as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a WD, CR or PR draft, results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification, the namespace URI will be changed accordingly.
Under this policy, the following are examples of backwards compatible changes that would not result in assignment of a new XML namespace URI:
Addition of new global element, attribute, complexType and simpleType definitions.
Addition of new elements or attributes in locations covered by a previously specified wildcard.
Modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the vast majority of instances would remain valid.
Modifications to the cardinality of elements (i.e. modifications to minOccurs or maxOccurs attribute value of an element declaration) for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule.
The keywords "
We introduce the following terms that are used throughout this document:
An
A
A
A
A
A
A
A
A
A
A
A
A
This section defines an abstract model for policies and for operations upon policies.
The descriptions below use XML Infoset terminology for convenience of description. However, this abstract model itself is independent of how it is represented as an XML Infoset.
An assertion MAY indicate that it is an ignorable policy assertion (see
Assertions are typed by the authors that define them.
Authors
The XML Infoset of a
Authors should be cognizant of the processing requirements when defining complex
assertions containing
Assertions within an alternative are not ordered, and thus aspects such as the
order in which behaviors (indicated by assertions) are applied to a
A policy alternative
Note: Depending on the semantics of the domain specific policy assertions a combination of the policy assertions can be required to specify a particular behavior.
Alternatives are not ordered, and thus aspects such as preferences between alternatives in a given context are beyond the scope of this specification.
Alternatives within a policy may differ significantly in terms of the behaviors they indicate. Conversely, alternatives within a policy may be very similar. In either case, the value or suitability of an alternative is generally a function of the semantics of assertions within the alternative and is therefore beyond the scope of this specification.
Applied to a Web services based system,
Any entity in a Web services based system may expose a policy to convey
conditions under which it functions. Satisfying assertions in the policy usually
results in behavior that reflects these conditions. For example, if two entities
- requester and provider - expose their policies, a requester might use the
policy of the provider to decide whether or not to use the service. A requester
A
Note that an entity may be able to support a policy even if the entity does not
understand the
This section describes how to convey
The normal form (see Section
While the policy language XML Schema is a representation of the compact form, the
normal form is more restrictive as outlined in Section
To facilitate interoperability, this specification defines a normal form for
The following describes the Element Information Items defined in the schema outline above:
A policy expression.
A collection of policy alternatives. If there are no Element
Information Items in the
A policy alternative; a collection of policy assertions. If there
are no Element Information Items in the
XML Infoset representation of a policy assertion.
Additional attributes
If an
To simplify processing and improve interoperability, the normal form of a policy
expression
For example, the following is the normal form of a policy expression.
Lines (03-07) and Lines (08-11) express the two alternatives in the policy. If
the first alternative is selected, the message body needs to be signed [
A
The following describes the Attribute Information Items listed and defined in the schema outline above:
The identity of the policy expression as an absolute IRI [
The identity of the policy expression as an ID
within
the enclosing XML document. If omitted, there is no implied value.
The constraints of the XML 1.0 [
The use of xml:id
attribute in conjunction with
Canonical XML 1.0 is inappropriate as described in Appendix C of
xml:id Version 1.0 [xml:id
attribute
should not be signed using XML Digital Signature when Canonical XML
1.0 is being used as the canonicalization method.
Canonical XML 1.1 [xml:id
. 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 [
The following example illustrates how to associate a policy expression with the
absolute IRI "http://www.example.com/policies/P1"
:
The following example illustrates how to associate a policy expression with the
IRI-reference "#P1"
:
To express a
A
To indicate that a
The following describes the Attribute Information Item defined in the schema outline above:
If the actual value (See XML Schema Part 1 [
If the actual value (See XML Schema Part 1 [
Omitting this attribute is semantically equivalent to including it with a value of false. Policy expressions should not include this attribute with a value of false, but policy parsers must accept this attribute with a value of false.
For example, the following compact policy expression:
is equivalent to the following normal form policy expression:
The
Any
The following describes additional processing constraints on the outline listed above:
This indicates that the assertion contains a nested policy
expression. If there is no
If the schema outline for an assertion type requires a nested
policy expression but the assertion does not further qualify one
or more aspects of the behavior indicated by the assertion type
(i.e., no assertions are needed in the nested policy
expression), the assertion <wsp:Policy/>
Element
Information Item in its
Note: This specification does not define processing for arbitrary
Policy assertions containing a nested policy expression are normalized
recursively. The nesting of a policy expression (and a
For example, consider the following policy expression with nested policy expressions in a compact form:
Lines (02-18) in this policy expression contain a single transport binding security policy assertion; within its nested policy expression (Lines 03-17), is an algorithm suite assertion (Lines 04-11) whose nested policy expression (Lines 05-10) contains two policy alternatives (Lines 07-08). Generally, a nested policy expression implies recursive processing; in the example above, the behavior indicated by the transport binding assertion requires the behavior indicated by one of the assertions within the algorithm suite assertion.
The example above is equivalent to the following:
In the listing above, the transport binding and its nested policy expression have been duplicated once for each of the nested alternatives in Lines (07-08) of the compact policy. The first alternative (Lines 03-18) contains a single nested algorithm suite alternative (Line 08) as does the second alternative (Lines 19-34 and 24).
The schema outline for the
The following describes the Attribute and Element Information Items defined in the schema outline above:
This element is the
This element is a nested
This element is a nested
This element is a nested
This element references a policy expression to be included per
Section
Additional attributes
Additional elements
The schema outline for the
The following describes the Attribute and Element Information Items defined in the schema outline above:
This element is the
This element is a nested
This element is a nested
This element is a nested
This element references a policy expression to be included per
Section
Additional elements
The schema outline for the
The following describes the Attribute and Element Information Items defined in the schema outline above:
This element is the
This element is a nested
This element is a nested
This element is a nested
This element references a policy expression to be included per
Section
Additional elements
The
The following rules are used to transform a compact policy expression into a normal form policy expression:
Use of
A collection of assertions in an
is equivalent to:
<wsp:All />
expresses a policy
with zero policy assertions. Note that since
<wsp:Policy
/>
is therefore equivalent to
<wsp:All />
, i.e., a
policy alternative with zero assertions.
<wsp:ExactlyOne />
expresses a
policy with zero policy alternatives.
In line with the previous statements that policy assertions
within a policy alternative and policy alternatives within a
policy are not ordered (see
is equivalent to:
and:
is equivalent to:
is equivalent to:
and:
is equivalent to:
is equivalent to:
and:
is equivalent to:
is equivalent to:
Similarly by repeatedly distributing wsp:All over wsp:ExactlyOne,
is equivalent to:
Distributing
is equivalent to:
and:
is equivalent to:
For example, given the following compact policy expression:
Applying Section
Note that the assertion listed in Line (02) in the first listing expands into the two alternatives in Lines (03-06) in the second listing.
Finally, noting that
Note that the two alternatives listed in Lines (03-06) in the second listing are combined with the two alternatives listed in Lines (09-14) in the second listing to create four alternatives in the normalized policy, Lines (03-06), (07-10), (11-13), and (14-16).
The
The schema outline for the
The following describes the Attribute and Element Information Items defined in the schema outline above:
This element references a policy expression that is being referenced.
This attribute references a policy expression by an IRI. For a
policy expression within the same XML Document, the reference
ID
. For an external
policy expression, there is no requirement that the IRI be
resolvable; retrieval mechanisms are beyond the scope of this
specification. After retrieval, there is no requirement to check
that the retrieved policy expression is associated (Section
This attribute is of type
This optional URI attribute specifies the digest algorithms being used. This specification predefines the default algorithm below, although additional algorithms can be expressed.
URI | Description |
---|---|
http://www.w3.org/ns/ws-policy/Sha1Exc (implied) | The digest is a SHA1 hash over the octet stream resulting from
using the Exclusive XML canonicalization defined for XML
Signature [ |
Additional attributes
Additional elements
In order to share
When a
In the example below two policies include and extend a common policy. In the first example there is a single policy document containing two policy assertions. The expression is given an identifier but not a fully qualified location. The second and third expressions reference the first expression by URI indicating the referenced expression is within the document.
There are times when it is desirable to "re-use" a portion of a policy expression. Generally, this can be accomplished by placing the common assertions in a separate policy expression and referencing it.
To interpret a compact
Start with the Element Information Item E (as defined in the XML
Information Set ["http://www.w3.org/ns/ws-policy"
. In the base case, the
"Policy"
; in the recursive case, the "Policy"
, "ExactlyOne"
, or
"All"
.
Expand Element Information Items (as defined in the XML Information
Set [
Convert each Element Information Item C in the
If the "http://www.w3.org/ns/ws-policy"
and the "Policy"
, "ExactlyOne"
, or
"All"
, C is an expression of a policy
operator; normalize C by recursively applying this
procedure.
Otherwise the Element Information Item C is an assertion;
normalize C per Sections
Apply the policy operator indicated by E to the normalized Element
Information Items in its
Note that an implementation may use a more efficient procedure and is not required to explicitly convert a compact expression into the normal form as long as the processing results are indistinguishable from doing so.
The
The following describes the Attribute Information Item defined in the schema outline above:
This attribute is of type xs:boolean
. If the actual
value (See XML Schema Part 1 [
Policy intersection is useful when two or more parties express
Because the set of behaviors indicated by a
Two
If either assertion contains a nested
If the mode is strict, two
if each assertion in A is compatible with an assertion in B, and
if each assertion in B is compatible with an assertion in A.
If the mode is lax, two
if each assertion in A that is not an
if each assertion in B that is not an
If two alternatives are compatible, their intersection is an alternative containing all of the assertions in both alternatives.
Two
See Section
As an example of intersection, consider two input policies in normal form:
The listing above contains two policy alternatives. The first alternative, (Lines
03-10) contains two policy assertions. One indicates which elements should be
signed (Lines 04-06); its type is
The second alternative (Lines 11-19) also contains two assertions, each with type (Line 12 and Line 16) and parameters (Lines 13-14 and Line 17).
As this example illustrates, compatibility between two policy assertions is based on assertion type and delegates parameter processing to domain-specific processing.
Because there is only one alternative (A2) in policy P1 with the same vocabulary — the assertions have the same type — as another alternative (A3) in policy P2, the intersection is a policy with a single alternative that contains all of the assertions in A2 and in A3.
Note that there are > 1 assertions of the type
Policy expressions use IRIs for some identifiers. This document does not define a
base URI but relies on the mechanisms defined in XML Base [
It is
Policies
It should be noted that the mechanisms described in this document could be secured as
part of a SOAP message [
This section describes the security considerations that service providers,
requestors, policy authors, policy assertion authors, and policy implementers need
to consider when exposing, consuming and designing
A policy is used to represent the capabilities and requirements of a Web Service.
Policies may include sensitive information. Malicious consumers may acquire
sensitive information, fingerprint the service and infer service
vulnerabilities. These threats can be mitigated by requiring authentication for
sensitive information, by omitting sensitive information from the policy or by
securing access to the policy. For securing access to policy metadata, policy
providers can use mechanisms from other Web Services specifications such as
WS-Security [
If a policy expression is unsigned it could be easily tampered with or replaced. To prevent tampering or spoofing of policy, requestors should discard a policy unless it is signed by the provider and presented with sufficient credentials. Requestors should also check that the signer is actually authorized to express policies for the given policy subject.
A policy may offer several alternatives that vary from weak to strong set of requirements. An adversary may interfere and remove all the alternatives except the weakest one (say no security requirements). Or, an adversary may interfere and discard this policy and insert a weaker policy previously issued by the same provider. Policy authors or providers can mitigate these threats by sun-setting older or weaker policy alternatives. Requestors can mitigate these threats by discarding policies unless they are signed by the provider.
Malicious providers may include policy assertions in its policy whose behavior cannot be verified by examining the wire message from the provider to requestor. In general, requestors have no guarantee that a provider will behave as described in the provider’s policy expression. The provider may not and perform a malicious activity. For example, say the policy assertion is privacy notice information and the provider violates the semantics by disclosing private information. Requestors can mitigate this threat by discarding policy alternatives which include assertions whose behavior cannot be verified by examining the wire message from the provider to requestor. Assertion authors can mitigate this threat by not designing assertions whose behavior cannot be verified using wire messages.
Malicious providers may provide a policy expression with a large number of alternatives, a large number of assertions in alternatives, deeply nested policy expressions or chains of PolicyReference elements that expand exponentially (see the chained sample below; this is similar to the well-known DTD entity expansion attack). Policy implementers need to anticipate these rogue providers and use a configurable bound with defaults on number of policy alternatives, number of assertions in an alternative, depth of nested policy expressions, etc.
Malicious providers may provide a policy expression that includes multiple PolicyReference elements that use a large number of different internet addresses. These may require the consumers to establish a large number of TCP connections. Policy implementers need to anticipate such rogue providers and use a configurable bound with defaults on number of PolicyReference elements per policy expression.
Implementers of Web Services policy language should be careful to protect their software against general XML threats like deeply nested XML or XML that contains malicious content.
An element information item whose namespace name is "http://www.w3.org/ns/ws-policy" and whose local
part is Policy or PolicyReference conforms to this specification if it is valid
according to the XML Schema [
This appendix defines the
application
wspolicy+xml
none
This parameter has identical semantics to the charset
parameter of the
Identical to those of
See section
There are no known interoperability issues.
This document and
This new media type is being registered to allow for deployment of Web Services Policy and references to Web Services Policy on the World Wide Web.
wspolicy
A syntax identical to that of
As specified in
TEXT
World Wide Web Consortium <web-human@w3.org>
COMMON
The Web Services Policy 1.5 specification set is a work
product of the World Wide Web Consortium's
This document is the work of the
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), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Paul Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Arnaud Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation), Bob Natale (MITRE Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (CA Inc.), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
Previous members of the Working Group were: Jeffrey Crump (Sonic Software), Jong Lee (BEA Systems, Inc.), Bob Natale (MITRE Corporation), Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.).
The people who have contributed to
A list of major editorial changes since the Working Draft dated 28 February, 2007 is below:
None.
Date | Author | Description |
---|---|---|
20060712 | ASV | Updated the list of editors. Completed action items |
20060718 | DBO | Completed action items: RFC2606 for domain names |
20060726 | ASV | Incorporated the |
20060803 | PY | Completed Issue: |
20060808 | PY | Completed action item: |
20060808 | DBO | Completed action items: |
20060808 | ASV | Implemented the |
20060809 | ASV | Implemented the |
20060811 | DBO | Completed action items: |
20060813 | ASV | Added a new Section |
20060818 | ASV | Implemented the |
20060822 | TIB | Completed action item: |
20060824 | PY | Completed action item: |
20060827 | TIB | Completed action item: |
20060828 | DBO | Completed action item: Partial |
20060829 | ASV | Implemented the |
20060830 | DBO | Completed action item: |
20060906 | DBO | Completed partial resolution for issue |
20060906 | TIB | Completed action item: |
20060912 | DBO | Completed action item: |
20060913 | TIB | Completed action item: |
20060913 | TIB | Completed action item: |
20060913 | TIB | Completed action item: |
20060918 | PY | Completed action item: |
20060918 | PY | Completed action item: |
20060918 | PY | Completed action item: |
20060918 | PY | Completed action item: |
20060918 | PY | Completed action item: |
20060918 | PY | Completed action item: |
20060918 | PY | Completed action item: |
20060920 | DBO | Completed action item: |
20060921 | PY | Completed action item: |
20060924 | TIB | Implemented the |
20060926 | ASV | Implemented the action item: |
20060927 | MH | Completed action item: |
20060927 | PY | Completed action item: |
20061002 | DBO | Completed action item: |
20061002 | DBO | Implemented the |
20061002 | DBO | Implemented the |
20061004 | PY | Completed action item: |
20061007 | TIB | Completed action item: |
20061007 | TIB | Completed action item: |
20061008 | MH | Completed action item: |
20061011 | PY | Updated "Changes in this Version" section (Appendix C) |
20061012 | DBO | Revisited action items: |
20061019 | PY | Completed action item: |
20061027 | ASV | Implemented the |
20061030 | DBO | Implemented the |
20061102 | ASV | Implemented the |
20061102 | ASV | Reset Section |
20061103 | ASV | Re-formatted the example in |
20061109 | PY | Implemented the editorial changes for Issue 3961 for Editors' Action
|
20061109 | TIB | Implemented Editors' Action |
20061109 | TIB | Implemented Editors' Action |
20061109 | ASV | Implemented the |
20061109 | ASV | Implemented Editors' Action |
20061109 | ASV | Updated Section |
20061114 | ASV | Fixed typos in Appendix |
20061127 | ASV | Added |
20061213 | TIB | Implemented Editors' Action |
20061218 | FH | Implemented the |
20061220 | PY | Completed action item: |
20070108 | ASV | Reset Section |
20070116 | DBO | Completed action item: |
20070121 | MH | Completed action item: |
20070121 | MH | Completed action item: |
20070121 | MH | Completed action item: |
20070122 | MH | Completed action item: |
20070122 | PY | Completed action item: |
20070122 | PY | Completed action item: |
20070122 | PY | Completed action item: |
20070122 | PY | Completed action item: |
20070122 | PY | Completed action item: |
20070122 | PY | Completed action item: |
20070122 | ASV | Implemented the resolution for issue |
20070122 | ASV | Implemented the |
20070122 | ASV | Implemented the |
20070122 | ASV | Implemented the |
20070123 | ASV | Implemented the |
20070123 | ASV | Fixed a typo in |
20070123 | ASV | Applied a |
20070124 | ASV | Updated Section |
20070207 | PY | Implemented the resolution for issue |
20070207 | ASV | Implemented the resolution for issue |
20070222 | ASV | Applied a |
20070313 | FJH | Applied |
20070321 | ASV | Reset Section |
20070328 | FS | Re-formatted the first example in |