From 95cc6a8ed1785e7fa73e518286001f5e78a80562 Mon Sep 17 00:00:00 2001
From: yuroitaki <25913766+yuroitaki@users.noreply.github.com>
Date: Wed, 21 May 2025 12:21:10 +0800
Subject: [PATCH] Add custom extension, minor fixes.

---
 docs/intro.md                            |  2 +-
 docs/protocol/commit_strategy.md         |  2 +-
 docs/protocol/custom_extension.md        | 64 ++++++++++++++++++++++++
 docs/protocol/server_identity_privacy.md |  4 +-
 4 files changed, 68 insertions(+), 4 deletions(-)
 create mode 100644 docs/protocol/custom_extension.md

diff --git a/docs/intro.md b/docs/intro.md
index bb679dd..0f2ab28 100644
--- a/docs/intro.md
+++ b/docs/intro.md
@@ -74,7 +74,7 @@ While TLSNotary can notarize publicly available data, it does not solve the "[or
 
 ## What TLS version does TLSNotary support?
 
-TLSNotary currently supports TLS 1.2. TLS 1.3 support will be added in 2024.
+TLSNotary currently supports TLS 1.2. Support for TLS 1.3 is on the roadmap.
 
 ## Who is behind TLSNotary?
 
diff --git a/docs/protocol/commit_strategy.md b/docs/protocol/commit_strategy.md
index c3e6f3f..60489d1 100644
--- a/docs/protocol/commit_strategy.md
+++ b/docs/protocol/commit_strategy.md
@@ -25,4 +25,4 @@ The commitment strategies differ mainly in the number of committed ranges (`K`).
 | `Attestation` | Artifact signed by the `Notary` attesting to the authenticity of the plaintext from a TLS session | Constant     | `Attestation` only contains data that remains constant-sized regardless of `K`, e.g., the Merkle root of the commitments |
 | `Secret`      | Artifact containing secret data that correspond to commitments in `Attestation`                   | Linear       | `Secret` contains some data whose sizes scale linearly with `K`, e.g., a Merkle tree whose number of leaves equals `K`   |
 
-Using the default hash algorithm (i.e., BLAKE3), every additional range committed costs around 250 bytes of increment in the size of `Secret`. For more details, please visit this [Jupyter notebook](https://github.com/tlsnotary/landing-page/blob/docusaurus/docs/Protocol/commit_strategy.ipynb).
+Using the default hash algorithm (i.e., BLAKE3), every additional range committed costs around 250 bytes of increment in the size of `Secret`. For more details, please visit this [Jupyter notebook](https://github.com/tlsnotary/landing-page/blob/master/docs/protocol/commit_strategy.ipynb).
diff --git a/docs/protocol/custom_extension.md b/docs/protocol/custom_extension.md
new file mode 100644
index 0000000..02df6b5
--- /dev/null
+++ b/docs/protocol/custom_extension.md
@@ -0,0 +1,64 @@
+---
+sidebar_position: 5
+---
+# Custom Extension
+
+The attestation signed by the `Notary` can be extended with custom extensions to support application specific requirements. Both the `Prover` and `Notary` can be configured to include custom data, which can later be verified by the third-party `Verifier`. The `Notary` can also be configured to validate any extensions requested by the `Prover`.
+
+## Use Cases
+- `Prover` includes their public key to bind it to their identity.
+- `Notary` includes their TEE (trusted execution environment) attestation to prove code integrity.
+- `Prover` includes a nullifier to prevent reuse of the attestation.
+
+## Example
+The following modifies the [attestation example](https://github.com/tlsnotary/tlsn/blob/main/crates/examples/attestation/README.md) to include the `Prover`'s public key as a custom extension.
+
+### Prover
+The [attestation prover](https://github.com/tlsnotary/tlsn/blob/main/crates/examples/attestation/prove.rs) is modified as follows. 
+```rust
+...
+    
+let builder = RequestConfig::builder();
+
+builder.extension(Extension {
+    id: b"prover_public_key".to_vec(),
+    value: b"PUBLIC_KEY_PEM".to_vec(),
+});
+
+let request_config = builder.build()?;
+
+...
+```
+Note that `Extension`'s `id` and `value` are of `Vec<u8>`, which means one is free to choose their encoding format.
+
+### Notary
+The [notary server](https://github.com/tlsnotary/tlsn/tree/main/crates/notary/server) is run with `allow_extensions` turned on.
+```bash
+NS_NOTARIZATION__ALLOW_EXTENSIONS=true cargo run --release
+```
+Note that the notary server currently doesn't support adding its own extension, or performing custom validations on extensions from the `Prover`. To do that, the notary server needs to be modified by using the relevant APIs outlined in the [API docs](https://tlsnotary.github.io/tlsn/tlsn_core/attestation/index.html#extensions).
+
+### Verifier
+The [attestation verifier](https://github.com/tlsnotary/tlsn/blob/main/crates/examples/attestation/verify.rs) is modified as follows.
+```rust
+...
+
+let PresentationOutput {
+    server_name,
+    connection_info,
+    transcript,
+    mut extensions, // Optionally, verify any custom extensions from prover/notary.
+    ..
+} = presentation.verify(&crypto_provider).unwrap();
+
+let Extension { id, value } = extensions.pop().unwrap();
+// Check the prover's public key.
+if id.as_slice() == b"prover_public_key" {
+    let public_key_pem = String::from_utf8(value).unwrap();
+    ...
+}
+
+...
+```
+The `Verifier` can now be confident that the attestation is binded to the identity associated with this public key.
+
diff --git a/docs/protocol/server_identity_privacy.md b/docs/protocol/server_identity_privacy.md
index 3a3a65c..aaf4a81 100644
--- a/docs/protocol/server_identity_privacy.md
+++ b/docs/protocol/server_identity_privacy.md
@@ -1,7 +1,7 @@
 ---
-sidebar_position: 5
+sidebar_position: 6
 ---
-# Server identity privacy
+# Server Identity Privacy
 
 To maximize `Prover` privacy, the server identity is not revealed to the `Verifier` by default. 
 The TLSNotary protocol mitigates the threat of a malicious `Verifier` attempting to infer the server identity from the messages they receive during MPC-TLS.