RE: Composibility problems with refps

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Monday, November 22, 2004 4:07 PM
> To: David Orchard
> Cc: public-ws-addressing@w3.org
> Subject: RE: Composibility problems with refps
> 
> David,
> 
> That's a pretty far fetched example:-) Why would I choose to
"understand"
> <allYourAssetsAreBelongToUs/>?

I wouldn't want to preclude a bank from having an interface that deals
with account transfers.  SOAP gives a powerful extensibility model for
interfaces, and an account transfer is a possible example of a header
block.  Oh, is this the "make the example sound as ridiculous and
farfetched and silly as possible" argument style? 
> 
> And how is the example you give an example of duplicate user headers
> (whatever they are)? 

It's a duplicate user header because the service offers the
"SendAssetsToGrandCayman" interface as a soap header that clients can
invoke, which is also accidentally or intentionally invoked by the EPR.

> And what makes
> you say that duplicates would necessarily be a security hole? 

Because the hacker gets the minter of the EPR to put the "sendAssets"
header in the EPR.  According to the WS-A processing model, they can't
tell whether it is a legit header block or not, they just echo away.

> And how does
> a wrapper mitigate against any of this?

Because the EPR could contain the "sendAssetsToGrandCayman" RefP, but it
wouldn't be sent as a soap header block, and thus the functionality
wouldn't be invoked.

> 
> By your account, we shouldn't have a SOAP processing model at all
because
> some unscrupulous client
> could stick in a <sendMeAllYourAssets soap:mustUnderstand='true'/>
header
> block.

No, that's not the same, because the two sides agree upon the interface
and the client is allowed to send the "sendassets" header block.  I'm
just pointing out a case where there's a valid interface, the EPR minter
can get hacked, and the normal model of EPRs - even with securing the
EPR - doesn't prevent the wrong thing from happening.  

People can easily say "well don't get hacked internally" but that's
harder said than done.

Cheers,
Dave

<snip/>

Received on Tuesday, 23 November 2004 00:26:08 UTC