REST API

Retrieves and returns an already generated crumtrail given a SHA-256 hash, if found; otherwise HTTP status 202 (Accepted) is returned: the content is a newly created crum. (Actually, this method is idempotent, so if you call this time method with the same hash seconds later, the existing crum you created seconds ago is returned.)

A crumtrail encapsulates a crum and a Merkle proof establishing a path from the hash of the crum to the root of a newly published Merkle tree.

The hash of a crum is computed from its binary representation as a sequence of bytes: 32 bytes for the hash witnessed, followed by 8 bytes for the witness time in UTC milliseconds. So the hash of a crum is the SHA-256 of this 40-byte sequence.

202 Side effect: if a crumtrail for a submitted hash cannot be found, then a new crum for that hash is automatically generated. In turn, the crum for this hash will be included in a subsequent Merkle tree. The net effect is that if this call first fails to return a crumtrail for a given hash, it will succeed on that same hash a few minutes later.

Verifies an uploaded crumtrail (timestamp). If it's at all old, the service will have long forgotten about the uploaded crumtrail and the hash that was used to generate it. But the service does remember the root of the Merkle tree of every crumtrail it has ever generated, and that root is sufficient to validate one of its proofs. There's some flexibility in the layout of an uploaded crumtrail. If the uploaded JSON crumtrail, contains any user-defined fields, they are ignored without a fuss.

Note since the roots of our Merkle trees are pubished and publicly advertised on 3rd party properties, this API method can be classified as a convenience method: a crumtrail can be verified by the user independently.

This method supports both POST and GET.

Lists the roots of the Merkle trees the service has published starting from a given time in chronological or reverse chronological order.

Returns a path of hashes linking the previous Merkle tree to the root of the given tree. In actuality, it's just a Merkle proof of the last leaf in the tree: every Merkle tree crums.io creates has the root of the previous tree as its last leaf.

On success the hash argument identifies a known Merkle tree and returns a Merkle proof of the last leaf in the tree. The last leaf in the tree is always arranged so that it contains that root hash of the last Merkle tree that this tree points to. That is, each crums.io Merkle tree contains a hash pointer to the tree it succeeds. These records in the crums.io ecosystem never expire: they are maintained indefinitely.

If the hash argument is not a known Merkle tree, then 404 Not Found is returned.

Returns the latest Merkle tree record generated by the service. Since the value at the root of the next Merkle tree cannot be predicted in advance, the value for the latet tree can be used as a coarse-grained beacon. If this value is in turn embedded in a product, depending on how embedded it is (how difficult it is to substitute this embedding with another), a product can prove its freshness via the value.

Returns the latest Merkle tree record generated by the service as a QR code. If this image is embedded in a product, depending on how embedded it is (e.g. it appears somewhere on scene in a video), a product can prove its freshness via the value.