Web Proofs
TLS Notary

TLSNotary

How does TLSNotary work?

The TLS Notary (TLSN) Protocol (opens in a new tab) was originally developed in 2014 (opens in a new tab) and has been subsequently re-designed and re-implemented (opens in a new tab) by the Ethereum Privacy, Scaling, and Exploration (opens in a new tab) group with modern cryptographic components. The TLSN documentation (opens in a new tab) is high-quality and comprehensive as well.

In our How does TLSNotary work? (opens in a new tab) blog post, we dive deeper into the mechanics of the protocol and provide the necessary mathematical background to understand the protocol. Please refer to that blog post for a more detailed overview of the below.

How does Pluto use TLSNotary?

We at Pluto.xyz (opens in a new tab) are productionizing TLSN to enable smart contract developers to take advantage of any off-chain data sources in their smart contracts in a service that we are calling Web Proofs.

If you were to share the contents of your TLS transcript with a third party, that party would have no way to detect whether the transcript had been forged with faulty data. TLSN is a protocol for Data Provenance (opens in a new tab) — data with proof of origination from some particular server.

TLS Notary (TLSN) at a high level

TLS (or Transport Layer Security) is a protocol for encrypting and authenticating communication between two parties: a Client (described elsewhere in this post as the Prover) and a Server. TLS Notary is a protocol that allows the Client to prove Data Provenance to a third party; in other words, TLS demonstrates that the Client honestly obtained the data from the Server, and did not interfere with the contents.

The TLS Notary protocol aims to achieve the following properties:

  • Authenticity - the protocol should demonstrate that TLS transcript is not a forgery by the client
  • Provenance - the protocol should authenticate the identity of the server via certificate chain verification--a valid transcript with a fake giithub.com (opens in a new tab) should be rejected
  • Privacy - the Client should not have to sacrifice the privacy of their data or credentials to a third party
  • Non-Proprietary - The protocol should avoid enshrining a single service provider as intermediary

For more information on the inner workings of Pluto's TLSNotary implementation, please see the How does TLSNotary work? (opens in a new tab) blog post.