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).
Journey flow
Depositing a physical check
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
- Samantha’s identity document
Scanning the check
The bank clerk starts by scanning the check with his mobile device to verify its authenticity and validity.
Initiating an mDL verification workflow
Next, the bank clerk wants to verify Samantha’s mDL. She uses a native application (e.g. wallet) on her mobile device to display a QR code, which is then scanned by the bank clerk with his mobile device.
Reviewing the verification request
Samantha is presented with a summary of the information from her mDL that will be shared during this process. She is then required to provide her consent and complete device authentication before proceeding with the data sharing.
Verifying the mDL and completing the interaction
Once the mDL is successfully verified, Samantha’s identity is confirmed and the bank clerk can proceed with processing the check deposit.
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.
Sharing the information
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.