Rich
to repeat what I think you said :)
proposal: add mustUnderstand to toplevel wsse:Security elements, in addition to wsse:Security
e.g.
wsse:UsernameToken
wsse:BinarySecurityToken
wsse:SecurityTokenReference
wsu:Timestamp
ds:Signature,ds:KeyInfo, xenc:EncryptedKey have mustUnderstand semantics associated with the wsse:Security header
since we cannot add mustUnderstand to them.
Processing rule:
If wsse:Security mustUnderstand is true then ds: and xenc: must be understood as well as top level ws-security
elements that have mustUnderstand true.
Seems to make sense to make mustUnderstand have finer granularity.
thanks
regards, Frederick
Frederick Hirsch
Nokia Mobile Phones
> -----Original Message-----
> From: ext Rich Salz [mailto:]
> Sent: Wednesday, November 05, 2003 9:09 PM
> To: Hirsch Frederick (NMP-MSW/Boston)
> Cc:
> Subject: Re: [wss] SOAP MustUnderstand issue
>
>
> > It seems that the relationship of interoperability and
> > adequate/appropriate security processing is of concern here. If
> > mustUnderstand is false, does that mean security is lost?
> I'd say no,
> > since it is the relying party's obligation regardless to make sure
> > policy is met - i.e. it shouldn't be driven by mustUnderstand.
>
> Chris Ferris and I have been talking about this. Here's an example
> we came up with. Suppose I add a "notAfter" attribute to a WSS
> identity token that specifies an expiration period. Clearly the
> recipient ignores that at their own peril, and without the
> sender-provided
> advice they might ignore it.
>
> I still believe the application (or its policy configuration
> that drives
> the WSS library layer) determines when mustUnderstand should be
> set. But I'm beginning to think that the WSS layer (as driven by
> policy) knows best when the semantics of *its* elements are being
> changed. This would imply that we need a "wsse:mustUnderstand"
> attribute on all our toplevel elements.
> /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
>
>
