Digital ID V2 SDK Migration
This acts as a short quick start guide for migrating from the original Digital ID SDK, to the new 'V2' SDK.
Scenarios created via the Hub are no longer compatible with the newly launched Digital ID SDK. To offer an improved user experience, we've transitioned to 'Sessions' which can provide granular session states throughout the entire user journey.
Should you require support on migrating from a scenario to the V2 SDK, or general support during the migration process, please get in touch through our support website.
Install the SDK
You will need to ensure the latest version of the Yoti backend SDK is installed.
Client Initialisation
The Class in the V1 client is referred to as Client.
This has now been renamed to the Digital Identity Client. Your current PEM Key and SDK ID are still valid. There's no obligation to generate a new set of keys, but you might consider doing so if you wish to segregate different instances.
Dynamic QR
The current SDK enables integrators to dynamically create policies, which are sets of requested attributes or schemes, during the sharing process. This offers a more flexible approach compared to having a static policy pre-configured in the Yoti Hub, or attempting to maintain multiple scenarios per policy.
Creating a policy
A policy is used to define what attributes are requested from the user. You can use the builder to define what attributes are needed.
In the V1 API, you would create a dynamic policy like this:
In the V2 API, you have to create a policy like this:
Specify a Scenario/Session request
The Scenario/Session request is built using:
The policy.
A callback/redirect URL for share completion. The provided URL is where the user will be redirected to after the share is completed. A token or receiptId will be added to the URL. You can use this to retrieve the user profile from the share.
Any extensions.
In the V1 API, you would specify a scenario:
In the V2 API, you have to specify a session configuration instead of a scenario. It also introduces the capability to subscribe to webhook notifications:
Create a Share URL/Session
Using the scenario/session request you need to get create a Share URL/Session which will be used by the Yoti scripts to generate a Yoti QR.
In the V1 API, you would create a Share URL like this:
In the V2 API, you have to create a session instead of a Share URL like this:
Client Side View
Yoti provides a client-side script that you can include in your html file to display a Yoti button or QR code.
In the V1 API, you would display a modal QR button using a Share URL:
In the V2 API, you will display the same modal QR button using a Session ID:
Retrieve Profile
This step involves using a one-time-use token (v1) or a receipt id (v2), and decrypting it to get a user profile.
In the V1 API, you would retrieve a user profile with a token:
In the V2 API, you will use the receipt id to retrieve a user profile:
New Functionality (v2 SDK)
In the Share v2 SDK, we have introduced new functionality to fetch the Session details and to configure Webhook notifications. The SDK includes the following relevant methods for these endpoints.
Fetch a Session
To retrieve a Share v2 session, use the following method:
Each session has a status associated with it, that will be one of the following:
Status | Description |
|---|---|
CREATED | Session created but no QR Code has been generated. |
QR_CODE_CREATED | At least one QR code has been created for the session and mobile app has not yet "scanned" it. |
QR_CODE_SCANNED | The mobile app has “scanned” the QR Code (i.e. a QR code was locked to a mobile app token) and system is waiting for user to complete (or cancel) the share. |
CANCELLED | Mobile app requested the session to be cancelled (before share was completed). |
EXPIRED | The share associated with the session was never completed (no receipt available). |
COMPLETED | The share associated with the session was completed (with success receipt available). |
FAILED | The share associated with the session was completed (with failure receipt available). |
ERROR | A "catch-all" status for unexpected/unrecoverable errors that might happen during execution (e.g. we get a receipt but the service fails to parse it, required parameter not present). |
Webhook notifications
Briefly described above, you can configure Webhook notifications for a Share v2 session as following:
Example notifications
The notifications will be sent in the following format:
COMPLETED:
FAILED:
Got a question? Contact us here.