xml-dev - RE: XML for forms

[Gavin McKenzie <gmckenzi@JetForm.com>]

Barclay,

Given this is the first time we've communicated, I must say that I'm not
impressed with the level of communication you've chosen.

See my comments below.

> -----Original Message-----
> From: Barclay Blair [mailto:barclay@uwi.com]
> Sent: Tuesday, July 13, 1999 5:20 PM
> To: Gavin McKenzie; 'Tim Bray'; David Megginson; xml-dev@ic.ac.uk
> Subject: RE: XML for forms
> 
> 
> Gavin,
> 
> >Determining admissible evidence is clearly outside the scope of
> responsibility of an e-forms vendor. :-)
> 
> This reminds me of the argument that cigarette manufactures don't need
> to worry  about the cancer that their cigarettes cause -- a specious
> argument, but one that made them wealthy for many years.  :-)

I trust that your other contributions will be more substantive and relevant.
You really are stretching the literary license of a smiley.

According to Merriam-Webster Online, specious is defined as:

Main Entry: spe·cious
Pronunciation: 'spE-sh&s
Function: adjective
Etymology: Middle English, visually pleasing, from Latin speciosus
beautiful, plausible, from species
Date: 1513
1 obsolete : SHOWY
2 : having deceptive attraction or allure
3 : having a false look of truth or genuineness : SOPHISTIC
- spe·cious·ly adverb
- spe·cious·ness noun 

Is there a point or connection that you're trying to make here?

> 
> Obviously it is the responsibility of a vendor to ensure that 
> their users
> are getting solutions that they need.  The simple fact is that any
> document used in conducting business becomes part of an audit 
> trail that
> must be sound if organizations are to protect themselves.

That's a nice sound bite, but what did this have to do with my original
post?

Appropriate solutions aren't met by 'simple fact'...unfortunately you've
just boxed all 'business' into a specific set of constraints.

Let's talk about responsibility over delivering appropriate solutions.

Security is based upon varying degrees of trust (or lack thereof).  We would
do well to provide security solutions that match the requirements of the
task at hand. 

For instance, when I fill out my timesheet at JetForm I sign it.  But
recognize that JetForm views this as an internal document, and there is a
certain level of trust between JetForm and myself.  It is unlikely that
JetForm will be seeking remedies to a timesheet that I have incorrectly
filled via a court of law; they have much simpler ways of correcting such
problems.  And in this case, the data is seen as sufficiently
self-describing that it can be signed on its own; that is, the data has been
signed without the incorporation of the presentation built into the
signature.  

Why?  Because if you sign data content along with presentation you are
limiting the ability of the signature to verify only when reincorporated
with the same presentation -- put another way, if the data is misrepresented
in another form, the signature will not verify.  That's the point.

But in the case of this particular timesheet used in an internal process it
has been deemed sufficient to sign the data on its own, and thus gain the
flexibility of representing the data within another presentation that
performs various comparison's of this month's timesheet data against
previous months.

So, for this scenario it was deemed that a lightweight approach to security
was sufficient, and met the other requirements for flexibility of
presentation.

Ok...so outside of an organization there are likely to be forms that require
a higher level of security.  These forms may require that the data be signed
in concert with the form's original presentation so that the signature will
only verify when presented in exactly the same way, in exactly the same
form.

Then there are potentially an unbounded number of solutions that fall in the
middle.  They require that some combination of the data and original form
presentation be incorporated into a signature, thus achieving a flexible
result where the data can be verified in a number of consistent contexts.

Oh, and there are undoubtedly a number of solutions where forms don't
require digital signatures at all.  Either because the process requires a
physical signature such as pen and ink (this will still be commonplace for a
*long* time to come) or because the data security needs are low, or maybe
the environment manages security and trust at a different level.

The reality is that creating appropriate solutions requires flexibility and
a keen attention to the requirements.

> Why should an
> e-forms vendor be less responsible for this than, say, a vendor of
> printed checks or multi-part forms?
> 
> >It requires that content (data) and 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.
> 
> This sounds like an "e-forms vendor's" opinion on legal-related issues
> to me.  Hmmn. Some legal experts wouldn't agree with your assessment.
> For example:

No. I am explaining a technology, not providing legal opinion. Read my
original post.  I was speaking of meeting the needs of digital signature
non-repudiation, not describing how a particular legal jurisdiction will
rule on the merits of digital signature technology, or the non-repudiation
that it claims to provide.

> 
> "Historically, capturing and maintaining over time all of the 
> major elements
> of the business transaction includes: 1) the data (the 
> content), 2) the
> reason for the transaction (the context), and 3) some or all 
> elements of the
> visual and interactive presentation of the transaction (the 
> structure). This
> has been deemed to be increasingly important as the value of 
> electronic
> transactions increases. For transactions in the tens or 
> hundreds of dollars,
> the risk of loss is not that significant. Therefore, the 
> requirement to
> retain every element of detail may not be as critical for regulatory
> compliance or for discovery and litigation. However, as the 
> value of the
> transaction, or the value of the information that is part of the
> transaction, increases to the hundreds of thousands or even 
> millions of
> dollars, the details retained can be tantamount to winning or losing."
> 
> The full text is available at: http://www.cohasset.com/comm_forms.html
> if you are interested in more information.
> 
> Barclay
> 

It would seem that you haven't read your own quotation.  Hence,

"...capturing and maintaining..." 
This says nothing about physically combining the data inside the
presentation, which is the basis of your assertions and your disagreement
with my posting.

"1) the data..."
Yes, that's what I have said.

"2) ...(the context)..."
Yes, that's what I have said.

"3) some or all of the elements..."
Note the "some **or** all part".  
This is what I have said.

The rest of the quotation goes on to state how the level of security should
be tailored to the level of risk (and trust).  It continues to state how the
retention of all the original details is not necessarily critical for
regulatory compliance, or discovery, or litigation.

This is what I have said.

Gavin.




> 
>  ============================================
>     Barclay Blair -- Industry Relations
>     UWI.Com -- The InternetForms Company
>   v: 250-479-8334 x161   fx: 250-479-3772
>  barclay@uwi.com	       www.uwi.com
> ============================================
> 
> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk 
> [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Gavin McKenzie
> Sent: Monday, July 05, 1999 1:06 PM
> To: 'Tim Bray'; David Megginson; xml-dev@ic.ac.uk
> Subject: RE: XML for forms
> 
> 
> 
> Tim Bray writes:
> > Emulating paper isn't the issue; making the transaction admissable
> > as evidence is.
> 
> Determining admissible evidence is clearly outside the scope of
> responsibility of an e-forms vendor. :-)
> 
> > 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).
> 
> Sign yes. Include no.  It requires that content (data) and 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@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)