RE: [wss] SOAP MustUnderstand issue

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

> From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
> 
> > proposal: add mustUnderstand to toplevel wsse:Security elements, in
> addition to wsse:Security
> 
> Not seeing value in this as these sub-elements have the same 
> mustUnderstand
> semantics associated with the wsse:Security header by default

I agree. I like Thomas DiMartini's approach in his recent message (http://www.oasis-open.org/archives/wss/200311/msg00019.html), though I'm not sure we need to go into so much detail.

I think the correct way to interpret these mustUnderstand issues is to look at the specific sub-elements of <wsse:Security> and decide which ones are critical to the entire <wsse:Security>.

The reasonable default, in my mind, is "all sub-elements are critical unless the specification says otherwise". This covers the "notAfter" example; if a receiver can't process notAfter, it MUST behave as if it cannot process the entire <wsse:Security>.

At that point the SOAP mU processing kicks in: if the <wsse:Security> was marked mU, the receiver MUST generate a fault. Otherwise, the receiver MAY ignore it. This puts some burden on the sender; if the <wsse:Security> is critical to the processing of the entire SOAP message, then of course the sender should mark it mU.



I think we should open three new issues:

a) Add text near the top of the spec that says "all sub-elements are critical unless specified otherwise"

b) Go over the spec in detail, and identify exactly which sub-elements MAY ALWAYS be safely ignored without changing the semantics of the <wsse:Security>, and add text for each making that clear. (this may be an empty set)

c) Go over our extension points in detail, and identify any that require a nested mU flag. The semantics of this flag are: if the extension point is mU and you don't understand the extension, you MUST behave as if you don't understand the entire <wsse:Security>. If the extension is not mU, you MAY ignore it and process the rest (or you MAY toss the entire <wsse:Security> anyways). As with the SOAP-level mU flag, the burden is on the sender to correctly flag the extension elements. Also, extension specifications can require that their top-level elements be marked mU if they feel strongly about it.

c.1) if an extension point doesn't support a mU flag, rule a) applies and any extension at that point is critical (but see below)

c.2) As with b), we might decide that all extensions are critical, at which point we don't add any mU flags and everything goes back to rule a).



Remember that mU processing *DOES NOT* require *every* implementation to support *every* possible variation and extension; the only requirement is that they correctly generate a fault if said variation or extension is not supported. The WS-Security spec and WS-I profiles will guide implementers as to exactly which variations to handle in order to be a "conforming implementation" under the specific profile.

So, for the XMLDsig example, we can treat it as "always critical". If some hypothetical WS-I profile says that you need only support RSA signatures, a conforming (to that profile) implementation MUST process messages that contain <wsse:Security> headers that contain RSA sigs. If they receive a <wsse:Security> that contains a DSA signature, they MUST *either* process it correctly or generate a fault; generating the fault is conformant with the profile, since the (hypothetical) profile does not require DSA support.