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

Rich,

Please see my comments below.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 11/25/2004 10:31:26 AM:

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

Ok, let's say I have a gateway that serves as the external facing endpoint
for all of my internal services, which are hidden behind a firewall.
I could expose an EPR that has the wsa:Address URI of my external gateway
and include ref prop(s) that are targetted at the soap:role of 
http://example.org/gateway which is the role of my Gateway. It knows only
to look for an element <gw:RouteTo> or something like that, of type 
xs:anyURI with a 
soap:MustUnderstand='true', and forwards the message to that URI, which 
could 
be an HTTP URI or possibly a URI for a WebSphereMQ queue from which the
service endpoint will dequeue messages to be processed (asynchronously, 
of course! It's the only way babe... :-) If the ref props/params are 
wrapped,
then somehow the soap:role and soap:mustUnderstand of the ref prop/param 
will need to be 
propogated to that wrapper element or else this use of ref props/params
doesn't work.

As for your point: "Nobody else does it.", I don't know what you mean by 
this.
Do you mean that there has, to date, been relatively little exploitation 
of
soap:role/actor? If so, I agree but I don't think that is an excuse to 
preclude its
use in the design of WS-Addressing.

As for the point: "It becomes impossible to write generic "process
addressing information" (e.g., WS management infrastructures) without
closely coupling the layers on a *per-operation* basis.". I don't buy 
that.
Just because the ref props/params can be anything, doesn't mean that there
won't be a set of well-defined Qnames that can be baked into some 
infrastructure
like WebSphere. The beauty of ws-addressing is that it allows for the 
minter
of the EPR to be free to implement as it chooses and it doesn't impact the
implementation choices of the recipient of that EPR. It just works.

As to the point: "It goes against the philosophy of composable headers.". 
Please
explain why it is you think that.

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

I've given a real-world use case above for leveraging the SOAP processing 
model.
I could certainly think of others.

> 
> 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 16:11:47 UTC