Hima,
Himagiri Mukkamala wrote:
>
> I'd agree with Chris.
<snip/>
> What's also missing is the canonicalization method!
> I used a hardcoded canonicalization method for
> the POC.
That too is prescribed in the ebXML MS spec, but
you are correct that to be truely flexible and valuable
in other domains, we should provide for this.
>
> About using a "Reference" DSIG element in the CPA,
> that would have to omit the "URI" element too
> cause that's something runtime would create
> for the business document which packaging it.
This is true, which suggests that a specific binding
on a per-message basis may be what is needed, not just
a per-channel basis as currently provided.
>
> -hima
>
> christopher ferris wrote:
>
> > Marty,
> >
> > My take on this is that this element could take the form
> > of a Signature "template" which effectively provided
> > all of the requisite binding information including
> > reference URI(s) with only the Digest and actual
> > signature omitted. The IBM Alphaworks XSS4J DSig
> > implementation provides for use of a template
> > to drive the signing behavior, which is a nice
> > feature of the tool (IMHO).
> >
> > I have successfully used the SignatureAlgorithm, HashFunction
> > and Protocol. I haven't used Certificate yet mostly
> > for implementation reasons.
> >
> > Presently, the ebXML MS specification prescribes the
> > Transform algorithm(s) that MUST be used, as well as
> > the Reference URIs necessary for the header, but not the
> > payload item(s) since that would depend upon the Content-ID
> > or Content-Location URI which might vary from message to
> > message even of the same type. Thus, presently this is
> > not an issue. However, to make this more flexible, it might
> > be useful to have the ability to fully describe the Transform
> > as well.
> >
> > Another approach would be to leverage the Reference element
> > from the DSig specification, omitting the DigestValue (like the
> > Signature "template" but without describing the full Signature.
> >
> > Cheers,
> >
> > Chris
> >
> > Martin W Sachs wrote:
> > >
> > > The NonRepudiation element specifies signing of the messages using XMLDSIG.
> > > Its child elements are Protocol, HashFunction, SignatureAlgorithm, and
> > > Certificate. I have recently been asked whether NonRepudiation also has to
> > > have a Transform(s) element. If XMLDSIG provides a choice of Transform,
> > > then the choice should probably be expressed under NonRepudiation.
> > > Alternatively, we might prescribe a particular answer in the text and not
> > > need an element.
> > >
> > > If something about transforms is needed in the specification, let's put it
> > > on the list for the maintenance release.
> > >
> > > Regards,
> > > Marty
> > >
> > > *************************************************************************************
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287; IBM tie line 863-7287
> > > Notes address: Martin W Sachs/Watson/IBM
> > > Internet address: mwsachs @ us.ibm.com
> > > *************************************************************************************
