Comparative Analysis of Verifiable Credential Stacks
Objective
The primary goal of this comparison is to highlight the unique strengths, technical capabilities, and architectural philosophies of each stack. By analyzing how these platforms handle data, connectivity, and trust, this document aims to guide stakeholders in choosing the solution that best fits their specific use cases—whether those involve government-grade offline identity, enterprise-scale multi-tenancy, or broad European ecosystem compliance.
Neutrality and Pro Bono Disclaimer
This comparative analysis is conducted on a pro bono basis by the Centre for Digital Public Infrastructure. We maintain a tech-neutral stance and have not received any financial compensation or "kickbacks" from the analyzed technology providers. Our goal is to support countries in their digital transformation journey, regardless of the specific technology stack they choose to implement.
Selection of Themes
The technical and operational dimensions explored in this document are not exhaustive. Instead, they represent the most common themes and challenges that arise during our country-level consultations. These dimensions were selected to address the specific needs of stakeholders looking for government-grade identity, enterprise scalability, or regulatory compliance.
Document Structure
The analysis is organized into key technical and operational dimensions:
Standards & Data Formats: An overview of the protocols (e.g., OpenID4VC, W3C) and data structures (e.g., JWT, SD-JWT, mDoc) supported by each provider.
Revocation & Security: An examination of the mechanisms used to invalidate or manage the status of credentials in production environments.
Infrastructure & Deployment: A look at Multi-Tenancy capabilities, distinguishing between stacks designed for single-use deployments and those built for scalable SaaS platforms.
Operational Connectivity: A deep dive into Offline Verification, assessing how each stack utilizes technologies like BLE, NFC.
Trust Anchors: A comparison of DID Methods and Blockchain integrations, ranging from ledger-agnostic web approaches to native Hyperledger Indy or Polygon support.
Hosting Options and Licensing: A look at all implementation models and Licences.
Documentation Quality & Sustainability: Examination of the accessibility of technical guides and the long-term viability.
Security, Privacy & Compliance: how the stacks adhere to security-by-design, cryptographic standards, and regulatory frameworks.
Assessment Baseline (Version Scope)
INJI
Wallet: Mobile (0.21) / Web (0.15)
CREDEBL
2.1
walt.id
Jan 2026 Release
QuarkID
Protocol v2.2
How to Read this Document
Each section includes a Feature Matrix that uses the following visual indicators to allow a quick at-a-glance comparison across stacks:
✅ Full support ⚠️ Partial / In progress ❌ Not supported
1. Standards Support
What is it?
These are the technical rules that allow wallets to communicate with each other.
Importance
It ensures interoperability. Without common standards, a user with a wallet from one provider couldn't present their credentials to a verifier using another provider
W3C VC Data Model 1.1
✅
✅
✅
✅
W3C VC Data Model 2.0
CREDEBL via roadmap; QuarkID partial
✅
⚠️
✅
⚠️
OpenID4VCI
Inji Draft 13; walt.id Draft 11 & 13
✅
✅
✅
✅
OpenID4VP
Inji Draft 23; walt.id Draft 14 & 20
✅
✅
✅
✅
IETF SD-JWT VC
✅
✅
✅
✅
ISO 18013-5 (mDL/mDoc)
Inji & CREDEBL in progress; walt.id full
⚠️
⚠️
✅
❌
ISO 18013-7
❌
❌
✅
❌
DIDComm v2
CREDEBL via Aries; QuarkID native
❌
✅
❌
✅
SIOPv2
❌
❌
⚠️
✅
Hyperledger AnonCreds
❌
✅
❌
❌
eIDAS 2.0 / EUID ARF
walt.id only - full alignment
❌
❌
✅
❌
EBSI / ESSIF
❌
❌
✅
❌
DIF Presentation Exchange
⚠️
✅
✅
⚠️
Trust over IP (ToIP)
❌
✅
❌
❌
Differences:
Inji and walt.id focus on modern web-friendly standards such as W3C VC 2.0 and OpenID4VCI. walt.id stands out as the only stack with native, full alignment for the European ecosystem (eIDAS 2.0 and EUID Architecture and Reference Framework). CREDEBL maintains a robust focus on the Hyperledger Aries ecosystem and DIF protocols, supporting deployments from enterprise scale to national-scale digital trust ecosystems. QuarkID acts as a versatile hybrid, supporting modern OpenID flows while adding advanced peer-to-peer security through DIDComm v2 and SIOPv2.
Implications:
Using walt.id is essential for projects requiring compliance with the European Union Digital Identity (EUID) wallet regulations or eIDAS 2.0. Inji is highly effective for integration within modern web-based mobile wallets in emerging markets. CREDEBL is the better fit for environments requiring the advanced privacy features of the AnonCreds ecosystem. QuarkID offers a unique advantage for those needing both standard web flows and highly secure, encrypted messaging between devices, particularly in the Latin American region.
2. Data Formats
What is it?
The technical structure used to package credential information.
Importance:
This determines how "heavy" a credential is and what security algorithms it uses.
JSON-LD with Linked Data Proofs
✅
✅
✅
✅
JWT (JWS)
✅
✅
✅
✅
SD-JWT
✅
✅
✅
✅
ISO mDoc (CBOR / 18013-5)
⚠️
⚠️
✅
❌
AnonCreds / ZKP-CL
❌
✅
❌
❌
ZKP (other - BBS+ / etc.)
❌
❌
❌
✅
Ed25519
✅
✅
✅
✅
secp256k1 / secp256r1
✅
✅
✅
⚠️
RSA
✅
❌
✅
❌
Decentralized Web Nodes (DWN)
❌
❌
❌
✅
Differences:
walt.id offers the greatest versatility by supporting mobile identity formats like mDoc (ISO 18013-5). CREDEBL specializes in AnonCreds (ZKP) signatures, while Inji prioritizes JSON-LD with Linked Data Proofs. QuarkID strengthens this category by offering support for ZKP (Zero-Knowledge Proofs) and modern formats like SD-JWT.
Implications:
Choosing walt.id allows an organization to issue digital driver’s licenses compatible with international transport standards. CREDEBL provides superior data protection through Zero-Knowledge Proofs, which allow users to prove attributes without revealing unnecessary underlying data.
3. Revocation Capabilities
What is it?
The mechanism used to invalidate a credential before its expiration date.
Importance
This is vital for trust. A system without efficient revocation is not viable for legal or high-security use cases.
Bitstring Status List (v1.0)
Inji experimental
⚠️
✅
✅
✅
StatusList2021 (W3C)
Inji JSON-LD only
⚠️
✅
✅
❌
RevocationList2020
❌
❌
✅
❌
IETF Token Status List
CREDEBL for SD-JWT & ISO mDoc
❌
✅
✅
❌
AnonCreds tails + accumulators
CREDEBL production-ready
❌
✅
❌
❌
On-chain revocation registry
❌
✅
❌
✅
Suspension (separate purpose)
❌
❌
✅
⚠️
Custom status reasons via policy
❌
❌
✅
⚠️
Self-hosted API endpoint
✅
✅
✅
✅
Differences:
CREDEBL stands out with the broadest multi-format revocation coverage: a production-ready solution based on "tails files" and accumulators for AnonCreds, plus IETF Token Status List support for SD-JWT and ISO mDoc credentials. This makes CREDEBL the only stack with production-grade revocation across all three major credential formats. Inji is currently in an experimental phase with Bitstring Status Lists. walt.id and QuarkID implement the more modern IETF Token/Bitstring Status Lists.
Implications:
For large-scale deployments that require the ability to invalidate thousands of credentials instantly, CREDEBL offers the most mature architecture. walt.id and QuarkID provide the most flexibility for defining custom status reasons (such as suspension) via policy.
4. Multi-Tenancy
What is it?
The ability for a single software installation to serve multiple independent clients or organizations securely
Importance
It reduces operational costs and complexity. It allows an organization to provide Credentials Issuing Service to various sub-departments or external clients
Full multi-tenant architecture
walt.id Enterprise Stack only
❌
✅
⚠️
✅
Shared agents (multi-tenant)
❌
✅
⚠️
✅
Dedicated agents (single-tenant)
✅
✅
✅
✅
Tenant-specific configurations
❌
✅
⚠️
✅
White-labeling / sub-accounts
❌
❌
⚠️
✅
Designed for SaaS deployments
❌
✅
⚠️
✅
Agent-agnostic architecture
❌
✅
⚠️
❌
National-scale deployment support
Inji & CREDEBL proven at national scale
✅
✅
❌
⚠️
Differences CREDEBL and QuarkID were designed specifically for SaaS deployments, allowing for the management of multiple clients through shared or dedicated agents. Inji is typically limited to a single issuer per deployment. walt.id provides this capability through its Enterprise Stack.
Implications
If your goal is to build a platform that offers "Credentialing as a Service" to third parties, CREDEBL or QuarkID are the most viable technical choices. It is equally important to note that CREDEBL also supports large-scale dedicated deployments for national government programs, not only SaaS models. Inji would be more expensive to scale in a multi-tenant SaaS scenario as it requires a separate instance for every client/issuer.
5. Offline Verification
What is it? The ability to present and validate an identity even when the issuer, user, or verifier does not have an active internet connection.
Importance
Critical for border control, rural areas, or emergency situations where connectivity is unreliable.
BLE (Bluetooth Low Energy)
Inji via Tuvali protocol
✅
❌
⚠️
✅
NFC
❌
❌
✅
❌
Wi-Fi Aware (mDL)
❌
❌
✅
❌
QR Code offline verification
✅
✅
✅
✅
PixelPass QR compression
Inji exclusive
✅
❌
❌
❌
Offline face authentication
Inji exclusive
✅
❌
❌
❌
AnonCreds offline predicates
❌
✅
❌
❌
Status list caching
❌
❌
✅
⚠️
Works without internet
✅
❌
⚠️
✅
Differences:
Inji leads this section with native support for Bluetooth Low Energy (BLE) and offline face authentication. QuarkID matches this with peer-to-peer sharing via BLE and offline-scannable QR codes. CREDEBL relies primarily on online agent connectivity for verification.
Implications:
The primary advantage of Inji and QuarkID is their ability to function in government identity programs in low-connectivity areas where face-to-face verification is a non-negotiable requirement.
6. DID Methods & Blockchain
What is it?
This defines where the root of trust for the identity lives (e.g., a web domain, a specific blockchain like Ethereum, etc).
Importance:
It determines the level of decentralization, cost, and censorship resistance of the system.
did:web
✅
✅
✅
✅
did:key
✅
✅
✅
✅
did:jwk
✅
❌
✅
❌
did:peer
❌
✅
❌
✅
did:indy (Hyperledger Indy)
❌
✅
❌
❌
did:ebsi (EBSI/ESSIF)
❌
❌
✅
❌
did:cheqd
❌
❌
✅
❌
Polygon blockchain
❌
✅
⚠️
✅
zkSync Era / Rootstock / ETH
QuarkID multichain EVM
❌
❌
❌
✅
X.509 Certificate Trust Anchoring
CREDEBL: Trust Chain & Trust Registry
❌
✅
⚠️
❌
Ecosystem Governance framework CREDEBL: incl. IATA Travel PoC
❌
✅
⚠️
⚠️
Ledger-agnostic / custom VDR
✅
✅
✅
❌
No blockchain dependency
✅
❌
✅
❌
Differences:
CREDEBL has the deepest integration with traditional identity blockchains like Hyperledger Indy and Polygon, but also with x.509 Certificate-base trust anchoring. Inji and walt.id adopt a "blockchain-minimal" approach, prioritizing web-based methods like did:web. QuarkID leverages public EVM-compatible chains like Polygon to provide transparency without the complexity of private ledgers.
Implications:
CREDEBL is the preferred choice for organizations that need flexible trust governance: whether based on private distributed ledgers (Hyperledger Indy, Polygon), existing PKI infrastructure (X.509 certificates), or a structured ecosystem governance framework with a Trust Registry. QuarkID is ideal for those wanting public immutable transparency. Inji and walt.id offer easier integration with current web infrastructure, avoiding a hard dependency on a specific blockchain network.
7. Hosting Options & Licensing
What is it? The legal framework (license) and physical deployment models (Cloud/On-premise) available for the stack
Importance:
Determines the total cost of ownership, legal freedom to modify/redistribute, and the level of sovereignty over data residency.
Cloud deployment
✅
✅
✅
✅
On-premise deployment
✅
✅
✅
✅
Sovereign cloud support
walt.id places specific emphasis
⚠️
⚠️
✅
⚠️
MIT License
✅
❌
❌
❌
Apache 2.0 License
❌
✅
✅
✅
Enterprise edition available
❌
⚠️
✅
⚠️
Foundation-backed
MOSIP & Linux Foundation respectively
✅
✅
❌
❌
Differences
Most stacks utilize the Apache 2.0 license, while INJI uses the even more permissive MIT license. All support flexible hosting, but walt.id places a specific emphasis on "sovereign cloud" environments.
Implications
High flexibility for governments to maintain data sovereignty through on-premise hosting across all stacks. The choice of MIT vs. Apache 2.0 primarily affects how organizations can redistribute modified versions of the core software.
8. Documentation Quality & Sustainability
What is it?
The accessibility of technical guides and the long-term viability/funding of the project.
Importance:
High-quality documentation reduces implementation time; project sustainability ensures long-term maintenance and updates.
Extensive developer documentation
✅
⚠️
✅
⚠️
API reference docs
✅
✅
✅
⚠️
Quickstart / sandbox guides
✅
⚠️
✅
❌
Active developer community
✅
✅
✅
⚠️
Foundation / institutional backing
MOSIP & Linux Foundation
✅
✅
❌
⚠️
Regular release cadence
✅
✅
✅
⚠️
Open roadmap published
⚠️
⚠️
✅
❌
Differences
walt.id currently offers the most structured documentation for developers. INJI and CREDEBL benefit from the long-term stability of major international foundations (MOSIP and Linux Foundation).
Implications
Projects with stronger institutional or foundation backing (Inji, CREDEBL) offer higher long-term peace of mind for national-scale infrastructure.
9. Security, Privacy, & Compliance
What is it?
Adherence to security-by-design, cryptographic standards, and regulatory frameworks.
Importance
Essential for protecting citizen data and meeting legal requirements (such as GDPR or national data laws).
Security-by-design principles
✅
✅
✅
✅
Key management infrastructure
⚠️
⚠️
✅
⚠️
Auditability / audit trails
⚠️
⚠️
✅
⚠️
GDPR-aligned design
⚠️
✅
✅
⚠️
eIDAS 2.0 compliance-ready
❌
❌
✅
❌
ZKP / selective disclosure
❌
✅
⚠️
✅
Hardware security module (HSM)
❌
⚠️
✅
❌
Biometric authentication
Inji offline face auth
✅
❌
❌
❌
Govt-grade hardening (out-of-box)
All stacks require implementer hardening
⚠️
⚠️
⚠️
⚠️
Differences
walt.id provides the most comprehensive focus on compliance-ready features like auditability. The other stacks prioritize core cryptographic security, leaving specific regulatory "hardening" to the implementer.
Implications
walt.id is particularly well-suited for highly regulated environments (like the EU) where auditability and key management are primary requirements. For other stacks, governments should allocate resources specifically for security hardening during the deployment phase.
🔑 Overall Key Distinctions:
INJI excels at offline capabilities with BLE and face authentication, making it ideal for low-connectivity environments and government identity programs. Strong focus on mobile-first experience. Takes a blockchain-minimal approach with web-based DIDs. So consider Inji if you need a mobile-first solution for government programs in low-connectivity environments.
CREDEBL provides the most comprehensive multi-tenancy and enterprise features, supporting both traditional SSI (AnonCreds) and modern standards. Best for organizations building SaaS platforms or managing multiple clients. Strongest blockchain support with native Hyperledger Indy and Polygon integration, ideal for ledger-based implementations. So consider CREDEBL if you are building population-scale digital trust ecosystems — including Decentralized National ID, Digital Travel Credentials, Academic Credentials, eKYC, or Health Data Exchange — with a focus on self-sovereign identity, privacy-preserving architectures, and local data protection requirements.
walt.id offers the most complete standards compliance across both stacks (Community & Enterprise), with strong eIDAS 2.0 alignment. Enterprise Stack provides production-ready multi-tenancy with extensive management tools. Broadest DID method support with focus on European ecosystem (EBSI) and extensibility. So consider walt.id if you need maximum standards compliance, alignment with European regulations (eIDAS), and high extensibility.
QuarkID stands out as a versatile hybrid that balances modern web standards (OpenID4VC) with advanced peer-to-peer security through DIDComm v2. It offers native multi-tenancy for SaaS models and leverages public EVM-compatible chains like Polygon to provide transparency without the complexity of private ledgers. So consider QuarkId if you want a balanced, multi-tenant platform that combines public blockchain transparency with high-security encrypted messaging
Last updated
Was this helpful?