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

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.


Rich Salz                  Chief Security Architect
DataPower Technology
XS40 XML Security Gateway
XML Security Overview

Received on Thursday, 25 November 2004 15:31:27 UTC