Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
