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

[Christopher B Ferris <chrisfer@us.ibm.com>]

David,

WS-Security is specifically designed to work with *any* version 
of SOAP, not just SOAP1.1. Starting at line 162 of WS-Security draft 17:

        "This specification is designed to work with the general SOAP 
message structure and message
        processing model, and should be applicable to any version of SOAP. 
The current SOAP 1.2
        namespace URI is used herein to provide detailed examples, but 
there is no intention to limit the
        applicability of this specification to a single version of SOAP."

Furthermore, WS-I BP1.0[1] clarifies SOAP1.1's somewhat ambiguous 
definiton of SOAP
mustUnderstand and the relationship with the SOAP process model in a 
manner
consistent with the SOAP1.2 Recommendation. Many if not most vendors have 
indicated
that they will soon, or already have, adopted the WS-I BP1.0 guidance in 
their product 
offerings.

Hence, even if it were the case that wss were only intended to be used 
normatively
with SOAP1.1, my proposed refinements to Irving's proposed changes would 
still
be quite relevant and consistent with current practice and interpretation 
of SOAP1.1.

[1] http://ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm#SOAPMEM

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

"David Orchard" <dorchard@bea.com> wrote on 10/29/2003 11:17:53 PM:

> Chris,
> 
> While all this is wunderbar stuff defined in soap 1.2, what if wss only
> normatively uses soap 1.1?  I would argue that using soap 1.2 would be
> advantageous to wss in this regard because soap 1.2 is a clearer model.
> However, I don't think that wss is moving to soap 1.2, despite the
> suggestions of groups like the xml protocol wg.  But then I guess 
there's
> some liaison history there.
> 
> Dave
> 
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Wednesday, October 29, 2003 6:37 PM
> > To: Christopher B Ferris
> > Cc: Reid, Irving; wss@lists.oasis-open.org
> > Subject: Re: [wss] ISSUE 190: text for SOAP MustUnderstand issue
> >
> >
> > <decloak/>
> > Oops... I was just re-reading my post and noticed that I neglected to
> > apply a final edit to change 'element' to 'header block' to
> > be consistent
> > with the other comment form the XMLP WG.
> >
> > >         Conforming implementations are said to "understand" a
> > >         <wsse:Security> element if they are able to process the
> > >         <wsse:Security> element and all of its descendant elements,
> > >         including any elements or attributes defined by profiles
> > >         or extensions.
> >
> > should have read:
> >
> > >         Conforming implementations are said to "understand" a
> > >         <wsse:Security> header block if they are able to
> > process the
> > >         <wsse:Security> header block and all of its
> > descendant elements,
> >
> > >         including any elements or attributes defined by profiles
> > >         or extensions.
> >
> > <cloak>
> >
> > Cheers,
> >
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > phone: +1 508 234 3624
> >
> > Christopher B Ferris/Waltham/IBM@IBMUS wrote on 10/29/2003
> > 09:27:57 PM:
> >
> > > <decloak/>
> > >
> > > SOAP1.1 may have been somewhat ambiguous as regards the
> > intent behind
> > > soap:mustUnderstand attribute, but SOAP1.2 is quite clear on the
> > > matter[1].
> > >         "A SOAP header block is said to be understood by a
> > SOAP node if
> > >         the software at that SOAP node has been written to
> > fully conform
> >
> > > to
> > >         and implement the semantics specified for the XML
> > expanded name
> > >         of the outer-most element information item of that header
> > block."
> > >
> > > IMO, it isn't a balance that must be struck. All it
> > requires is that
> > > the specification for the header block define the implied
> > semantics.
> > >
> > > The SOAP mustUnderstand attribute with a value of true does not
> > > mean "ignore at your own peril", it is an integral part of the
> > > SOAP protocol.
> > >
> > > Section 2.4 of the SOAP1.2 spec continues:
> > >
> > >         "Mandatory SOAP header blocks are presumed to
> > somehow modify the
> >
> > > semantics of other
> > >         SOAP header blocks or SOAP body elements.
> > Therefore, for every
> > > mandatory SOAP header
> > >         block targeted to a node, that node MUST either process the
> > header
> > > block or not process the
> > >         SOAP message at all, and instead generate a fault (see 2.6
> > > Processing SOAP Messages
> > >         and 5.4 SOAP Fault). Tagging SOAP header blocks as
> > mandatory
> > thus
> > > assures that such
> > >         modifications will not be silently (and, presumably,
> > erroneously)
> > > ignored by a SOAP node
> > >         to which the header block is targeted."
> > >
> > > The understanding of a SOAP header block labeled as
> > mandatory, by means
> > > of a SOAP mustUnderstand attribute, is not important only
> > to the SOAP
> > > node processing the message, it may have consequences for
> > the sender of
> > > that message as well. That's why the SOAP spec requires that a
> > > MustUnderstand fault be generated, so that both the sender
> > and receiver
> > > are protected from unintended consequences.
> > >
> > > One last point. It is not always possible to "return a fault".
> > > A SOAP fault is said to be "generated", which is distinct from
> > > returning a message containing that fault to the sender of the
> > > message that caused the fault to be generated. The important
> > > point is that the generation of a fault terminates all subsequent
> > > processing of the message beyond that which is necessary to
> > > handle the fault (e.g backing out uncommitted processing results
> > > and possibly creating a SOAP Fault message to transmit the
> > > fault to the sender).
> > >
> > > I would suggest the following refinement to your proposal:
> > >
> > >         Conforming implementations are said to "understand" a
> > >         <wsse:Security> element if they are able to process the
> > >         <wsse:Security> element and all of its descendant elements,
> > >         including any elements or attributes defined by profiles
> > >         or extensions.
> > >
> > >         If a <wsse:Security> header block is marked as mandatory by
> > >         means of a SOAP mustUnderstand attribute, and also contains
> > >         extension elements or attributes that are not recognized
> > >         by the SOAP node to which the <wsse:Security>
> > header block is
> > >         targetted, a conforming implementation MUST generate a
> > >         SOAP MustUnderstand fault.
> > >
> > > The tricky part becomes what to do with non-mandatory
> > <wsse:Security>
> > > header blocks when they contain unrecognized extension elements or
> > > attributes. There are two possibilities, ignore the unrecognized
> > > content but process the <wsse:Security> header block as if they were
> > > not present, or discontinue processing the <wsse:Security> header
> > > block entirely (e.g. ignore it altogether).
> > >
> > > SOAP header blocks that are not marked as mandatory with a SOAP
> > > mustUnderstand attribute carry the semantic that they MAY be safely
> > > ignored if not understood. From the SOAP1.2 specification section
> > > 2.6:
> > >
> > >         "4.     ... A SOAP node MAY also choose to process
> > non-mandatory
> >
> > > SOAP
> > >         header blocks targeted at it."
> > >
> > > Given this, and to be consistent with SOAP, I would suggest that
> > > the implementation be given the option of "ignoring unrecognized
> > > extensions at its peril" or ignoring the header block altogether.
> > >
> > > Suggested prose:
> > >
> > >         If a <wsse:Security> header block is not marked as mandatory
> > >         by means of a SOAP mustUnderstand attribute, and
> > also contains
> > >         extension elements or attributes that are not
> > recognized by the
> > >         SOAP node to which the <wsse:Security> header block is
> > targetted,
> > >         a conforming implementation MAY choose not to process the
> > >         <wsse:Security> header block.
> > >
> > > [1] http://www.w3.org/TR/soap12-part1/#muprocessing
> > >
> > > <cloak/>
> > >
> > > Cheers,
> > >
> > > Christopher Ferris
> > > STSM, Emerging e-business Industry Architecture
> > > email: chrisfer@us.ibm.com
> > > phone: +1 508 234 3624
> > >
> > > "Reid, Irving" <irving.reid@hp.com> wrote on 10/29/2003 06:44:31 PM:
> > >
> > > > This message relates to Issue 190, raised by the W3C XMLP working
> > group.
> > > >
> > > > In WSS-SOAPMessageSecurity-17-082703-merged.pdf, lines
> > 455-457, the
> > > draft reads:
> > > >
> > > > 455 The optional mustUnderstand SOAP attribute on Security header
> > (sic)
> > > simply means you are aware of
> > > > 456 the Web Services Security: SOAP Message Security
> > specification,
> > and
> > > there are no implied
> > > > 457 semantics.
> > > >
> > > >
> > > >
> > > > The background is that SOAP allows header elements to contain a
> > > "MustUnderstand" attribute, and if
> > > > MustUnderstand="1" (or "true") then the recipient of the
> > message MUST
> > > return a fault if it does
> > > > not understand said header element. Unfortunately, it's
> > not clear what
> >
> > > "understand" means in this context.
> > > >
> > > > We need to strike a balance between the extremes of:
> > > >
> > > >  o MustUnderstand just means "ignore at your own peril";
> > a recipient
> > can
> > > completely ignore the
> > > > content, but if that leads to problems they have no one
> > to blame but
> > > themselves. In the real
> > > > world, this is what it really comes down to. We don't
> > have a protocol
> > > for sending Big Foam
> > > > Cluebats across the network to people who ignore MustUnderstand
> > > elements.
> > > >
> > > >  o MustUnderstand means that a recipient must be able to
> > fully process
> >
> > > every optional sub-element
> > > > and possible extension of the MustUnderstand header
> > element. This is
> > > clearly too strict a constraint.
> > > >
> > > >
> > > > The problem is further complicated by the fact that
> > elements within
> > > wsse:Security may be
> > > > extensions defined in other specifications, so we can't clearly
> > specify
> > > where people need to look
> > > > to determine how to "understand" them.
> > > >
> > > >
> > > > I think the balance looks very much like the text we
> > already have in
> > the
> > > spec (WSS-
> > > > SOAPMessageSecurity-17-082703-merged.pdf) in the "Message
> > Security
> > > Model" section:
> > > >
> > > > 237 Where the specification requires that an element be
> > "processed" it
> >
> > > means that the element type
> > > > 238 MUST be recognized to the extent that an appropriate error is
> > > returned if the element is not
> > > > 239 supported..
> > > >
> > > > and also immediately above the text in question:
> > > >
> > > > 450 All compliant implementations MUST declare which
> > profiles they
> > > support and MUST be able to
> > > > 451 process a <wsse:Security> element including any
> > sub-elements which
> >
> > > may be defined by that
> > > > 452 profile.
> > > >
> > > >
> > > > Now, there is also an open issue (189) complaining about
> > this text,
> > > since we don't provide a way
> > > > for implementations to "declare" which profiles they support and
> > > therefore this MUST is
> > > > unimplementable/unenforceable.
> > > >
> > > > Perhaps we could replace lines 450-452 and 455-457 with
> > the following,
> >
> > > and move lines 453-454 to
> > > > the end of the section:
> > > >
> > > >
> > > > Conforming implementations MUST be able to process the
> > <wsse:Security>
> >
> > > element and all sub-
> > > > elements, including any elements defined by profiles or
> > extensions
> > > supported by that
> > > > implementation. If the <wsse:Security> header has a SOAP
> > > mustUnderstand="true" attribute and the
> > > > implementation cannot process all sub-element and extensions, the
> > > implementation MUST return an
> > > > appropriate SOAP fault. If the <wsse:Security> header
> > does not have a
> > > mustUnderstand="true"
> > > > attribute, the implementation SHOULD return a fault if it cannot
> > process
> > > all sub-elements and extensions.
> > > >
> > > >
> > > > (I struggled a bit with the semantics of this - one
> > option would be to
> >
> > > try and effectively
> > > > override mustUnderstand by saying that conforming
> > implementations MUST
> >
> > > process or fault,
> > > > independent of mustUnderstand; I changed my mind on that
> > because SOAP
> > > listeners without Soap
> > > > Message Security implementations can legally ignore
> > <wsse:Security
> > > mustUnderstand="false">
> > > > headers, so why can't conforming implementations?)
> > > >
> > > >
> > > > I think this says what we mean, modulo the above and the
> > fact that the
> >
> > > current specification isn't
> > > > always clear about what it means to "process" the contents of a
> > > <wsse:Security> header. Speak up
> > > > if you think I'm off track with the semantics, or if you
> > have better
> > > wording.
> > > >
> > > >  - irving -
> > >
> > > To unsubscribe from this mailing list (and be removed from
> > the roster of
> > the OASIS TC), go to
> > >
> > http://www.oasis-open.org/apps/org/workgroup/wss/members/leave
> _workgroup.php.
> >
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
the
> OASIS TC), go to
> 
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
> .
> 
>