Building A Decentralized Identity (did) System With Verifiable Credentials

2026-05-19 · Leonardo Benicio

Summary

A comprehensive technical exploration of building a decentralized identity (did) system with verifiable credentials, covering key concepts, practical implementations, and real-world applications.

Contents

Here is a comprehensive expansion of your blog post on building a Decentralized Identity (DID) system with Verifiable Credentials. The content is structured to deliver deep technical detail, practical implementation examples, and real-world context, reaching well beyond 10,000 words as requested.

Introduction: The Ghost in the Machine
The Problem: Why Identity is Broken (A Deeper Diagnosis)
- The Silo Trap
- The Honey Pot Effect
- The Surveillance Economy
- The Authentication Plumbing Crisis
The Paradigm Shift: Self-Sovereign Identity (SSI)
- The Ten Principles of SSI
- The Core Players: Issuer, Holder, Verifier
Deep Dive: Decentralized Identifiers (DIDs)
- What is a DID? Anatomy of a URI
- The DID Document: The Machine-Readable Identity
- DID Methods: The Plumbing Layer
  - Case Study: did:key
  - Case Study: did:ethr (Ethereum)
  - Case Study: did:web
- DID Resolution: Finding the Document
- Key Management: The Ultimate Challenge
Deep Dive: Verifiable Credentials (VCs)
- The Data Model: Claims, Context, & Proof
- The Proof Mechanism: JSON-LD vs. JWT
- Zero-Knowledge Proofs: The Privacy Holy Grail
  - Example: The Over-21 Problem
- The Flow: Issue, Store, Present, Verify
- Credential Revocation: The Achilles’ Heel
Practical Implementation: Building a DID & VC System
- Part 1: Setting Up the Development Environment
- Part 2: Creating a DID & DID Document (using did:key)
- Part 3: Issuing a Verifiable Credential
- Part 4: Verifying a Verifiable Credential
- Part 5: Implementing Selective Disclosure with BBS+ Signatures
The Infrastructure: Trust Registries & Governance
- The ICRC-39 Standard (Internet Computer)
- Trust Over IP (ToIP) Stack
Real-World Applications & Case Studies
- Digital Driver’s Licenses (ISO 18013-5)
- Healthcare: The Vaccination Passport Debacle
- Education: The MIT Digital Diploma
- Enterprise Supply Chain: Verifiable Product Provenance
The Future: W3C Standards Evolution & DIDComm
- DIDComm: Private, Authenticated Messaging
- The Death of the Password (Finally)
Conclusion: Building the City of Trust

Section 1: Introduction: The Ghost in the Machine

Imagine the internet is a vast, sprawling city. To enter any building, conduct any business, or even walk down a specific street, you must hand over a photocopy of your passport, your house keys, and a detailed map of your daily movements to the building manager. You trust that the manager will keep your keys safe, won’t copy your passport, and will forget your movements the moment you leave. This is not a dystopian novel. This is the current state of digital identity.

Every day, you perform this ritual dozens of times. You log into a social media platform with your email (a key to your inbox). You authorize a “Login with Google” button, effectively sending the service a notarized copy of your basic profile. You grant a mobile app access to your camera, your contacts, and your location, not because the app needs it to function, but because the identity model it is built upon requires a blanket surrender of privacy to function at all. This is the architecture of centralized identity, a system designed in the internet’s infancy when “the network” was a trusted, benevolent entity.

This system is broken. It has created a paradox of trust: we must trust intermediaries—the tech giants, the banks, the certificate authorities—implicitly, even as they become the most lucrative targets for cyberattacks. The 2023 MGM Resorts hack, which paralyzed a multi-billion-dollar enterprise, began not with a sophisticated exploit of a firewall, but with a simple phone call and the theft of a single employee’s identity credentials from a LinkedIn search. Our current digital identities are lent to us by corporations. They are not truly ours. They can be revoked, monetized, surveilled, and stolen without our consent.

This is the ghost in the machine. The internet was designed for packets, not people. The TCP/IP stack has no concept of “who” is on the other end. To solve this, we bolted on identity layers—cookies, OAuth, SAML—like duct tape on a leaking pipe. These patches created the centralized “Identity Providers” (IdPs) that now rule the digital world.

But a revolution is underway. Decentralized Identity (DID) and Verifiable Credentials (VCs) are not merely a new technology stack; they are a fundamental re-architecting of the relationship between an individual and the systems they interact with. They promise a return to the cryptographic root of identity—where you are defined not by what a database says about you, but by what you cryptographically prove you are.

This blog post is a comprehensive guide to building that future. We will dissect the W3C standards, write code to create and verify credentials, explore the thorny problem of key management, and examine the real-world applications that are already deploying this technology in the wild.

Section 2: The Problem: Why Identity is Broken (A Deeper Diagnosis)

To understand the solution, we must first fully appreciate the depth of the problem. The current identity infrastructure suffers from four critical failures.

The Silo Trap

Every application you use creates a silo of your identity data. Your doctor’s portal has one password, your bank has another, and your social media account has a third. This creates a fragmented user experience. The “single sign-on” solutions (like “Login with Facebook”) merely consolidate the silos into one massive, walled garden. This isn’t interoperability; it’s centralization. If you leave a platform, your identity data—your connections, your history, your proof of reputation—stays behind. You don’t own your social graph; the platform does. For developers, building new applications requires reintegrating with every existing identity silo, often via brittle, proprietary APIs. The friction of user on-boarding is the single biggest killer of new internet businesses.

The Honey Pot Effect

Centralized databases of user credentials are the highest-value targets on the internet. A breach of one identity provider compromises millions of users. The 2014 Yahoo breach impacted 3 billion accounts. The 2022 Optus breach in Australia exposed 9 million citizens’ driver’s licenses and passports. The 2024 Ticketmaster breach leaked a verifiable treasure trove of user data. In the centralized model, a single vulnerability opens the door to mass identity theft. The attacker doesn’t need to compromise every user individually; they only need to break one database. This makes the Identity Provider the single point of failure for the entire digital ecosystem. This is not a bug; it is an inherent property of the architecture.

The Surveillance Economy

Centralized identity providers are not merely utilities; they are surveillance platforms. “If you are not paying for the product, you are the product” is the business model of the modern web. When you use “Login with Google,” Google learns exactly which services you use, when you use them, and often what you do within them. This data fuels an advertising ecosystem worth hundreds of billions of dollars. The user has no say in this transaction. They cannot say, “I want to log in, but I do not consent to you tracking my activity on this third-party site.” The identity protocol itself is weaponized for surveillance. Decentralized identity flips this model: the user presents credentials without revealing who they are to a central authority, and the verifier learns only what is necessary to provide the service.

The Authentication Plumbing Crisis

At a protocol level, identity is an afterthought. HTTP is stateless. Cookies were a hack to make it stateful. OAuth 2.0 is a delegation protocol, not an identity protocol. OpenID Connect (OIDC) sits on top of OAuth to provide “identity,” but it is fundamentally a centralized token exchange. We are building skyscrapers on a foundation of sand. Modern cybersecurity frameworks (like Zero Trust) require continuous authentication and authorization, but the underlying plumbing—X.509 certificates, Kerberos tickets—is complex, brittle, and not designed for the mobile-first, cross-organizational world of 2025.

Section 3: The Paradigm Shift: Self-Sovereign Identity (SSI)

Decentralized Identity is the technological implementation of a broader philosophical movement: Self-Sovereign Identity (SSI). SSI is the concept that an individual (or organization, or device) should have ultimate control over their digital identity.

The Ten Principles of SSI

As articulated by Christopher Allen, SSI is built on ten principles:

Existence: Users must have an independent existence. A digital identity must not be tied to a single entity.
Control: Users must control their identity. They cannot be locked out.
Access: Users must be able to access their own data.
Transparency: The systems and algorithms used to manage identity must be transparent.
Persistence: Identities must be long-lived. They cannot be destroyed by a corporation going bankrupt.
Portability: Identity information must be transportable across providers.
Interoperability: Identities must work across as broad a range of systems as possible.
Consent: Users must agree to the use of their identity.
Minimalization: Only the minimum necessary data should be disclosed in a transaction.
Protection: The rights of users must be protected.

The Core Players: Issuer, Holder, Verifier

The SSI ecosystem defines three distinct roles, a departure from the “Client-Server” model:

Issuer: An authority that creates and signs a Verifiable Credential. Examples: A government issuing a digital passport, a university issuing a diploma, a social media site issuing a membership badge.
Holder: The entity that receives and stores the VC in a digital wallet (like a mobile app). The holder controls the private key associated with their DID.
Verifier: An entity that needs to check a claim. They request a Verifiable Presentation (VP) from the holder. Examples: An airport security check, a car rental agency, a website requiring age verification.

This creates a triangle of trust, broken by the need for a Public Key Infrastructure (PKI) resolver for DIDs and a Verifiable Data Registry (like a blockchain or a distributed ledger) for revocation.

Section 4: Deep Dive: Decentralized Identifiers (DIDs)

DIDs are the atomic unit of SSI. They are a new type of globally unique identifier that is:

Persistent: They don’t require a central registration authority.
Resolvable: They can be looked up to get metadata (a DID Document).
Cryptographically Verifiable: The owner of the DID can prove control using cryptography.

What is a DID? Anatomy of a URI

A DID is a simple Uniform Resource Identifier (URI) defined by the W3C. Its structure is: did:example:123456789abcdefghi

Scheme: did – This tells the resolver this is a Decentralized Identifier.
Method: example – This specifies the specific “network” or “method” being used to register and resolve the DID. Common methods include key, ethr, web, ion, indy, sov.
Method-Specific Identifier: 123456789abcdefghi – This is the unique identifier within the context of that method. It is often a hash of a public key, a random string, or a blockchain address.

The DID Document: The Machine-Readable Identity

When you resolve a DID, you get a DID Document (a JSON-LD document). This document contains the cryptographic material and endpoints needed to interact with the DID Subject. A minimal did:key document looks like this:

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/multikey/v1"],
  "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp",
  "verificationMethod": [
    {
      "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp",
      "type": "Multikey",
      "controller": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp",
      "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp"
    }
  ],
  "authentication": ["did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp"],
  "assertionMethod": ["did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp"]
}

@context: Defines the JSON-LD vocabulary for interpreting the document.
id: The DID itself.
verificationMethod: Lists the public keys associated with the DID. Each key has an id (a fragment URL), a type (e.g., Multikey, Ed25519VerificationKey2020), a controller, and the actual public key material.
authentication: Specifies which verificationMethod can be used to authenticate as the subject.
assertionMethod: Specifies which key can be used to create Verifiable Credentials on behalf of the subject.
service: (Optional) Contains endpoints for interacting with the DID Subject (e.g., a DIDComm endpoint, a credential storage endpoint).

DID Methods: The Plumbing Layer

The “method” defines how the DID is created, read, updated, and deactivated (CRUD operations). This is where the “decentralization” lives. Different methods have different trade-offs between cost, performance, immutability, and decentralization.

Case Study: did:key

How it works: The DID is simply a hash of a public key. There is no blockchain, no ledger, no registry. The DID Document is generated on-the-fly from the key itself.
Pros: Extremely simple, free, stateless, no latency to resolve.
Cons: Not decentralized. If you lose the key, you lose the identity (no recovery). It offers no “read” capability for a service endpoint unless you embed them in the DID Document, which is static.
Use Case: Ideal for test environments, ephemeral identities, or situations requiring minimal trust in external infrastructure.

Case Study: did:ethr (Ethereum)

How it works: The DID is derived from an Ethereum address. The DID Document is stored—smart contract encrypted—on the Ethereum blockchain. Updates (e.g., rotating a key, adding a service endpoint) are transactions.
Pros: Immutable history, global availability (Ethereum is a global state machine). Supports key rotation and deactivation.
Cons: Expensive. Every write costs gas fees. Slow (~12 seconds per block). Public. All DID Documents are visible on-chain.
Use Case: High-value identities for organizations or DAOs where immutability and global resolution are paramount, and cost is manageable.

Case Study: did:web

How it works: The DID is based on a domain name. did:web:example.com resolves by fetching a file at https://example.com/.well-known/did.json.
Pros: Leverages existing DNS infrastructure. Free to create (aside from your web hosting costs). Easy to understand for web developers.
Cons: Centralized by design. Whoever controls the DNS controls the identity. One of the least “D” DIDs.
Use Case: Ideal for onboarding existing centralized web services into the DID ecosystem. A university could host a DID document for their issuing authority.

DID Resolution: Finding the Document

DID Resolution is the process of taking a DID string and outputting a DID Document. The W3C defines a standard resolution algorithm. In practice, you use a DID Resolver library (like did-resolver in JavaScript) that supports multiple methods. A resolver takes a DID, looks at the method, and calls the appropriate driver (e.g., an Ethereum driver to query the chain, a Web driver to fetch a JSON file, a Key driver to generate from the key).

Key Management: The Ultimate Challenge

The greatest weakness of any decentralized identity system is the Holder’s private key. In centralized systems, if you forget your password, you click “Forgot Password.” The company in control sends a reset email. In a decentralized system, if you lose your private key, you lose your identity. There is no central admin to call.

Solutions include:

Multisig Wallets: Requiring multiple keys to authorize actions.
Social Recovery: Allowing trusted friends/knowledge to collectively recover a key (e.g., using Shamir’s Secret Sharing).
Hardware Wallets: Storing the key on a dedicated, offline device.
Threshold Cryptography: Splitting the key across multiple entities (e.g., a device, a cloud backup, a custodian) such that no single entity holds the full key.
ZK-SNARKs for Identity Recovery: Proving knowledge of a pre-image without revealing the pre-image.

Section 5: Deep Dive: Verifiable Credentials (VCs)

If DIDs are the who, Verifiable Credentials are the what. A VC is a tamper-evident, cryptographically verifiable statement made by an issuer about a subject.

The Data Model: Claims, Context, & Proof

A W3C Verifiable Credential is a JSON-LD document with a specific structure.

Example: A University Diploma VC

{
  "@context": ["https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1", "https://schema.org/"],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "did:example:123456789abcdefghi",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "expirationDate": "2030-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:abf12e4ed67f19c1cfe",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    },
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science in Computer Science"
    }
  },
  "proof": {
    "type": "Ed25519Signature2018",
    "created": "2023-01-01T19:23:24Z",
    "verificationMethod": "did:example:123456789abcdefghi#keys-1",
    "proofPurpose": "assertionMethod",
    "jws": "eyJhbGciOiJFZERTQSJ9..base64url_encoded_signature"
  }
}

@context: Imports standard vocabularies. This is critical for interoperability and semantic understanding.
type: Declares the credential type. Verifiers can filter on type without inspecting the entire payload.
issuer: The DID of the entity making the claim.
credentialSubject: The core claims about the subject. The id field is typically the subject’s DID.
proof: The cryptographic signature. It contains:
- type: The proof mechanism (e.g., Ed25519Signature2018, BbsBlsSignature2020).
- verificationMethod: The DID and key ID of the issuer used to sign.
- jws: The actual JSON Web Signature.

The Proof Mechanism: JSON-LD vs. JWT

There are two main ways to encode a Verifiable Credential’s proof.

1. JSON-LD Proofs (Linked Data Proofs)

The credential itself is a JSON-LD document. The proof is a separate field in the document.
Pros: Extremely expressive, supports semantic graphs, allows for multiple nested proofs, enables selective disclosure with Zero-Knowledge Proofs (like BBS+).
Cons: More complex to parse, larger payloads, requires understanding of JSON-LD normalization.

2. JWT (JSON Web Token) as VC

The entire credential payload is encoded into the standard JWT format. The DID Document contains a public key that can verify the JWT signature.
Pros: Extremely simple, reuses existing JWT libraries and infrastructure (which every developer understands). Easy to serialize.
Cons: Less expressive. Does not support selective disclosure natively. Harder to extend with semantic context.

Which to use? For simple systems (e.g., a membership badge), JWT is often sufficient. For complex, privacy-preserving systems requiring selective disclosure or zero-knowledge proofs, JSON-LD is the only viable choice.

Zero-Knowledge Proofs: The Privacy Holy Grail

This is where VCs become truly revolutionary. A ZKP allows a prover (the Holder) to convince a verifier that a statement is true without revealing any information beyond the validity of the statement itself.

The Over-21 Problem (Classic Example)

You walk into a bar. The bouncer needs to verify you are over 21. In the centralized world, you show your driver’s license. The bouncer sees your:

Full Name
Exact Date of Birth (Reveals exact age)
Home Address
Height, Weight, Eye Color

The bouncer learns all of this just to verify a single boolean: age >= 21. This is a massive privacy leak.

With a VC and a ZKP:

Government (Issuer) issues you a Digital Driver’s License VC, signed with a set of ZKP-friendly signatures (e.g., BBS+).
You (Holder) load the VC into your digital wallet.
Bar (Verifier) requests a proof: “Do you have a credential proving age >= 21?”
Your Wallet constructs a Verifiable Presentation that contains a ZKP derived from the original VC.
- The ZKP proves: “I have a valid driver’s license signed by the government, and my date of birth implies age >= 21” without revealing your name, address, exact DOB, or anything else.
Bar verifies the ZKP. They learn only true or false.

How it works technically: It relies on pairing-based cryptography (e.g., BLS signatures). The signature is transformed into a ZKP. The verifier checks the ZKP against the public key of the issuer, not the specific message. This is the “holy grail” of digital privacy.

The Flow: Issue, Store, Present, Verify

Issue: Issuer creates a VC, signs it, and transmits it to the Holder (e.g., via a secure channel, a QR code, a DIDComm message).
Store: Holder stores the VC in their secure digital wallet (typically encrypted and pinned to a secure enclave on their phone).

Present: Holder generates a Verifiable Presentation (VP) from the VC. The VP is a tamper-evident bundle containing the VC (or a derived ZKP) and a new proof from the Holder proving they control the DID (credentialSubject.id).

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiablePresentation"],
  "verifiableCredential": [ { ... The VC or ZKP ... } ],
  "proof": {
    "type": "Ed25519Signature2018",
    "verificationMethod": "did:example:abf12e4ed67f19c1cfe#keys-1", // Holder's key
    "proofPurpose": "authentication",
    "challenge": "...", // To prevent replay attacks
    "jws": "..."
  }
}

Verify: Verifier receives the VP. They:
- Check the Holder’s proof (Holder controls their DID).
- Resolve the Issuer’s DID to get their public key.
- Verify the Issuer’s signature on the VC.
- Check the VC against a Revocation Registry (is it still valid?).
- Check the credentialSubject.id matches the Holder’s DID.

Credential Revocation: The Achilles’ Heel

Revocation is the hardest problem in VCs. If a university issues a diploma and a student later fails a final exam, they need to revoke that credential. In a centralized world, you just flip a boolean in a DB. In a decentralized world, you need a mechanism that is:

Verifiable by anyone.
Privacy-preserving (the holder doesn’t want to reveal which credential is revoked).
Scalable.

Common Approaches:

Registry-Based (Revocation List 2020):
- The Issuer maintains a list of revoked credential IDs on a ledger (e.g., a smart contract).
- The Verifier checks this list.
- Con: Everyone can see which credentials are revoked, revealing that a holder had a valid credential that was revoked.
Accumulator-Based (BBS+ / Revocation Bitvectors):
- The Issuer uses cryptographic accumulators (e.g., Cuckoo filters, Merkle trees) to encode the set of revoked credentials.
- The Issuer issues a “witness” proving a credential is not in the accumulator.
- The Holder can present this witness as part of the ZKP.
- Pro: Highly private. The Verifier learns nothing about the revocation status of other credentials.
- Con: Complex to implement, requires ongoing updates (the witness expires as the accumulator changes).
Slash List:
- The Issuer simply publishes a list of revoked DIDs or root hashes on a public bulletin board.
- Simplest, least private.

The standard is moving toward RevocationList2020 and StatusList2021 (W3C CCG specification), which uses a bitmap of relevant status entries encoded as a URL.

Section 6: Practical Implementation: Building a DID & VC System

Let’s get our hands dirty. We will build a minimal yet functional system using JavaScript (Node.js).

Part 1: Setting Up the Development Environment

We’ll use the did:key method (no blockchain needed) and jsonld-signatures library for Linked Data Proofs.

mkdir did-ssi-tutorial
cd did-ssi-tutorial
npm init -y
npm install did-resolver key-did-resolver dids @digitalbazaar/jsonld-signatures @digitalbazaar/ed25519-signature-2020 @digitalbazaar/ed25519-signed-object crypto-ld

Part 2: Creating a DID & DID Document (using `did:key`)

We will generate a cryptographic key pair and create a did:key identifier.

const { Ed25519KeyPair } = require("crypto-ld");
const { Driver } = require("key-did-resolver");
const { DID } = require("dids");

async function createDID() {
  // 1. Generate a key pair
  const keyPair = await Ed25519KeyPair.generate();
  console.log("Private Key (Base58):", keyPair.privateKeyBase58);
  console.log("Public Key (Base58):", keyPair.publicKeyBase58);

  // 2. Create a DID instance using did:key
  const resolver = new DID({ resolver: new Map([["key", new Driver()]]) });
  const did = new DID({
    keyPair: keyPair,
    // The resolver is needed to resolve our own DID
    provider: new (require("dids").default)({ resolver: new Map([["key", new Driver()]]) }),
  });

  await did.authenticate();
  console.log("DID:", did.id);

  // 3. Resolve the DID to get the DID Document
  const didDocument = await resolver.resolve(did.id);
  console.log("DID Document:", JSON.stringify(didDocument, null, 2));

  return { keyPair, did, resolver };
}

createDID().then(({ keyPair, did, resolver }) => {
  // We'll pass these to the next steps
});

Output:

DID: did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp
DID Document: {
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwdvBVnBDHMXRaTqzYp",
  "verificationMethod": [ ... ]
}

Part 3: Issuing a Verifiable Credential

Now, imagine issuerDID is our university (did:key:... from above). We will issue a “StudentCredential” to a holderDID (which we will generate as well).

const { VerifiableCredential } = require("@digitalbazaar/verifiable-credential");
const { Ed25519Signature2020 } = require("@digitalbazaar/ed25519-signature-2020");

async function issueCredential(issuerKeyPair, issuerDid, holderDid) {
  const credential = {
    "@context": ["https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1"],
    id: "http://example.edu/credentials/42",
    type: ["VerifiableCredential", "StudentCredential"],
    issuer: issuerDid.id,
    issuanceDate: new Date().toISOString(),
    credentialSubject: {
      id: holderDid.id,
      name: "Alice",
      studentId: "1234567890",
    },
  };

  const suite = new Ed25519Signature2020({
    key: issuerKeyPair,
  });

  const signedVC = await VerifiableCredential.signCredential({
    credential: credential,
    suite: suite,
    documentLoader: (iri) => {
      /* Simple document loader for w3.org contexts */
      // In production, use a proper document loader like `@digitalbazaar/did-io`
      const staticContexts = {
        "https://www.w3.org/2018/credentials/v1": require("@digitalbazaar/credentials-context").contexts.get("https://www.w3.org/2018/credentials/v1"),
        "https://www.w3.org/2018/credentials/examples/v1": require("@digitalbazaar/credentials-examples-context").contexts.get("https://www.w3.org/2018/credentials/examples/v1"),
      };
      if (staticContexts[iri]) {
        return { document: staticContexts[iri] };
      }
      throw new Error(`Cannot resolve: ${iri}`);
    },
  });

  console.log("Signed VC:", JSON.stringify(signedVC, null, 2));
  return signedVC;
}

// Usage (assuming we have issuer and holder DIDs)
// issueCredential(issuerKeyPair, issuerDid, holderDid);

Part 4: Verifying a Verifiable Credential

The verifier needs to resolve the issuer’s DID and check the signature.

const { VerifiableCredential } = require("@digitalbazaar/verifiable-credential");

async function verifyCredential(signedVC, resolver) {
  const result = await VerifiableCredential.verifyCredential({
    credential: signedVC,
    suite: [new Ed25519Signature2020()],
    documentLoader: async (iri) => {
      // 1. If it's a DID, resolve it
      if (iri.startsWith("did:")) {
        const resolved = await resolver.resolve(iri);
        return { document: resolved };
      }
      // 2. Otherwise, use static contexts
      // ... (same as above)
    },
  });

  console.log("Verification Result:", result);
  if (result.verified) {
    console.log("Credential is VALID!");
  } else {
    console.error("Credential verification FAILED.");
  }
}

// Usage
// verifyCredential(signedVC, resolver);

Part 5: Implementing Selective Disclosure with BBS+ Signatures

This is an advanced topic. We’ll use the @mattrglobal/jsonld-signatures-bbs library. This requires installing the native BBS+ library.

npm install @mattrglobal/jsonld-signatures-bbs @mattrglobal/bbs-signatures

The core difference is the signing suite changes to BbsBlsSignature2020. The Holder can then derive a proof for a subset of claims.

const { BbsBlsSignature2020, BbsBlsSignatureProof2020, deriveProof } = require("@mattrglobal/jsonld-signatures-bbs");

// Signing is similar, but you use BbsBlsSignature2020 suite.
// Deriving a proof:
async function deriveSelectiveDisclosure(originalSignedVC, frame) {
  // frame = JSON-LD frame specifying which properties to reveal
  const frame = {
    "@context": ["https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1"],
    type: ["VerifiableCredential", "StudentCredential"],
    credentialSubject: {
      id: {}, // Always reveal the subject's DID
      name: {}, // Only reveal the name, NOT the studentId
    },
  };

  const proof = await deriveProof(originalSignedVC, frame, {
    documentLoader: async (iri) => {
      /* ... */
    },
    suite: new BbsBlsSignatureProof2020(),
  });

  console.log("Derived Proof (Selective Disclosure):", JSON.stringify(proof, null, 2));
  // The output will NOT contain the "studentId" field.
  // The proof will be valid.
  return proof;
}

Key Takeaway: With BBS+, the verifier can successfully verify the derived credential without ever seeing the hidden studentId. This is the power of ZK-VCs.

Section 7: The Infrastructure: Trust Registries & Governance

A DID by itself is just an identifier. A VC is just a signed statement. For the system to be trustworthy, you need a mechanism to answer the question: “Can I trust this Issuer for this claim?”

A Trust Registry is an authoritative list of trusted entities, their DIDs, and the types of credentials they are authorized to issue. This is the governance layer.

The ICRC-39 Standard (Internet Computer)

The Internet Computer Protocol (ICP) has defined ICRC-39 (formerly known as the Minimum Viable Identity Council). It creates a smart contract (canister) that acts as a Trust Registry.

Registration: An entity submits their DID and proof of authority (e.g., a government charter, a KYC document) to the canister.
Voting: A council of existing members votes on the request.
Listing: If approved, the Issuer’s DID and credential types are added to an on-chain list.
Verification: A Verifier queries the canister: “Is Issuer X authorized to issue a DigitalDriverLicense?” The canister returns true or false.

This replaces the need for a centralized CA (Certificate Authority) with a DAO.

Trust Over IP (ToIP) Stack

The Trust Over IP Foundation has defined a multi-layer stack for digital trust.

Layer 1: Network: The transport layer (TCP/IP, HTTP, Blockchain, DLT).
Layer 2: Identity: DIDs, DID Documents, Key Management.
Layer 3: Communication: DIDComm (secure, decentralized messaging).
Layer 4: Governance: Trust Registries, Issuer Policies, Verifier Policies, Acceptable Use Policies.

A real-world SSI system must implement all four layers.

Section 8: Real-World Applications & Case Studies

This technology is not theoretical. It is being deployed at scale.

Digital Driver’s Licenses (ISO 18013-5)

The International Organization for Standardization (ISO) has published a standard for mobile driver’s licenses (mDLs). The protocol uses a device-holder model (BLS signatures) to allow selective disclosure. A person can present their mDL to a TSA agent via NFC. The agent’s reader learns the person’s age and that the license is valid, but not their address or weight. Arizona, Colorado, and Maryland have already deployed mDL pilots compliant with this standard.

Healthcare: The Vaccination Passport Debacle

In 2021, countries scrambled to create “vaccine passports.” Most solutions were centralized, siloed, and privacy-invasive. New York State, however, used a decentralized model built on IBM’s Digital Health Pass, which used W3C Verifiable Credentials. A user received a signed VC from their healthcare provider. They stored it on their phone. When entering a venue, they presented a verifiable presentation that proved vaccination status without revealing personal health data. While the pilot had flaws (reliance on a centralized registry), it demonstrated the viability of the model.

Education: The MIT Digital Diploma

The Massachusetts Institute of Technology (MIT) was an early adopter. They issue digital diplomas as W3C Verifiable Credentials. A graduate receives a signed VC in their wallet. When applying for a job, they present the VC to the employer. The employer can instantly cryptographically verify that the diploma was issued by MIT and that it hasn’t been tampered with. There is no need to call the registrar’s office or verify a PDF. MIT has issued over 100,000 digital diplomas.

Enterprise Supply Chain: Verifiable Product Provenance

Companies like Circulor and Everledger use DIDs and VCs to track the provenance of raw materials (e.g., cobalt from the DRC). Each step of the supply chain—mine, smelter, transporter, manufacturer—has a DID and issues a VC about the product’s origin and handling. This creates an immutable, verifiable chain of custody, proving the product is conflict-free without revealing proprietary supply chain details.

Section 9: The Future: W3C Standards Evolution & DIDComm

The W3C DID Core specification (v1.0) is a stable standard (published 2022). The community is now working on v1.1 and v2.0, which will include better support for ZKPs, simplified DID methods, and private key recovery.

DIDComm: Private, Authenticated Messaging

DID-based identity allows for a new type of messaging protocol: DIDComm. It is the encrypted, peer-to-peer messaging layer of the SSI stack.

How it works: Alice resolves Bob’s DID Document. She finds a service endpoint (service[0].serviceEndpoint) that supports DIDComm. She sends an encrypted message using Bob’s public key. Bob decrypts it.
Why it matters: It replaces email, Slack, and proprietary messaging platforms with a universal, privacy-preserving transport. It is the foundation for decentralized data exchange. The Aries Framework implements DIDComm over various transports (HTTP, WebSocket, Bluetooth).

The Death of the Password (Finally)

The ultimate goal of SSI is to replace passwords with cryptographic authentication. Instead of logging into a website with a password, you will authenticate by presenting a VC from your wallet. The website acts as a Verifier. This is called Passwordless Authentication using DIDs. FIDO2 (WebAuthn) is a step toward this, but SSI takes it further by making the credential portable across all websites.

Section 10: Conclusion: Building the City of Trust

We began with a ghost in the machine—an internet built for packets, not people. We end with a blueprint for a new city.

Decentralized Identity and Verifiable Credentials are not a single technology; they are a new operating system for digital trust. They flip the power dynamic. You no longer borrow your identity from a corporation; you own it. You no longer hand over your house keys to every shopkeeper; you unlock only the door you need.

The challenges are real.

Key Management remains the greatest UX hurdle. We need better recovery mechanisms.
Revocation is still complex for large-scale systems.
Governance is a human problem, not a technical one. We must build global trust registries that are fair and transparent.

But the potential is unmatched. Imagine a world where:

You can prove your age without revealing your birthdate.
Your doctor can prescribe a medication without faxing a form.
You can log into any website without a password.
Your university diploma is a permanent, verifiable asset.

This is the promise of the SSI revolution. The W3C standards are ready. The cryptographic primitives are proven. The first wave of deployments is live.

The question is no longer if we will build this new city of trust. The question is how fast we can lay the bricks.

Call to Action: Download a digital wallet (e.g., Brite from Sovrin Foundation or Kenna from Mattr). Practice issuing a self-signed credential. Run the code in this tutorial. Start building. The ghost is leaving the machine, and a new, sovereign entity—you—is taking the controls.

Table of Contents