Prior-art comparison
This is a qualitative guide to choosing a starting point. It is not a benchmark, security audit, maturity ranking, or claim that any deployment has a particular availability or support level.
What this comparison does well
It makes the primary design choice explicit: a timestamp token, a public-chain proof, a transparency log, an identity-backed software record, or a configured Witness quorum are related but not interchangeable outputs.
Trust, privacy, and operational model
Compare the trust anchor before comparing features. A single authority, a public ledger, a log operator with monitors, and a threshold federation have different failure and recovery assumptions. Hash-only submission can limit content disclosure, but public or predictable hashes and request metadata still require careful review. Hosted and self-managed choices also move different key, availability, retention, and abuse-control responsibilities to the operator.
Difference from Witness
Witness is the row for a configured quorum that signs each attestation and can provide local, Merkle, federation, and external-anchor verification. The other rows are included because they may be a better fit for a particular trust, interoperability, or operational requirement—not because they are lesser versions of Witness.
| Need | A relevant starting point | Why |
|---|---|---|
| Standard signed timestamp token | RFC 3161 or a trusted TSA | Interoperability and a conventional authority model |
| Public-chain-derived hash proof | OpenTimestamps or a direct blockchain anchor | Chain-based durability and public verification |
| Software provenance and identity | Sigstore Rekor | Supply-chain transparency and identity-aware workflows |
| Certificate issuance visibility | Certificate Transparency | Public logs and ecosystem monitoring for certificates |
| Configured witness quorum with hash-only submission | Witness | Per-attestation threshold signatures and optional log/federation/anchor layers |
When to use an alternative instead
Use an alternative when its defining property is the requirement: RFC 3161 for standard TSA tokens, OpenTimestamps or a direct chain for public-chain evidence, Rekor for software provenance, or CT for certificate issuance transparency. Use Witness when its configured quorum and accountless hash workflow are the better match.
Questions to ask
- Is the important trust anchor a single authority, a configured federation, or a public blockchain?
- Is account or issuer identity part of the requirement, or should submission remain accountless?
- Can the system expose the hash, certificate name, artifact metadata, or transaction metadata without violating the intended privacy model?
- What latency, fees, confirmation, retention, and operational ownership are acceptable?
- Does the verifier need a standard token, a Merkle proof, a chain transaction, or a threshold-signed application attestation?
Witness-specific limitations remain important: it is pre-1.0, unaudited, not Byzantine-fault-tolerant, and does not hide network metadata. See the threat model before selecting it.