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.

This document is a NOTE made available by the W3C for discussion only.
Publication of this Note by W3C indicates no endorsement of its content
by W3C, nor that W3C has, is, or will be allocating any resources to
the issues addressed by the Note. This document is a work in progress
and may be updated, replaced, or rendered obsolete by other documents
at any time.

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.

1. Introduction

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.

1.1 Notational Conventions

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]).

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.

3. Specification of SOAP Message Normalization

SOAP Message Normalization is specified as an XML infoset
transformation and consists of the following steps:

4. Use in XML Security

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: