Privacy model
Every stage of the pipeline is designed so that the party operating it learns as little as the stage permits. This page collects the whole picture; the per-product view for integrators is at Connect: privacy.
Knowledge by party
- Provider
- Learns that the user signed in, as in any session; not that a proof was generated at all.
- Notary
- Learns connection metadata and commitments; not session plaintext or disclosed values.
- Keyring, during verification
- Learns the disclosed fields, wallet, and policy; not session tokens or undisclosed fields.
- Keyring, during issuance
- Learns a blinded message and its validity proof; not the credential it is signing.
- Chain observers
- Learn address, policy, expiry, and a ciphertext; not identity, provider, or disclosed fields.
- Regime authority
- Learns the identity commitment behind a credential, on decryption; nothing beyond what the backdoor contains.
Three mechanisms carry the model
Redaction before disclosure. The TLSNotary presentation contains only the fields the proof plan names; the rest of the transcript exists solely as commitments. Nothing undisclosed can be extracted later, by anyone.
Blindness at issuance. The signature protocol hides the unblinded credential message during issuance. The verification-data boundary is described in Connect: unlinkability.
Escrowed identity. Anonymity is not absolute by design. The credential carries the holder’s identity commitment encrypted to regime authorities; decryption is possible for them alone and leaves everyone else’s view unchanged. The governance of that capability is a policy matter documented in the trust model.
The durable record
The chain exposes wallets and credential parameters, not the disclosed proof fields. Keyring stores disclosed fields and wallet associations off chain. Authorised policy administrators can retrieve policy data through the data-sharing API.