Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Digital Identities: Getting to Know the Verifiable Digital Credential Ecosystem

Understanding mDL credential formats

Standards in the VDC Ecosystem

In our first blog post in this series, we highlighted that VDCs can represent a wide range of credentials, from a driver’s license to a diploma to proof of age. The ability to use VDCs in a wide variety of use cases is a major reason why many are looking at the VDC ecosystem as technology that can change how we present identity and attributes (both in person and online). While credential variety is a good thing, interoperability requires a common set of standards and protocols for issuing, using, and verifying VDCs. The next few posts in this series will focus on the array of standards that promise to make that interoperability a reality and help the reader understand which standard may best fit individual use cases. This post will cover the different credential formats, while future posts will go into more detail on other elements of the ecosystem. 

This blog post is #2 in our series on Verifiable Digital Credentials (VDCs) and assumes that readers have a basic understanding of VDC concepts, which we discuss in our previous post

Understanding mDL Credential Formats

Hand holding phone
Credit: Bill Fisher, NIST

If you’ve ever been asked to scan a QR code to show your boarding pass or concert ticket, you’ve already experienced how VDCs can simplify real-world transactions. But not all VDCs work the same way. Behind the scenes, different credential formats shape how your information is stored, shared, and verified.

As VDCs gain traction for both in-person and online identity verification, understanding the technical foundations becomes essential. Two key standards are helping to define this space: ISO/IEC 18013-5, which underpins mobile driver’s licenses (mDLs) and related mobile documents (mdocs), and the World Wide Web Consortium’s (W3C) Verifiable Credentials (VC) credential formats.

So how do these credential formats differ? And what does that mean for implementers, developers, and users?

What’s a Credential Format, Anyway?

Think of a credential format as a blueprint. It defines what information is in the credential (like name or date of birth) and how that information is structured and packaged for transmission and verification. Credential formats influence everything from how credentials are issued to how they’re used in practice.

Both ISO’s mDL standard and the W3C Verifiable Credential standard aim to support secure, privacy-respecting credential exchange. But they do so in very different ways, because they were built from different starting points.

Two Formats, Two Paths

The ISO/IEC 18013 specifications were initially designed for mobile driver’s licenses and define the mdoc credential format. It’s part of a larger family of standards focused on how organizations issue and validate credentials for identification. The ISO mdoc model is tightly coupled: it defines not only the structure of the data, but also how the credential is transferred from your phone to a verifier using in-person technologies like near-field communication (NFC) or Bluetooth or web protocols, which we’ll cover in a later blog post.

In contrast, the W3C Verifiable Credential Data Model (VCDM) was created for a broader digital ecosystem. It defines a way to describe any kind of credential—academic degrees, memberships, licenses, and more—and is intentionally flexible about how credentials are presented. The W3C model focuses on remote, web-based use cases, where credentials might be shared via a browser, app, or other digital interface.

Here’s a quick comparison:

 

mdoc

Verifiable Credentials

SpecificationsThe mdoc framework is defined across the ISO 23220 and ISO 18013 series of documents. 18013-5 specifically focuses on in- person presentation of mdocs, while 18013-7 covers online presentation of mdocs.The Verifiable credential format is defined by the W3C Verifiable Credential Data Model.
Primary Use CaseThe mdoc credential format was originally developed to support government-issued mobile IDs, such as state or national driver’s licenses or ID cards. However, it is not limited to those deployments. Because mdocs define a standardized, interoperable way to represent identity attributes, they are increasingly being explored for non-government use cases that require high assurance and predefined data structures—such as healthcare, corporate identity, and regulated industry credentials. Most current deployments are in-person, but active work is extending mdoc use to online and cross-sector applications.Verifiable Credentials were designed from the start to support a broad range of digital interactions. They are most often used in remote or online workflows, such as verifying qualifications, memberships, or attributes across web services. Their flexibility makes them especially well-suited to scenarios where data schemas vary by context or where decentralized issuance is preferred.
Data Formatmdocs use a predefined, standardized data schema that defines exactly which attributes can appear in a credential and how they are encoded. The format is based on CBOR (Concise Binary Object Representation), which provides a compact and efficient structure suitable for constrained environments like mobile devices.VCs use a flexible data structure, most often expressed in JSON-LD (JSON for Linked Data). This flexibility allows issuers to define custom attributes and schemas tailored to specific use cases, supporting everything from enterprise credentials to niche, community-based attestations.
Standardization BodyThe mdoc standard is developed under ISO/IEC, where participation is typically led by national standards bodies and government organizations, with significant input from private-sector technical experts and industry participants. Access to the specifications generally requires purchase.The Verifiable Credentials standard is developed within the World Wide Web Consortium (W3C), an open, web-industry consortium. Participation is open to individuals and organizations, and the specifications are freely available to the public. This open process encourages broad collaboration and faster iteration.
Credential VocabularyThe ISO approach defines a fixed and controlled vocabulary for identity attributes, ensuring that all conformant mdocs represent data in a consistent and interoperable way across jurisdictions. This is particularly beneficial for official credentials that must meet regulatory and legal requirements.The W3C approach allows issuers to define their own credential vocabularies and schemas. This openness promotes innovation and supports a wide range of credentials, but it also means interoperability depends on voluntary coordination and shared registries rather than strict standardization.

Why Do These Differences Matter?

While both models can support verifiable digital credentials, the differences in their technical structure have real-world implications.

  • Use Case Fit: The predefined data structure of mdocs has made them a popular choice for high-assurance use cases, both online and in-person. Most current deployments focus on government-issued credentials where in-person presentation is common. However, ISO/IEC 18013-7 expands this model to support remote use, enabling mdocs to be used for online onboarding, regulated transactions, and cross-border verification. W3C Verifiable Credentials, by contrast, were built from the outset for web-based interactions. They excel in distributed and decentralized environments where organizations issue and verify various credential types, such as educational achievements, professional certifications, or access tokens used on digital platforms.
  • Integration Complexity: Developers and organizations may find one credential format easier to work with depending on their existing infrastructure and how verification is implemented. In practice, much of the complexity falls on the verifier—whether an internal system or a third-party product—to correctly handle different credential formats and associated trust models.
  • Interoperability and Ecosystem: ISO’s work ensures an mDL issued in one jurisdiction can be used in another. For example, more than a dozen U.S. States are issuing mdoc based mDLs which can be presented across the country at TSA PreCheck to board a plane. In parallel, large-scale efforts such as the EU Architecture Reference Framework (ARF) and EUDI Wallet programs are driving cross-border interoperability for both mdoc-based credentials and W3C-aligned VCDM formats.

Can’t We Just Pick One?

In a perfect world, one standard might serve all use cases. But digital identity is not one-size-fits-all. Different sectors, geographies, and technical environments have different needs. And because digital credentials often intersect with regulation, security, privacy, and user experience, organizations may need to support more than one standard.

At NIST’s National Cybersecurity Center of Excellence (NCCoE), we’re exploring how these models can work together. The first use case under our mDL project is focused on helping financial institutions accept mobile driver’s licenses for identity verification and online account creation, while ensuring security and privacy. As part of this project, the NCCoE worked with a team of industry collaborators to successfully demonstrate how a single verifier could interoperate with multiple digital wallets presenting mDLs in both mdoc and VC credential formats – a critical first step to realizing these technologies at internet scale.

What’s Next?

The landscape is still evolving. Critical features, like advanced privacy protections, support for presenting multiple credentials, and reliable cross-device flows, are still in development across standards bodies. As adoption grows, industry feedback will help shape future updates.

If you’re working in this space, now is the time to get involved!

  • Want to share feedback on how these models fit (or don’t fit) into your systems?
  • Curious how mDLs might complement or compete with existing credential flows in your organization?

We want to hear from you!

📨 Join our mDL community of interest to receive project updates and opportunities to collaborate. Sign up here or email us at mdl-nccoe [at] nist.gov (mdl-nccoe[at]nist[dot]gov).

📰 Provide feedback on project deliverables by visiting our mDL pages site.

Stay tuned for our third blog post in this series, which will dive into the standards that support the mDL issuance process. Together, we can help define how trustworthy digital identity works—online and in the real world.

 

About the author

Bill Fisher

Bill Fisher is a security engineer at the National Cybersecurity Center of Excellence (NCCoE). In this role, he is responsible for leading a team of engineers that work collaboratively with industry partners to address cybersecurity business challenges facing the nation. He lead the center’s Attribute Based Access Control (ABAC) project and was a member the ITL Cybersecurity for IoT program. He lead’s the NCCoE Public Safety and Data Security programs and is a member of the NCCoE ransomware team. Recently he joined as co-lead on the NCCoE mobile driver’s license (mDL) project

Ryan Galluzzo

Ryan is the Digital Identity Program Lead for the Applied Cybersecurity Division at the National Institute of Standards and Technology (NIST). In this role he coordinates digital identity projects, initiatives, and efforts to advance NIST’s standards & guidance and drive foundational research to promote innovation in digital identity. He has contributed to multiple NIST Special Publications including NIST SP 800-63 Digital Identity Guidelines. Prior to joining NIST, Ryan was a Specialist Leader at Deloitte & Touche where he spent over 10 years providing cybersecurity and identity management subject-matter insights to multiple federal agencies, including the Internal Revenue Service (IRS), the General Services Administration (GSA), and NIST.

Heather Flanagan

Heather Flanagan is the Principal at Spherical Cow Consulting. With more than 15 years of experience translating complex technical concepts into clear, actionable strategy, Heather is known for her ability to bridge communities, guide collaborative work, and make standards development a little less intimidating.  Heather is also a regular speaker and writer, focusing on standards, governance, and the real-world challenges of identity implementation.

Related Posts

Comments

Add new comment

CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Please be respectful when posting comments. We will post all comments without editing as long as they are appropriate for a public, family friendly website, are on topic and do not contain profanity, personal attacks, misleading or false information/accusations or promote specific commercial products, services or organizations. Comments that violate our comment policy or include links to non-government organizations/web pages will not be posted.
Was this page helpful?