Engineering · 2026-03-26

Verifiable Credentials Without the Blockchain: A Pragmatic Approach to Digital Identity

By J. W. Bouckaert

The blockchain question every enterprise asks

There is a question that surfaces in every enterprise identity architecture review in 2026. It is asked by CTOs evaluating decentralized identity. It is asked by compliance officers reviewing vendor proposals. It is asked by engineers who have read the W3C specifications and noticed something conspicuous in their absence.

The question: Do verifiable credentials require a blockchain?

The answer is no. They never did.

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.

This narrative was intellectually coherent. It was also operationally devastating.

Latency

Credential verification that requires on-chain resolution introduces latency that is incompatible with real-time identity decisions. Ethereum block finality averages 12 seconds. Hyperledger Indy ledger reads, while faster, still carry network round-trip costs of 50–200ms depending on node topology. For an identity platform processing carrier signals inside the request, a 200ms ledger lookup is a non-starter.

PasskeyBridge's VC engine resolves DID documents via did:web and did:key—both of which resolve over standard HTTPS with sub-10ms latency at the edge. 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, yet the gap between specification and production deployment is measured in years, not months.

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. The infrastructure exists. It works. It scales.

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 cold-start delta is measured in weeks versus hours.

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 security properties are equivalent. A did:web document served over HTTPS with DNSSEC validation and Certificate Transparency monitoring provides the same integrity guarantees as a DID document published to a permissioned ledger—with the added benefit that the enterprise controls key rotation without submitting ledger transactions.

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 latency: Sub-10ms. The bitstring is served from edge-cached endpoints. No ledger read required.
• 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. No blockchain required.

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.

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.

This defends against harvest-now-decrypt-later (HNDL) attacks that are actively targeting identity credentials today, well ahead of any hypothetical future threat. Credentials issued with classical-only signatures will be forgeable by quantum-capable adversaries. Credentials issued with hybrid PQC signatures will not.

Blockchain-anchored VC systems face a particularly acute HNDL risk: 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. The ledger entry is permanent. The cryptographic vulnerability is permanent.

PasskeyBridge's approach—signing credentials with hybrid PQC and publishing DID documents with PQC key material—avoids this trap entirely. Key rotation is a DID document update. Credential re-issuance is an API call. No ledger migration required.

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 architecturally impossible with most blockchain-anchored VC systems, where on-chain records—transaction hashes, DID registrations, schema publications—create correlation vectors that privacy researchers have demonstrated can be used to deanonymize credential holders through temporal and structural analysis.

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:

The pattern is consistent: every capability the blockchain provides, the standards-based stack provides faster, cheaper, and with fewer operational dependencies.

Cases where a ledger adds value

Intellectual honesty requires acknowledging the cases where a ledger adds genuine value:

• 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 are legitimate use cases. They are also edge cases. The vast majority of enterprise VC deployments—employee credentialing, customer identity verification, partner attestation, agent delegation certificates—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). Credential types include IdentityAttestation, AgentDelegation, and DeviceBinding.
• Resolution: Native did:web and did:key resolver with sub-10ms edge latency.
• 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: Automatic three-pillar cross-reference binding—carrier signal hash × VC subject hash × passkey credential ID—verified at every presentation.
• Audit: Zero-PII audit trail with append-only logging of every issuance, verification, and revocation event.

There is no blockchain, no token, no gas fee and no consensus latency, only cryptographic proofs, standard protocols, and the operational simplicity of HTTPS and DNS.

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. Every component of a production VC system exists as a ratified, implemented, interoperable standard.

The blockchain was never in the specification. It was in the narrative. And the narrative is not shipping to production.

PasskeyBridge ships to production. Every day. Without a chain.

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

Start free · Test the API