Credentials

A credential is the end of a pipeline that starts with a TLSNotary proof and ends with a uint64 expiration in contract storage. Each stage narrows what the next stage gets to see.

Stage 1: claims

A verified TLSNotary presentation yields disclosed fields: labelled values that provably came from a provider (see TLSNotary). Keyring evaluates these against the policy’s rules. A policy might require a particular KYC tier, an account age, or a jurisdiction; the rules consume the disclosed fields and produce a yes or no.

Stage 2: authorization

When the rules pass, the prover constructs the authorization message inside the zero-knowledge circuit described in zero-knowledge proofs. The message binds:

• the wallet address the credential will attach to,
• the policy payload (policy, validity, cost),
• the backdoor: the prover’s identity commitment encrypted to the regime authorities.

The message reaches the issuer only in blinded form, accompanied by the proof that it is well-formed.

Stage 3: blind signature

The issuer signs the blinded message and returns the signature. The prover unblinds it, producing a signature over the plain authorization message that verifies against the issuer’s public key. The issuer has signed something it could not read and will not recognise later.

Stage 4: the on-chain credential

The unblinded parameters become a createCredential call on KeyringCore. The contract checks the issuer signature over all parameters (address, policy, chain, expiry, cost, backdoor), takes the fee, stores the expiration, and emits the backdoor bytes with the CredentialCreated event. From here the mechanics are contract territory: credential lifecycle.

The result

Compliance is checkable by anyone, per address and policy, via checkCredential. The underlying facts stay private; disclosed fields exist only during issuance.

The distribution of knowledge across all parties is summarised in the privacy model.