Copyright ©2003 W3C®(MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
SOAP 1.2 intermediaries have some license when reserializing messages that pass through them. This document defines a transformation algorithm that renders all semantically equivalent SOAP messages identically. The transformation may be used in conjunction with an XML canonicalization algorithm prior to the generation of a message digest in producing XML digital signatures that are sufficiently robust to survive passage through one or more SOAP intermediaries.
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 W3C technical reports index at http://www.w3.org/TR/.
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.
This document is the work of the W3C XML Protocol Working Group, and no more work from this Working Group is currently expected on this document.
The XML Protocol Working Group is part of the Web Services Activity.
Comments on this document should be sent to the publicly archived mailing list xml-dist-app@w3.org
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
1. Introduction
1.1 Notational Conventions
2. The Need for SOAP Message Normalization
2.1 A Simple Example
3. Specification of SOAP Message Normalization
4. Use in XML Security
5. References
5.1 Normative References
5.2 Informative References
A. XSLT Implementation (Non-Normative)
B. Acknowledgements (Non-Normative)
SOAP 1.2 [SOAP Part1] intermediaries have some license when reserializing messages that pass through them. Current XML canonicalizations (see [XML C14N] and [EXCL C14N]) do not take into account the transforms that a SOAP intermediary can legally apply to messages passing through it. This document defines a transformation that renders all semantically equivalent SOAP messages identically. This transformation may be used in conjunction with an XML canonicalization algorithm prior to the generation of a message digest in producing XML digital signatures that are sufficiently robust to survive passage through one or more SOAP intermediaries.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
This note uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [XML InfoSet]).
| Prefix | Namespace | Notes |
|---|---|---|
| env | "http://www.w3.org/2003/05/soap-envelope" | A normative XML Schema [XML Schema Part1], [XML Schema Part2] document for the "http://www.w3.org/2003/05/soap-envelope" namespace can be found at http://www.w3.org/2003/05/soap-envelope. |
Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs (see [RFC 2396]).
All parts of this note are normative, with the exception of examples and sections explicitly marked as "Non-Normative".
As a simple example of the kind of problem a SOAP intermediary can cause for an XML signature, consider the following SOAP message:
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <n:alertcontrol env:mustUnderstand="false" xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope>
A SOAP intermediary is at liberty to remove the
env:mustUnderstand attribute from SOAP header blocks
when its value is "false" or "0".
If the message included a signature of the header block
generated using XML Canonicalization [XML C14N] or
Exclusive XML Canonicalization [EXCL C14N] then
that signature would be invalidated if the intermediary removed
the mustUnderstand attribute. There is therefore a
requirement for a transformation that takes into account the
variations that a SOAP intermediary can introduce. SOAP Message
Normalization fulfils this requirement.
SOAP Message Normalization is specified as an XML infoset transformation and consists of the following steps:
A SOAP Header element information
item that has no child element information items is
removed.
If a SOAP Header element information
item is present then for each child element information item
of the SOAP Header element information item:
If the SOAP mustUnderstand attribute
information item is present with a value of
"0" or "false" then remove the
mustUnderstand attribute information
item.
If the SOAP mustUnderstand attribute
information item is present with a value of
"1" then change its value to
"true".
If the SOAP role attribute information
item is present with a value of
"http://www.w3.org/2003/05/soap-envelope/role/
ultimateReceiver" or "" then remove
the role attribute information item.
If the SOAP relay attribute
information item is present with a value of
"0" or "false" then remove the
relay attribute information
item.
If the SOAP relay attribute
information item is present with a value of
"1" then change its value to
"true".
Processing instruction information items that are
children of the SOAP Envelope , Header ,
Fault , Code , Subcode , Value ,
Reason , Text , Node and Role
element information items are removed.
Whitespace character information items that are
children of the SOAP Envelope , Header ,
Fault , Code , Subcode , Value ,
Reason , Node and Role element
information items are removed.
SOAP Message Normalization may be used as a Transform
algorithm in XML Digital Signature [XML DSig]. Use of
a separate CanonicalizationMethod such as XML
Canonicalization [XML C14N] or Exclusive XML
Canonicalization [EXCL C14N] is required. SOAP
Message Normalization is identified with the following URI:
"http://www.w3.org/2003/10/soap12-n11n"