Trust model
Connect distributes trust across four 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 final credential value and cannot link an on-chain credential back to the verification session that produced it. Keyring operates the notary and the issuer keys; an integrator’s trust in credential quality is ultimately trust in Keyring’s policy enforcement.
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. This is the mechanism that makes
credentials accountable to compliance processes while keeping them anonymous
to everyone else, including the dApps that check them.
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.
- An observer of the chain cannot recover identity from a credential; the backdoor ciphertext requires a regime key to decrypt.
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.
The data-flow view of the same boundaries is in privacy.