W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2004

Problems with the SOAP binding

From: Rich Salz <rsalz@datapower.com>
Date: Sat, 18 Dec 2004 18:24:56 -0500 (EST)
To: public-ws-addressing@w3.org
Message-ID: <Pine.LNX.4.44L0.0412181821530.18688-100000@smtp.datapower.com>

After some off-line discussion with Glen (sparked by my "+1"
response to Dims's proposal), I'm still concerned about the way
the SOAP binding promotes refp's to first-class SOAP headers.

Suppose a sender has a set of refp's and wants to make sure that
they come back, unmodified.  The natural way to do this would be
to sign them, with a single signature covering all the elements.
(There could be multiple signatures, but it's really not important

Where should that signature go?  Suppose the client is using
WS-Security.  The sender can't create a WS-Security header, since
WSS does not allow multiple WSS elements targeted to the same node.

Suppose the sender generates a signature element.  The current
SOAP binding says that this header must be promoted to top-level
Header element.  This conflicts with WSS which says that all security
elements should be contained within WSS.

Whenever an EPR has a signature, it seems impossible for the client
to be conformant with both WSS and WSA.  Gudge, you're also involved
in both groups -- can you prove me wrong?

The work-around -- the sender creates its own WSS header, with a
unique SOAP actor attribute that just happens to be an internal
"alias" for the server itself, is a real hack.

(I think this is a general problem whenever an EPR includes a
refp that is *part* of another header.  Folks have claimed that
WS-RM could use refps, perhaps by include a sequence ACK header.
But suppose the server just wants to identify the sequence,
leaving it up to the sender or WS-RM layer to determine whether to
continue or terminate.  But I'm on thin ice here, as I don't know how
folks are using WS-RM.  Not that I care a great deal, since it's a
proprietary spec and there's an open WS-ReliableMessaging already :).
I'm much more sure of the WSS/WSA conflict I described above.)

Unless I'm wrong, this seems to me like a fundamental flaw in the
SOAP binding.


Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html
Received on Saturday, 18 December 2004 23:25:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:22 UTC