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, which none of the above SaaS platform allows.

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 proposes an evolution of data anchoring: Signature anchoring on Bitcoin. The functionality is already available on 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:

Remote signing of documents one can send a file to a set of signees and ask them for a proof of signature: the file doesn’t need to follow a workflow and is never tampered

Signature timestamping with no intermediate 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  — IoT sensors can emit data along with a signature proof to prove data origin and creation time
 — schools can certify the diploma they deliver
 — e-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 does signature anchoring manage signee identity?

Signature anchoring uses Bitcoin’s legacy signature scheme. Thus, a signee is identified by his Bitcoin address (a cryptic number like 10cbJgAXivkAMXwfckMKSrTSrHWk3UCQWh). While sufficient for most use cases, it is not human friendly, and there is a need to know for sure who owns a given Bitcoin address.

We are carefully following the evolutions of decentralized identity management on the blockchain. This field, also known as « self-sovereign identity » aims to give better control to individuals on the disclosure of identity information. While many research projets have started, there is no proven implementation today.

Meanwhile, Woleet has chosen to leverage a currently available, well proven and widely used identity verification source: the Certification Authorities Certification Authorities are the trusted third parties issuing the TLS certificates used to secure the web. Thanks to these certificates, you can securely surf the web and be sure you are talking with Google, with your bank or with your energy utility company.

Wherever the identity of a signee needs to be verified, an identity verification URL can be added to the signature proof. This URL, hosted by the signee and protected by his TLS certificate (bought by the signee from a Certification Authority that will verify his identity) allows the verifier to check that the owner of the certificate also owns the signee Bitcoin address, by asking him to sign some random data using the same Bitcoin address. Of course, this process requires the signee to host a web service: this is the purpose of Woleet.ID Server Edition. By signee we mean either legal persons or physical persons. Woleet.ID Server can manage the signature keys of the employees within an enterprise. In this case, the employees' identity will be attested by the organization which is identified in the TLS certificate of the web service.

How does signature anchoring work?

Signature anchoring is similar to data anchoring, except that the anchored data is not the original data itself (ie. the one that is signed) but instead the signature of the original data (produced by the signee).

A signature anchoring receipt is a Chainpoint compatible receipt with an additional signature property containing 3 mandatory sub-properties, and 1 optional:

• signedHash: the SHA256 hash (ie. the fingerprint) of the original data (this hash is what is actually signed)
• pubKey: the Bitcoin address of the signee
• signature: the signature of the content of « signedHash » using the « pubKey » Bitcoin address of the signee
• identityURL: optional web hook to be called whenever the signee Bitcoin address has to be verified

Note also that the target_hash property of the Chainpoint receipt is the SHA256 hash of the signature instead of the SHA256 hash of the data. Consequently, verifying a signature anchoring receipt using the regular Chainpoint verification process proves that the signature (and by transitivity the data) existed at some point in time: a signature receipt is thus equivalent to a regular anchoring receipt.

The verification process is completed by a signature verification step: this step checks that the signature provided is a valid signature of the hash of the original data produced using the signee’s Bitcoin address.

Optionally, if the identityURL property is provided, the verification process is completed by an identity verification process (described in the previous part).

Concretely, how can I sign my data and create proof of signature?

A Ledger Nano S

A Ledger Nano S

For end-users, creating signature anchors is a simple drag&drop operation using Woleet’s web app ProofDesk. Signees have the choice between diverse signature solutions: either the signee owns a personal device containing a private key, or he relies on a dedicated service, Woleet.ID Server Edition, an open source software that can be deployed by organizations to manage the signature keys and the identities of their users.

Woleet is compatible with Ledger Nano S Bitcoin hardware wallet. These hardware wallets are the most secured on the market: your private key cannot leak outside the hardware, even if you connect it on a compromised computer. If you lose your device or someone stole it, you will be able to regenerate your private key. Note that Google Chrome is currently required for communicating with the Ledger device (other browsers are about to integrate the required U2F API).

Another type of personal device is the smartphone. Thanks to Woleet.ID Mobile Edition, our mobile application, you can create a private key on your mobile and use it to sign.

Finally, in organization contexts where the deployment of personal devices is not possible, Woleet.ID Server Edition can be used to create private keys and perform electronic signature, either for legal or physical persons.

Updated 2 months 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.