RE: Problems with the SOAP binding

Rich,

Am thinking aloud here...so bear with me. If you see Scenario #2 in
OASIS WSS Interop [1]. I can easily see that we could send the whole
wsse:Security as a header property as shows below and the client can
just send the whole thing back as-is. If the client has to add its own
stuff then it follows the same rules as laid out in the OASIS WSS main
spec[2] Section #5 for intermediaries. Yes, we'd have to relax the rules
for opacity such that the client can modify the wsse header block. Will
this work?

Thanks,
dims

<wsa:To>
  <wsa:Address>urn:example:bar</wsa:Address>
  <wsa:ReferenceProperties>
    <wsse:Security soap:mustUnderstand="1"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext">
	<xenc:EncryptedKey
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
		<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
		<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
			<wsse:SecurityTokenReference>
				<wsse:KeyIdentifier
ValueType="wsse:X509v3">B39R...=</wsse:KeyIdentifier>
			</wsse:SecurityTokenReference>
		</KeyInfo>
		<xenc:CipherData>
	
<xenc:CipherValue>pPzyO...XlM=</xenc:CipherValue>
		</xenc:CipherData>
		<xenc:ReferenceList>
			<xenc:DataReference URI="#enc-un"/>
		</xenc:ReferenceList>
	</xenc:EncryptedKey>
	<xenc:EncryptedData wsu:Id="enc-un"
Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
		<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
		<xenc:CipherData>
	
<xenc:CipherValue>A/ufDw...chA==</xenc:CipherValue>
		</xenc:CipherData>
	</xenc:EncryptedData>
    </wsse:Security>
  </wsa:ReferenceProperties>
</wsa:To>

[1] http://lists.oasis-open.org/archives/wss/200306/msg00050.html 
[2]
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-sec
urity-1.0.pdf

-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Rich Salz
Sent: Saturday, December 18, 2004 6:25 PM
To: public-ws-addressing@w3.org
Subject: 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 Tuesday, 21 December 2004 22:01:03 UTC