Skip to Content
LearnTLSNotary

TLSNotary

TLS already authenticates servers: a browser knows it is talking to provider.com. What TLS does not provide is a way to show a third party what the server said. TLSNotary adds that missing property. Keyring’s implementation builds on the TLSNotary protocol, with the prover compiled to WebAssembly so proving runs inside the browser extension.

The three roles

  • The prover (the user’s browser) drives an ordinary HTTPS session with the provider.
  • The notary participates in that session through multi-party computation. The TLS keys are secret-shared between prover and notary, so neither can unilaterally forge traffic, and the notary handles only encrypted data.
  • The verifier (Keyring’s backend) later checks the notary’s signature and the transcript commitments, with no need to have been present.
the user's browser,proving in WebAssemblythe server beingproven againstchecks the result later;needn't be presentProverProviderVerifierordinary HTTPS sessionNotaryjoins via MPC; keys secret-shared,handles only encrypted datapresentation: signed attestation + labelled openings
Neither party can unilaterally forge traffic: the TLS keys are secret-shared between prover and notary, and the notary never holds plaintext.

During the session the notary records connection facts (the server’s ephemeral key and certificate chain, timing, byte counts) and commitments to the transcript, and signs an attestation over them with an elliptic-curve key. It never holds the plaintext.

Selective disclosure

The prover chooses which parts of the committed transcript to open. Keyring’s proof plans name the exact fields a policy needs (for example one JSON field out of an account response); those become labelled openings in the final presentation, and every other byte is redacted. Redacted content is not merely hidden from display; it is absent from what the verifier receives, and the commitments prove the openings were not tampered with.

What verification checks

A presentation is accepted when three things hold:

  1. The notary signature is valid and matches a pinned, expected notary key.
  2. The server identity in the attestation matches the provider the proof claims (certificate chain and ephemeral key).
  3. Every disclosed field opens correctly against the transcript commitments.

The verified output is compact: a server name, a timestamp, the notary’s public key, and the disclosed fields by label.

What TLSNotary does and does not prove

It proves that a specific server served specific bytes during a live session. It does not prove the bytes are true (that trust remains with the provider), and it does not reveal anything the prover chose to redact. How the disclosed fields then become an anonymous credential is covered in credentials.

Last verified on