Verifiable Digital Credential Presentment

In earlier posts, we discussed how verifiable digital credentials (VDCs) are issued and compared the underlying credential formats (ISO/IEC “mdoc” vs. W3C Verifiable Credentials). In this post, we turn to the other side of the story: presentation; that is, how a holder shows their VDC to a verifier at runtime in both in-person and online contexts. We’ll again explore the mobile driver’s license (mDL) use case, consider the differences between ISO/IEC 18013-5 and 18013-7, and discuss the current technical and usability challenges that implementers must address.

In-Person vs. Online mDL Presentation: 18013-5 and 18013-7

One useful way to frame mDL presentation is by distinguishing in-person (attended) use from remote or online (unattended) use. In both cases, the underlying credential remains the same ISO-defined mdoc; the difference lies in how that credential is presented to a verifier. The ISO/IEC standards reflect that separation:

• ISO/IEC 18013-5 is primarily focused on in-person presentation scenarios, where a verifier (e.g., a reader device) is physically present and can interact directly with the holder’s device and their credentials. Think about an experience similar to mobile payments where you tap your phone to a device at a terminal or checkout. In this model, a secure device-to-device connection is established over near field communication (NFC) or through a QR code and data is then transferred over that secure channel using bluetooth low energy (BLE), NFC, or Wi-Fi Aware technology.
• ISO/IEC 18013-7 is a newer technical specification that builds on ISO/IEC 18013-5 and adds support for presenting an mDL over the internet, enabling remote presentation scenarios where the verifier and holder are not physically co-located. Often, this occurs through the scanning of a QR code that kicks off a process to establish a secure connection between your device and the online verifier you are interacting with (and allows you to present credentials in your digital wallet).

Because mDL holders will encounter both online and in-person use cases, the holder’s device and wallet should be capable of responding to both remote presentation requests (if using ISO/IEC 18013-7) and handling traditional device-to-device exchanges under 18013-5. While not all mDLs issued today are in wallets that support both forms of presentation, movement towards support for both physical and online presentation models is essential to adoption.

Example In-Person Use Cases

Here are a few scenarios where mDLs presented in person yield clear benefits, often resembling how mobile payments or contactless systems are already used:

• Airport security (TSA pre-check or checkpoint identity): A traveler presents their mDL at a checkpoint reader, which verifies the credential cryptographically and confirms identity attributes such as name and date of birth. Because this is an attended transaction, the verifier can ensure live interaction and possibly request biometrics or challenge-response operations.
• Age verification at point-of-sale (POS): At a retail checkout or bar, a POS-connected reader (for example, integrated into a cash register) requests “over-21?” (or equivalent). The user’s mDL wallet responds with only the minimal attribute required (e.g., yes/no).

In these settings, latency, reliability, and minimal friction are critical; many of the same design principles in mobile payments—user experience, fallback paths, trust frameworks—also apply.

Online Presentation Protocols

While in-person mDL presentation is an important use case, online presentation of mDLs and other VDCs is expected to be the more common use case. For this reason, the NCCoE mDL project focused exclusively on mDL presentation in remote contexts. Within ISO/IEC 18013-7, the specification offers two protocol options for online mDL presentation:

1. Annex B and Annex D (currently in draft) of ISO/IEC 18013-7 specifies the use of OpenID for Verifiable Presentation (OID4VP) protocol. Because OID4VP is an OpenID Foundation (OIDF) spec, 18013-7 references out to OIDF specifications for implementation. The major distinction between Annex B and Annex D is in how the credential is transferred, with Annex B using HTTP redirects (which include the ability to use custom schemes) and Annex D using the World Wide Web Consortium (W3C) Digital Credentials API (DC API) - a specialized API designed to enable integration of Digital Credential requests through a user’s browser. Annex D also aligns to the High Assurance Interoperability Profile (HAIP) for OID4VP, which has enhanced security properties. OID4VP supports multiple credential formats, including mDOC.
2. 18013-7 outlines a second presentation protocol in Annex C of the document. This protocol builds on the presentation framework outlined in 18013-5 and uses the device retrieval method and the DC API to establish a session with the holder’s device and request credentials in the holder’s wallet. Annex C currently only supports the mDOC format, but work is ongoing to expand this support to Selective Disclosure JSON Web Tokens (SD-JWT).

In-person and online presentation are not mutually exclusive; they are complementary modalities that mDL systems increasingly need to support.

Example Online (Remote) Use Cases

When ISO/IEC 18013-7 remote presentation is supported, a wealth of new use cases emerge, many of which are already being explored in pilots and early deployments. Some possible examples:

• Online financial account creation/KYC/onboarding: A user opens a bank account or financial service via web or mobile app. Rather than uploading photos or scanned IDs, the service sends an mDL presentation request (via OID4VP or device-based channel), and the user consents to provide verified identity attributes. The verifier checks the signature and optionally queries revocation or status.
• Age verification for digital services: A website or mobile app requests proof of age (e.g., “over 18”) before allowing access to restricted content or purchases. The user can respond with an mDL-based credential exchange without needing to upload a copy of their driver’s license.
• Access to government services and portals: A state or federal web portal may require that a user present a government-issued mDL to access secure services, such as filing tax returns, renewing licenses, or accessing government benefits.
• Remote identity verification: Renting a car online in advance, verifying identity to a telehealth app, onboarding to a new job, or submitting credentials to a regulated service (e.g., financial, insurance) without in-person steps.

These use cases depend on robust remote-presentation support, interoperability across wallets and verifiers, and user flows that handle cross-device transitions (e.g., the user is on a laptop but the credential is on their phone).

Challenges & Barriers to Adoption

While the promise is strong, several technical, usability, and architectural challenges remain in building practical mDL presentation systems.

Multi-Wallet and Multi-Credential Flows

Users may carry multiple wallet apps or want to present multiple credentials at once, either from the same wallet or across different wallets. Deciding which wallet to use, how credentials are presented, and how flows are routed becomes both a user experience and a privacy challenge. Users must know the specific wallet they are using, and consent to the specific credential and information they are presenting. Additionally, users should not be trained to present more information than is necessary to relying parties and verifiers. As such, user flow and experience for these more complex multi-wallet and credential flows are still being tested and developed. As we move forward, it’s expected the DC API will help standard these flows across platforms.

Interoperability & Versioning

Several key components of the mDL remote presentation ecosystem are still relatively new, including OID4VP, and ISO/IEC 18013-7 Annex C. Because these standards are maturing at the same time, implementations often reflect different interpretations, feature sets, or draft-era assumptions. Wallets and verifiers may support overlapping but not identical capabilities, such as specific cryptographic options, device-binding mechanisms, or cross-device flow patterns. Versioning and feature negotiation therefore become important considerations, particularly as updates are made to improve security, usability, or interoperability.

Ensuring consistent features across wallet vendors, verifier implementations, and relying-party systems will require continued coordination across standards bodies, open-source projects, and pilot deployments. Reference architectures that meet real-world needs and interoperability testing play a critical role in identifying gaps early and helping implementers converge on approaches that work reliably at scale.

Presentation Protocol Complexity

While current online presentation protocols have provided an interoperable way for wallets to present mDLs and for verifiers to request and accept them, having two different credential presentation protocols has created complexity and cost in the ecosystem. If wallets and verifiers want to support users across all platforms, their products must implement and maintain each protocol. To reduce this complexity and cost, an OIDF working group is now being chartered to harmonize these credential presentation protocols. As the ecosystem evolves, we expect to see a unified approach to online mDL presentation and anticipate convergence across online and in-person presentation as well.

Revocation Handling

Verifiers are responsible for ensuring that a presented mDL is valid at the time of presentation (for example, not expired or cryptographically invalid), as they ultimately bear the risk of relying on an outdated or compromised credential. To do this, verifiers typically rely on an up-to-date set of trusted issuer public keys and metadata, which can be refreshed periodically or distributed in batches. To limit the exposure of potential credential compromise, issuers refresh credentials frequency, however some latency remains where invalid credentials may remain active for a short period of time after they are revoked.

In some scenarios—particularly remote or higher-risk transactions—additional credential status information may be desired by the relying party. Revocation lists, status services, or other issuer-provided mechanisms support this, as can information in the credential itself (such as issuance date, or information from the wallet such as credential revocation freshness metadata). Emerging standards such as IETF's Token Status List (Active Internet Draft) are gaining traction (and will be referenced in the next version of 18013-5) as potentially valuable tools to more rapidly and effectively address revocation status while preserving the independent nature of the issuer-verifier interactions. While mDLs are much easier to revoke than a physical IDs or other identity documents, designing systems that balance security, privacy, and availability while ensuring stale credentials are appropriately rejected, remains a key architectural challenge.

W3C Digital Credentials API

The DC API is a spec developed by the W3C that specifies an API enabling user agents to mediate the presentation of digital credentials, such as mDL and VDC, through a browser. The spec is currently under development, but is supported by both Chrome and Safari today, with support planned for Firefox. The DC API was developed to help address several of the challenges listed above to include providing a consistent user experience and to help establish phishing resistance cross-device VDC presentation. Our next blog post will highlight the DC API and other evolving standards work that fills gaps to support the mDL ecosystem.

Connecting to the NCCoE mDL Project

The NCCoE mDL project’s financial onboarding/KYC use case demonstrates mDL presentation using OID4VP over the DC API during financial account opening and for high-risk transaction authorization.

The project’s online resource hub contains interactive architecture and interaction diagrams, a Privacy Risk Assessment Methodology (PRAM), and an mDL usability assessment which help flesh out technical considerations and challenges behind these use cases.

By building its reference implementation, NCCoE aims to surface real-world design tradeoffs and interoperability challenges that implementers are likely to encounter as mDL adoption expands.