In-person IDV integration pattern

This journey pattern is used to verify a credential presented via a proximity verification workflow as part of an in-person high-assurance interaction.

Overview

Issuance channel: In-person, Supervised
Device/s: Cross-device
Formats: mDocs
Information assurance level: Very High
Identity assurance level: High (exact identity assurance levels depends on specific IDV blocks implemented in the workflow).

In this interaction, Samantha attempts to complete an in-person process that requires high-assurance IDV, such as walking into a bank to deposit a physical check. The bank clerk is responsible for validating the authenticity and validity of the physical bank deposit check and verifying Samantha's identity using her mDL.

1 / 5

Architecture

In-person IDV architecture

Establishing the connection

The user uses their digital wallet (1) to choose an mDL to present, which renders a QR code on the Holder’s device screen.

The verifier application (2) can be an application built with the MATTR Pi Verifier SDK or a MATTR GO Verify branded application. It is used to scan the presented QR code and set up a secure Bluetooth Low Energy (BLE) connection with the user’s device.

Sending a presentation request

Once the Bluetooth connection is established, the verifier requests specific information by sending a presentation request. This request contains all the information needed for the digital wallet or holding device to understand:

What information is being requested.
Who is asking for it.
Where the wallet should respond to.
Required assurance levels.

Reviewing the presentation request

The digital wallet (1) will locate any stored credentials that match the information specified in the request and present them to the user, indicating what information is requested by the verifier.

The user consents to sharing the information, which is then bundled by the wallet as a verifiable presentation, cryptographically signed, and sent to the verifier application as a presentation response.

Verifying the information

The verifier application (2) interprets and verifies the credentials:

The digital signature is valid, indicating the content of the credential hasn't been tampered with.
It hasn’t been revoked or suspended by the issuer.
The credential is currently valid and hasn't expired yet (based on valid from and valid until values included in the credential).
It’s been issued by an issuer that is trusted to issue this type of credential according to information retrieved from the Digital Trust Service (3).

Verification results are then displayed by the verifier application, enabling the physical interaction to continue accordingly.