RE: [wss] ISSUE 190: text for SOAP MustUnderstand issue

["Reid, Irving" <irving.reid@hp.com>]

Let me start by saying I mostly agree with you; I think I'll write up two versions of the text and request a vote...

> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
> 
> I would like to clarify point A and disagree with point B. 
> 
> Disagreement - security policy should not define fault 
> generation associated with mustUnderstand.
> Security policy is between both sender and receiver, may 
> involve other security layers (e.g. SSL/TLS) 
> and may involve other policy mechanisms defined elsewhere. (A 
> fault might be generated regardless of mustUnderstand)

But equally, a fault might _not_ be generated. This gives receivers a way to defend themselves against uncooperative senders. If the receiver truly doesn't care, no amount of mU from the sender should force the receiver to do any more work than it has to.

> Alternative interpretation of mustUnderstand:
> 
> mustUnderstand true for a SOAP Message Security header block means 
> 
> 1) the receiver must return a SOAP fault if it has not 
> implemented the SOAP Message Security 
> specification corresponding to the namespace. Implementation 
> means ability to interpret the schema as well as follow the 
> required processing rules specified in SOAP Message Security.

This is pretty well the rule from the SOAP 1.2 spec.

> 2) the receiver must return a fault if unable to interpret or 
> process security tokens contained in the SOAP Message 
> Security header block according to the corresponding SOAP 
> Message Security token profiles.

The current spec does not provide a way for the sender to mark an extension as non-critical. With this rule, an uncooperative sender can put a private extension in every wsse:Security they generate, and if they have a large enough market share everyone else will be forced to figure out how to process it.

> I do not understand why headers targeted at a role should be 
> ignored when mustUnderstand is true. Why are they used if not 
> meaningful for that role? (If the sender intends flexibility, 
> why not set mustUnderstand to false?)
> 
> Can someone reiterate why #2 is a problem?

I'm operating from the assumption that the receiver is providing some service. As "owner" of the service, the receiver _must_ have final say over what policy is applied. This includes the option of ignoring incoming security information, especially when that security information might be both irrelevant and quite expensive to process.

 - irving -