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?
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.
C. If there is a BinarySecurityToken whose valueType I don't recognize, but
there is no reference to that BinarySecurityToken have I understood it?
>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:
>phone: +1 508 234 3624
>
>Rich Salz <> 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.
