When California's DMV launched its mobile driver's license program, it made a technical decision that didn't get much attention outside architecture circles: support both ISO 18013-5 and W3C Verifiable Credentials from day one. That choice wasn't about hedging bets or satisfying competing vendors. It was about aligning the credential format with actual use-case requirements and avoiding a decision that would constrain the program's utility for years.
Many Californians now carry verifiable digital credentials that work at TSA checkpoints and, increasingly, across online government services. The dual-format architecture is why that coverage exists. Understanding the technical and policy rationale behind multi-format issuance matters for any state architecting digital identity infrastructure today.
The debate over mobile driver's license formats is often framed as ISO versus W3C. That framing misses the operational reality. Different credential formats emerged to address different problems, and those problems persist in state service delivery.
ISO 18013-5 was designed for highly regulated, in-person verification scenarios where strong security and offline operation are non-negotiable. It specifies cryptographic protocols for device-to-device communication, handles selective disclosure at the data element level, and includes tamper detection for the physical device presenting the credential. TSA checkpoints, age verification at retail, and law enforcement interactions all map cleanly to ISO's design assumptions.
W3C Verifiable Credentials emerged from a different set of requirements: online verification, interoperability across disparate systems, flexible data models, and integration with existing web infrastructure. The W3C model assumes network connectivity, supports rich metadata, and works naturally with standard web protocols. Applying for benefits, accessing health records, proving eligibility for services - these workflows align with W3C's architectural approach.
States don't face an either/or choice because their residents need both kinds of transactions. A credential system that only supports ISO can't easily power online service access. A system built only for W3C credentials creates friction for in-person verification, where ISO is rapidly becoming table stakes, particularly as TSA acceptance expands and retail point-of-sale systems adopt ISO readers.
Supporting multiple formats doesn't mean running parallel credential systems. SpruceID's approach involves issuing credentials in both ISO 18013-5 and W3C formats from the same authoritative data source. The architectural pattern is straightforward: verify the holder's identity once, sign the attested claims using appropriate cryptographic methods for each format, and provision both credential types to the holder's wallet.
This approach maintains a single source of truth (the issuing authority's identity proofing and data systems) while generating format-specific outputs. When California DMV provisions a mobile driver's license, the resident receives an ISO mDL for proximity-based verification and a W3C credential. Both credentials attest to the same identity attributes, signed by the same issuing authority, but packaged according to different technical specifications.
The cryptographic security model remains consistent across formats. Both ISO and W3C credentials rely on public key infrastructure, both support selective disclosure of attributes, and both enable offline verification where appropriate. The difference lies in protocol-level details - how devices communicate, how attributes are encoded, and how verification requests are structured.
From an integration perspective, multi-format issuance creates durability that single-format systems lack. As new use cases emerge, as verification requirements evolve, and as interoperability standards mature, states can adapt without reissuing credentials or rebuilding core infrastructure. The holder's wallet might need updates to support new presentation protocols, but the issuing authority's investment in identity proofing, data integration, and security controls remains stable.
Implementing dual-format credentials requires specific architectural choices at the issuance, wallet, and verification layers. These decisions determine whether multi-format support becomes a source of technical complexity or a relatively clean extension of existing capabilities.
At the issuance layer, the critical decision is whether to treat formats as distinct outputs from a shared data model or as parallel systems with synchronized data. A common architectural approach uses a shared canonical data model: the issuing authority maintains authoritative identity data, and the issuance service transforms that data into format-specific representations at provisioning time. This avoids data synchronization challenges and helps ensure consistent attribute values across credential formats.
Key management typically follows the same principle. Instead of maintaining separate key hierarchies for different credential formats, many implementations rely on a unified key management system that generates format-appropriate signatures from a shared root of trust. This simplifies auditing, reduces operational complexity, and keeps cryptographic operations within established security boundaries—often using hardware security modules or cloud-based key management systems integrated with existing government infrastructure.
Wallet architecture determines how effectively residents can use multi-format credentials. A well-designed wallet can store multiple credential formats and automatically detect the type of verification request. The wallet then presents the appropriate format without requiring the credential holder to understand the technical distinction. From a user perspective, this means they have a single digital driver's license that works across different verification scenarios, with format selection handled transparently by the wallet software.
At the verification layer, relying parties need to support the protocols appropriate to each credential format. ISO 18013-5 verification typically occurs over Bluetooth Low Energy or NFC, using the proximity-based security model defined in the standard. W3C Verifiable Credential verification generally happens over HTTPS, often using protocols such as OpenID for Verifiable Presentations (OpenID4VP) or similar web-based interaction models. States can encourage verifier adoption by providing reference implementations, testing environments, and clear technical documentation for both interaction patterns.
The verification layer is also where interoperability standards matter most. As discussed in Interoperability Without Lock-In: Why Standards Matter, a verifier implementing ISO 18013-5 correctly should be able to verify any conformant mobile driver's license, regardless of which state issued it or which vendor built the wallet. Similarly, W3C credential verification should function across compliant issuers, wallets, and verifiers. Supporting multiple formats does not introduce interoperability challenges—in many cases, it expands the number of environments where standards-based verification can operate effectively.
The technical architecture enables policy flexibility that matters for program design and long-term governance. Supporting both formats means states can match credential types to use case requirements without limiting future program expansion.
Consider eligibility verification for state benefits. These transactions occur online, typically involve multiple attributes beyond basic identity, and require integration with existing case management systems that already use web APIs. W3C credentials map cleanly to this workflow. The verifying agency receives a signed, tamper-evident data package over standard HTTPS, extracts the relevant attributes, and processes the application. The credential's format aligns with how the system already handles data.
Contrast that with age verification at a bar or convenience store. The merchant's verification device communicates directly with the holder's phone over short-range wireless, operates offline, and only needs to confirm one binary fact: is this person over 21? ISO 18013-5 was designed for exactly this scenario. The proximity requirement prevents relay attacks, selective disclosure protects privacy, and offline operation ensures the issuing authority doesn't track every transaction.
States that commit to a single format either limit use case coverage or force awkward technical workarounds. An ISO-only program struggles to support online service access because the proximity-based security model doesn't translate well to web interactions. A W3C-only program faces headwinds with retail adoption, law enforcement acceptance, and TSA checkpoint integration—markets where ISO 18013-5 has established momentum.
Multi-format support also creates policy optionality as digital credential adoption expands. When a new verification use case emerges (professional licensing verification, vehicle registration proof, health credential presentation), the state can evaluate which format better serves that scenario without constraining the decision based on what their existing infrastructure supports. The technical capability exists for both paths; policy can drive the choice.
This flexibility matters particularly as states consider expanding the use of digital credentials beyond driver's licenses. Birth certificates, professional licenses, permits, and other government-issued credentials all benefit from cryptographic security and selective disclosure. But different credential types follow different use-case patterns. A fishing license might predominantly need in-person verification; a professional credential might primarily support online verification by employers and licensing boards. Supporting both formats from the start means states can scale credential programs based on citizen needs rather than technical constraints.
Format decisions create long-term dependencies that affect vendor relationships, procurement flexibility, and program sustainability. When a state adopts proprietary credential formats or tightly couples its infrastructure to a single vendor’s implementation, it can become difficult to expand programs, adopt new capabilities, or integrate with other systems without significant redevelopment. Architectures built on open standards and multi-format support help reduce this risk.
Both ISO 18013-5 and W3C Verifiable Credentials are open, publicly documented standards with multiple implementations across different vendors and technology stacks. Systems designed around these standards allow states to evolve their credential ecosystems without requiring residents to replace their credentials or relying on vendor-specific protocols. The standards themselves (not proprietary interfaces) define how credentials are structured, presented, and verified.
This has practical implications for procurement and long-term governance. States can competitively bid for wallet development, issuance platform upgrades, and verification infrastructure based on standards compliance rather than committing to a single vendor ecosystem. Agencies also gain the flexibility to adopt best-of-breed components across the credential lifecycle—issuance, wallet applications, verification services, and registries—while maintaining interoperability across the system.
Open-source implementations can further reduce operational risk by providing transparency into how credential systems work. When components are openly available for review, agencies and independent security auditors can examine how privacy protections, cryptographic controls, and protocol implementations function in practice. This visibility can support procurement evaluations, security reviews, and long-term program governance.
The vendor lock-in question becomes especially important as verifiable digital credential adoption scales. With millions of credentials already issued in programs like California’s mobile driver’s license deployment, and projections showing tens of millions more across the United States over the coming decade, states are making infrastructure decisions that will shape digital identity ecosystems for years to come. Choosing standards-based architectures helps ensure those systems remain adaptable as technology evolves, new use cases emerge, and additional vendors participate in the ecosystem.
SpruceID's approach to the format question is straightforward: let use cases drive format selection, and build infrastructure that supports both. This isn't fence-sitting; it's recognizing that different verification scenarios have distinct requirements, which map to distinct technical specifications.
When California's DMV evaluated format options, they explored which use cases mattered to California residents, which verification scenarios needed to work reliably from day one, and which technical capabilities the program needed to scale over time. The answer was both ISO for in-person verification and W3C for online services.
That pragmatic stance extends beyond driver's licenses. As states digitize more credentials and expand verification use cases, format selection should follow the same logic: what are we trying to accomplish, who needs to verify what information, and which technical approach best serves that scenario? Sometimes the answer is ISO. Sometimes it's W3C. Often it's both, for different parts of the same program.
The alternative, picking one format and forcing all use cases to conform, creates friction in credential adoption, limits program utility, and ultimately slows the transition to more secure, privacy-preserving identity infrastructure. States that support multiple formats based on open standards gain flexibility, reduce risk, and deliver better outcomes for residents and agencies alike.
Verifiable digital credentials are an operational infrastructure. The technical choices that underpin credential programs need to serve actual service-delivery requirements, integrate with systems that states already rely on, and remain sustainable as programs scale. Multi-format support based on open standards does that. Single-format commitments, particularly to proprietary implementations, do not.
Three and a half million mobile driver's license credentials have been issued in California, which work because the state chose technical architecture over format ideology. That's a model worth replicating.
Building digital services that scale take the right foundation.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.
