Cowrie Research

tlsnotary

3 min read

TLSNotary

  • Name: TLSNotary
  • URL: https://tlsnotary.org/
  • Category: web-data attestation primitive / TLS portability protocol / MPC-based provenance middleware
  • Summary: TLSNotary is the lower-layer web-proof primitive. It is not the app. It turns HTTPS session data into portable evidence by bringing a verifier or notary into the handshake, then supporting selective disclosure afterward. That makes it the clean anchor for comparing wrappers like Reclaim, vlayer, and other proof-packaging systems.
  • What it does:
    • Lets a Prover make a TLS request while cooperating with a Verifier through MPC so the response can later be authenticated to a third party
    • Supports selective disclosure, letting the Prover reveal only chosen parts of the transcript and redact the rest
    • Allows an optional general-purpose Notary role that can participate in the online MPC session and later sign portable attestations for downstream Verifiers
    • Ships an open-source Rust implementation plus a browser-extension stack with sandboxed plugins, verifier server, and WebSocket proxy for browser-based proof generation
    • Frames itself as a privacy-preserving data-portability primitive for proving facts about accounts, messages, transfers, purchases, certificates, or other HTTPS-delivered data
  • Key claims:
    • The core reusable insight is that TLSNotary is not mainly an identity app or an oracle. It is a transport-layer authenticity primitive for web data, sitting beneath higher-level products that decide which fields matter, who is trusted as verifier/notary, and how proofs are consumed.
    • The official intro is analytically useful because it cleanly separates three phases: MPC-assisted TLS session creation, selective disclosure, and verifier-side validation. That decomposition makes the real control surface much clearer than generic zkTLS marketing language.
    • The docs explicitly say the Notary is optional. That matters because it separates two trust models that are often flattened together: direct verifier participation in the TLS session versus delegated notarization that trades convenience for a trust decision about the notary.
    • The FAQ is especially helpful because it states the protocol’s goal narrowly: TLS alone does not give third parties transcript authenticity because the client knows the symmetric keys, so TLSNotary adds another participant to remove unilateral forgery power from the prover.
    • The browser-extension architecture shows where practical chokepoints may accumulate even in an open protocol stack: plugin definitions, verifier-server deployment, proxy infrastructure, and user-consent UX can become as important as the cryptography itself.
    • TLSNotary is useful in the active corpus because it gives a lower-bound comparison point for Reclaim, Primus, vlayer, and ZKP2P. Without it, those systems are too easy to flatten into one vague web proofs bucket.
    • Current implementation posture also matters: the docs and repo still emphasize active development, browser-extension helpers, and TLS 1.2 support, which means downstream systems inherit meaningful implementation and compatibility constraints from the lower layer.
  • Whitepaper: No single canonical TLSNotary whitepaper surfaced in this pass. The strongest primary materials were the official introduction, FAQ, browser-extension architecture docs, and the current Rust implementation README collected in ../whitepapers/tlsnotary-primary-sources-2026-05-11.md.
  • Sources:

Internal linkages

Control surface

  • The leverage sits in verifier or notary choice, plugin and extension distribution, proxy deployment, selective-disclosure defaults, and protocol compatibility constraints.

  • Read TLSNotary as the provenance primitive, not as a generic identity or app layer.

  • Last reviewed: 2026-06-14 UTC

Graph View

Backlinks