Re: Semantics in signatures

I have just joined the list to participate in the discussion of
SignatureProperties. Although I am a co-chairman of the Signatures workgroup
of Legal XML, I am participating here individually.

On Tue, 11 Apr 2000 17:18:17 -0400,
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0040.html
Joseph M. Reagle Jr. wrote

"The short of this though, is that since I that I think we should encourage
people to use the approach captured in the example above, I'd like to
include a few sentences and an example similar to the above such that we
aren't unduly encouraging people to use SignatureProperty."

I have been communicating privately with Todd Vincent. He and I agree on
some points and disagree on others.

I agree with posted portion quoted above in that there is a need to limit
what can legimately be put into the SignatureProperties element so that it
it is not used for matters that are not directly related to the signature as
such. On the other hand, in at least two respects, I think signatures do
have properties that should legitimately be expressed as
SignatureProperties .

In a first example, one such property relates to signatures of individuals
made on behalf of entities and agencies, which may become a large part of B
to B commerce.

There is a fundamental difference when a signer in the world of pen and
paper signs as "John Doe" as compared with "XYZ corporation by John Doe, its
agent". In the former, John Doe is responsible. In the latter, XYZ
corporation is the signatory. I think it is clear that the identity of the
true signer is a property of the signature. As an agent John Doe is probably
not responsible or liable if XYZ corporation fails to perform. A signature
property is that John Doe signs *for* XYZ corporation within an agency
relationship. Applications will need a standard way to understand this
difference. Digital signatures supported by X-509 certificates may not
adequately express this difference and it can be argued they cannot do so on
the basis of identity certificates alone. The SignatureProperties element
should be a place to store such information.

As several people in previous posts have pointed out, the multiple signer
example should also be considered a candidate for the signature property
element. I agree, particularly where detached signatures are used.

Chris Smithies has raised the example of needed forensic examination
material. This relates, as I understand it, to the specifics of the
signature technology of signature dynamics.

A more difficult example is where the signature authority of a signer is
limited to certain transactions or dollar value transactions, as in the
original example taken from discussions with Taka. This does not relate to
the technology of the signature or the identity of the signer or signers,
but to the authority to act. I agree with Todd Vincent and Joseph Reagle
that this is extrinsic to the signature itself and relates to authority of
an agent to act within a certain grant of authority, and therefore the
limitation is not a property of the signature but of the transaction or
document being signed.

Where a signer has reservations about a certain commitment or level of
commitment, as in Tom Ginden's suggested example and Donald Eastlake's
elaboration, and wants to indicate one or more such reservations within the
signature property element, the case for a signature property as opposed to
another element is weaker. I believe that in Tom and Don's example, the
signature is a part of a process, but what is happening is not a property of
a signature. Historically signatures have been used to mark an event that
fixes a legal commitment. Prior to universal literacy, in early common law,
people transferred real property by grabbing a clod of grass or dirt and
pulling it out of the ground, passing the clump of soil to another. That
primitive method fixed the transfer of title and ownership as irrevocably
done. Signatures on paper later came to replace this earlier method as
marking the event. Some such mechanism is probably needed to combat a
natural tendency towards what is popularly called "buyer's remorse".
Electronic signatures can replace ink ones for this purpose, but the
signature is a step in a process extrinsic to it, and the process is not a
property of the signature. Though John Boyer has constructed a useful
scenario about a possible interaction of a signature engine and an
application to derive intent, it is the pressing of the "sign" button which
fixes a user's intent, not the mechanical application of the signature,
though customarily we tend to associate the one act with the other. In
certain early court e-filing projects, which do not yet use signatures, such
intent is expressed by pressing a "submit" button, which simply uploads an
unsigned document presented for filing to a court server. By court rule or
in California by statute, submitting the document is the act which fixes the
intent. Some consider this method to be unsatisfactorily primitive
(including myself, because for example there is no way to insure data
integrity).  Regardless of one's views of the method, with that approach,
should we include the "submission" information within a Signatures Property
element? I don't think so. Intent is expressed by pressing a button to
upload a document, but there is no signature. Another method of establishing
intent has been used and is either implicit in the application or if more
information is needed, this should be reflected in the document, not as a
Signature Property.

I agree that at some point a line should be drawn and respected as to what
is a property of the signature and what is not.

Received on Wednesday, 19 April 2000 21:19:40 UTC