Credential Hub

A credential hub facilitates the creation of verifiable credentials by authorized issuers and stores them in a user-controlled manner, typically using decentralized storage networks like IPFS or Arweave. This ensures data provenance is cryptographically verifiable and resistant to single points of failure.

• Issuers (e.g., protocols, DAOs) sign claims about a user's identity or history.
• Holders maintain custody of their credentials, often in a digital wallet.
• Storage is off-chain for efficiency, with on-chain cryptographic commitments (like hashes) for verification.

The hub provides a framework for defining and executing verification rules. Applications (verifiers) can query the hub to check if a user's credentials satisfy specific conditions without accessing the raw data.

• Example: A lending protocol can request proof that a user's wallet has >100 days of governance token ownership without seeing the full transaction history.
• This is enabled through zero-knowledge proofs (ZKPs) or selective disclosure mechanisms, preserving user privacy.
• Rules are often expressed as circuits or policy languages.

Users can aggregate multiple credentials from different sources into a single, composite proof of reputation or eligibility. This creates a portable, on-chain identity that is not siloed within a single application.

• Example: A user's Gitcoin Passport score, DAO contributor badge, and lending history can be combined to prove trustworthiness for a new protocol's whitelist.
• Aggregation reduces redundancy and lowers the barrier for users to access new services.
• Portability is a core tenet of self-sovereign identity (SSI).

Credential hubs rely on and promote open standards to ensure credentials are understood across different ecosystems. Key standards include:

• W3C Verifiable Credentials (VCs): A data model for expressing cryptographically verifiable claims.
• Decentralized Identifiers (DIDs): A standard for creating self-owned, verifiable identifiers.
• EIP-712: A standard for typed structured data signing in Ethereum, often used for credential signatures.
• Adherence to these standards prevents vendor lock-in and enables cross-chain and cross-protocol credential use.

A core feature is enabling verification without exposing underlying data. This is achieved through cryptographic techniques that allow users to prove statements about their credentials.

• Zero-Knowledge Proofs (ZKPs): Prove you satisfy a condition (e.g., "age > 18") without revealing your birth date.
• Selective Disclosure: Reveal only specific attributes from a credential.
• Blind Signatures: Allow an issuer to sign a credential without seeing its contents, enhancing privacy during issuance.
• These mechanisms are critical for compliance with regulations like GDPR while maintaining utility.

Credential hubs provide mechanisms to invalidate credentials that are no longer valid, such as expired memberships or compromised attestations. This maintains the integrity of the system.

• Revocation Registries: On-chain or decentralized lists where issuers can post identifiers of revoked credentials.
• Status Lists: A W3C standard for managing credential status.
• Time-Locked Credentials: Credentials can be issued with a built-in expiry timestamp, after which they are automatically considered invalid.
• Verifiers must check revocation status as part of the verification process.

A Decentralized Identifier (DID) is a globally unique, cryptographically verifiable identifier that is controlled by the user, not a centralized registry. It forms the foundation of self-sovereign identity in a Credential Hub.

• User Control: DIDs are anchored on a blockchain or distributed ledger, but the private keys controlling them are held solely by the user.
• Verifiability: Any party can cryptographically verify proofs signed by a DID without needing to contact the issuing authority.
• Example: did:ethr:0xab32...1c is a DID anchored on the Ethereum blockchain, controlled by the holder's private key.

A Verifiable Credential (VC) is a tamper-evident digital claim, such as a passport or university degree, issued by a trusted entity and cryptographically signed. It is presented as a JSON Web Token (JWT) or JSON-LD document.

• Tamper-Proof: Uses digital signatures (e.g., EdDSA, ECDSA) to ensure the credential's integrity and authenticity.
• Selective Disclosure: Users can prove specific attributes (e.g., age > 21) without revealing the entire credential using zero-knowledge proofs (ZKPs).
• Standardization: Governed by the W3C Verifiable Credentials Data Model, ensuring interoperability across different systems.

Zero-Knowledge Proofs (ZKPs) are cryptographic protocols that allow a user (the prover) to prove a statement is true to a verifier without revealing any underlying data. This is critical for privacy-preserving verification in Credential Hubs.

• Privacy-Preserving: Enables selective disclosure and predicate proofs (e.g., proving you are over 18 without revealing your birth date).
• Use Case: A user can generate a ZKP from their driver's license VC to prove they have a valid license from a specific state, without revealing the license number or address.
• Common Schemes: zk-SNARKs and zk-STARKs are advanced ZKP systems used for complex credential logic.

Managing the lifecycle of a Verifiable Credential, especially revocation, is a critical security function. Credential Hubs use decentralized methods to check if a credential is still valid.

• Revocation Registries: Issuers maintain a revocation registry (often a smart contract or a verifiable data registry) where revoked credential IDs are listed.
• Status List 2021: A W3C-standardized method where credential status is encoded in a bitstring within a VC itself, allowing for offline-verifiable status checks.
• Challenge: Balancing privacy (avoiding correlation) with the need for issuers to revoke compromised credentials.

Holder binding ensures that the person presenting a Verifiable Credential is its legitimate owner. This prevents credential theft and replay attacks during the verification process.

• Challenge-Response: The verifier sends a cryptographically random nonce that the holder must sign with their DID's private key when presenting the VC.
• Verifiable Presentation: The holder creates a Verifiable Presentation—a wrapper that contains one or more VCs and a proof of holder binding.
• Security Guarantee: This process proves the presenter controls the private keys associated with the DIDs in the presented credentials.

Secure key management is the cornerstone of a Credential Hub's security. Users must safely generate, store, and use the private keys controlling their DIDs.

• Custody Models: Ranges from self-custody (user-managed wallets) to distributed custody (multi-party computation/MPC wallets) and custodial services.
• Recovery: Systems like social recovery or shamir's secret sharing are used to recover access without a single point of failure.
• Hardware Security: Integration with Hardware Security Modules (HSMs) and secure enclaves (e.g., Apple Secure Enclave) provides high-assurance key storage.

An Identity Wallet is a user-controlled application (mobile or desktop) that stores private keys, manages DIDs, and holds Verifiable Credentials. It is the primary user interface for interacting with a Credential Hub.

• Core Functions: Securely stores credentials, presents proofs to verifiers, and manages consent for data sharing.
• Architecture: Often connects to a backend Credential Hub for sync and backup, but the private keys never leave the user's device.
• Examples: Open-source wallets like Trinsic, Veramo, or Serto.

A Zero-Knowledge Proof is a cryptographic method that allows one party (the prover) to prove to another (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself. This is critical for privacy-preserving credential presentations.

• Use in Credentials: Enables proving you are over 21 from a credential without revealing your birth date.
• Technology: Implementations like zk-SNARKs or zk-STARKs are used to generate succinct proofs.
• Impact: Shifts verification from seeing raw data to verifying a cryptographic proof, enhancing user privacy.

A Credential Schema defines the structure and data fields of a Verifiable Credential (e.g., which fields are in a driver's license). An Issuer Registry is a trusted, often on-chain, list of authorized credential issuers.

• Schema Purpose: Ensures interoperability so verifiers understand the data format.
• Registry Purpose: Allows verifiers to check if a credential was issued by a trusted entity, preventing fraud.
• Implementation: Schemas can be published on IPFS or a blockchain. Registries are often implemented as smart contracts or decentralized ledgers.

Selective Disclosure is the ability to reveal only specific, necessary claims from a credential. A Verifiable Presentation is the packaged data (often one or more proofs) sent to a verifier in response to a query.

• Process: A user's wallet, instructed by the Credential Hub, creates a presentation containing only the required ZK proofs or revealed claims.
• Standard: Governed by the W3C Verifiable Presentation specification.
• Example: Proving you have a valid, non-expired professional license from a specific board, without showing your license number or issuance date.