Journeys
What the identity runtime does across regulated wallet profiles, national identity systems, and delegated agents.
Web evidence
Not every fact you need lives in a government attestation. TLSNotary lets the wallet take an ordinary HTTPS response — a bank statement, an order history, a utility account — and turn it into a credential a relying party can verify, without the website having to issue anything. It is honest, bounded, development-only evidence today (vct dev.advatar.tlsn.evidence), and it is designed to go post-quantum by reusing machinery the wallet already ships.
MPC-TLS
The wallet and a notary run the TLS session together under multi-party computation, so neither side ever holds the full session key alone. Neither can forge or alter the server's bytes — the transcript is provably authentic even though the website never opted in and never learns a proof was made.
Selective reveal
In the wallet you pick, field by field, what a JSON response discloses — an account holder, a balance band, a statement date — and leave the rest out. Disclosure is whole-field, never a loose substring, so a value is never shown without the key that gives it meaning. Today the chosen fields are recorded in the credential and the notary signs over the transcript; binding each field to only its own transcript bytes — so unselected fields are cryptographically stripped, not merely omitted — is the tracked next step.
Bound to a credential
VCIssuer verifies the notary's signed attestation against a pinned notary key — fresh, and tamper-evident — then mints a device-bound SD-JWT VC (dev.advatar.tlsn.evidence). You present it to any relying party exactly like a PID or an mDL.
Who does what. Three roles stay distinct. Your wallet is the prover. An independent notary co-signs the transcript, and VCIssuer pins that notary’s key (TLSN_TRUSTED_NOTARY_KEY). VCIssuer itself is the issuer: it verifies the notary’s attestation and mints the credential, but it is not the notary. Keeping issuer and notary separate is what makes this evidence rather than self-attestation. (A development-only demo mode can host an ephemeral notary inside VCIssuer to complete the flow without a live notary; it is never used in production.)
Making it post-quantum
Yes — web evidence can be made post-quantum, and only one of the three layers needs new work. The commitments are already quantum-safe; the transport is opportunistic; the piece that matters is the notary's signature, and the hybrid signer that protects it already exists in this wallet.
| Layer | Today | Post-quantum path |
|---|---|---|
| Notary attestation signature | ES256 (classical P-256); hybrid verification already enforced | Sign the notary attestation with the same hybrid ES256 + ML-DSA-65 envelope the wallet already ships for credentials, so an attacker must break BOTH signatures — a transcript harvested today stays unforgeable against a future quantum adversary. VCIssuer already ENFORCES this when the notary's ML-DSA-65 key is configured (downgrade-closed: both signatures must verify); the one remaining piece is a notary that emits the second signature. |
| TLS transport key exchange | Whatever the target server negotiates | Prefer a post-quantum hybrid KEM (X25519MLKEM768) in the MPC-TLS handshake. This is opportunistic — the server has to support it — so it hardens the channel where possible without weakening the guarantee. |
| Transcript commitments | SHA-256 (already used) | Already quantum-safe. Grover's algorithm only halves pre-image strength, leaving SHA-256 comfortably out of reach; no change needed. |
The issuer side is already done: when a notary's ML-DSA-65 key is configured, VCIssuer requires the attestation to be a downgrade-closed hybrid — valid ES256 and valid ML-DSA-65 — reusing the same envelope the wallet ships for credentials. The only remaining piece is a notary that emits the ML-DSA signature; the verification path is real, not new cryptography.