Anakin Insights

What evidence does an Anakin e-signature leave behind?

A completed envelope carries SHA-256 hashes of the original and final documents, a hash-chained event log with IP and user agent, an HMAC-SHA256 seal over the canonical evidence, an RFC 3161 timestamp when the timestamp authority responds, and a certificate PDF. A verify endpoint recomputes the chain and seal on request.

What is in the evidence package?

When an envelope completes, Anakin assembles an evidence package from these parts:

  • Document hashes. A SHA-256 hash of the original PDF and of the completed PDF.
  • Event log. Every action is an event, for example uploaded, sent, viewed, signed, declined, voided, reminded, extended, and completed. Events carry the signer's IP address and user agent where available.
  • Hash chain. Each event's hash includes the previous event's hash, so editing or removing an earlier event breaks every later one.
  • HMAC seal. The canonical form of the evidence is sealed with HMAC-SHA256 using a server-side secret.
  • Timestamp. An RFC 3161 token anchoring the evidence to a point in time, when the timestamp authority responds.
  • Certificate of completion. A PDF summarizing the signers, their company and title, the consent version, the hashes, and the timeline.

What does the signer agree to?

The ceremony records a consent version, currently anakin-esign-v2-2026-10. It covers intent to sign electronically and the signer's representation that they are authorized to bind the business they named.

How does verification work?

The owner can run a verify call on a finished envelope. It recomputes the hash chain from the stored events and recomputes the HMAC over the canonical evidence, then reports whether both still match. A mismatch means the stored record was altered after sealing.

How does the timestamp work, and what are its limits?

Anakin hashes the canonical evidence with SHA-256 and requests an RFC 3161 timestamp over it, with an 8-second timeout. FreeTSA is the default authority, which issues standard, non-qualified timestamps. If the request fails, the envelope still completes without it.

Two honest limits: the timestamp is best-effort rather than guaranteed, and Anakin does not validate the token's certificate chain locally.

Is this the same as a qualified signature?

No. This is advanced-style evidence for ordinary business agreements, not a qualified electronic signature. See the QES article for when that distinction matters.

What if the timestamp authority is down when someone signs?

The signature still completes. The RFC 3161 timestamp is best-effort: a failure or timeout is logged and the envelope finishes without the timestamp rather than blocking the signer.

Can I verify a completed envelope later?

Yes. The owner can call the verify endpoint on an envelope, which recomputes the event hash chain and the HMAC seal and reports whether they still match.

Which timestamp authority is used?

FreeTSA by default, which issues standard non-qualified timestamps. Operators can point to a different authority with the TSA_URL setting or turn timestamping off with TSA_DISABLED.

Does Anakin fully validate the timestamp token itself?

Not locally. The token is stored and shown with the evidence, but validating its certificate chain back to a trust anchor is not done inside Anakin. Use a dedicated validation tool if you need that.