For your understanding, here is a formal description of the verification process.
From a file and a proof of existence receipt:
- 1 - compute the SHA256 hash of the file
- 2 - check that the targetHash property matches the hash of the file
- 3 - check that the proof property is a valid Merkle proof (see the Chainpoint standard for this step)
- 4 - retrieve the Bitcoin transaction from the anchors property
- 5 - check that the OP_RETURN field of the Bitcoin transaction matches the merkleRoot property
These steps verify the existence of the file at the time of the Bitcoin transaction.
From a file and a proof of signature receipt:
- 1 - compute the SHA256 hash of the file
- 2 - check that the signedHash property matches the hash of the file
- 3 - check that the signature property is a valid signature of the signedHash property for the public key stored in the pubKey property
- 4 - check that the targetHash property matches the SHA256 hash of the signature property
- 5 - check that the proof property is a valid Merkle proof (see the Chainpoint standard for this step)
- 6 - retrieve the Bitcoin transaction from the anchors property
- 7 - check that the OP_RETURN field of the Bitcoin transaction matches the merkleRoot property
Additionally, if an identityURL property is available:
- call identityURL to make the callee sign some random data using the public key pubKey
- check that the returned signature is valid
- get the TLS certificates of the URL (it must be an HTTPS URL) to get insight about the signee’s identity
Note that verifications steps 4 to 7 for proofs of signature are similar to steps 2 to 5 for proofs of existence: these steps verify the existence of the signature at the time of the Bitcoin transaction, which by transitivity verifies the existence of the file at the time of the Bitcoin transaction.