Login IDV integration pattern
This integration pattern is used to verify a credential presented online when attempting to log into an existing service from a different device.
Overview
- Issuance channel: Remote, Unsupervised
- 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
Attempting login in from a different device
Samantha already has an existing account and is logged in on her native mobile app. Now, she wants to log into her account on her desktop computer for the first time.
Request for identity verification
When attempting to log in, Samatha is offered the option to login using her Identity documents, such as a Mobile Driver’s License (mDL), another verifiable mobile credential (mDoc), a physical document scan, or an alternative ID verification option. She decides to submit her mDL.
Scanning a QR code
A QR code is displayed on Samantha’s desktop screen, and when she scans it with her mobile device, it invokes a mobile application (e.g. wallet) holding the matching mDL.
Sharing credentials
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.
Continue interaction
Once mDL is shared on the mobile application, Samantha can continue the interaction on her desktop browser.
Successful login
Upon successful verification of her mDL, Samantha is logged in to the web application.
Architecture
Interacting with the website
The user is using a web browser on their desktop to access a website where they attempt to log into a service where they already have an active account. They are logged into this service on their mobile device.
Requesting an mDL for verification
One of the options to login on their desktop browser is to present an mDL for verification. This mDL will then be compared with information stored as part of the initial account setup.
This is achieved by embedding the MATTR Pi Verifier Web SDK into the web application and requesting the user to display an mDL for verification.
When the user agrees to proceed, the Verifier Web SDK makes a request to a configured MATTR VII Verifier tenant. That request defines what credentials and claims are required for verification.
The MATTR VII verifier tenant is configured with the following:
- What domains it can accept requests from.
- What workflows it supports (e.g. same-device and/or cross-device).
- What wallet applications it can interact with.
- How to invoke these supported wallet applications.
The MATTR VII verifier tenant recognizes that the user began the interaction on a desktop browser and responds with a link that is rendered as a QR code by the Verifier Web SDK inside the web application.
The user then scans that QR code with a mobile device to invoke a matching native application which includes the required mDL.
Presenting request details to the user
Once the wallet is launched, it authenticates the user and interacts with the MATTR VII tenant to retrieve and display the request details to the user:
- What credentials are requested.
- What claims from the credentials are requested.
- Whether the relying party is vetted by the digital trust service, and whether they are allowed to request this type of information.
- What matching credentials are available and can be shared with the verifier.
Based on that information, the user can select to proceed with the verification workflow and share the required information with the verifier.
Verifying the mDL
The MATTR VII verifier tenant verifies the shared credentials to validate that:
- The information has not been tampered with.
- The credential has not been revoked or suspended.
- The credential has not expired.
- The credential was issued by a trusted issuer (based on information retrieved from the DTS).
Displaying verification results
The MATTR VII verifier tenant shares the verification results with the Verifier Web SDK. These results can then be compared to existing databases to verify that this is the same user who created the account.
Upon successful verification, the user is logged into their account on their desktop browser.