Trust model
Connect distributes trust across several parties. Each one is trusted for a narrow, specific thing, and several kinds of misbehaviour are made cryptographically impossible rather than merely forbidden.
The parties
The data provider (the site being proven against) is trusted as the source of truth for the underlying fact. TLSNotary proves that a response really came from the provider’s TLS endpoint; it cannot make a provider’s data correct.
The notary co-runs the TLS session with the prover as a multi-party computation participant and signs the resulting attestation. During the session it handles only encrypted traffic and transcript commitments, so it learns connection metadata (server identity, timing, byte counts) but not the plaintext. Its signature is what makes a proof verifiable by anyone; a colluding prover and notary could fabricate attestations, which is why verification pins the expected notary key.
Keyring configures policies and proof plans, verifies proofs, evaluates rules, and issues attestations. Issuance uses a blinded-signature protocol, so Keyring signs without seeing the unblinded credential message during issuance. Keyring operates the notary and the issuer keys; an integrator’s trust in credential quality is ultimately trust in Keyring’s policy enforcement.
Policy administrators represent the organisation the user is onboarding with. When authorised for data sharing, they receive the verified fields their policy uses. They are trusted to protect those fields and use them for the agreed purpose.
The KeyringCore contract verifies the issuer signature over all credential parameters (including chain ID and expiry) and answers checks from public state. Once deployed, its rules hold for everyone; roles cover key rotation, blacklisting, fee collection, and upgrades, as listed in the KeyringCore reference.
Regime access
Every credential carries a backdoor field: the prover’s identity
commitment, encrypted inside the zero-knowledge circuit to the public keys of
designated regime authorities. The circuit enforces that this encryption is
well-formed, so a credential cannot be issued without it. An authority
holding a regime private key, and only such an authority, can decrypt the
identity commitment behind a credential.
What cannot happen
- A credential cannot be forged without a registered issuer key; signatures commit to the policy, address, cost, expiry, and chain.
- A credential issued for one chain cannot be replayed on another; the chain ID is inside the signed message and checked at creation.
- A proof cannot claim fields the provider never served; the transcript is committed during the live TLS session.
- The backdoor ciphertext cannot be decrypted without a regime key.
What requires trust
- Keyring’s rule evaluation and issuance discipline (a compromised issuer key could sign invalid credentials until revoked).
- The notary’s non-collusion with provers, mitigated by Keyring operating and pinning the notary.
- Regime authorities’ handling of their decryption capability.
- Keyring’s handling of stored wallet-to-proof associations and policy administrators’ handling of disclosed data.
The data-flow view and the boundary between signature unlinkability and verification data are in privacy.