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.
This is an updated Public Working Draft of the Web Services Policy 1.5 - Framework specification for review
by W3C members and other interested parties. It has been produced by
the
Discussion of this document takes place on the public
This document was produced by a group operating under the
Publication as a Working Draft 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.
Last Modified: $Date: 2006/09/23 00:44:59 $
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.
Web Services Policy 1.5 - Framework does not specify policy discovery or
The following example illustrates a security
Lines (01-06) represent a policy for the algorithm suite required for performing cryptographic operations with symmetric or asymmetric key-based security tokens.
Lines (02-05) 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 a 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 other than the http://www.w3.org/2006/07/ws-policy namespace.
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, 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/2006/07/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/2006/07/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 but rather change only when 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.
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 preponderance of instance would remain valid.
Modifications to the cardinality of elements 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:
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.
A
Assertions are strongly typed by the domain authors
that define them. The
Domain authors
The XML Infoset of a
Domain authors should be cognizant of the processing requirements when defining complex assertions containing additional assertion content or nested policy expressions. Specifically, domain authors are encouraged to consider when the identity of the root Element Information Item alone is enough to convey the requirement or capability.
A
The vocabulary of a policy alternative is the set of
all
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
At the abstract level a
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 in the Web services model,
A
Note that a requester may be able to support a policy
even if the requester does not understand the
To convey policy in an interoperable form, a
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 should be used where practical.
For example, the following is the normal form of the policy expression example introduced earlier.
Lines (03-05) and Lines (06-08) express the two alternatives in the
policy. If the first alternative is selected, only the Basic 256 RSA
15 algorithm suite [
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. To
refer to this policy expression, an IRI-reference
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.
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 policy in a more compact form while still using the
XML Infoset, this specification defines three constructs: an attribute
to decorate an
To interpret a compact policy expression in an interoperable form, a compact expression may be converted to the corresponding normal form expression by the following procedure:
Start with the "http://www.w3.org/2006/07/ws-policy"
. In the base case,
the "Policy"
; in the recursive case, the "Policy"
, "ExactlyOne"
, or
"All"
.
Expand Element Information Items in the
Convert each Element Information Item C in the
If the "http://www.w3.org/2006/07/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 D 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.
To indicate that a
The following describes the Attribute Information Item defined in the schema outline above:
If true, the expression of the assertion is semantically equivalent to the following:
If false, the expression of the assertion is semantically equivalent to the following:
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
Note: 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
This specification does not define processing for arbitrary
<Lorem><Ipsum><wsp:Policy> …
</wsp:Policy></Ipsum></Lorem>
.
Policy assertions containing a nested policy expression are
normalized recursively. The nesting of a policy expression (and a
For example, consider the following compact nested policy expression:
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 normalized form of this policy 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).
To compactly express complex policies, policy operators
The following rules are used to transform a compact policy expression into a normal form policy expression:
<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,
is equivalent to:
Distributing
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).
In order to share
When a
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 included.
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 optional attribute specifies the digest of the referenced policy expression. This is used to ensure the included policy is the expected policy. If omitted, there is no implied value.
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/2006/07/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
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.
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
Two
Two
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
It is
Policies
It should be noted that the mechanisms described in this document
could be secured as part of a SOAP message [
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), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Bijan Parsia (University of Manchester), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
The people who have contributed to
A list of substantive changes since the Working Draft dated 31 July 2006 is below:
Added support for the xml:id
attribute.
Added an empty conformance section.
Replaced URI with IRI.
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:
|
200609006 | DBO | Completed partial resolution for issue
|
20060906 | TIB | Completed action item:
|