Signature Anchoring


Data anchoring is a very efficient way to prove the existence of data at a given point in time, and allows to address an important set of use cases. However, data anchoring is also often claimed as being able to address the problem of authenticating or certifying data, which ultimately consists of being able to reply to the questions « who is the creator of this data? » or « who approved this data? »

This claim is wrong at a practical level. Let’s see why. In order to authenticate or certify some data using only data anchoring, the creator or certifier of the data would need to create the anchoring transaction by himself, using his own Bitcoin address and paying the fees with his own bitcoins.

Because transaction fees are expensive (a few dollars for Bitcoin transactions as of writing) all platforms factorize as much anchors as possible into one transaction obviously signed by the platform and paid using the platform’s bitcoins.

So, YES, you can prove that the data existed at a given point in time with data anchoring, but NO, you cannot know who actually anchored the data (the owner of the transaction will always be Woleet, Tierion or Stampery).

What is signature anchoring?

To address this limitation, and allow a new set of use cases, Woleet proposed an evolution of data anchoring: signature anchoring on Bitcoin. The functionality is implemented by the Woleet platform and the specification is open (described here and in the Woleet API documentation). Anybody is free to implement a similar functionality in a different way, but of course everyone would benefit from a standardization and interoperability of proofs of signature (which is the case for Chainpoint based proofs of existence).

The process of signature anchoring is actually similar to data anchoring, except it creates a timestamped proof of signature of the data. With such a proof, not only you can prove that some data existed at a given point in time, but additionally that it was signed by an actor (eg. the creator of the data of any other actor wanting to « put its stamp » on the data).

The same data can be signed by any number of actors, at any point in time. Each signature generates a new proof and never modifies the source data. This allows a set of new use cases:

Signing any type of confidential documents
Legacy signature solutions requires to upload a PDF document to their platform, and the signatures are inserted in the document, which is thus tempered.
Signature anchoring allows the signed document to be of any type, and preserves its confidentiality (only its digital fingerprint is provided). The integrity of the document can be verified at every step.

Signature timestamping without intermediary
Legacy signature solutions are either not timestamped, or use a centralized authority to prove signature timestamp, while time stamping is inherent to signature anchoring

Data provenance verification
Schools can certify the diplomas they award.: a diploma sent by email can be verified by a sjngle drag&drop on a public verifier (like https://auditor.woleet.io)
IoT sensors can emit data along with a signature proof to prove data origin and creation time
Electronic documents used as proof of residence (like utility bills) can be signed by their emitter to eradicate forgery

Data certification verification
Within a data processing workflow, a Certification Authority can sign some data to prove it certified it at a given date

How can I sign my data and create signature proofs?

A Ledger Nano S

Signing a document is a simple drag&drop operation using ProofDesk. The signer can choose to sign in one-click by delegating his signature to ProofDesk, or can generate his signature by using a privately owned key pair stored inside a personal device and accessible though an app:

When using ProofDesk for Teams the signer can additionally delegate his signature to the identity and key server of his organization (usually a privately hosted instance of Woleet.ID Server Edition.

Updated about a month ago

Signature Anchoring

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.