RE: Semantics in signatures

Hi Chris, Joseph and all,

Actually, I think both Chris and Joseph are right; they are coming from
different points of view that are not irreconcilable.

Chris is coming from a viewpoint of creating a signing ceremony that
includes capturing the intent of the signer.  To take one of Todd Vincent's
examples, Todd could communicate that despite what is said on the face of
the document, his intent in signing is only to achieve a certain level of
realism in a student training scenario and is not intended to legally
obligate him to pay anything.

Joseph's viewpoint is that it is the application that defines what
constitutes appropriate intent.  For example, a check may not be valid
unless signed by N signers.  A particular signer may intend to authorize a
check, but the application is aware of the need for authorization from
multiple parties in other roles.

It is helpful to consider this scenario from the relying party's viewpoint.
An application receives a signed check.  The application knows what
constitutes an authorized check, so it goes to the check element and finds
the 'pointers' to the requisite signatures.  The 'pointers' in Joseph's
example happen to carry the additional information of what 'intent' was
chosen by the signer (approval).  Since approval is what the application
requires, the application then calls upon core behavior to verify the
signature(s) before processing the transaction.

So, it is clear that 'pointers' are required to get from the document to the
signatures, though they may be implicit, esp. in the case of enveloped
signatures within a document.  It is also clear that the rules regarding the
semantic interpretation of intent (e.g. its sufficiency for proceeding with
a transaction) are application specific and belong in the document.  But the
location for storing the actual declaration of intent *depends on who is
providing the mechanism by which the signer's intent is specified*.

It is helpful to think about this from the standpoint of an application
(such as an e-check system) that integrates with a signature generation
engine.  The application provides the face of the document and the face of
the document may explicitly indicate what the signer is doing by signing
(e.g. "I agree to pay X").  Upon hitting the "Sign here" button, the
application turns control over to the signature generation engine, which may
then allow the signer to specify some intent (e.g. typing "Not really!" into
an edit field).

The signature generation engine is one application that is only aware of the
signature element.  It is designed to qualify that signature through
signature properties.  But to assert that a 'secure' application would
integrate with such an engine without taking its properties into account
would be ludicrous.  The application could

1) turn off the signature engine's generation of properties if the
application knows that it is providing the intent declarations, or

2) account for the signature engine's method for specifying signer intent
(which could get complicated if the signer is given a free-form text box to
type whatever they like).

In the latter case, the application is usually allowed to parameterize what
the signature engine's intent message will say and what the signer's options
are (e.g. the user can click OK or click Cancel in response to a specific
message, rather than being given the freedom to type any contradictory
message they like).

And if the application is already on the hook for parameterizing a given
signature engine, then the application can certainly deal with finding the
intent results of a signature in a signature property subelement.

John Boyer
Software Development Manager
PureEdge Solutions, Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com


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.

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.

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.)

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.

CPK Smithies
PenOp

Received on Wednesday, 12 April 2000 15:27:31 UTC