Seal and signature proofs

While data anchoring produces proofs of timestamp, signature anchoring produces proofs of seal or proofs of signature. Both types of proofs are technically equivalent, but their purpose differs:

• a proof of seal proves the signature of a data by an organization. The signature is usually automated within a data processing workflow.
  A proof of seal allows to check the identity of the sealer and the control of the signing key by the organization by querying the organization's identity server (which is achieved by issuing a signature challenge to the identity server).

• a proof of signature proves the signature of a data by an individual. The signature is usually interactive and on demand. A proof of signature is always associated with a signature request managed by a trusted third-party (usually Woleet) so that more evidences of the signature can be provided, such as a complete audit trail sealed by the trusted thrid-party.
  A proof of signature allows to check the identity of the signer by querying the trusted thrid-party's identity server.

In both cases, the proof is a Chainpoint compatible proof 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 signer
• signature: the signature of the content of « signedHash » using the « pubKey » Bitcoin address of the signer
• identityURL: an optional web hook used to:
  • retrieve the identity of the sealer/signer from his bitcoin address
  • verify the control of the private key associated with the Bitcoin address by the identity server (for seals only)

Note also that the targetHash 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 continues with the verification of the signature: the signature provided must be a valid signature of the hash of the original data produced using the signer’s Bitcoin address.

Optionally, if the identityURL property is provided, the verification process is completed by an identity verification process (see Identity management).