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 created this data? » or « who certified 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, find a way to link his bitcoin address to his identity, and pay 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 the anchoring platform).

To address this limitation, and allow a new set of use cases, Woleet proposed an evolution of data anchoring: signature anchoring. 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 proves the existence of a signature of the data at a given point in time. With signature anchoring, not only you can prove that some data existed at a given point in time, but additionally that this data was signed by a given 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