Privacy

The design goal is data minimisation: each party in the flow receives the minimum it needs, and disclosed proof fields are not published on chain.

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.

Policy administrators

Represent the organisation the user is onboarding with. When authorised for data sharing, they receive the verified fields their policy uses.

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

Blind signatures prevent linking issuance to an on-chain credential through the signature itself.

A submitted wallet address alone does not establish a verified link between that wallet and a Keyring entity.

Regime access establishes a credential-specific link by decrypting the credential’s backdoor and matching the recovered identifier to stored verification records. See regime access.

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). The credential itself does not disclose the proof’s fields or datasource.

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