1. Which authority is used?
This deployment is configured to use an external RFC 3161 time-stamp authority: provider not yet configured. Requests are sent over HTTPS using SHA-256, and the operator authenticates to the provider where the provider requires it. Read the provider’s own policy for its accuracy, availability, certification status and published CA certificate. The app batches the latest ledger head at the operator’s configured interval when the worker is running; an interval is a target, not a guarantee. No empty or unchanged head is sent. If no authority is configured, deposits remain pending and no independent time is claimed.
Only a digest of the public chain-head record and a fresh request nonce leave the server for timestamping. Your invention text, title, author label, account email and reveal token are not sent to the TSA. The provider does see the service’s network address. OpenTimestamps/Bitcoin is not enabled or claimed in this release.
2. Understand the three states
- Recorded / pending
- The deposit is saved and sealed, but has no covering verified external checkpoint. Its server-recorded time is not independent evidence. A worker outage or a failed signature check keeps it in this state.
- External checkpoint recorded
- The app verified the response against the original request/nonce and exact head bytes using its configured CA. The displayed TSA time is decoded from that signed response, not copied from the database capture time. Download and verify the evidence yourself.
- Independently verified
- You have checked the complete hash-link path from the deposit to the signed head and verified the TSA signature with a trust certificate you obtained independently. You can also check the exact original text bytes against the recorded content hash.
3. Save the right files
After a successful checkpoint, use Download inclusion proof on your deposit or public hash lookup result. You can also download one using the public endpoint /api/entries/RECORD_NUMBER/proof. The proof contains immutable public event bodies from that deposit to the first recorded covering checkpoint, the original RFC 3161 request and signed response, and convenience metadata. It does not contain your reveal token, encrypted content, private labels or revealed plaintext.
Save your initial deposit receipt and reveal token separately. A head-only receipt from the public ledger proves that head’s timestamp but does not, by itself, supply the links needed to prove that a particular earlier deposit is covered.
4. Verify a complete deposit proof offline
From the downloaded project directory, with its Python dependencies and OpenSSL installed:
python -m app.timestamp_cli verify-proof \
--proof invent-priority-proof-1.json \
--ca trusted-tsa-ca.pem \
--content original-text.txtObtain and authenticate the CA yourself from the authority’s official site; do not blindly trust a CA supplied by a party whose evidence you are checking. The optional --content file must contain the exact UTF-8 bytes submitted, including whitespace and line breaks, not a PDF or word-processing wrapper. Omit that argument to verify the inclusion and timestamp only.
A successful result includes verified: true, the TSA’s signed UTC time and whether original content was checked. The verifier recomputes every included event hash, checks sequence and previous-hash links, binds the final head to the timestamp, verifies the request nonce, checks the signature/certificate chain, and compares the response imprint with the exact canonical head JSON. Editing a displayed timestamp in the JSON does not change the verified time.
5. Inspect and verify with OpenSSL
You can unpack a head receipt or inclusion proof into standard RFC 3161 files:
python -m app.timestamp_cli unpack \
--receipt invent-priority-proof-1.json \
--out-dir evidence
openssl ts -verify -queryfile evidence/head.tsq \
-in evidence/head.tsr -CAfile trusted-tsa-ca.pem
openssl ts -verify -data evidence/head.json \
-in evidence/head.tsr -CAfile trusted-tsa-ca.pem
openssl ts -reply -in evidence/head.tsr -textBoth verification commands must succeed. The text command only decodes the response; it does not verify a signature. These OpenSSL checks verify the head timestamp; use the full proof verifier for the deposit-to-head links. The signing certificate is requested in the response with -cert; the separately trusted root remains your responsibility.
6. Trust and long-term limitations
The provider’s signed time and stated accuracy, not our server clock, supply the independent bound. You still trust the TSA’s clock, keys, certification practices and the selected root. We do not claim that the provider is an Australian government authority, or that its timestamps are automatically accepted by every browser, patent office or court. Qualified-timestamp status under EU rules, where a provider claims it, is the provider’s status and must be checked against the relevant EU Trusted List for the signing key.
The included checks use OpenSSL’s certificate-validation rules; they do not perform live OCSP/CRL revocation checks or provide a complete long-term archival validation system. Preserve provider certificates, relevant policies and revocation evidence; seek specialist review before evidential deadlines or certificate expiry. Do not disable certificate or time checks to make an invalid receipt appear valid. A later timestamp cannot recover an earlier unanchored time.
Record hashes and proofs in independently controlled storage. A local ledger audit cannot prove the accuracy of its own server clock or guarantee that no earlier or competing ledger has existed. Timestamping does not establish inventorship, official patent priority, ownership, novelty or infringement.