Re: Semantics in signatures

There is a difference between signature "syntax/mechanics" and signature
"semantics/meaning."

The XML-Signatures specification is for standardizing signatures
"mechanics."  Trying to standardize signatures "meaning" is not possible in
this specification.  Indeed, standardizing signatures "meaing" is not
possible because signatures, in and of themselves, do not have any meaning.
Three concrete examples follow:

Example 1:  I am sitting in a waiting room doodling on a peice of paper and
I sign my name on the paper.  The signature has no meaning.

Example 2: Yesterday I signed an invoice for $51,000 for work that was
actually performed for me by four developers.  If you were to look at the
face of the signed document, it would appear that I own $51,000.  In fact, I
don't owe anyone anything because the "developers" were students senior
seminar class and I was a "fake" contractor.  They did the work.  I received
the benefit.  But, the "surrounding circumstances" clearly indicate that I
have no obligation to pay them.

Example 3: I digitally sign an electronic will that gives me estate to my
nephew, but excludes my sons and daughters.  I sign the document using a
private key that, in fact, belongs to me.  Mechanically, the signature
validates using the corresponding public key.  The will is invalid, however,
and the signature is meaningless, because it comes to light that when I
signed the document, my nephew had a gun to my head.

The key to each of these examples is "intent" or, stated another way, the
"meaning" of what the person did when he/she signed. You cannot capture
intent/meaning in a signature.  Even if you could, you couldn't standardize
it, because there are an infinite flavors of intent.

Meaning and intent is usually specified in documents/writings.  The modern
term is "records" and this might include audio, video, or other tangible
medium.  Usually "records" are signed, because a signature is additional
evidence of what is meant was, in fact, really meant (i.e., authorized,
affirmed, accepted, etc., etc.)  Meaning and intent may also be garnered
from "surrounding circumstances."  Surrounding circumstances are not
captured in signatures or even in records.

> 1: some signature semantics are not application-specific in the usual
sense
> of that term. They may not belong to all signatures, but they belong to a
> very large subset.

I suspect you mean things like dates and times.  Dates and times are
captured on documents/records.  Documents with dates and times are signed to
give them additional credibility.  It is not only inappropriate to put a
date and time in a signature, it is also dangerous.  Not only is it contrary
to common understanding, there is the potential for conflict if the
date/time in the document/record is different than the date/time in the
signature.  If I sign a document that, on its face, says 1/23/2001 on it and
a signature application embeds 12/30/2001 in it, and the two are associated,
then what is the correct date/time?


> 2: Joseph's example, in which the signed data contain an <approved by
> ="xxx"> element referring to the signature, has I think two drawbacks,
> neither of them fatal.
>
> 2.1: It will be hard work to allow arbitrarily many signatures to be added
> to a document using this approach. Subject to what John Boyer has to say,
> it looks to me as if a document will need to be specially designed to
allow
> multiple signatures to be added.

If there are "mechanical" reasons for using <SignatureProperties> (or any
other element), then I am not opposed to using <SignatureProperties>.

I am somewhat concerned about Tom Gindin's post yesterday where he says:

<Tom>
The primary use of SignatureProperty, IMHO, is in the case where
multiple signatures are affixed to the same document and one of the signers
wishes to add qualifications to his or her signature without affecting the
document signed by the others.
</Tom>

If this is the use of <SignatureProperty> then it is an improper use.  If
Person A evidences his/her agreement on a document with a signature and then
Person B wants to amend or qualify the agreement (by means of alterning the
document or the signature), then you don't have an agreement, so you would
*never* want to allow this.  There is no "meeting of the minds."

If either Person A or Person B wants to qualify the meaning of the
transaction, they cannot do so unilaterally via a document or a signature.
The way it is usually done is to change or amend the document and then
*everyone* resigns.

> 2.2: Information about the signature logically belongs with the signature.
> Forensic examination of signatures will be complicated by the need to
> consult a plurality of resources in different locations in order to
> reconstruct the evidence of a single historical event.

If you mean signature "mechanics" then I agree.  Everything necessary to
mechanically verify the signature should be standardized in this
specification.  However, the "meaning" and "trust semantics" *do not*
logically belong to the signature; these things belong to the
document/record and surrounding circumstances.


> 3: It is not the application which defines the meaning of a signature. The
> application can only define whether the signature _can have_ any
semantics.
> It is the intent of the signatory which determines what a signature
> actually means. (For more on application semantics, see e.g.
> http://www.uniroma3.it/kant/field/chinese.html.)

The "intent of the signatory" (to the extent it can be ascertained)
determines the meaning of the transaction.  However, the signature has no
inherent meaning.  You could just as easily say the "intent of the author."
A signature is a meaningless act, unless it is associated with something
that gives it some meaning.

(Feel free to skip the next three paragraphs . . . it is a tangent. . . )

All of this having been said, since you pointed to Searle, about an hour
after I sent off the post yesterday (. . . in which I stated that current
technology cannot capture intent . . .) I had a meeting with a professor in
the CIS department at the university working in biotechnology.  She, with
help from a doctor, is writing device drivers for use with a diode that is
embedded in the brain of a blind quadriplegic.  They are picking up
electrical signals from the man's brain as he thinks about things (like
moving his hand or his leg).  The man can hear and he can blink.  He cannot
see or otherwise communicate.  Previously, the man (via the diode, device
drivers, etc.) was able to move and stop a mouse cursor on a computer screen
in a strait line.  Yesterday, for the first time, he was able to move the
mouse cursor up, down, left and right, on command, simply by thinking about
it.

If you combine the above with the following stentences from the Searle
article and substitue the word "computer" below for "human" you get an
interesting result.

Contrary to "strong AI", then, no matter how intelligent-seeming a computer
[human] behaves and no matter what programming makes it behave that way,
since the symbols it processes are meaningless (lack semantics) to it, it's
not really intelligent. It's not actually thinking. Its internal states and
processes, being purely syntactic, lack semantics (meaning); so, it doesn't
really have intentional (i.e., meaningful) mental states.

Hmmmm . . .

> For these reasons I think that Joseph's proposal is actually more untidy
> than making use of the SignatureProperties. Perhaps he would like to point
> out where I'm going wrong.

I still agree with Joseph.

Todd

Received on Wednesday, 12 April 2000 13:00:34 UTC