How to verify a mobile driver's licence in your application

Mobile driver's licences (mDLs) are becoming the standard for identity verification across government services, financial institutions, age-restricted retail, travel, and healthcare. As an implementer, you need a verification solution that handles the complexity of standards compliance, trust establishment, and cross-platform support—without requiring deep cryptographic expertise.

This guide walks you through the key decisions and steps for adding mDL verification to your application, whether you're verifying in person at a counter, remotely through a website, or within a native mobile app.

How mDL verification works

An mDL is a digital credential stored in a holder's wallet, issued by a government authority. Unlike traditional document scans or OCR (optical character recognition)-based checks, mDL verification is cryptographic: your application validates a digitally signed credential against a trusted issuer's certificate chain.

This means:

• No visual inspection required: Verification is automated and tamper-evident.
• Selective disclosure: Holders share only the data points you request (e.g., "over 18" without revealing full date of birth).
• Offline capable: In-person verification can work without network connectivity.
• Standards-based: Built on ISO/IEC 18013-5 and ISO/IEC 18013-7, ensuring interoperability across wallets and issuers.

Choose your verification channel

The first decision is where and how your users will present their mDL. Each channel has different technical requirements, user experience characteristics, and standards underpinnings.

In-person verification (ISO/IEC 18013-5)

Best for: retail counters, border control, event entry, age verification at point of sale.

The holder presents their mDL by displaying a QR code or initiating a BLE connection from their wallet. Your verifier application reads the credential over a proximity channel, validates it cryptographically, and returns the result—all within seconds.

• Uses Bluetooth Low Energy (BLE) for secure device-to-device communication.
• Supports offline verification.
• Aligned with ISO/IEC 18013-5.

MATTR tooling: MATTR Pi Verifier SDKs for iOS, Android, and React Native.

Remote web verification (ISO/IEC 18013-7 + OID4VP)

Best for: online account opening, e-commerce age gates, government service portals, insurance applications.

Your web application initiates a verification request. The user's wallet receives the request (via redirect or the Digital Credentials API), the user consents to share specific attributes, and the verified result is returned to your backend.

• Supports same-device and cross-device flows.
• Uses OID4VP as the presentation protocol.
• Aligned with ISO/IEC 18013-7.

MATTR tooling: MATTR Pi Verifier Web SDK + MATTR VII as the backend verification service.

Remote mobile verification (ISO/IEC 18013-7 + OID4VP)

Best for: native mobile apps for banking, ride-sharing, age-restricted delivery, telehealth.

Your native app triggers a verification request using the embedded Verifier SDK. The wallet app on the same device (or a secondary device) responds with the credential presentation.

• Direct app-to-wallet communication on the same device.
• Supports cross-device scenarios where the wallet is on a different device.
• Uses OID4VP for interoperable credential exchange.

MATTR tooling: MATTR Pi Verifier Mobile SDK + MATTR VII as the backend verification service.

Decide what data you need to verify

mDL verification supports selective disclosure, meaning you only request the specific data elements relevant to your use case. Common verification scenarios include:

When configuring your verifier, you define a presentation request that specifies which data elements to request from the credential. Both MATTR VII and the MATTR Pi SDKs support flexible presentation requests that map directly to the ISO/IEC 18013-5 namespace (org.iso.18013.5.1).

Embed the SDKs into your application

MATTR provides SDKs that abstract the protocol complexity so you can focus on your user experience.

Integration approach

The recommended approach is to embed the MATTR Pi Verifier SDK directly into your application rather than redirecting users to an intermediate verification service. This:

• Maintains trust continuity—wallets validate your app's origin directly.
• Delivers a seamless user experience without navigation interruptions.
• Ensures compatibility with platform-specific security requirements.

See implementation guidelines for detailed guidance on direct integration.

SDK options by channel

Backend configuration (remote channels)

For remote verification (web and mobile), you also need a MATTR VII tenant configured with:

• A verifier application registered with your domain or app identifiers.
• A wallet provider configuration for each wallet ecosystem you accept.
• Trusted issuer certificates for the jurisdictions you support.

Establish trust with issuers

For mDL verification to work, your application must trust the issuer's signing certificates. This is managed through Issuing Authority Certificate Authority (IACA) certificates—the root certificates published by government authorities that issue mDLs.

How trust works

1. Each government issuer publishes IACA root certificates. This can be done at the state, territory, or national level depending on the jurisdiction.
2. Your verifier is configured with a list of trusted IACA certificates.
3. During verification, the SDK validates that the mDL's signature chains back to a trusted IACA certificate.
4. If the chain is valid, the credential is trusted. If not, verification fails.

Managed trust lists from MATTR

Maintaining an up-to-date list of IACA certificates across multiple jurisdictions is operationally complex. Certificates rotate, new issuers come online, and different states or territories may publish certificates independently.

MATTR provides managed trust lists that include verified IACA certificates for mDL issuers:

• Australia — all state and territory issuers.
• United States — state-level issuers participating in mDL programmes.
• Additional jurisdictions as they come online.

These managed lists are kept current by MATTR, reducing your operational burden and ensuring your application stays compatible as new issuers join the ecosystem.

Configuring trusted issuers

• In-person (SDK): Load trusted IACA certificates into the SDK's local trust store.
• Remote (MATTR VII): Use the MATTR Portal or the Create a Trusted Issuer API to register IACA certificates on your tenant.

Handling verification results

When verification completes, your application receives a structured result containing:

• Verification status: Whether the credential passed all checks.
• Disclosed claims: The specific data elements the holder consented to share.
• Verification checks performed: Signature validity, issuer trust, expiry, revocation status.
• Failure details: If verification failed, the specific reason.

Your application logic should handle both success and failure paths gracefully. For detailed guidance on interpreting and acting on results, see:

• Handling in-person verification results
• Handling remote web verification results

Frequently asked questions

What standards does mDL verification use?

mDL verification is based on ISO/IEC 18013-5 for in-person (proximity) verification and ISO/IEC 18013-7 for remote (online) verification. Remote verification uses OID4VP as the presentation protocol, as specified in ISO/IEC 18013-7 Annex B.

Can I verify mDLs offline?

Yes. In-person verification using the MATTR Pi Verifier SDK operates over BLE and can perform full cryptographic verification without network connectivity. Trusted issuer certificates and revocation status lists are cached locally. Remote verification requires network connectivity.

Which wallets are supported?

MATTR's verification SDKs are interoperable with any wallet that implements ISO/IEC 18013-5 (for proximity) or ISO/IEC 18013-7 with OID4VP (for remote). This includes Apple Wallet, Google Wallet, and government-issued wallet applications. Specific wallet support is configured through wallet provider registrations in MATTR VII.

How do I handle expired or revoked credentials?

The verification result includes checks for credential validity period and revocation status. Your application should treat expired or revoked credentials as failed verifications and prompt the user to present a current credential. See revocation status checks for configuration details.

What if I need to support multiple jurisdictions?

Configure your trusted issuers list with IACA certificates from each jurisdiction you want to accept. MATTR's managed trust lists simplify this by providing pre-verified certificate bundles for supported regions. Contact MATTR to discuss your jurisdiction requirements.

Do I need both MATTR Pi and MATTR VII?

It depends on your channel:

• In-person only: MATTR Pi Verifier SDK is sufficient for proximity-based verification.
• Remote (web or mobile): You need both MATTR Pi (Verifier SDK embedded in your app) and MATTR VII (backend service that manages trust, sessions, and verification logic).

How long does verification take?

In-person verification typically completes in 1-3 seconds. Remote verification depends on the user's interaction speed with their wallet but the cryptographic verification itself is near-instant once the presentation is received.

What data do I receive after verification?

You receive only the data elements you requested in your presentation definition. The holder must consent to share each element. You do not receive the full credential or any data beyond what was explicitly requested.