light-mode-image
Learn

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 overview 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. Start here, then follow the pages in order or jump to the topic you need.

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).

Verifying a credential does not include evaluating the truth of the claims encoded in the credential. Verification confirms only that these are the same claims signed by the issuer and that the credential has not been tampered with.

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

MATTR Credential Verification capabilities

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

Explore the overview

Work through these pages to design your verification solution from simple to more complex concepts:

  1. Choose your verification channel: in-person, remote web, or remote mobile.
  2. Decide what data you need to verify: selective disclosure and presentation requests.
  3. Embed the SDKs into your application: integration approach, SDK options, and backend configuration.
  4. Establish trust with issuers: trusted issuer certificates and managed trust lists.
  5. Handling verification results: interpreting and acting on results.
  6. Frequently asked questions: answers to common verification questions.

How would you rate this page?

Last updated on

On this page