Re: Some possible rqmt/design points

[I apologize in advance for the length of this email.]

Richard Brown stated best a distinction that I believe is mirrored by the
law:

> The body of the document represents the assertion. The signature attests
its
> authenticity.

I also agree strongly with Barb Fox:

> If a signer wants to make qualified
> statements about a particular XML blob, then the signer should make those
> statements in XML (perhaps including a strong reference/hash of the
original
> blob) and sign *that*.  In any event, you're always signing a particular
XML
> object.
>
> --Barb

A signature is a combination of an act and a mental state.  In the paper
world, the act is making some sort of mark or symbol.  The mental state is
the *intent* to authorize, authenticate, accept, acknowledge (etc., etc. . .
the list is long) information in a writing/record.

See:

http://e-ct-file.gsu.edu/ERSA/Definition-Signature_1.asp

and

http://e-ct-file.gsu.edu/ERSA/Definition-ElectronicSignature-Insecure_1.asp

A signer or signatory is the person who makes the signature.

See:

http://e-ct-file.gsu.edu/ERSA/Definition-Signer_1.asp

For evidentiary purposes (or, in other words, security) it is helpful if the
"mark" or "signature" is unique to the signer, although this is certainly
not a legal requirement.  Further, "unique" does not mean "unique in fact"
but rather "practically unique" - i.e., the probability of duplication is
low.

See:

http://e-ct-file.gsu.edu/ERSA/Definition-ElectronicSignature-Secure_1.asp

A "record" or "writing" contains "information" (statements/assertions) to
which a person may potentially be legally bound.

http://e-ct-file.gsu.edu/ERSA/Definition-Writing_10.asp

http://e-ct-file.gsu.edu/ERSA/Definition-Writing_15.asp

http://e-ct-file.gsu.edu/ERSA/Definition-ElectronicRecord-Insecure_1.asp


The important points: a "signature" by itself is meaningless; a record by
itself has no legal effect.  However, information in a record/writing has
legal significance if it can be bound to (attributed to . . . logically
associated with) a person (signer) by that person's signature.

Although I do not have a citation, in e-commerce vocabulary, I would call a
"transaction" the completed process of a signer(s) signing a record (noting
that a signature could be a *click* on a click-through agreement).   The
legal vocabulary is "agreement" or "contract."

http://e-ct-file.gsu.edu/ERSA/Definition-DigitalSignature_6.asp (sorry about
the URL name, must be an MS bug).

http://e-ct-file.gsu.edu/ERSA/Definition-DigitalSignature_23.asp

The question with which we are struggling is whether the "transaction"
should be scoped or limited by (a) information about the signature or (b)
information contained in the record/writing.

In my view, backed by what I believe is consistent with legal concepts, the
"transaction" should be scoped or limited by information contained in the
record/writing not the signature.

So, for instance, I agree with many if not all of the requirements Phil
would like to place on transactions, but I disagree with his position that
such requirements should be achieved by way of signature semantics.  Barb
and Richard's positions are more practical and consistent with legal
definitions.

One final point regarding Dave's statement:

> Also, beyond the basic mathematics, I will continue to argue
> that the decision to "accept" a signed thing is based on the rules of
> the relying party, not the signer (although quite possibly dictated by
> external agreement); hence the assertion of criticality by the signer is
> misplaced.

Whether to "'accept' a signed thing" is and offer/acceptance contract
question that relates to information in an offer (a "record") not
information about a signature.

Generally, the offeror is in control of the offer.  The offeree can either
accept or counter-offer.  If the offeree accepts, there is a contract.  If
the offeree counter-offers, there is *no* contract.  Further, if the offeree
counter-offers, the original offeror becomes the offeree, and the originally
offeree becomes the offeror and is then in the position to accept or
counter-offer.

So, for instance, if Alice offers (1) to sell 10 widgets (2) at $10.00 a
widget (3) with acceptance made only via fax, then Bob can accept the offer,
decline, or counteroffer.  If Bob "agrees" to buy 10 widgets at $10.00 but
sends his acceptance via email, there is no contract (because acceptance
wasn't sent by fax and Alice is in control of the offer, not Bob).
Likewise, if Bob "agrees" to buy 5 widgets at $10.00 and sends his
acceptance by fax, there is no contract (because Alice offered to sell 10
widgets, not 5).   In the latter case, Bob's agreement may be considered a
counteroffer, in which case Alice is in the position to accept, decline, or
counteroffer.

So, Dave argument, if I understand it, is not consistent with legal
reasoning.  It is for this reason that I continue to be perplexed with
applications that ignore "critical" flags that relate to the substance of
the transaction (as opposed to the mechanics of the signature).  I'm not
arguing for or against "critical" flags in "things" that have more to do
with "signatures" than "writings/records", I'm just saying that if critical
flags are in the "transaction", then a relying party whose application
ignores such flags has a good chance of having the transaction invalidated.
If the relying party (a user/human) does not know that the application is
ignoring the critical flag and the transaction falls through as a result, I
would argue that the relying party's software developer could be held liable
(although I know plenty of lawyers who would argue against this position).

The point is, there are an infinite number of ways to scope, limit,
condition, etc. an offer/contract/transaction (i.e., assign it
attribute/value pairs).  Assigning attribute/value pairs to transactions is
a good thing because it helps us to automate transactions.  However, the way
to do so is with information contained in a record/writing (that happens to
be signed), not by trying to say that Signature X means X (attribute X=
"limit $10K") and Signature Y means Y (attribute Y="limit $5K").

Todd

Received on Thursday, 17 June 1999 12:53:30 UTC