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

[Christopher B Ferris <chrisfer@us.ibm.com>]

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.
>