Credential Verification

Mobile documents (mDocs) are the emerging standard for high-assurance digital credentials. Mobile driver's licenses (mDLs) are the most prominent and most adopted example to date, but the same verification capabilities apply to any high-assurance credential built on the mDoc family of standards, including national identity cards, residence permits, professional licenses, and other credentials beyond the driver's license.

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 mDoc verification to your application, whether you're verifying in person at a counter, remotely through a website, or within a native mobile app.

How mDoc verification works

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

A complete verification covers both identity and information assurance:

• Identity assurance: resolve the issuer's identifier and confirm the credential was signed by a trusted issuer, typically by checking the issuer's certificate against a local trust list or an external trust registry.
• Information assurance: verify the digital signature to confirm integrity, validate the credential format against its referenced specification, and check that the credential is currently active (not expired or revoked).

In practice, 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). See selective disclosure for the underlying mechanism.
• Offline capable: In-person verification can work without network connectivity.
• Standards-based: Built on ISO/IEC 18013-5, 18013-7 and 23220, ensuring interoperability across wallets and issuers.

Underlying platforms

You can use different MATTR VII, MATTR Pi and/or MATTR GO capabilities to verify different credential formats based on your use case:

• MATTR VII:
  • In-person verification of CWT and Semantic CWT credentials.
  • Remote verification of mDocs.
• MATTR Pi:
  • In-person verification of CWT and Semantic CWT credentials.
  • In-person and Remote verification of mDocs.
• MATTR GO:
  • In-person verification of CWT and Semantic CWT credentials and mDocs.

Choose your verification channel

The first decision is where and how your users will present their credential. 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 credential 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

mDoc 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. For mDLs, presentation requests map to the ISO/IEC 18013-5 namespace (org.iso.18013.5.1). Other mDoc credentials use the namespaces defined by their respective specifications (for example, ISO/IEC 23220-based credentials). Both MATTR VII and the MATTR Pi SDKs support flexible presentation requests across these namespaces.

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 and credential types you support.

Establish trust with issuers

For mDoc verification to work, your application must trust the issuer's signing certificates. The underlying chain of trust model is the same across mDoc credential types, though the terminology differs by credential family.

How trust works

1. Each issuer publishes root certificates. For mDLs, these are Issuing Authority Certificate Authority (IACA) roots, published at the state, territory, or national level depending on the jurisdiction. Other mDoc credential types follow the same chain-of-trust model with their own issuer certificate authorities.
2. Your verifier is configured with a list of trusted root certificates.
3. During verification, the SDK validates that the credential's signature chains back to a trusted root.
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 issuer certificates across multiple jurisdictions and credential types is operationally complex. Certificates rotate, new issuers come online, and different authorities 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 programs.
• 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. For non-mDL mDoc credentials, you configure the issuer's certificates directly through the same trust APIs.

Configuring trusted issuers

• In-person (SDK): Load trusted root certificates into the SDK's local trust store.
• Remote (MATTR VII): Use the MATTR Portal or the Create a Trusted Issuer API to register issuer 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 mDoc verification use?

mDoc 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. For mDoc credentials beyond the driver's license, ISO/IEC 23220 generalizes these foundations.

Can I verify credentials 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 root certificates from each jurisdiction you want to accept. MATTR's managed trust lists simplify this for mDLs by providing pre-verified certificate bundles for supported regions. For other mDoc credential types, register the issuer's certificates through the same trust APIs. Contact us 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.