DocsIntegrationsPatternsOnboarding IDV (same-device)

Onboarding same-device IDV integration pattern

This integration pattern is used to verify a credential presented online as part of onboarding a customer to a new service via a same-device workflow.

Overview

  • Issuance channel: Remote, unsupervised
  • Device/s: Same-device (Web app to mobile app, Mobile app to mobile app).
  • Formats: mDocs
  • Information assurance level: Very High
  • Identity assurance level: High (exact identity assurance levels depends on specific IDV blocks implemented in the workflow).

Integration pattern

Same device onboarding integration pattern part 1

Opening an account on a mobile device

Samantha starts the process of creating an account with a new service that demands high assurance levels (such as opening a bank account) - either in a mobile browser or a native mobile application.

Request for identity document

Samantha is prompted to provide an identity document, 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.

Invoking a digital wallet

Samantha is redirected into a mobile application (e.g. wallet) holding the matching mDL.

Same device onboarding integration pattern part 2

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.

Redirect back to the website

Samantha is redirected from the mobile application/wallet back to the mobile browser or original native mobile application, allowing her to continue with the interaction.

Additional IDV journey blocks

Once her mDL is successfully verified, Samantha can proceed with the next steps in the IDV process. These may include different verification methods, such as:

  • Biometric check.
  • Liveness detection.
  • Call center validation.
  • Proof of address check.
  • Voice capture.
  • Database check.
  • Live video interview.
  • Authentication.
  • Physical ID validation.

Same device onboarding integration pattern part 3

Continue with opening account

Once the IDV process is complete, Samantha can move forward with opening her account. Some fields may be pre-populated with information gathered during the IDV journey, including details from the mDL verification.

Account opened

Samantha successfully opens a new account with the service.

Architecture

Enrolment architecture

Interacting with the website

The user is using a web browser on their mobile device to access a website where they attempt to create a new account. This requires them to complete an IDV workflow.

Requesting an mDL for verification

The first step in the IDV workflow is to present an mDL for verification.

This is achieved by embedding the MATTR Pi Verifier Web SDK into the web application and the IDV workflow by 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 mobile browser and responds with a link that is used by the Verifier Web SDK to redirect the user from their web browser and invoke a matching native application installed on the same mobile device and which holds 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.

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.

Handling verification results

The MATTR VII verifier tenant shares the verification results with the Verifier Web SDK, which redirects the user back to their browser where they can continue the IDV workflow and complete any additional required steps.

The IDV workflow can use information retrieved from the verified mDL (e.g. portrait image, credential claims) and compare them against any existing databases to increase the workflows’ assurance levels.

This is just an example workflow. The mDL verification can be embedded in any part of the IDV journey to accommodate different workflows and requirements.

Additional resources

Tutorials

Docs

Guides