Credential Lifecycle

The process where an issuer (e.g., a university) cryptographically signs a claim about a subject (e.g., a graduate) to create a Verifiable Credential (VC). This involves binding the credential to the subject's Decentralized Identifier (DID) and publishing the associated public key to a verifiable data registry, such as a blockchain, for trust anchoring.

The subject stores their credentials in a secure, user-controlled digital wallet. This wallet acts as a custodian for private keys and credentials, enabling selective disclosure. Storage models include:

• Local/Edge Storage: Credentials stored on the user's device.
• Cloud Backup: Encrypted backups with user-controlled keys.
• Custodial Wallets: Managed by a third-party service, offering convenience but less user sovereignty.

The act where a holder presents proof to a verifier. This involves creating a Verifiable Presentation (VP), which is a wrapper for one or more VCs, often with selective disclosure to minimize data shared. The verifier checks the cryptographic signatures, ensures the issuer's DID is resolved and trusted, and confirms the credential status (e.g., not revoked) without contacting the issuer directly.

Mechanisms for an issuer to invalidate a credential before its expiration. Common status tracking methods include:

• Revocation Registries: A cryptographically secure list (e.g., a revocation bitmap) published by the issuer.
• Status Lists: Standardized IETF lists for compact status representation.
• Smart Contract Registries: On-chain contracts that map credential IDs to a revocation status, enabling permissionless verification.

A core privacy feature allowing a holder to prove specific claims from a credential without revealing the entire document. Techniques include:

• BBS+ Signatures: Enable proving predicates (e.g., 'age > 21') without revealing the exact birth date.
• Zero-Knowledge Proofs (ZKPs): Generate cryptographic proofs that statements are true without revealing underlying data.
• JSON Web Token (JWT) VC: Can embed disclosed claims directly in the presentation.

Protocols and data models that enable credentials to work across different systems and organizations. Key standards include:

• W3C Verifiable Credentials Data Model: The foundational specification for VCs and VPs.
• Decentralized Identifiers (DIDs): Standardized resolvers for issuer public keys.
• Credential Formats: Such as JSON-LD with Linked Data Proofs and JWT-based VCs.
• Presentation Exchange (PE): A protocol for defining what credentials a verifier requests.

A hospital issues a verifiable credential for a patient's vaccination record. The patient stores it in their personal health wallet. The lifecycle facilitates:

• Consent-Driven Sharing: Patient presents the credential to a pharmacy when traveling.
• Interoperability: Credentials from different providers (lab, GP, specialist) are aggregated in one wallet.
• Emergency Access: First responders can request and verify critical health data with patient consent, using privacy-preserving proofs.

This critical phase of the lifecycle manages security incidents. If a user's digital wallet device is lost or stolen, the issuer can update the revocation registry (e.g., a blockchain state change or a signed revocation list). Subsequent verification requests will fail for any presentation attempt using the compromised credentials. This mechanism is essential for maintaining system trust without requiring the re-issuance of all credentials for every user.

The process where an issuer (e.g., a university, government, or DAO) cryptographically signs and creates a Verifiable Credential (VC) for a holder. This involves binding a set of claims (like a degree or membership) to the holder's Decentralized Identifier (DID) and packaging it into a secure, tamper-evident data structure.

The act where a holder (user) presents a credential to a verifier (e.g., a dApp or employer). The verifier checks the cryptographic proof (signature), ensures the credential hasn't been revoked, and confirms the issuer's DID is trusted. This is often done via a Verifiable Presentation, which can contain selective disclosures.

Mechanisms to invalidate a credential before its natural expiration. Common methods include:

• Revocation Registries: A list of revoked credential IDs maintained by the issuer.
• Status Lists: W3C standard for compact status bitstrings.
• Smart Contract Registries: On-chain mappings that record revocation status, enabling decentralized checks. This ensures verifiers can trust the ongoing validity of presented claims.

How holders securely store and manage their credentials. Models include:

• Digital Wallets: User-controlled apps (mobile or browser-based) that store private keys and VCs.
• Cloud Agents: Managed services that hold credentials on behalf of the user.
• On-Chain Attestations: For public, non-private claims, credentials can be written directly to a blockchain (e.g., Ethereum Attestation Service). Security centers on holder control and portability.

The technical specifications that ensure interoperability across the lifecycle:

• W3C Verifiable Credentials Data Model: The core data model and proof formats.
• Decentralized Identifiers (DIDs): The standard for issuer and holder identifiers.
• JSON Web Tokens (JWT) & JSON-LD Signatures: Common proof formats for VCs.
• BBS+ Signatures: Enable selective disclosure, allowing users to prove specific claims without revealing the entire credential.

Practical implementations of the credential lifecycle:

• DeFi: Proof-of-personhood (e.g., World ID) for sybil-resistant airdrops.
• DAO Governance: Verifiable membership credentials for voting.
• Professional Credentials: On-chain attestations of skills or employment history.
• Supply Chain: Verifiable certificates of origin or compliance for goods.

The initial phase where a credential's cryptographic link to its holder is established. Security hinges on the issuer's authority and the binding mechanism (e.g., a digital signature to a holder's Decentralized Identifier). A weak binding allows credential theft or impersonation. Privacy risks emerge if the issuance process leaks metadata about the holder's interaction with the issuer.

This phase concerns how holders store their credentials, typically in a digital wallet. Security risks include:

• Private Key Compromise: Loss of the signing key controlling the wallet leads to total credential loss.
• Wallet Vulnerabilities: Bugs or exploits in wallet software.
• Cloud Backup Risks: Storing encrypted backups in centralized services creates a single point of failure. The core privacy principle is holder sovereignty—the issuer should not have ongoing access to stored credentials.

A critical privacy-preserving technique allowing holders to prove specific claims from a credential without revealing the entire document. This is achieved using Zero-Knowledge Proofs (ZKPs).

• Example: Proving you are over 21 from a driver's license without revealing your birth date or address.
• Security Impact: Reduces the attack surface by minimizing exposed data but requires complex, audited cryptographic implementations to remain sound.

When a holder presents a credential to a verifier. Security risks include:

• Replay Attacks: A verifier reusing a presented proof.
• Man-in-the-Middle Attacks: Interception of the credential data in transit.
• Verifier Malware: Compromised verifier software stealing credentials. Privacy risks involve correlation—if a verifier can link multiple presentations back to the same anonymous identity, it can build a profile of the holder's activities.

The mechanism for invalidating a credential before its natural expiration. Common methods have trade-offs:

• Revocation Lists: Simple but reveal which specific credentials were revoked, potentially leaking holder activity.
• Accumulators & ZKPs: Privacy-preserving (e.g., proving a credential is not on a list without revealing which one), but computationally complex.
• Status Registries: Centralized registries create availability risks and can become tracking points if poorly designed.

The ongoing process of securing and, if lost, recovering the cryptographic keys that control credentials. This is the most common point of failure.

• Social Recovery: Using a group of trusted contacts to restore access, balancing security and usability.
• Multi-Party Computation (MPC): Splitting key material across devices or parties to avoid a single point of compromise.
• Hardware Security Modules (HSMs): Physical devices providing tamper-resistant key storage, essential for high-value credentials.

A Credential Schema defines the structure, data types, and semantic meaning of the claims within a Verifiable Credential. It acts as a blueprint for issuance and ensures interoperability during verification. Key aspects include:

• Standardized Data Fields: Ensures all issuers and verifiers interpret attributes (e.g., degreeType, issueDate) consistently.
• Schema Registry: Often published to a decentralized or trusted registry (like a blockchain) to provide a persistent reference.
• Versioning: Allows schemas to evolve while maintaining backward compatibility for existing credentials.

A Verifiable Presentation is a package of one or more Verifiable Credentials, bundled and presented by a holder to a verifier. Presentation Exchange is the protocol governing this interaction, which involves:

• Presentation Request: The verifier specifies the required credentials and constraints (e.g., "Prove you are over 21").
• Selective Disclosure: The holder can choose which credentials to share and may use zero-knowledge proofs to reveal only specific claims without exposing the entire credential.
• Proof Generation: The holder creates a new cryptographic proof binding the presentation to the request.

A Revocation Registry is a mechanism for an issuer to invalidate a credential before its natural expiration. It is a critical component for managing the revocation phase of the lifecycle. Common implementations include:

• Accumulator-based (e.g., CL Signatures): The issuer maintains a cryptographic accumulator; a valid credential must prove non-membership in the revocation set.
• Status List (e.g., W3C Status List 2021): The issuer publishes a bitstring on a ledger, where each bit corresponds to a credential's revocation status.
• Smart Contract Registries: On-chain contracts that maintain a mapping of credential IDs to their current status.

The Holder is the entity (person or organization) that receives, stores, and controls the use of their Verifiable Credentials. A Digital Wallet (or Identity Wallet) is the software agent that enables this control, providing:

• Secure Storage: Encrypted custody of private keys and credential data.
• User Agency: Interfaces for consenting to credential issuance and constructing presentations.
• Interoperability: Adherence to standards (like OpenID for Verifiable Credentials) to communicate with issuers and verifiers across ecosystems.