Decentralized Identity (DID) and Verifiable Credentials 2026

Introduction

Digital identity is broken. Users manage dozens of passwords, organizations store massive databases of personal data that become breach targets, and verifying a credential requires calling the issuer — a process that takes days and costs money. Decentralized identity solves this with a cryptographic model: issuers sign credentials with private keys, holders store them in wallets, and verifiers check the signature against the issuer’s public DID — without contacting the issuer or exposing more data than necessary.

2026 is a watershed year for this technology. The EU’s eIDAS 2.0 regulation requires all member states to offer certified digital identity wallets by November 2026. The W3C published Verifiable Credentials 2.0 as a full standard in 2025. Verifiable credential issuance reached 28 million credentials in Q1 2026 alone, up 340% year-over-year.

This guide covers the full stack: DID methods and their tradeoffs, the W3C VC data model, selective disclosure with cryptographic proofs, the eIDAS 2.0 framework, enterprise deployment patterns, and the protocols driving wallet interoperability.

The Trust Triangle

Every verifiable credential system has three roles:

The key innovation: the verifier never needs to call the issuer. The cryptographic signature proves the credential came from the issuer and hasn’t been tampered with. This eliminates the phone calls, API calls, and database lookups that make traditional credential verification slow and expensive.

DID Methods

DID Format

A Decentralized Identifier (DID) is a URI with the format did:method:identifier. The method specifies how the DID is created, resolved, updated, and deactivated. As of 2026, over 150 DID methods exist, but a handful dominate production use:

did:web — The Most Deployed Method

did:web resolves by fetching a did.json file from an HTTPS endpoint. For did:web:example.com, the resolver fetches https://example.com/.well-known/did.json:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:example.com",
  "verificationMethod": [
    {
      "id": "did:web:example.com#key-0",
      "type": "JsonWebKey2020",
      "controller": "did:web:example.com",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "0-e2i2_Ua1S5HbTYnVB0lj2Z2ytXu2-tYmDFf8f5NjU"
      }
    }
  ],
  "authentication": ["did:web:example.com#key-0"],
  "assertionMethod": ["did:web:example.com#key-0"]
}

did:web dominates because it requires no blockchain, no gas fees, and no new infrastructure — any organization with a domain and HTTPS can issue DIDs immediately. However, it inherits the domain’s security: if the domain expires or is compromised, the DID is lost.

did:webvh — Verifiable History

did:webvh (Web + Verifiable History) extends did:web by adding a cryptographic hash chain of DID document versions. Each update references the previous version’s hash, creating an append-only, verifiable log:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:webvh:example.com",
  "versionId": "1.0.0",
  "previousVersionId": null,
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-2022",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:webvh:example.com#key-0",
    "proofValue": "z3s2x..."
  },
  "verificationMethod": [
    {
      "id": "did:webvh:example.com#key-0",
      "type": "JsonWebKey2020",
      "controller": "did:webvh:example.com",
      "publicKeyJwk": { "kty": "OKP", "crv": "Ed25519", "x": "..." }
    }
  ]
}

This solves the key limitation of did:web: anyone can verify that the current DID document is the legitimate latest version, not a rollback or hijack.

Verifiable Credentials

W3C Verifiable Credentials Data Model 2.0

The W3C published VC Data Model 2.0 as a full Recommendation in 2025. It defines a standard JSON-LD structure for credentials, with DataIntegrityProof as the modern proof format (replacing the earlier EcdsaSecp256k1Signature2019 approach):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiableCredential", "ProfessionalCertification"],
  "issuer": "did:web:example-university.edu",
  "validFrom": "2026-01-15T00:00:00Z",
  "validUntil": "2028-01-15T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MktaugqFBMkzTBPNqK9R",
    "name": "Maria Andersson",
    "certification": "Certified Security Professional",
    "level": "Expert",
    "issuedBy": "European Security Association"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-2022",
    "created": "2026-01-15T12:00:00Z",
    "verificationMethod": "did:web:example-university.edu#key-0",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic9q9gxQVzQaRE..."
  }
}

Key changes in VC 2.0 vs 1.1:

• DataIntegrityProof replaces the family of *Signature2019/2020 proof types as the recommended approach
• validFrom / validUntil replace issuanceDate / expirationDate for clarity
• Support for ecdsa-sd-2023 cryptosuite enabling selective disclosure
• Cleaner JSON-LD context management

Issuing a VC — Node.js Example

The issuance flow in code: the issuer builds the credential, signs it with their private key, and transmits it to the holder’s wallet:

import { Ed25519VerificationKey2020 } from '@digitalbazaar/ed25519-verification-key-2020';
import { Ed25519Signature2020 } from '@digitalbazaar/ed25519-signature-2020';
import jsigs from 'jsonld-signatures';

async function issueCredential(holderDid, claims, issuerKeyPair) {
  const credential = {
    '@context': ['https://www.w3.org/ns/credentials/v2'],
    type: ['VerifiableCredential'],
    issuer: issuerKeyPair.controller,
    validFrom: new Date().toISOString(),
    credentialSubject: {
      id: holderDid,
      ...claims
    }
  };

  // Sign with Ed25519Signature2020 suite
  const suite = new Ed25519Signature2020({ key: issuerKeyPair });
  const signedVC = await jsigs.sign(credential, {
    suite,
    purpose: new jsigs.purposes.AssertionProofPurpose()
  });

  return signedVC;
}

The holder stores the signed VC in their wallet. When a verifier requests it, the holder creates a Verifiable Presentation (VP) — a wrapper around one or more VCs that may include additional context or selective disclosure.

Selective Disclosure with BBS+ / ecdsa-sd-2023

Selective disclosure allows the holder to reveal only specific attributes from a credential while keeping others hidden. For example, proving “age over 21” without revealing the exact birth date. This is enabled by the ecdsa-sd-2023 (ECDSA Selective Disclosure) cryptosuite:

import { EcdsaSelectiveDisclosure2023 } from '@digitalbazaar/ecdsa-sd-2023';

async function createSelectivePresentation(signedVC, revealedAttributes) {
  // Create a verifiable presentation revealing only selected claims
  const suite = new EcdsaSelectiveDisclosure2023();

  const presentation = await jsigs.present(signedVC, {
    suite,
    purpose: new jsigs.purposes.AuthenticationProofPurpose(),
    frame: {
      '@context': signedVC['@context'],
      type: ['VerifiablePresentation'],
      verifiableCredential: [{
        '@context': signedVC['@context'],
        type: signedVC.type,
        credentialSubject: {
          // Only include the requested attributes
          ...Object.fromEntries(
            revealedAttributes.map(attr => [attr, {}])
          )
        }
      }]
    }
  });

  return presentation;
}

// Usage: holder reveals only "ageOver" from a KYC credential
const vp = await createSelectivePresentation(kycCredential, ['ageOver']);
// Verifier receives the VP and can verify "ageOver == true"
// without seeing name, address, or exact birth date

The verifier checks the presentation’s proof against the issuer’s public key. If the proof validates, the revealed attributes are guaranteed to come from the original signed credential — even though the unrevealed attributes were never transmitted.

eIDAS 2.0 and the EU Digital Identity Wallet

What Changed in 2026

The EU’s eIDAS 2.0 regulation (amending the original 2014 eIDAS framework) is the largest government-driven deployment of decentralized identity in history. Key mandates:

• November 2026: All 27 member states must offer at least one certified EU Digital Identity (EUDI) Wallet to citizens and businesses
• November 2027: Financial institutions, payment services, and regulated entities must accept EUDI Wallets for strong customer authentication
• Very Large Online Platforms (VLOPs under the Digital Services Act) must also accept EUDI Wallets by 2027

EUDI Wallet Architecture

               EU DI WALLET ARCHITECTURE (SIMPLIFIED)

      Issuer                          Holder                    Verifier
    (Government)                   (Citizen)                  (Bank)

  ┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐
  │  Attestation     │      │  EUDI Wallet App │      │  Verifier API   │
  │  Provider        │─────►│  (e.g. Italian   │─────►│  (accepts       │
  │  (Signs VC with  │      │   IT Wallet,     │      │   VCs via       │
  │   qualified cert)│      │   French         │      │   OpenID4VP)   │
  └──────────────────┘      │   Identité       │      └──────────────────┘
                            │   Numérique)     │
                            └──────────────────┘
                                    │
                            ┌───────┴───────┐
                            │  PID + QEAA   │
                            │  (Person      │
                            │   Identification│
                            │   Data +      │
                            │   Qualified   │
                            │   Electronic  │
                            │   Attestation)│
                            └───────────────┘

Each EUDI Wallet stores:

• PID (Person Identification Data): government-verified identity attributes (name, date of birth, national ID number)
• QEAA (Qualified Electronic Attestation of Attributes): professional licenses, diplomas, health records signed by qualified trust service providers
• PU-EAA (non-qualified attestations): loyalty cards, library cards, subscriptions

Wallets communicate with verifiers using OpenID4VP (OpenID for Verifiable Presentations) — an IETF-standardized protocol built on top of OAuth 2.0.

OpenID4VC — Wallet Interoperability

The OpenID Foundation’s OpenID4VC (Verifiable Credentials) family of specifications provides the transport layer for wallet-based credential exchange:

A typical OpenID4VP flow:

1. Verifier sends an authorization request with presentation_definition specifying required claims
2. Wallet checks which stored VCs satisfy the requirements
3. User consents to share specific attributes
4. Wallet constructs a Verifiable Presentation and sends it as the authorization response
5. Verifier validates the proof against the issuer’s public DID

Enterprise Adoption Patterns

Reusable KYC

The most commercially successful DID use case in 2026. A user completes KYC once with a regulated issuer (bank, government), receives a VC, and reuses it across multiple services without re-submitting documents:

┌─────────────────────────────────────────────────────────────────────┐
│                   REUSABLE KYC FLOW                                  │
│                                                                     │
│  1. User uploads passport to regulated KYC provider                 │
│  2. Provider verifies documents (AML, sanctions, PEP checks)        │
│  3. Provider issues KYC VC: { "kycLevel": "enhanced",              │
│     "verifiedAt": "2026-03-01", "country": "SE" }                  │
│  4. User stores VC in wallet                                        │
│  5. User opens account at Bank B: scan QR code, approve share       │
│  6. Bank B verifies proof against KYC provider's DID               │
│  7. No re-submission — account opened in < 2 minutes               │
└─────────────────────────────────────────────────────────────────────┘

Results from production deployments: KYC time reduced from 2-3 days to under 2 minutes, cost per verification reduced by 60-80%, and fraud rates drop because the issuer’s signature is cryptographically bound to the user’s DID.

Employment and Education Credentials

Verifiable credentials for hiring: a university issues a degree as a VC, the graduate stores it in their wallet, and employers verify it instantly without calling the registrar. In Q1 2026, employment verification (37%) and academic credentials (18%) were the largest and third-largest VC use cases by volume.

Self-Sovereign Identity (SSI) Principles

On-Chain vs Off-Chain Credential Verification

DIDs and VCs do not require storing credentials on a blockchain. The blockchain (or verifiable data registry) serves only as a public key directory — a place to resolve DIDs to their current public keys. The credentials themselves are stored in the holder’s wallet and transmitted peer-to-peer.

This is a common misconception: VCs are not “on-chain credentials.” The blockchain provides the trust anchor (the issuer’s public key), but the credential data lives off-chain, in the holder’s wallet.

The only on-chain component typically needed is a status list — a bitstring published to the registry indicating which credential IDs have been revoked. The Status List 2021 specification defines this format.

Verifiable Credential Revocation

Credentials include a credentialStatus field that points to a status list entry. The issuer periodically updates the status list on a registry; the verifier checks it during presentation:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "type": ["VerifiableCredential", "ProfessionalCertification"],
  "issuer": "did:web:example-university.edu",
  "credentialSubject": { "id": "did:key:z6Mktaug...", "degree": "BSc" },
  "credentialStatus": {
    "id": "https://example-university.edu/status/3#0",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "0",
    "statusListCredential": "https://example-university.edu/status/3"
  },
  "proof": { ... }
}

The verifier fetches the status list credential, checks whether bit 0 of the list is 1 (revoked), and accepts the credential only if it is unrevoked.

Conclusion

Decentralized identity has crossed from experimental to mandatory infrastructure — at least in the EU, where eIDAS 2.0 forces every member state to deploy certified wallets by the end of 2026. The technical foundations are stable: W3C VC 2.0 provides the data model, did:web / did:webvh provide practical DID methods without blockchain overhead, OpenID4VP provides wallet interoperability, and selective disclosure cryptosuites (ecdsa-sd-2023) solve the privacy problem that plagued earlier digital identity attempts.

For enterprises, the path forward is clear:

• Start with did:web — it requires no blockchain and works with existing domain infrastructure
• Issue VCs for one use case first — reusable KYC is the highest-ROI starting point
• Support OpenID4VP — it is becoming the universal wallet protocol
• Plan for EUDI Wallet acceptance by 2027 — if your business operates in the EU, regulated entities must accept the wallet for authentication

The 28 million credentials issued in Q1 2026 are a signal: decentralized identity is no longer speculative. It is live, regulated, and scaling.

Resources

• W3C Verifiable Credentials Data Model 2.0 — The official VC specification
• W3C Decentralized Identifiers (DIDs) 1.1 — DID Core specification
• did:web Method Specification — W3C CCG spec for web-based DIDs
• did:webvh (Verifiable History) — DID method with version history
• eIDAS 2.0 Regulation (EU 2024/1183) — The EU Digital Identity framework
• OpenID4VP Specification — Wallet interoperability protocol
• Status List 2021 — Off-chain credential revocation
• Dock.io — Decentralized Identity Guide — Practical enterprise deployment patterns