XML for forms
gmckenzi at JetForm.com
Mon Jul 5 22:26:49 BST 1999
Ooops...pardon me, something unfortunate has just been brought to my
> Tim Bray wrote:
> > That is why XFDL for example insists on including
> > in the form document all the presentational information and so on -
> > the claim is that you have to digitally sign not only the answers to
> > the questions but the questions and how they were presented to the
> > user, in order to achieve the goal of non-repudiation. (Mind you,
> > this should be done using CSS or flow objects rather than with
> > custom tags as XFDL did).
Gavin McKenzie wrote:
> Sign yes. Include no. It requires that content (data) and
My comments might lead somebody to believe that I am attempting to clarify
the position of XFDL -- if it isn't already obvious from the domain of my
email address, I am doing no such thing -- obviously based on my previous
emails I have a professional bias on this topic towards the body of work
known as XFA. I am speaking for my own opinions and the XFA specifications.
When I said, "It requires that..." I was not speaking of XFDL, which I
cannot speak for. Rather, I was generally stating that "Non-repudiation
(often) requires that the context and presentation be signed...".
People (customers) have a wide range of requirements that are not best
served by a single simple solution. Persisting presentation and data
together isn't required or necessary.
> the context (presentation) be signed, but fusing the data
> content and the presentation together isn't necessary; and it
> is very costly on a number of levels.
> Simply including a fingerprint of the presentation as part of the data
> signing is sufficient. Nothing more is achieved by choosing
> to store or
> incorporate the presentation with the data or vice-versa.
> > As a legal illiterate, I'm not sure what the real state of play is
> > here - but I still think that a list of context-free name/value
> > pairs is a pretty shaky basis for a legally binding transaction. -T.
> True. Hence why incorporating the presentation as a
> participant in the
> signature is so important.
> But also recognize that not all forms require such a heavy
> hand of security.
> Many forms are used in (closed) environments with a higher
> level of trust.
> Other forms are simply 'worksheets' that facilitate the data
> entry of data
> which is completely self-describing and can be signed on its own.
> Some processes do not need to sacrifice the particular aspect
> of flexibility
> that is lost when signing data in concert with presentation -- the
> flexibility lost is that the data won't verify in another
> presentation...this of course is the primary feature of including the
> presentation in the signature, but in some usage contexts
> this feature is
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev