Engineering · 2026-03-26

Verifiable Credentials Without a Blockchain

By J. W. Bouckaert

The blockchain question every enterprise asks

One question comes up in many enterprise identity architecture reviews, from CTOs evaluating decentralized identity, from compliance officers reviewing vendor proposals, and from engineers who have read the W3C specifications and noticed that they do not mention a ledger.

The question: Do verifiable credentials require a blockchain?

The answer is no.

The W3C Verifiable Credentials Data Model v2.0 is deliberately agnostic about the underlying trust infrastructure. The specification defines the data envelope—claims, proofs, issuers, holders, verifiers—but says nothing prescriptive about where issuer public keys must be published, where revocation status must be checked, or where credential schemas must live. A verifiable credential signed with a key published at a did:web endpoint and revoked via a Bitstring Status List (the W3C Recommendation that promoted the original StatusList2021 working draft) is exactly as "verifiable" as one anchored to Ethereum or Hyperledger Indy. The cryptographic proof is identical. The trust model is identical. The enterprise operational complexity is not.

This article makes the case—technically, operationally, and economically—that blockchain-free verifiable credentials are the pragmatic default for enterprises that need verifiability without the operational overhead, latency penalties, and governance ambiguity that distributed ledger dependencies introduce.

The maximalist narrative

The decentralized identity movement emerged from a legitimate frustration: centralized identity providers are single points of failure, data honeypots, and gatekeepers. The blockchain maximalist response was to eliminate the center entirely—publish DID documents to immutable ledgers, anchor credential schemas on-chain, and resolve revocation through smart contracts.

The approach was coherent on paper. In operation it added latency, governance questions and setup work.

Latency

Credential verification that requires on-chain resolution introduces latency that is incompatible with real-time identity decisions. Ethereum produces a block every 12 seconds, and a block becomes final after two epochs, about 12.8 minutes. Permissioned ledgers such as Hyperledger Indy are faster, but every read is still a network query to ledger nodes. For an identity platform processing carrier signals inside the request, waiting on a ledger is hard to justify.

PasskeyBridge's VC engine resolves DID documents via did:web, which resolves over standard HTTPS, and did:key, which resolves locally from the key itself. There is no consensus protocol, no block confirmation and no gas fee.

The governance vacuum

Who operates the nodes? Who pays for storage? Who arbitrates disputes when a DID document published to a public ledger conflicts with off-chain reality? These governance questions remain largely unanswered in the decentralized identity ecosystem.

The Trust Over IP Foundation has produced governance frameworks, but adoption among enterprise identity providers remains fragmented. The Decentralized Identity Foundation (DIF) continues to iterate on interoperability profiles, and many of its specifications are still moving toward production deployment.

Meanwhile, did:web governance is straightforward: the entity that controls the domain controls the DID document. DNS is already governed, already auditable, and already integrated into every enterprise's security posture. DNSSEC provides integrity. Certificate Transparency logs provide accountability. All of it is already in place.

Cold start

A new enterprise deploying blockchain-anchored VCs must: provision ledger nodes (or pay for hosted access), manage cryptographic key material across chain-specific formats, train operations teams on consensus mechanics, and integrate chain-specific SDKs into existing CI/CD pipelines.

A new enterprise deploying PasskeyBridge VCs must: generate a did:web document, publish it at /.well-known/did.json, and call an API.

The architecture that replaces the chain

PasskeyBridge's VC engine implements three capabilities that blockchain proponents argue require a ledger. None of them do.

1. Issuer key discovery—did:web + did:key

The foundational question in any VC system is: How does the verifier discover the issuer's public key?

Blockchain-anchored systems answer this with on-chain DID document resolution. PasskeyBridge answers it with did:web—a DID method that resolves to a JSON document hosted at a well-known HTTPS endpoint.

did:web:shield.passkeybridge.io
→ GET https://shield.passkeybridge.io/.well-known/did.json

The resolved document contains the issuer's public key(s), key types, and verification relationships—everything a verifier needs to validate a credential signature. For ephemeral or self-issued credentials, did:key encodes the public key directly in the DID identifier, eliminating even the HTTPS resolution step.

Both methods are W3C DID Core compliant. Both are supported by PasskeyBridge's native DID resolver. Neither requires a ledger.

The trust model differs, and for most enterprise uses it is the simpler one. A did:web document served over HTTPS with DNSSEC validation and Certificate Transparency monitoring places trust in the domain owner and the web PKI instead of in ledger operators, and the enterprise rotates keys without submitting ledger transactions. Our did:web adoption analysis covers why enterprises have consolidated on did:web over did:ion, did:key and did:peer.

2. Revocation—StatusList2021

Revocation is the capability most frequently cited as requiring a blockchain. The argument: credential status must be publicly verifiable and tamper-evident, therefore it must live on an immutable ledger.

The argument conflates "publicly verifiable" with "globally replicated." StatusList2021 achieves the former without the latter.

A Bitstring Status List credential (formerly StatusList2021) is a compressed bitstring where each bit position corresponds to a credential index. Bit 0 = active. Bit 1 = revoked (or suspended, depending on the statusPurpose). The entire list is published as a verifiable credential itself—signed by the issuer, hosted at a stable URL, and cacheable by verifiers.

PasskeyBridge's implementation:

• Compression: Gzip-compressed, base64-encoded bitstring. A standard 16KB list supports 131,072 credentials.
• Resolution: The bitstring is served from edge-cached endpoints.
• Privacy: The verifier learns only the status of the specific credential index being checked. No other credential states are revealed—a property called herd privacy.
• Offline verification: Once cached, the bitstring enables fully offline revocation checks. This is critical for air-gapped environments and edge deployments where network connectivity is intermittent.

The integrity guarantee is cryptographic. The StatusList2021 credential is signed by the issuer. If the bitstring is tampered with, the signature fails. Checking it needs only the issuer's public key. Bitstring Status List vs accumulator proofs compares the two revocation approaches on verifier work and privacy leakage at 1M, 10M and 100M credentials.

3. Presentation—OpenID4VP

The third blockchain dependency in the maximalist stack is the presentation layer—how a holder presents credentials to a verifier. DIDComm and blockchain-anchored presentation protocols introduce complex peer-to-peer messaging layers that most enterprises cannot justify.

PasskeyBridge uses OpenID4VP (OpenID for Verifiable Presentations)—a protocol that extends the OpenID Connect framework enterprises already deploy.

The flow is familiar:

1. Verifier publishes a presentation_definition specifying required credential types and claim constraints (using Presentation Exchange 2.0)
2. Holder's wallet evaluates the definition against locally-held credentials, selects matching VCs, and constructs a vp_token
3. Verifier validates the VP signature, verifies each contained VC, checks revocation status via StatusList2021, and makes an access decision

No DIDComm. No peer-to-peer relay infrastructure. No blockchain interaction at any step. The entire exchange runs over HTTPS—the same transport layer enterprises use for every other API call. In the browser, Chrome carries OpenID4VP requests through the W3C Digital Credentials API, while Safari's implementation currently accepts only ISO mdoc requests; OpenID4VP over the Digital Credentials API covers what the browser mediates and what the verifier must still check.

PasskeyBridge's Presentation Exchange engine supports complex presentation_definition requirements with JSON Path extraction and JSON Schema filter evaluation, enabling verifiers to express precise credential requirements: "present an IdentityAttestation VC issued after 2026-01-01 with a trust_level of at least 'high'."

The hybrid PQC layer

Every credential issued by PasskeyBridge is signed with hybrid post-quantum cryptographic (PQC) signatures—a classical ES256 (ECDSA P-256) layer paired with ML-DSA-65 (FIPS 204) lattice-based signatures.

Harvest-now-decrypt-later is a risk for encrypted data. For signatures the risk is forgery: an adversary with a cryptographically relevant quantum computer, which does not exist today, could forge ECDSA signatures, so a long-lived credential signed only with ECDSA could no longer be trusted. A hybrid signature stays valid as long as either of its two algorithms holds.

Blockchain-anchored VC systems have a harder time with this, because their on-chain records are immutable by design. A credential anchored to Ethereum with an ECDSA signature cannot be re-signed with a PQC algorithm after the fact, so the ledger entry keeps the classical signature permanently.

PasskeyBridge signs credentials with hybrid PQC and publishes DID documents with PQC key material. Key rotation is a DID document update. Credential re-issuance is an API call.

Zero-PII by construction

PasskeyBridge's VC engine operates under a zero-PII architecture. Credential subjects are referenced by DID alone, never by name or email. Claim values can be hashed before issuance—the verifier checks the hash and never sees the plaintext. The audit trail records credential issuance, verification, and revocation events without storing any personally identifiable information.

This is harder in blockchain-anchored VC systems, where public on-chain records such as transaction hashes, DID registrations and schema publications are permanent and can be correlated over time with other activity.

StatusList2021 avoids this correlation risk through herd privacy: all credentials share the same status list, and the verifier's query reveals only a single bit position. There is no on-chain transaction that correlates a verification event with a specific credential or holder.

The enterprise decision framework

For enterprises evaluating VC infrastructure in 2026, the decision framework is straightforward:

For each of these capabilities, the standards-based stack does the job without a ledger and with fewer operational dependencies.

Cases where a ledger adds value

A ledger does add value in some cases:

• Multi-stakeholder trust registries where no single entity can be trusted to host the DID document (e.g., cross-border government credential ecosystems)
• Public credential schema registries that must survive the failure of any single organization
• Regulatory mandates that explicitly require immutable audit anchoring (rare, but emerging in some jurisdictions)

These cases are real but narrow. Most enterprise VC deployments, such as employee credentialing, customer identity verification, partner attestation and agent delegation, do not require global consensus. They require cryptographic verifiability, which is a property of the proof.

Production reality

PasskeyBridge processes verifiable credentials in production today. The stack:

• Issuance: JWT-VC format with hybrid PQC signatures (ML-DSA-65 + classical). The issuer sets the credential type, for example IdentityAttestation or CarrierVerification.
• Resolution: Native did:web and did:key resolver, with no ledger or consensus step.
• Revocation: StatusList2021 with gzip-compressed bitstrings, supporting 131,072 credentials per list.
• Presentation: OpenID4VP with Presentation Exchange 2.0, supporting complex multi-credential requirements.
• Cross-referencing: When a presentation carries a carrier-signal hash, PasskeyBridge binds it to a cross-reference record that links the keyed signal digest to the keyed credential-subject digest.
• Audit: Zero-PII audit trail with append-only logging of every issuance, verification, and revocation event.

The stack uses cryptographic proofs, standard protocols, HTTPS and DNS. It has no ledger, token or gas fee.

The stack is the standard

The W3C wrote the specification. IETF standardized the transport. OpenID Foundation defined the presentation protocol. NIST published the post-quantum algorithms. Each component of a production VC system is a published standard with working implementations, and none of them requires a ledger.

Explore the VC Engine → Read the PQC Deep-Dive → Get Started with PasskeyBridge →

Start free · Test the API