Problems with the SOAP binding

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

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.

        /r$

-- 
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