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

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