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

RE: Using attributes to mark RefProp's and RefParam's

From: Rich Salz <rsalz@datapower.com>
Date: Thu, 25 Nov 2004 10:31:26 -0500 (EST)
To: public-ws-addressing@w3.org
cc: Martin Gudgin <mgudgin@microsoft.com>, Christopher B Ferris <chrisfer@us.ibm.com>
Message-ID: <Pine.LNX.4.44L0.0411251014140.23590-100000@smtp.datapower.com>

> When Chris told me that we lose the ability to subject the soap headers
> to the SOAP Processing model if we have a wrapper

I am not sure that this is true.  If refprop/param information is intended
for the ultimate recipient -- it is an *Endpoint*Reference, after all --
then I do not see why the recipient can't look for wsa:refprop/foo as
easily as it can look for foo.

Why is it so important to promote refprops/params to generic soap headers?
Nobody else does it. It becomes impossible to write generic "process
addressing information" (e.g., WS management infrastructures) without
closely coupling the layers on a *per-operation* basis.  Same for
security.  It goes against the philosophy of composable headers. And Mark
B will argue that it goes against the Web architecture of
self-description.

I think "we" have made our case that there are real security, and
coupling, concerns by doing this, and that it goes against the grain of
everyting else in ws-xxx-land being self-identifying.  I think now "you"
should need to answer the question above.

The problem with Dim's suggestion to add an attribute is that it
now makes it impossible for anyone to sign a refprop/param directly
(you have to use an XPath transform or something similar), since
the content changes during the promotion.

> I don't understand that scenario. A given endpoint X expects certain
> SOAP headers to be in a message.

This requires that endpoint X not have any optional headers, else you
are subject to the insertion attacks discussed earlier.  I do not think
it is reasonable to prohibit optional data, and the security cost of
allowing it seems too high.

	/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 Thursday, 25 November 2004 15:31:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:00 GMT