A starter page for a protocol of digital signing. This would be a set of customs and actions undertaken by agreeing parties. It is not clear yet whether it is possible or efficient to make a broad horizontal protocol across all CAcert users; there remain substantial details to work out.

See DigitalSigning for main information.

Requirements for Digital Signing

All good protocol design start with laying out the requirements (6.1). In order to usefully compete with human face-to-face signing with support from Pen v1.0, digital signing protocol needs to meet several requirements:

R1. The agreement

The agreement needs to be identified. That is, the contract(s) or document(s) need to be clearly identified.

R1.a Preservation of identification

Such identification needs to be preserved.

R1.b Preservation of document

The document itself needs to be preserved.

R2. The Parties

The parties need to be recorded.

R2.a Precision in identification

Some precision is desired as disputes happen much later. Normally this is done by putting the full name of the party on the contract, and some other ancillary info to reduce the pool. Traditionally, the place of residence of the person. More recently, companies have used SSNs (or similar) or DoBs.

R2.b Multiple Parties

There may be more than 2 parties.

R2.c Types of Parties

Organisation versus Individual. Where an organisation enters into an agreement, normally one or more Individuals are authorised to make that so. In this case there will be both the Organisation Identity and the individuals who act on behalf.

R2. The Intent

The real intent of the parties should be recorded. This generally suggests something like "I agree to ..." It can be more complex for more serious contracts, and can include things like checkboxes for clarifying actual intent as opposed to blind signing.

R3. The Entire Record

For record should be singular. That is, the record should include all the necessary components for further use, even after a long time.

This indicates one document, one file. Multiple files tend to become separated.

R4. The Date

The date of should be recorded.

R4.a The Date of Signing

The dates of each signature should be recorded. The protocol should preserve some convention as to which is the date of effect of the contract.

R4.b The Time

For digital applications, precise times should be recorded for forensic purposes.

R4.c Date of Effect

The Date of Effect is generally the point at which the agreement is fixed. As there are revocation issues in digital signing, it would be generally better to check revocation after the signing. Hence a contract could be null and void if no revocation occurs beforehand.

R5 Simplicity

The concept should stretch as far as possible towards simplifying the future.

R5.a Paper

The contract should easily be printable, with as much or all necessary components in the paper form. Disputes normally are resolved around paper documents, because Desk (v200x100mm) has more resolution that Screen (v40x30mm). Paper documents are easily firewalled in the human mind whereas digital documents are not.

This approach says that text documents are best, because it is easy to audit the contents. PDFs might be a pragmatic second, but even they have special artifacts inside, features available to more advanced readers. OpenOffice or Word documents are the worst.

R5.b Redundancy

The salient details should be recorded in the text. Even if the digital components include extra features, they are opaque without the right tools, and lost on paper. Digital tool rot starts within a few months, and with several years is highly advanced.

R6 Custom and Clauses

Some context has to be preserved such that the scope and custom of the agreement is reached. This might be a reference to another document, or a boilerplate clause that refers to jurisdiction and law.

R7 Variability

R7.a Purpose

A signature means different things depending on the purpose of signing. The meaning needs to be captured. E.g., a signature that was meant to mean "received delivery of book by courier" is not to be misinterpreted later on as "agreed to purchase book for $100".

R7.b Value

A signing protocol should be tunable to different value propositions. E.g., it needs to cope with the scrawl accepting the book delivery, above, and the affirmation on a Will / Last Testament.

R7.c Time

Some signing protocol needs are short term, others are long term. The protocol needs to cope with needs as short as a day, and as long as 30 years.

R8 Technology Robust

R8.a Neutral to Technology

Ideally a protocol should be able to be employed using different technological methods, or should at least integrate those methods in a holistic fashion. E.g., short term, low value signing (see R7) might be done with checkboxes, whereas high value, long term signing could be augmented by voiceprints and witnesses.

R8.a Robust to Technological Quirks

The signing should not fall apart when the tech breaks. E.g., revocation, expiry, key rollover should be dealt with without undue difficulties.

Further Research

DigitalSigningProtocol (last edited 2008-07-19 16:38:44 by anonymous)