mDocs in-person verification journey pattern

This journey pattern is used to verify an mDoc in-person via a proximity verification workflow, as per ISO/IEC 18013-5:2021.

Overview

• Issuance channel: In-person, supervised
• Device/s: Cross-device
• Formats: mDocs
• Information assurance level: High
• Identity assurance level: High

Journey flow

Architecture

Establishing the connection

The user opens their digital wallet app on their mobile device and selects a credential they wish to present. They then establish a secure connection with the verifier in one of the following ways:

The wallet app displays a QR code on the screen. The verifier application, which may be operated by a person or run on a self-service kiosk, scans this QR code using its device. Scanning the QR code initiates a secure Bluetooth Low Energy (BLE) connection between the two devices.

On Android devices, the BLE connection can also be initiated via NFC tap.

Sending a presentation request

Once the secure connection is established, the verifier application sends a presentation request to the wallet app. This request includes:

• The specific information being requested (e.g. claims or attributes from a credential).
• The identity of the verifier making the request.
• The required assurance level for the data.
• Instructions on how and where the response should be returned.

Reviewing the presentation request

The wallet app processes the presentation request and identifies any matching credentials stored on the device. It presents this information to the user, showing:

• Which credential(s) can satisfy the request.
• Exactly what data will be disclosed if the user proceeds.
• Whether selective disclosure is available for that credential, allowing the user to share only the requested claims.
• Whether the verifier is trusted, using information from a Digital Trust Service configured for the current trust network.

Sharing the information

If the user consents, the wallet app:

• Creates a verifiable presentation using the selected credential and requested data.
• Cryptographically signs the presentation.
• Sends the signed presentation back to the verifier app over the BLE connection.

Verifying the information

The verifier application receives the presentation and performs a series of verification checks, including:

• Validating the digital signature to confirm the data has not been tampered with.
• Checking that the credential has not been revoked or suspended, using a revocation list (if applicable).
• Verifying that the credential is currently valid, based on its “valid from” and “valid until” dates.
• Ensuring the credential was issued by a trusted issuer, based on information retrieved from a Digital Trust Service.