W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

Re: Mr. Vincent's position paper

From: John Boyer <jboyer@uwi.com>
Date: Tue, 13 Apr 1999 11:06:18 -0700
Message-ID: <002e01be85d8$558a7500$9ccbf4cc@kuratowski.uwi.bc.ca>
To: "Winchel 'Todd' Vincent, III" <winchel@mindspring.com>
Cc: "Dsig group" <w3c-xml-sig-ws@w3.org>
Hi Todd,
    The point of a potential W3C XML-Digital Signature working group, in my
view, is not to adopt one particular technology or specification but to
synthesize the best ideas from many technologies and/or specifications in
order to produce a non-proprietary standard.  To date, I have read and
studied Himes' XCI, Brown's XMLDSIG, and Davidson's Digital Receipt (in this
order).  I like a lot of what I see in the Brown draft, but I am not yet
ready to adopt any draft -- again, this is the point of a potential

    I agree.  My own paper talks about how to take the XFDL ideas and use
them to create a better signed XML spec.  Though not all XML apps do things
the same way as XFDL, the underlying ideas we had to come up with are still
applicable.  Most of those ideas surround precisely the types of legal
opinions you expressed.

    I have not had time to thoroughly read the XFDL spec; I have only
skimmed it.  Noting that I have not detailed the draft (i.e, correct me if I
am mischaracterizing XFDL . . .), while I think, as a legal matter, that
style sheets should be signed and delivered with content, I like and support
the idea of separating, logically and/or physically, structural and
semantic/data elements and formatting (stylesheets), which XFDL does not
appear to do (??), and I absolutely do _not_ support pages in electronic
documents, which XFDL appears to do (??).

    Whether or not you agree with having them put together does not change
whether or not you agree with the fact that they have to be signed together.
As I pointed out in my paper, it seems acceptable to me to add the data
layer and the stylesheet together to obtain a message to be signed.

    As for whether you agree with pages, the fact that XFDL can support
multiple pages doesn't mean that you have to recommend that multiple pages
be available in applications.  However, XFDL forms are meant to be like
paper, and I don't think the legal community has a problem with multipage
paper forms being signed on the last page.  Further, over half our our
deployments require multipage forms because organizations simply won't
tolerate having e-forms that aren't like their paper forms-- not without a
whole pack of attorneys telling them it's OK to change everything!  For what
it's worth, XFDL signs the presentation logic statements, so logic that
changes the page when the user isn't looking also gets signed, and a
malicious e-form could thereby be discovered.

    As for whether XFDL can support separation of data and presentation, it
is actually a common misconception that XFDL cannot support separation of
data and presentation.  The problem is that we've had to work so hard to
convince people that data and presentation need to be together, esp. for
signing, that this is often what is heard most often, so our marketing
efforts are partly to blame!  However, 1 unit of creativity outweighs 100
units of belief.  Because XFDL has a computation system built in, it can do
virtually anything (I've even done parallel processing simulations in XFDL
forms).  Ironically, the method also uses the very idea you don't like:
multiple pages.

    A form can use a page to carry the data layer, then use multiple other
pages to show various views to different people. The selection of view can
even be made at run-time.  Computes are used to carry the data to all views,
and only the page (or pages) with the right view (or views) is actually
shown to the user.  During signing, signature filters are used to
incorporate the data layer into whatever page is actually being signed, so
we still can bind the data and presentation into one signature.  We can even
bind all style sheets to a single signature if desired so that all valid
views are frozen.

    Basically, it should be easy to do easy things, and the most often used
features should be the defaults, and this is why XFDL puts data and
presentation together-- for e-commerce, that's what people need to do most
of the time anyway.

    In sum, I think it is premature to tout one draft over another.  I look
forward to meeting all of you in Boston and to working with you on these
important issues in the future.

    At this workshop, I'm hoping that positions like ours and yours will
help get the signed XML group to include features like wrapping in
stylesheets and unparsed entities as well as offering signature filters-.


    -----Original Message-----
    From: John Boyer <jboyer@uwi.com>
    To: Dsig group <w3c-xml-sig-ws@w3.org>
    Cc: Winchel 'Todd' Vincent, III <winchel@mindspring.com>
    Date: Monday, April 12, 1999 2:41 PM
    Subject: Re: Mr. Vincent's position paper

        Hello all,

        Naturally, UWI.Com is in agreement with the views expressed by Mr.
Vincent since these views were the ones that guided the creation of UFDL,
the non-XML predecessor of XFDL that existed before there was an XML.
Joseph, do you think it is possible to include Mr. Vincent's position paper
on the signed XML web site?

        It should be noted that Mr. Vincent's position has substantial
backing within the legal community.  As far as I know, Cohasset is the
leading legal authority on the admissibility of documents into a court of
law.  You can read a paper they've put together on this issue using
http://www.cohasset.com/comm_forms.html.  For those who want to remain as
pure as possible, be forewarned that we like this article because it has a
nice blurb at the end which talks about XFDL being an enabling technology
for legal filings, most of the paper is not really about UWI.Com so much as
it is about the types of issues that Mr. Vincent raises and that should be
addressed by a signed XML standard.

        John Boyer
        Software Development Manager
        UWI.Com -- The Internet Forms Company
Received on Tuesday, 13 April 1999 14:02:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:59 UTC