Remote (online) verification
Remote (online) verification is an implementation of 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, compliant with ISO/IEC 18013-7.
Online (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.
The interaction comprises the following steps, based on the OAuth 2.0 mechanism:
Authorisation request
The verifier sends an authorisation request to the wallet, containing a presentation definition that details what information the verifier requires. This can include what type of credential(s), in what format(s), which individual claims within those credential(s), etc.
The verifier can configure the request to invoke any compliant wallet app, or define a specific wallet app that will be used to handle this authorisation request.
Gathering matching credentials
The wallet determines what available credentials match the verifier’s request, authenticates the holder and requests for consent to share matching credentials with the verifier.
Authorisation response
Upon consent, the digital wallet creates a verifiable presentation(s) from matching mDoc(s) the
holder has consented to share. It then sends a response to the verifier with the verifiable
presentation(s) included in a vp_token parameter.
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.
Let’s look into these two workflows in detail.
Same-device verification workflow
Same-device workflows include a single device which houses two different applications:
- One 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 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 authorisation request and response between the two applications.
Authorisation request
When the holder performs an interaction with the BankApp which requires presenting an mDoc (for example, providing a supporting identity document), the BankApp sends an authorisation request that the WalletApp can respond to.
This request contains a presentation definition that details what information the BankApp 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 WalletApp determines what available mDocs match the presentation request, authenticates the holder and requests for consent to share the required information with the BankApp.
Upon consent, the WalletApp creates a verifiable presentation(s) from matching verifiable credential(s) the holder has consented to share.
Authorisation response
The WalletApp sends the verifiable presentation response via a redirect to the BankApp as an
authorisation response. This response includes a verifiable presentation contained inside a
vp_token parameter.
Verifying the verifiable presentation
Once the BankApp receives the verifiable presentation(s), it can apply its own unique business logic and validation rules to verify the content of the presentation.
Example
Consider a scenario where a user attempts to execute a financial transaction through their mobile banking app. Upon initiating the transaction, the banking app 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 the issuer attested to and is 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 as well as the presentation’s signature. If the private key used to sign the presentation matches the one attested by the issuer who issued the credential, 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. Generally, 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 controlled by the verifier. It is used to create the presentation request and verify the incoming presentation response.
-
One device is controlled by the holder. It is used to receive the presentation request, authenticate the holder, gather matching mDocs and share them (upon holder’s consent) with the verifier.
Request URI
The Verifier renders a verification request as a QR Code, which is scanned by the holder using their digital wallet.
The QR code only includes a Request URI, where the wallet can obtain a Request object with all the required authorisation request parameters.
This keeps the size of the QR Code small and enables signing and optionally encrypting the request object.
Rendering a verification request as a QR code is available for same-device workflows as well.
Obtain request object
The wallet makes an HTTPS GET request to retrieve the request object from the request URI obtained from the QR code.
Request object
The HTTPS GET response returns the request object. It 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 credentials match the verifier’s request, authenticates the holder and requests for consent to present the required information.
Authorisation response
Upon consent, the WalletApp creates a verifiable presentation(s) from matching verifiable credential(s) the holder has consented to share.
The wallet then a makes direct HTTPS POST request to a URL defined and controlled by the Verifier.
This request includes a Verifiable Presentation contained inside a vp_token parameter.
Verifying the verifiable presentation
Once the verifier receives the verifiable presentation, they can apply their own business logic and validation rules to verify the content of the presentation.
Cross-device workflow variations
Cross-device flows cater to a wider array of use cases and, although they all fall under the umbrella of cross-device interactions, they possess distinctive characteristics. These differences are defined by the specific capabilities each flow enables, the foundational assumptions they rely on, the technological infrastructure they utilise, and their inherent features and limitations:
Device control
A typical cross-device presentation flow involves a verifier operating a mobile device with a verification app to authenticate a credential stored in a digital wallet on the holder’s mobile device. Any variations in device control and ownership do not change the classification of the flow as cross-device.
Following up on our previous example, consider a financial transaction conducted on a bank’s online portal:
- The user begins the interaction on their laptop as they visit the bank’s online portal.
- When requested to present an mDoc for verification, they switch to use their mobile device and scan a QR code displayed on the screen. This invokes their digital wallet, which enables them to present the required mDoc for verification.
- Upon completing the verification workflow, the user can return to their laptop and complete the interaction in the bank’s online portal.
Despite a single user controlling both devices, this interaction is still categorised as a cross-device flow.
Applications variability
Cross-device flows offer substantial versatility across varying technological platforms, supporting a broad spectrum of applications from native mobile apps to web applications and even bespoke hardware systems. While they are all used to implement cross-device flows, each employs distinct underlying technologies and capabilities.
For example, one of the current hurdles is that web applications are unable to tap into platform-specific APIs, posing notable security challenges for web-based cross-device flows, mostly the ability to ascertain proximity between the two devices and mitigate replay attacks. Efforts by industry leaders are underway to bridge this gap by enhancing browser APIs to interact with platform APIs. However, until these advancements are rolled out, any implementations will need to navigate these constraints and their security considerations.
Connectivity requirements
Variability in cross-device flows often extends to their internet connectivity needs, which are dictated by the particular demands of the use case or by anticipated usage patterns.
For instance, certain applications, like real-time data verification, necessitate an uninterrupted online connection, while others, such as the verification of mDLs in remote areas, may be designed to function offline.
It’s crucial to recognise this aspect as distinct from the general concept of cross-device flows. An offline cross-device flow presents a set of challenges and capabilities that differ markedly from those of an online-dependent implementation.