RE: [ANN] W3C SOAP Digital Signature

 Hello. 8-)

 I cc'd the xmldsig mailing list so that the XML-Sig folks can also
respond to my first concern (the following paragraph, more in the
first cited message below).

 I understand now why you chose to do the SOAP digsig the way you did
it. Hopefully the final Recommendation of XML-Sig allows adding
arbitrary namespace-qualified attributes at least to the root elements
of the xml digital signatures. This would solve one of my concerns
with SOAP digsig.

 I disagree that you might want to add any unrelated information under
SOAP-SEC:Signature, I think if such information is necessary the
Signature element should be wrapped by an element like foo:routing or
foo:processOrder where routing or processing order can be specified. I
don't like even possible overloading SOAP-SEC:Signature with such
unrelated information.

 I also disagree with your trying to separate SOAP-ENV:id and
SOAP-SEC:id value spaces in application level, since every XML
compliant parser would complain on conflicts anyway.

 Either the type ID shouldn't be used or there is no need for
SOAP-SEC:id.

 Best regards
                            Jacek Kopecky
                               Idoox



On Thu, 8 Mar 2001, Satoshi Hada wrote:

 > 
 > Hello,
 > 
 > > Just a little curious remark: why didn't you just add the
 > > SOAP-ENV:actor and SOAP-ENV:mustUnderstand attributes to the
 > > ds:Signature element?
 > 
 > I don't think the XML-Signature schema allows to add new attributes to the
 > ds:Signature element.
 > http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd
 > 
 > > The SOAP-SEC namespace also introduces the SOAP-SEC:id attribute to
 > > help applications recognize attributes of type ID, that's good, but I
 > > think that such an attribute should be added to SOAP (and I hope it
 > > will be in XP) so that we don't end up having every extension to
 > > SOAP/XP carry their own ID attribute.
 > 
 > I agree with you.
 > Unfortunately, the current SOAP spec does not provide such an attribute.
 > That's why we defined the SOAP-SEC:id attribute in our Note.
 > That's my understanding.
 > 
 > Thanks,
 > 
 > Satoshi Hada
 > IBM Tokyo Research Laboratory
 > mailto:satoshih@jp.ibm.com
 > 
 > 
 > From: Jacek Kopecky <jacek@idoox.com> on 2001/03/08 18:09
 > 
 > Please respond to Jacek Kopecky <jacek@idoox.com>
 > 
 > To:   allenbr@microsoft.com, bfox@Exchange.Microsoft.com, Satoshi
 >       Hada/Japan/IBM@IBMJP, bal@microsoft.com, Hiroshi
 >       Maruyama/Japan/IBM@IBMJP
 > cc:
 > Subject:  RE: [ANN] W3C SOAP Digital Signature
 > 
 > 
 > 
 >  Hello. 8-)
 > 
 >  I'm responding to the announcement of "SOAP Security
 > Extensions: Digital Signature" W3C note.
 > 
 >  I posted this note earlier to SOAP@DISCUSS.DEVELOP.COM and to
 > xml-dev@lists.xml.org, but nobody responded, so I was advised to
 > target you, the authors themselves.
 > 
 >  It's great to see things are getting done, err, I mean specified. 8-)
 > 
 >  Just a little curious remark: why didn't you just add the
 > SOAP-ENV:actor and SOAP-ENV:mustUnderstand attributes to the
 > ds:Signature element?
 > 
 >  The SOAP-SEC namespace also introduces the SOAP-SEC:id attribute to
 > help applications recognize attributes of type ID, that's good, but I
 > think that such an attribute should be added to SOAP (and I hope it
 > will be in XP) so that we don't end up having every extension to
 > SOAP/XP carry their own ID attribute.
 > 
 >  There may be reasons behind this spec, but I can't easily see them
 > and I have to think that this spec is superfluous. As Henrik Frystyk
 > Nielsen said recently, he was very pleased with SOAP With Attachments
 > spec that didn't add any new stuff, only specified the composition of
 > existing specs.
 > 
 >  Best regards
 > 
 >                             Jacek Kopecky
 >                                Idoox
 > 
 > 
 > 

On Fri, 9 Mar 2001, Hiroshi Maruyama wrote:

 > 
 > Jacek,
 > Thanks for your comments.  I apologize that I overlooked your post on
 > axis-dev.  The reason why we did not use ds:Signature as a header entry is
 > two fold.  One is that we did not want to extend the Signature schema.
 > Although we know that XML Schema allows us to extend the Signature schema
 > and to define additional attributes to the Signature element, we were not
 > very sure if this mechanism will be used in a general way, or if it will be
 > included in the final XML Schema specification in the current form.  The
 > other reason was that we anticipated to add other information under
 > SOAP-SEC:Signature but not under ds:Signature.  For example, if multiple
 > header entries are specified, and a specific processing order is required,
 > it may be necessary to include such information under SOAP-SEC:Signature.
 > The current structure allows such future extensions.
 > 
 > The reason why we defined SOAP-SEC:id is similar.  We did not want to
 > disrupt the current SOAP implementations which treat SOAP-ENV:id as type
 > ID.  If you use SOAP-ENV:id in your encoding, there may be a danger of
 > potential collision of the ID values.  There is no way to solve this
 > problem provided that we need to conform to XML 1.0 Recommendation anyway,
 > but at least you can treat SOAP-ENV:id and SOAP-SEC:id separately in your
 > operational environment.  As for compositionality, I think you can see that
 > SOAP Signature and SOAP Attachment work together nicely.
 > 
 > Hiroshi
 > 
 > --
 > Hiroshi Maruyama
 > Manager, Internet Technology, Tokyo Research Laboratory
 > +81-46-215-4576
 > maruyama@jp.ibm.com
 > 
 > 
 >

Received on Wednesday, 21 March 2001 11:29:08 UTC