mDocs remote verification
MATTR’s remote verification capabilities implement the OID4VP specification. While OID4VP supports online presentation and verification of other credential formats, MATTR’s implementation is specific to online presentation and verification of mDocs, as per ISO/IEC 18013-7:2024 .
Remote verification is a digital interaction between two entities:
- The holder of an mDoc (typically stored in a digital wallet application).
- The verifier (or relying party) who needs to establish trust with information contained in that mDoc.
Basic OID4VP workflow
The interaction comprises the following steps, based on the OAuth 2.0 mechanism :
Authorization request
When a user interacts with a verifier application which requires presenting an mDoc, the verifier application responds with a request URI.
The verifier can configure the request URI to invoke any registered wallet application or define a specific registered wallet application that will be used to handle this authorization request.
The wallet uses the request URI to retrieve the request object, which includes a presentation definition detailing the information the verifier requires. It can include the type and format(s) of credential(s) and any individual claims required from those credential(s).
Gathering matching credentials
The wallet determines what available mDocs match the presentation request, authenticates the holder and requests for consent to present the required information. Upon consent, the wallet creates a verifiable presentation(s) from matching verifiable credential(s) the holder has consented to share.
Authorization response
The wallet sends the encrypted verifiable presentation response to the verifier’s application
response endpoint as an authorization response. This response includes a verifiable presentation
contained inside a vp_token parameter. The verifier provides a secure redirect URL in the response
to redirect the user back to where they started the interaction.
Verifying the verifiable presentation
Once the verifier receives the verifiable presentations, they can apply their own business logic and validation rules to verify the content of the presentation.
OID4VP supports both same-device and cross-device verification workflows:
- Same-device workflows involve a single device which houses both the verifier and wallet applications.
- Cross-device workflows involve two different devices:
- The first device houses the verifier application and issues a presentation request.
- The second device houses a wallet application that responds with the requested information.
Same-device verification workflow
Same-device workflows include a single device and two different applications:
- One web/mobile application is used to verify mDocs. It is used to create a presentation request and verify the incoming presentation response. In our example this it the BankApp.
- One mobile application is used to hold and present mDocs. It is used to receive a presentation request, authenticate the holder, gather matching credentials and share them (upon holder’s consent) with the verifier. In our example this is the WalletApp.
This workflow uses simple redirects to exchange the authorization request and response between the two applications.
For example, consider a scenario where a user performs a financial transaction in a banking web application using their mobile device. Upon initiating the transaction, the banking application requests a proof of the user’s identity. The digital wallet receives this request and seeks the holder’s consent to send a presentation response with a matching credential, such as a drivers’ license, national ID card or passport.
Upon receiving consent, the presentation response is signed using a private key with its corresponding public key attested by the issuer and included in the credential. This private key is typically stored in the mobile platform secure key store, which must be unlocked by biometrics, verifying the identity of the holder.
The wallet then sends the presentation response to the verifier, who verifies both the credential and the presentation’s signature. If the public key found in the credential can be used to verify the presentation’s signature, the verifier can confirm the identity of the entity presenting the credential.
With authentication confirmed, the transaction proceeds, all within the confines of the user’s single mobile device.
Same-device flows typically have few variations and predominantly make use of mobile platform features such as deep links and redirects to enable a verifying application to interface with a wallet application.
The technical protocols underlying this flow allow both the verifier and wallet applications to be either platform-native or web-based applications.
Cross-device verification workflow
Cross-device verification workflows include two devices:
-
One device is used to create the presentation request and verify the incoming presentation response.
-
One device is used to receive the presentation request, authenticate the holder, gather matching mDocs and share them (upon holder’s consent) with the verifier.
While the same-device flow uses a deep-link to invoke the digital wallet, in a cross-device flow the link is rendered as a QR code, which is then scanned by the holder to invoke their digital wallet and enable them to present the required credentials. Additionally, at the end of a cross-device flow the holder is not redirected on their mobile device, but rather continues the interaction on the device where they started it.
Following up on our previous example, consider a financial transaction conducted on a bank’s online portal, where the user begins the interaction on their desktop browser. When they are asked to present an mDoc for verification, the user is presented with a QR code which they scan with their mobile device. Upon scanning the QR code, their digital wallet is invoked and displays what information is required by the bank for verification. The user consents to sharing the information, and upon successful verification returns to their desktop browser to complete the interaction.