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

["David Orchard" <dorchard@bea.com>]

I agree that the use of MustUnderstand is clear in SOAP 1.2 (one reason I
like soap 1.2 a lot) and I agree with most of what you said in that area.  I
specifically agree with the wording around mandatory WSS header blocks with
extensions and optional WSS header blocks with extensions.  In a related
matter, I have tried and failed to convince some people that WSS should
provide a mechanism for indicating the mandatory nature of extensions, ala
soap:mustUnderstand, but that in no way takes away from your suggested
wording.

The point of this message is about the use of MustUnderstand in WSS, and
expands into actor/role.  To get the "right" behaviour for MustUnderstand
and Role in WSS, a WSS vendor must:

a) use soap 1.1 + soap 1.2 role attribute - soap 1.1 actor attribute + WS-I
BP 1.0 + the forthcoming WS-I BSP 1.0 (which my guess would also reference
WS-I BP 1.0 ).  Which doesn't seem like it's *really* soap 1.1 if it's
mixing in soap12 qnames and requiring soap11 qnames can't exist.  Maybe I'm
the only one that finds it strange that some software can be asserted to be
conformant when it doesn't support the required elements of a spec.

b) use soap 1.2 + the forthcoming WS-I BSP 1.0 + the as yet unpublished WS-I
BP x.y for soap 1.2.

I don't quite see how WS-Security is specifically designed to work with
*any* version of soap wrt mustUnderstand if it doesn't define the mappings
between the WS-Security use of constructs in soap 1.1 and the *roughly*
equivalent constructs in 1.2.  In this case, actor/role and mustUnderstand.
Seems like it's specifically designed to ignore *any* version of soap and
require something else define how to work with *any* particular version of
soap.  Maybe a profile of WS-Security is designed for that, but not
WS-Security - at least in this manner.  As an example, I don't see
WS-Security saying something like "WS-I BP 1.0 rules for soap:mustUnderstand
must be followed when using SOAP 1.1 to ensure that consistent treatment of
soap:mustUnderstand is followed across *any* version of soap".  But I'm sure
there will be a profile, like WS-I BSP 1.0, which will say "When using
WS-Security and SOAP 1.1 follow WS-I BP 1.0 + potentially some tbd
constraints".  That doesn't say that WSS works with *any* version, what
works with *any* version is WSS + some other stuff.

The point of this message is not to disagree with the use of MustUnderstand
of extensions as you've suggested, but to point out that the "inheriting" of
soap 1.2 role and mustUnderstand into the soap-neutral WS-Security via
profiles is pretty cumbersome and unclear at this point in time, at least to
me.  WSS could have done something to make it clearer if they had chosen to
do so.

Cheers,
Dave

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Wednesday, October 29, 2003 9:06 PM
> To: wss@lists.oasis-open.org
> Subject: RE: [wss] ISSUE 190: text for SOAP MustUnderstand issue
>
>
> 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
> .
>
>


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
.