Introduction: understanding the complexity so your users don’t have to
In our previous blog, we explored the growing need to support multiple verification channels—from in-person NFC to remote web and mobile flows. That flexibility is critical for real-world adoption of digital credentials. But it also introduces a new layer of complexity beneath the surface.
At the infrastructure layer, these different channels are powered by a web of evolving standards, platform-specific constraints and protocol variations. What works in one browser or operating system may not work in another. Each device, wallet, and verifier interaction can trigger a different flow, based on what the underlying platform supports.
But here’s the catch: for mass adoption to succeed, this complexity must never be visible to the end user. Interactions need to feel fast, intuitive, and seamless—regardless of what device someone is using. That’s where abstraction becomes critical. But before we can abstract it, we need to understand it.
This blog is a guide for anyone building or integrating with digital credential systems. We'll unpack how the various ISO standards define credential verification flows, explain what each Annex does, explore how support varies by platform, and ultimately show how MATTR handles this complexity for you—so you don’t have to.
In-person vs remote
At a high level, the ISO/IEC 18013 standard family distinguishes between two types of credential presentation:
- In-person presentation flows, where the holder and verifier are physically co-located. For example, a traveller presents their mobile driver’s license at an airport security checkpoint by tapping their phone on a kiosk or having a security agent scan a QR code from their wallet app.
- Remote presentation flows, where the verifier and holder are in separate locations and the interaction happens over the internet. For example, a user applies for a rental car online and is prompted to share their mobile driver’s license from a digital wallet. They scan a QR code on their desktop screen or get redirected to the wallet app on their phone to approve the credential request.
Each of these categories includes further distinctions, depending on how the devices interact, how data is transferred, and which platform is involved.
In-person verification
ISO 18013-5 governs proximity-based, in-person credential verification. Here’s what a typical user journey looks like:
1. The holder initiates the interaction by opening their wallet app and choosing to present a credential.
2. The holder presents a QR code or taps their phone using NFC to begin the engagement.
3. The verifier sends a request for a credential or specific claims.
4. The holder reviews the request, consents, and the wallet responds with the required information.
5. The verifier validates the credential data and concludes the session.
Flavours of engagement
There are multiple ways to initiate the connection (known as device engagement) between the holder and verifier:
- QR code (device engagement): The holder displays a QR code, which the verifier scans to initiate a secure handshake.
- NFC: The holder taps their phone on the verifier’s device to initiate a secure handshake.
Before diving into platform differences, it’s important to understand what NFC is actually used for. While ISO/IEC 18013-5 does define a method for using NFC to transfer credential data, this approach is not commonly used due to performance limitations. Instead, NFC typically serves as a mechanism for device engagement—a fast and simple way to initiate a secure communication channel between devices.
The actual credential data is usually transmitted over BLE (Bluetooth Low Energy), as defined in ISO/IEC 18013-5.
Performing either the holder or verifier role in NFC-based device engagement requires access to specific NFC capabilities—particularly for the more commonly used variant, Negotiated Handover.
On mobile platforms, Android provides open access to the necessary NFC functionality to build either a verifier or holder application capable of NFC-based device engagement. In contrast, iOS restricts access to this functionality, requiring specific application entitlements to enable it. These entitlements are required by Apple and must be requested and approved as part of their app development and distribution process.
Remote verification
ISO/IEC 18013-7 introduces more flexibility and complexity by enabling remote credential verification across web and mobile applications. The standard outlines two key dimensions for defining remote flows:
Wallet Interaction type
Request type
The ISO 18013-7 specification defines specific annexes that combine the request and interaction types in different ways:
* Annex D as defined in ISO 18013-7 is still in draft and is expected to appear in a future version of the standard. However, the underlying protocol of OID4VP (including usage over the Digital Credentials API) is now an official standard published by the OpenID Foundation.
In addition to the ISO defined flows, Apple provides a separate mechanism for same-device app-based verification: Verify with Wallet. This native API enables direct communication between verifier and wallet apps on iOS devices, offering a smoother experience in same-device flows.
Which flows are supported where?
To simplify integration planning, here’s a breakdown of which annexes and protocols are supported by platform and channel, and how they map to MATTR’s product availability.
Verifier mobile applications
Verifier web applications
You focus on your users, we’ll handle the protocols
Delivering seamless digital credential experiences shouldn’t require you to track every technical nuance across evolving standards, platforms, and device capabilities. Your job is to build trusted, user-friendly services—not to decode annexes or rewrite code every time a new version of a spec is released.
With MATTR’s Pi SDKs and the MATTR VII platform, all of that complexity stays under the hood. You don’t need to worry about:
- What device your user is on
- What browser they’re using
- Which wallet or standard is in play
- Or whether the spec changed last month
We make sure it just works
Whether your use case involves in-person verification at a kiosk or remote presentation through a website or app, MATTR manages the underlying protocol and stays aligned with the latest standards—so your solutions remain consistent, secure, and future-ready.
You can focus on delivering value to your customers. We’ll take care of everything else.
Want to dive deeper?
- Try a developer tutorial to see how quickly you can get started.
- Let’s work together to bring your use case to life.
