What the evidence behind an e-signature should contain

Most legal systems accept an electronic signature. The EU’s eIDAS regulation and the United States’ ESIGN Act are the best known examples, and plenty of other countries have their own. So the argument, when there is one, is rarely about whether an electronic signature can count. It is about evidence: can you show what happened, two or five years later, to somebody who has every reason to doubt you?

That evidence is usually called an audit trail or a certificate of completion, and providers vary a great deal in what goes into it. These are the parts worth looking for.

Who was asked, and how each person proved who they were

The record should name each person invited to sign and say how each one proved who they were. An email link proves that somebody could read that inbox. A code sent to a phone proves a little more, and an access code agreed in advance more again. None of these is wrong for every agreement, but the record must say which one was used for each signer, and must never claim more than was checked.

In Rutba Sign the level is chosen per signer (email, a phone code, an access code or location), and the certificate states what was actually done for each one. If a signer proved nothing beyond clicking a link in an email, the certificate says exactly that.

Exactly what they saw and agreed to

A dispute often turns on which version somebody signed. The record should fix the document with a cryptographic fingerprint (a hash) the moment it arrives, and record any disclosure or consent the signer accepted on the way. Rutba Sign pins each document by its hash on arrival and never rewrites it. Signatures and filled-in values are added to the PDF through the format’s own append-only mechanism, so the original bytes stay checkable underneath them.

When each step happened, in an order nobody can rearrange

Invited, opened, identity checked, signed: each event needs a time, and the sequence needs protecting as much as the times. If events are kept as separate rows, somebody with access to the database could reorder or quietly remove one. Chaining each event to the one before it by hash makes that visible. A timestamp from a public timestamping authority (the standard is RFC 3161) shows the record existed at a given moment without relying on the provider’s own clock.

Rutba Sign records the signing as it happens, chains the events by hash, and seals the completion record with an RFC 3161 timestamp from a public authority.

Proof each party can keep, and check without you

Two things are easy to overlook. First, a signer who signs today may wait weeks for the other parties. In Rutba Sign every act is countersigned the moment it happens, so that person leaves with a receipt of their own act straight away. Second, evidence that only the provider can confirm is only as good as your relationship with that provider. Rutba Sign’s verification is public: anybody can check a completed package or a single receipt against a published key set, with no account, no key and no request to your own systems. The answer is valid, tampered or unknown.

What to ask any provider

• Does the certificate say how each signer proved who they were, or only that they signed?
• Is the document fixed by a hash when it arrives, and is the original kept unchanged?
• Are the events chained so that a reordered or missing event shows?
• Is the record timestamped by a public authority, or only by your own servers?
• Can my counterparty verify the signed document without an account, and after I stop being your customer?
• Does a party who signs first get proof of their own act before everyone has signed?

For developers, the same engine is available as an API. Rutba Sign API is listed in TrustList’s digital signature software directory, and TrustList’s page on Rutba lists the other Rutba products by category. Verification that never touches your servers goes further into how the public check works.