RE: Issue 7 - processing model for SOAP headers

Marc,

I think this is desperataly needed. I've seen router implementations that
change the value of wsa:To in transit. The WSA spec needs to say whether or
not that is allowed.

This is also relevant to the discussion of issue 9 regarding multiple
instances of headers. I mentioned in a separate message that there might be
security issues there. With vague header processing rules, one can imagine
all sorts of dastardly deeds, including inserting an extra wsa:Action header
before the real one in order to get an intermediary (who might not be
validating signatures on headers because they were targeted at the ultimate
receiver) to route the message somewhere it shouldn't. If the intermediary
removed that header during processing, there might be no trace that it had
been tricked.

Thanks,
Tim-

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Marc Hadley
> Sent: Wednesday, January 12, 2005 4:00 PM
> To: public-ws-addressing@w3.org
> Subject: Issue 7 - processing model for SOAP headers
> 
> 
> Issue 7 concerns the processing model (or lack of) for the 
> SOAP headers defined by WS-Addressing. WS-A defines the 
> following message addressing properties, each of which is 
> bound to an individual SOAP header:
> 
> wsa:MessageID
> wsa:RelatesTo
> wsa:ReplyTo
> wsa:From
> wsa:FaultTo
> wsa:To
> wsa:Action
> 
> All of the above headers (when specified by the sender) seem 
> to be required at the destination endpoint but might also be 
> useful to intermediaries in the SOAP message path, e.g. 
> wsa:To, wsa:Action, wsa:RelatesTo might be used for message routing.
> 
> SOAP defines a processing model[1] for message receivers 
> (intermediaries and the ultimate recipient) that defines how 
> a message is processed, this includes:
> 
> - what SOAP headers are processed at a receiver (targeting)
> - understanding of headers and description of mustUnderstand 
> processing
> - relaying of SOAP messages including removal of processed headers.
> 
> The specification of a particular SOAP header can define 
> additional semantics that apply to that header, e.g. the 
> specification of a particular header might require that it be 
> reinserted if processed by a SOAP intermediary such that it 
> survives intermediary processing and remains in the message 
> until it reaches the ultimate recipient.
> 
> Currently the SOAP Binding for WS-A doesn't discuss targeting 
> or replaying of WS-A defined headers in any normative way. 
> The examples in the specification do not include a role/actor 
> attribute, this is equivalent to targeting the header to the 
> ultimate recipient but if we decide to specify this 
> normatively then we preclude processing of WS-A headers by a 
> forwarding intermediary (note that SOAP active intermediaries 
> provide a way round this). My preference would be to specify 
> that all of the WS-A header blocks are reinserted if 
> processed by an intermediary and recommend that they carry a 
> relay="true" and role=".../next" attribute. This formulation 
> woul dallow each header to be processed by a forwarding 
> intermediary whilst ensuring that all WS-A headers also 
> survive to the ultimate recipient.
> 
> Beyond the simple reinsert processing model proposed above I 
> also think it would be worth adding sections to the SOAP 
> binding specification containing a processing model for each 
> header. This may be as simple as referring back to the 
> relevant section in the core document or (in some
> cases) specifying that there is no processing model and that 
> the header is purely informational.
> 
> Thoughts, comments ?
> 
> Marc.
> 
> [1] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#msgexchngmdl
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
> 
>

Received on Thursday, 13 January 2005 14:28:35 UTC