witness.directcase.aidirectcase/witness

DirectCase Witness

Independent witnesses for web content. Each witness runs a TLSNotary notary that joins your HTTPS session and signs a receipt proving which server delivered the content you disclose, and when. Every witness is an identified natural person whose signing key is declared in an eIDAS-signed document.

Test mode. The service is for testing purposes only and is open to a small group of users. It is provided without warranty. Receipts must not be relied upon as evidence in legal, financial or other critical matters until the service is publicly released.

Witnesses

WitnessServerDeclared key
Portrait of Pavol Trávnik, operator of this notaryIng. Mgr. Pavol Trávnik
natural person		pavoltravnik.witness.directcase.ai73a6bdba645a59e4

Want to be a witness? Contact us at info@directcase.ai.

Capture a web page

The open-source tool github.com/directcase/witness (MIT) captures a web page as evidence with a witness and lets anyone verify the capture later. It needs only Docker.

git clone https://github.com/directcase/witness.git && cd witness
./create.sh https://example.org/ --expect "some text on the page" --timestamp --eidas
./verify.sh captures/example.org/index/<time> --online

The witness is https://pavoltravnik.witness.directcase.ai unless you set WITNESS_NOTARY=https://<slug>.witness.directcase.ai. --urls urls.json captures many pages in one run. Each capture is a folder captures/<domain>/<page>/<time>/:

evidence.zipScreenshot, rendered HTML and text, the browser's full traffic (HAR), a WARC of the HTTP exchange and the TLSNotary receipt signed by the witness, with a manifest hashing every file.
report.pdfReadable summary with the screenshot and the SHA-256 of evidence.zip.
evidence.zip.ots--timestamp: OpenTimestamps proof that the zip existed no later than a Bitcoin block.
report_signed.pdf--eidas: your own eIDAS signature (PAdES-B-LT) over the report, made with your eID card.

verify.sh checks the files against the manifest, the receipt's signature and key window against the witness's published keys, that the signed bytes equal the transcript, the witness's own /verify, the Bitcoin timestamp and the eIDAS signature (with --online, through the EU DSS validator). It exits with 0 only if every check passes.

A receipt covers one HTTPS GET over TLS 1.2: the server's HTML or PDF, not content that JavaScript adds later. The screenshot and the HAR cover that.

How TLSNotary works

HTTPS protects a connection between your browser and a website, but it does not let you prove to anyone else what the website sent. A screenshot or a saved page can be edited. TLSNotary adds a third party, the notary, to the TLS session. The notary cannot read or change your traffic, yet afterwards it can confirm that the bytes you choose to disclose really came from that server.

Roles: prover, notary, server and relying party Proveryou, in your app Notary (witness)joins the TLS session Serverany HTTPS website Relying partycourt, lender, counterparty signed receipt
Figure 1. The prover talks to the website through a session the notary takes part in. The relying party trusts the notary's key, not the prover.

The notary runs in one of two modes. The prover's software chooses the mode for each session.

Proxy mode (fast)

Proxy mode message flow ProverNotaryServer 1 open session, proxy mode, server name 2 TCP connection to port 443 3 TLS handshake and encrypted request 4 encrypted response the notary relays and records everyencrypted byte and checks the servercertificate against the server name 5 disclosed bytes + zero-knowledge proof the proof shows that the disclosedbytes decrypt the recorded ciphertext 6 signed receipt
Figure 2. In proxy mode the notary carries the encrypted traffic itself. It sees only ciphertext. Afterwards the prover proves that the disclosed plaintext matches it.

Proxy mode needs little bandwidth and a session takes about a second. It assumes that the network path between the notary and the website is honest: an attacker who can reroute the notary's own connection (DNS or BGP hijacking) could make it talk to a fake server.

MPC-TLS mode (no network assumption)

MPC-TLS message flow ProverNotaryServer 1 compute the TLS keys jointly neither side ever holdsthe full session keys 2 TLS handshake and encrypted request 3 encrypted response each record is encrypted andauthenticated jointly: the provercannot forge server data and thenotary never sees plaintext 4 disclose bytes, commit the rest 5 signed receipt
Figure 3. In MPC-TLS the prover and the notary split the TLS session keys by secure multi-party computation. The prover's traffic reaches the server directly (a browser uses the notary's WebSocket-to-TCP bridge, which forwards bytes only), but it cannot fake a response without the notary's share.

MPC-TLS does not depend on the notary's network path, but it needs much more bandwidth and computation, and a session takes considerably longer.

The receipt

After a successful session the witness signs a receipt: a JSON payload with the server name, the mode, the time of verification, the transcript lengths, the disclosed bytes (hidden bytes are zeros), hashes of committed ranges and the session metadata. The signature is ECDSA over secp256k1 and SHA-256 of the exact payload bytes. A receipt proves that the disclosed content was served over TLS by the named server at the stated time, and that this witness saw it. It does not prove that the content is true, and it says nothing about the parts that were hidden.

Trust model

Evidence log and timestamps

Hash-chained records, hourly files, OpenTimestamps and Bitcoin recordrecordrecord hourly fileOpenTimestampsBitcoin blockwrite-once copy each record includes the hash of the one before
Figure 4. Removing or changing any record breaks every later hash. Each sealed hour is anchored in Bitcoin, which fixes the time it existed.

Every session, relay and receipt check is written as one record in a hash chain, and each witness keeps a copy of every receipt it signs. Every UTC hour is sealed into files that are timestamped with OpenTimestamps and archived in write-once storage. The files contain personal data (IP addresses) and are disclosed only in legal proceedings. Their hashes and proofs are published on each witness's page.

How to check

  1. The declaration. Download a witness's signed declaration PDF and validate its eIDAS signature with the EU DSS validator. Confirm that the key id in the declaration matches the witness's page.
  2. The timestamp. Upload a document (or an evidence file) together with its .ots proof at opentimestamps.org to verify it; you can stamp your own files there as well. Offline: ots verify file.ots.
  3. The receipt. Verify the ECDSA signature over the payload bytes against the declared public key yourself, or send the receipt to the witness's POST /verify. Check that verified_at is within the key's active window.