XML for forms

[Gavin McKenzie]

Ooops...pardon me, something unfortunate has just been brought to my
attention.

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

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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)