Proof Request

The core of the request, specifying the Verifiable Credential types and the specific claims (attributes) required from each. This defines the 'what' of the proof.

• Credential Schema ID: A unique identifier (e.g., a DID URL) pointing to the schema that defines the credential's structure.
• Required Attributes: The specific data fields requested, such as dateOfBirth, degreeEarned, or accountBalance.
• Optional Constraints: Conditions on attribute values, like issuanceDate after a certain date.

This section defines the cryptographic and logical conditions the proof must satisfy, ensuring its integrity and authenticity. It answers 'how' the proof must be constructed.

• Proof Type: Specifies the zero-knowledge proof system (e.g., BBS+, CL-Signatures) or digital signature scheme to be used.
• Challenge/Nonce: A random value supplied by the Verifier to prevent replay attacks, ensuring the proof is fresh and generated specifically for this request.
• Domain Separation: A context string to bind the proof to this specific interaction, preventing misuse in other contexts.

Metadata identifying the entity making the request, allowing the Prover to make an informed consent decision. This establishes the request's origin and purpose.

• Verifier DID: The Decentralized Identifier of the requesting service, providing a cryptographically verifiable identity.
• Purpose Statement: A human-readable explanation of why the data is being requested (e.g., 'To verify age for service access').
• Privacy Policy URI: A link to the Verifier's data handling and retention policies.

Rules governing how much information the Prover must reveal, enabling privacy-preserving proofs. This is a key feature of advanced ZK-proof systems.

• Attribute Disclosure: Specifies which of the requested attributes can be revealed as predicates (e.g., age >= 21 is proven without revealing the exact dateOfBirth).
• Predicate Proofs: Requests for range proofs, set memberships, or equality proofs without revealing the underlying value.
• Unlinkability Guarantees: Ensures multiple proofs from the same credential cannot be linked together by the Verifier.

In DeFi or traditional finance, a lender can request a proof of a user's credit score range or income bracket. The user's wallet generates a ZKP from a credential issued by a credit bureau, proving their score is above a certain threshold (e.g., >700) or their income falls within a specific bracket. The lender receives cryptographic assurance of creditworthiness without accessing the raw score, transaction history, or personal financial details, enabling privacy-preserving underwriting.

Proof requests control access to gated communities, content, or events. A website or DAO tool can request proof that a user holds a specific Non-Fungible Token (NFT) or membership credential. The proof verifies ownership or membership status directly from the user's wallet without requiring a wallet connection that exposes all assets. This is used for:

• Token-gated websites and Discord servers.
• Exclusive event ticketing.
• Access to premium software features for verified holders.

Financial institutions and regulated entities use proof requests to satisfy regulatory requirements like Anti-Money Laundering (AML) and Travel Rule compliance in a privacy-enhanced manner. A user can prove they are not on a sanctions list or that their wallet address is associated with a verified identity, without continuously streaming all their transaction data to the institution. The proof is a one-time, cryptographically verifiable attestation that meets the compliance check.

The verifier (the party requesting the proof) must be authenticated to prevent malicious or spam requests. Trust is established through:

• On-chain verification: The verifier's identity is often a smart contract address with known permissions.
• Off-chain protocols: Requests may be signed using the verifier's private key, ensuring non-repudiation.
• Selective disclosure: The prover can cryptographically verify the requestor's right to ask for specific data, a core principle of Verifiable Credentials.

The security of a proof request hinges on the integrity of the underlying circuit (for ZKPs) or schema (for credentials). Critical considerations include:

• Deterministic Verification: The verification logic must be publicly auditable and immutable.
• Code Is Law: The circuit defines the exact claim being proven; a bug or backdoor compromises all proofs.
• Trusted Setup: For some ZK systems (e.g., Groth16), a secure and verifiable trusted setup ceremony is required to generate the proving/verification keys.

A core security goal is to minimize data exposure. A well-designed proof request ensures:

• Zero-Knowledge Property: The prover reveals only the truth of the statement, not the supporting data.
• Selective Disclosure: The prover can satisfy the request by revealing only specific attributes from a larger credential.
• Unlinkability: Multiple proof requests for the same credential should not be linkable to each other or to the prover's identity, preventing tracking.

Proof requests must guard against replay attacks, where an old proof is reused. Mitigations include:

• Nonces: Incorporating a unique, time-bound challenge (nonce) from the verifier into the proof request.
• Timestamps: Binding the proof to a specific time window or block height.
• Revocation Checks: The request should mandate a check against a revocation registry to ensure the prover's credential is still valid.

Understanding the threat model is essential. Key trust assumptions include:

• Honest Verifier: Most ZK protocols assume the verifier follows the protocol but may be curious (Honest-Verifier Zero-Knowledge).
• Secure Hardware: The prover's environment must be trusted to not leak secret inputs during proof generation.
• Oracle Reliability: If the proof depends on external data (e.g., a price feed), the security of those oracles becomes critical.

Security failures often occur in implementation, not theory. Risks to manage:

• Side-Channel Attacks: Proof generation time or power consumption could leak secrets.
• Malicious Inputs: Verifiers must validate that the proof's public inputs conform to expected ranges and formats.
• Gas Limits & DoS: On-chain verification must be gas-efficient to prevent denial-of-service via expensive proof requests.

The entity, typically an end-user, that receives and stores Verifiable Credentials from Issuers and presents them in response to Proof Requests. The holder controls a cryptographic wallet (e.g., a digital identity wallet) that manages their private keys and credentials.

• Key Role: Maintains sovereignty over their data, choosing what to share and with whom.
• Interaction: Receives a Proof Request from a Verifier and selectively discloses credentials.

The entity that requests and validates proof from a Holder. The Verifier creates and sends the Proof Request, specifying the required credentials or claims. It then cryptographically verifies the presented proofs.

• Purpose: To establish trust in a Holder's attributes without holding their raw data.
• Example: A decentralized application (dApp) requiring proof of age or a financial institution verifying KYC credentials.

A trusted organization or entity that creates and signs Verifiable Credentials and issues them to Holders. The Issuer's digital signature is the foundation of trust for the entire credential.

• Authority: Acts as the authoritative source for specific claims (e.g., a DMV for driver's licenses).
• On-Chain Role: May publish a DID and credential schema to a blockchain to enable decentralized verification.

A privacy-preserving feature that allows a Holder to reveal only specific claims from a credential or prove a predicate (e.g., 'age > 21') without exposing the underlying data. This is a core capability enabled by the response to a Proof Request.

• Mechanisms: Achieved through zero-knowledge proofs or BBS+ signatures.
• Benefit: Minimizes data exposure and enhances user privacy.