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
Selecting a credential to present
Samantha uses her digital wallet to select a credential to present. This generates a QR code on her wallet.
Establishing a secure connection
The verifier uses their device to scan the QR code directly form Samantha’s digital wallet and establish a Bluetooth connection between the two devices.
Once a secure connection is established, the verifier creates a presentation request and shares it with Samantha’s device.
Reviewing the presentation request
Samantha’s wallet uses the presentation request to locate any matching credentials, and displays them to Samantha with an indication of what information she is about to share with this verifier.
The wallet can optionally check the verifier against the Digital Trust Service and make sure they are allowed to request this type of information.
Once Samantha consents to sharing the information, the wallet bundles it as a presentation response, signs it and returns it to the verifier.
The verifier receives the presentation response
The verifier receives the presentation response and performs the required verification checks.
Verification results
The verification result is displayed to the verifier.
Architecture
Establishing the connection
The user uses their MATTR Pi or MATTR GO digital wallet (1) to choose a credential for verification, 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, scans the presented QR code to set up a secure Bluetooth Low Energy (BLE) connection with the Holder’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 holder, indicating what information is requested by the verifier.
If any of the matching credentials support selective disclosure, the holder can share only the required information, and nothing extra. This is an optional capability that increases the privacy-preserving features of this workflow.
The wallet can also check the verifier against a Digital Trust Service (3) to ensure they are allowed to ask for this type of information in the context of the current trust network. This is an optional capability that enables network operators to add another layer of trust to their network.
Sharing the information
The holder 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).
The only reliance the verification has on the issuer is calling an online revocation list (if the credential has revocation properties), which the credential issuer may host, to check the status of the credential being presented.
No information relating to the verifier or the context in which the holder is utilizing the credential is shared or available to the issuer.