TLSNotary ― Flow Overview

Working on Bring ID I've dived into the TLSNotary protocol. This tiny article is a compilation of what could be found in Rust Crate docs made to help you faster understand the core concepts and the flow of what happens after the MPC-TLS part. It is assumed that you have read the general documentation and understand what Prover, Notary and Verifier are.

Glossary

• Transcript The plaintext of all application data communicated between the Prover and the Server.

• Attestation
  A cryptographically signed document issued by a Notary who witnessed a TLS connection. It contains various fields which can be used to verify statements about the connection and the associated application data.

  Attestations are comprised of two parts: a Header and a Body.

  The header is the data structure which is signed by a Notary. It contains a unique identifier, the protocol version, and a Merkle root of the body fields.

  The body contains the fields of the attestation. These fields include data which can be used to verify aspects of a TLS connection, such as the server’s identity, and facts about the transcript.

• Extension
  An attestation may be extended using Extension fields included in the body. Extensions may be used to implement application specific functionality.

  A Prover may append extensions to their attestation request, provided that the Notary supports them. A Notary may also be configured to validate any extensions requested by a Prover using custom application logic. Additionally, a Notary may include their own extensions.

• Presentation
  A proof of an attestation from a Notary along with additional selectively disclosed information about the TLS connection such as the server’s identity and the application data communicated with the server.

  A presentation is self-contained and can be verified by a Verifier without needing access to external data. The Verifier need only check that the key used to sign the attestation, referred to as a VerifyingKey, is from a Notary they trust.

Flow

1. The MPC-TLS protocol produces commitments to the entire Transcript of application data.
2. Prover has the opportunity to slice and dice the commitments into smaller sections which can be selectively disclosed. Additionally, the Prover may want to use different commitment schemes depending on the context they expect to disclose.
3. Prover makes an attestation Request, which can be configured. With it the Prover can configure some of the details of the Attestation, such as which cryptographic algorithms are used. The Prover may also request for Extensions to be added to the Attestation. Upon being issued an Attestation, the Prover will also hold a corresponding Secrets which contains all private information.
4. Upon receiving a request, the Notary can issue an Attestation.
5. Prover uses an Attestation and the corresponding Secrets to construct a verifiable Presentation.
6. Verifier checks the verifying key and verifies the Presentation.

— Ian (@cxrtisxl)