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

[Peter Dapkus <pdapkus@bea.com>]

Timestamp/Expires is an interesting case to consider:  Expires means
that the sender wishes to invalidate the security properties of the
header after a certain time.   In this case, if the receiver were to
ignore the timestamp and process the message after the expiry, they
would be incorrectly (and at their own risk) attributing those security
properties to the message.

Since we don't constrain the possible semantics of tokens and we have at
least one example of a token that negates the semantics of other tokens
(and signatures), it seems risky to allow for selective processing of
tokens in the header.

I think the point of view that mustUnderstand's meaning should be
relative to application policy has merit (have I understood this header
well enough to determine if it meets my policy?).  However, it seems
like if the policy requires that the message be granted some level of
authority based on the header processing, then the bar for
mustUnderstand should be significantly higher.

-PEte

On Thu, 2003-10-30 at 11:57, Christopher B Ferris wrote:
> Jerry,
> 
> Please see below.
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
> 
> Jerry Schwarz <jerry.schwarz@oracle.com> wrote on 10/30/2003 12:30:22 PM:
> 
> > 
> > Indeed, I would like further clarification of your intent in some 
> examples.
> > 
> > A. If I can't validate a signature because it uses a digest method that 
> I 
> > don't implement have I understood it?
> 
> Yes, but you failed Signature Validation.
> 
> > 
> > B. If I ignore a UsernameToken or SAML element because I'm implementing 
> a 
> > service that I allow anyone to use have I understood it.
> 
> In the case of UsernameToken, yes. In the case of SAML, if the WSS 
> implementation
> at the targetted SOAP node doesn't grok SAML, I think that the answer 
> should be
> no. How would it know that the unrecognized security token was for 
> authorization?
> 
> > 
> > C. If there is a BinarySecurityToken whose valueType I don't recognize, 
> but 
> > there is no reference to that BinarySecurityToken have I understood it?
> 
> Yes
> 
> > 
> > 
> > 
> > >Rich,
> > >
> > >I think that you DO need the language I proposed to define what it 
> means
> > >to
> > >"understand" a wsse:Security header block. Without it, there will be
> > >rampant confusion.
> > >I certainly concur with your suggestion that lines 162-3 be added to 
> Goals
> > >section.
> > >
> > >Cheers,
> > >
> > >Christopher Ferris
> > >STSM, Emerging e-business Industry Architecture
> > >email: chrisfer@us.ibm.com
> > >phone: +1 508 234 3624
> > >
> > >Rich Salz <rsalz@datapower.com> wrote on 10/30/2003 10:46:50 AM:
> > >
> > > > I took another look through the spec, and it seems the only place 
> that
> > > > really needs "fixing" to address soap 1.1 and (vs.?)soap 1.2 issues 
> is
> > > > sec 5.
> > > >
> > > > I propose the following
> > > >    Copy lines 162-163 (that say any SOAP version) into the Goals 
> section
> > >
> > > > after line 121.
> > > >
> > > >    Remove all mention of mustUnderstand; its semantics are defined 
> by
> > > > SOAP, and we can't constrain, subclass, or further modify it (see 
> lines
> > > > 455-457).
> > > >
> > > >    Genericize the wording in section 5 so that it is more clearly
> > > > soap-version-neutral.  It looks easy to do this; I can send a draft
> > > > later today if there's interest.
> > > >
> > > >    /r$
> > > >
> > > > --
> > > > Rich Salz, Chief Security Architect
> > > > DataPower Technology http://www.datapower.com
> > > > XS40 XML Security Gateway 
> http://www.datapower.com/products/xs40.html
> > > > XML Security Overview 
> http://www.datapower.com/xmldev/xmlsecurity.html
> > > >
> > >
> > >
> > >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.
-- 
Peter Dapkus <pdapkus@bea.com>