RE: ISSUE 8 : "Clarity and Safety"

Glen,

SOAP endpoints process headers ( and the body if they're the ultimate
receiver ). They process these headers by looking at the QName and
deciding whether they have software to process that QName.

SOAP endpoints expect a given set of headers to be in messages they
receive. In some cases this set will be empty. In other cases, it will
include headers related to security, reliability etc. In still other
cases it will include headers defined by WS-Addressing, possibly
including headers inserted because an EPR contained
ReferenceProperties/Parameters. However the sender decided to put a
given set of headers in a message, the fact remains that they are
headers the endpoint expects to be present. Whether they are Reference
Properties/Parameters is immaterial. 

SOAP headers can, in general, be processed in any order. Certain
implementations may impose an order of processing based on the QNames of
the headers, others may decide to process headers in document order.
Other implementations may decide to process headers in parallel, perhaps
to take advantage of SMP.

SOAP headers can be targetted at different roles, marked as mandatory
and (in the SOAP 1.2 case) marked for relaying if targetted at 'next'.

Regarding EPRs, they are issued by some party, perhaps as part of some
protocol exchange, perhaps in a WSDL document or something like it. Each
EPR specifies the value of the wsa:To header and (optionally) the
various Reference Properties/Parameters that are needed to address a
message to a particular endpoint. The EPR issuer may choose to mark
certain Reference Properties/Parameters for processing by a particular
role/actor or mark certain headers for mandatory processing. 

Thus an EPR specifies a (sub)set of QNames that a SOAP endpoint expects.
The endpoint might also expect other headers not related to addressing.
The need for these headers is communicated somehow to the sender (
perhaps via some form of policy ).

The sender constructs a message according to the contract it has with
the endpoint, including the various headers. In all cases, the sender is
saying 'please process these QNames'. In the case of wsa:To and
Reference Properties/Parameters, the sender is saying 'please process
these QNames so that my message gets to the right endpoint'. These
headers are just part of the contract with that endpoint, just like
security, reliability etc. 

Regarding security of EPRs, if the user of an EPR doesn't trust the
issuer of that EPR, then that user shouldn't send messages to the
endpoint the EPR identifies. This applies whether or not the EPR
contains any Reference Properties and/or Parameters. EPRs should be
integrity protected in transit.

If the user of an EPR determines that it doesn't like one or more of the
Reference Properties/Parameters present in that EPR, that user shouldn't
send message to the endpoint the EPR identifies.

If the issuer of an EPR is stupid enough (or broken enough) to issue
EPRs with Reference Properties/Parameters that cause problems for the
endpoint then that is something the issuer and the endpoint need to sort
out for themselves (often they will be co-located). Endpoints should be
robust in the face of arbitrary headers appearing in SOAP messages
anyway, whether they appear as a result of EPR processing or some other
reason.

The only party a 'bad' EPR can cause problems for is the recipient of
the message, not the sender. The worst that will happen to the sender is
that it will send a bogus message and either get nothing back or get a
fault back.

I don't see any benefit to relegating Reference Properties/Parameters to
second-class status inside wsa:To. I think that doing so will
unnecessarily complicate and restrict the construction of SOAP
processing pipelines and result in re-capitulation of the SOAP
processing model inside that header. 

More stuff inline below, but it's essentially restating the above...

Gudge


> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Glen Daniels
> Sent: 09 November 2004 06:46
> To: public-ws-addressing@w3.org
> Subject: ISSUE 8 : "Clarity and Safety"
> 
> 
> 
> Here's a start at issue 8, and a clarification of some stuff I wrote
> about issue 11.  Upon another read of [1], I think that was a pretty
> good summary, actually.  However, I'll endeavor to go a little further
> here.  I'll split these out into separate emails for easier 
> discussion.
> This one is about "Clarity and Safety".
> 
> Let's consider a refP as follows (namespace mappings are assumed in
> examples):
> 
>   <epr>
>    <refps>
>     <wsse:Security>
>       ...
>     </wsse:Security>
>    </refps>
>   </epr>
> 
> This would result in a static wsse:Security header appearing in a
> message to this endpoint, as a result of following the rules 
> for refp's
> as they stand.  This header might be a) wrong with respect to the rest
> of the message, or b) a duplicate.  

Agreed. And such a message would presumably be rejected at the receiver.

> Another example:
> 
>   <epr>
>    <refps>
>     <admin:ShutDown/>
>    </refps>
>   </epr>
> 
> The thrust of thes particular cases involves an error (either
> happenstance or malicious) on the part of someone supplying 
> an EPR, and
> of course we cannot protect against all such situations.  However, the
> current design forces such errors (bad refps) to happen at the SOAP
> infrastructure layer, as opposed to inside the WSA module of an
> implementation.  This has a few implications.
> 
> First, a layering problem - if I am to protect against such errors, my
> infrastructure should probably scan all my refp's to make sure they
> don't step on the toes of some "real" SOAP extension.  One might argue
> that this isn't necessary, and that you should just "trust 
> the source of
> the EPR", but I disagree - one could make the same argument against
> checking for nulls/bad data in methods on a C# or Java object.  If you
> provide a way for data (EPRs) that affects your SOAP processor to be
> supplied by the outside world, you open yourself up to errors in that
> data affecting your SOAP node in potentially unclear ways - especially
> since refp's lose their "refp-ness" once they get "header-ized". (this
> is the "safety" part)

But the problem here doesn't occur at the sender, it only has potential
to happen at the receiver. So I guess I don't see the problem. If I, as
the issuer of an EPR, give out an EPR that causes me problems, isn't
that my lookout? I would consider it my job to protect against such
errors (rather than the senders job). Indeed, I'd want to protect
against such problems anyway, even for headers which were not RefProps
just in case a black hat was able to insert a header into the message.

> 
> Second, if some node (either an intermediary who has no 
> knowledge of the
> EPR in question or maybe even the endpoint) has a problem with one of
> these refps, it becomes harder to debug what's going on when 
> you account
> for the fact that any of the headers might have been inserted due to
> processing an EPR instead of due to actually following some 
> extension's
> contract.  

I'm not sure it really matters does it? The receiver has a set of QNames
she expects to appear as headers in the message, some of those MUST be
there, some of them are optional. At the end of the day, whether they
are there due to being refprops/params in an EPR or because of some
other part of the contract doesn't seem to matter to me.

> In many (most?) modern SOAP processing systems, there are
> going to be code modules which are responsible for processing
> extensions.  In general each of these modules is going to be directly
> responsible for a small subset of headers.  Having a WSA module be
> required to insert an arbitrary number of arbitrary headers 
> may make it
> much less clear where things are coming from, and which code 
> to examine
> when there is a problem. (this is the "clarity" part)

If there's a problem processing a header with a given QName, look at the
code responsible for processing that QName. If there are multiple
occurences of that code, look at all of them. How is this different from
figuring out which piece of code was supposed to process the
wsse:Security header?

> 
> I would put forth that the SOAP processing model actually has 
> two sides
> to it.  The first is the one we're all familiar with, i.e. what nodes
> must do when processing a message containing headers.  The other side,
> though, is that the *originator* of a given message actually inserted
> some SOAP headers, and therefore by virtue of that fact, they 
> agreed to
> the semantics of those headers.  

I don't think I agree with this. As I noted above, as a sender of a SOAP
message, I'm saying to a receiver, please process these QNames. In the
case of mandatory headers I'm saying to the receiver, you must process
these QNames or fault. In many cases, I'll have put headers in a message
just because the endpoint requires that they be there. Whether that
header's a simple QName/value pair or a security header with tokens,
signatures and encrypted data, I'm putting it in because something told
me that was what I had to do to talk to this endpoint.

> If WSA allows, or rather 
> forces, us to
> insert arbitrary headers which are explicitly opaque, we change that
> part of the SOAP contract in what I believe are at least 
> confusing, and
> possibly dangerous, ways.

I don't agree that it's confusing or dangerous. You put the
refprop/param headers in because they're part of the contract with the
endpoint. Just like any other header. 

I do agree that they are opaque ( or as opaque as the EPR issuer wants
them to be ). I don't see this as a problem.

> 
> Proposal:
> 
> I would like to have the group consider the ramifications of 
> sending the
> refp's inside another element, whether that be <wsa:To> or a separate
> <wsa:RefPs> header.  In either case, the same exact 
> information would be
> available to the SOAP node (I am intentionally not saying "the
> application" to avoid implementation-specific layering assumptions) as
> in the case where each refp was a separate header, except 
> there would be
> a well defined semantic that <wsa:RefPs> (or whatever name) contains a
> bag of data that is meant to go along with each message sent to this
> endpoint.  This would solve the problems I mention above (and others -
> see other threads), and as far as I can tell would not lose 
> us anything.

As far as I'm concerned it would remove a significant benefit of
WS-Addressing, namely the ability to process pieces of address
information as SOAP headers. I've said before that I don't see why
software that is designed to process SOAP headers should have to look
inside another header in order to pull out the relevant information. I
know you've posited that if WS-Addressing occurs 'first' then it could
easily make that information available to subsequent nodes in the
pipeline. But SOAP headers are not ordered, and I might not want to put
the WS-Addressing processing at the front of the pipeline ( relative to
the processing of refprops/params ). And if I decided to process the
headers in parallel, because I'm on an SMP machine, I *really* don't
know whether WS-Addressing processing will have kicked in early enough
for the information to be available at the right point. 

Conversely, if these things are SOAP headers, unordered, seperately
processable SOAP headers, I can implement my pipeline pretty much anyway
I like.

Gudge

> 
> Thanks,
> --Glen
> 
> [1]
> http://lists.w3.org/Archives/Public/public-ws-addressing/2004N
> ov/0008.ht
> ml
> 
>

Received on Monday, 15 November 2004 16:50:52 UTC