OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] SOAP MustUnderstand issue


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:rsalz@datapower.com]
> Sent: Wednesday, November 05, 2003 9:09 PM
> To: Hirsch Frederick (NMP-MSW/Boston)
> Cc: wss@lists.oasis-open.org
> 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
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]