Privacy

The design goal is data minimisation: each party in the flow receives the minimum it needs, and the durable public record contains no personal data.

What stays in the browser

• Provider passwords are typed on the provider’s own pages, never in the extension.
• Session cookies and authorization headers are captured only as required by the proof plan, are used locally to drive the proving session, and leave the browser only inside cryptographic commitments, never as plaintext.
• The full provider responses stay local; fields not named by the proof plan are redacted before anything is shared.

What each party receives

Data provider

Receives a normal signed-in session from the user’s browser; gets no indication that a proof is being generated.

Notary

Receives encrypted traffic, transcript commitments, server identity, timing and sizes; never plaintext or disclosed field values.

Keyring

Receives the proof with its selectively disclosed fields, wallet address, and policy and entity identifiers; never provider credentials, session tokens, or undisclosed fields.

The chain, publicly

Receives policy ID, wallet address, expiry, cost, and the encrypted backdoor blob; no names, documents, account data, or disclosed fields.

The disclosed fields are the point of the proof (for example, a KYC tier), so Keyring necessarily sees them during rule evaluation. Everything else in the provider session is out of reach by construction.

Unlinkability

Attestations are issued through blind signatures: the issuer signs a blinded message and never observes the unblinded credential. As a result, Keyring cannot correlate an on-chain credential with the verification session it came from. The exception is deliberate and scoped: regime authorities can decrypt the credential’s backdoor field to recover the holder’s identity commitment, as described in the trust model.

What the public record shows

An on-chain credential reveals that an address satisfied a policy until some expiry. Observers can see compliance status per policy (that is what makes checkCredential work), and nothing about why or through which provider the status was earned.

The cryptographic mechanisms behind these properties are described in Learn, specifically TLSNotary, zero-knowledge proofs, and the privacy model.