OneSDK with IDVerse IDKit

Using IDVerse IDKit

The IDVerse (formerly known as OCRLabs) IDKit is one of OneSDK's providers under the IDV flow.

The IDKit steps are only going to be triggered when IDV module’s mount method is called and for that reason it is expected that mount is called immediately by the host application.

A typical sequence to use IDVerse IDKit with OneSDK is as follows:

IDVerse IDKit sequence

Initialisation
1. The User visits the host application for Onboarding, for example with this URL, “.../onboarding/[customer_reference]"
  The host application’s backend generates a machine session with the customer unique reference.
2. Using the generated session, the host application initialises OneSDK with session.persist and session.appReference which can be used to send host application channel.
3. The host application initialises the idv module and triggers idv.mount
  The Javascript code for initialising this is as follows:
```
const token = await generateTokenUsingMachineToken();
const sessionConfiguration = { 
  session: { 
    token, 
    appReference: "the-app-name",
    persist: true
  }
};
// Initialise OneSDK
const oneSdk = await OneSdk(sessionConfiguration);
// Initialise IDV Flow
const idvFlow = oneSdk.flow("idv") <-- get an instance of the idv flow
// Display vendor ui
idvFlow.mount("somewhere-in-the-screen")
```
Once mount is called, the OneSDK will retrieve a special URL from our FrankieOne backend service, which is integrated with IDKit in the backend. The URL will be used to redirect the user to the vendor web page, which will redirect back to the original web page once the capture is completed. The vendor's web page will be styled according to appReference, which is required and is provided in the session config shown in the code above.
IDV Flow
OneSDK redirects user to the vendor-generated URL.
Results
1. Once completed, the user is redirected to our system with a success flag stored within our platform.
2. The user is redirected to the original host application URL.
3. Host application does the same as step 1.
4. idv.mount will request our FrankieOne backend if there’s any success flag stored, and then to skip the initalisation.
5. idv.mount will then request FrankieOne backend service to proceed with the IDV Processing.
6. idv.mount will then emit “results”, or another of the events described in Events/Outcomes.

Additional information on using IDVerse IDKit

Implementing the IDVerse IDKit requires a browser redirect. This impacts the UX, because:

the whole URL in the search bar is going to change to the new URL.
the host application has no control over the looks and UI context/frame of the vendor UI, any customisations need to be done directly with IDKit.

This impacts the implementation slightly, because by redirecting the web page, the OneSDK loses all information it had before the redirect, such as:

session information, including
1. session-id, and
2. entity identification (either entity ID or customer reference)
state of the ongoing flow, such as:
1. which modules were run so far
2. was any data already added to the OneSDK, but not persisted in our backend

To address the issue, OneSDK uses a feature called session. Persist, which stores the session details within the browser local storage for one hour. When the user is redirected back, the web page needs to ensure mount is called again, so the results can be retrieved from the backend.

Since the IDVerse UI doesn’t actually render on the same website, the "somewhere" in mount("somewhere") isn’t used by IDVerse. It is still required, to keep compatibility between multiple vendors, since most will require a dedicated space on the app’s UI. An “Orphaned” HTML Element may be used instead of a reference to an element on the UI:

const orphanedHTML = document.create("div"); // div not present on the screen  
idvFlow.mount(orphanedHTML);