Identity Verification (Yoti)

Introduction

On 27 December 2021, the government announced its intention to enable employers and landlords to use certified digital identity service providers (IDSPs) to carry out identity checks on their behalf for many who are not in scope to use the Home Office online services, including British and Irish citizens. Alongside this the Disclosure and Barring Service’s (DBS) proposal will enable digital identity checking within their criminal record checking process using certified digital identity service IDSPs.

The trust framework is a set of rules organisations agree to follow to conduct secure, trustworthy identity or attribute checks. The initial alpha version of the trust framework was published in February 2021, with an updated version of the trust framework published in August 2021 following feedback from the public, industry, and civil society. A consultation on underpinning the trust framework in legislation ran from July to September 2021.

The Right to Work, Right to Rent, and DBS initiatives form part of DCMS’s trust framework’s testing process, and learnings will help to further refine its development.

Implications for the UK

Employers and landlords will be able to work with IDSPs to utilise Identification Document Validation Technology (IDVT) to carry out digital identity checks on behalf of British and Irish citizens who hold a valid passport (including Irish passport cards). The relevant changes to legislation will take effect from 6 April 2022.

Enabling the use of IDVT for Right to Work, Right to Rent and DBS checks will help to support long-term post pandemic working practices, accelerate the recruitment and onboarding process, improve employee mobility and enhance the security and integrity of the checks.

This supports the continued development of the DCMS trust framework and enables employers and landlords to make use of IDVT where they already have an established commercial relationship with an IDSP.

Whilst it will not be mandatory for employers and landlords to use a certified IDSP for the purposes of right to work and right to rent checks, the Home Office recommends employers and landlords use a certified IDSP. This will provide assurance that their chosen IDSP meets relevant scheme guidance and the standards set out in the trust framework. This means an employer or landlord can reduce risk by recruiting and renting in a safer way as they are able to assure prospective employee and tenants’ identities and eligibility using consistent and more secure methods. Employers and landlords will retain obligations that they must comply with under the Schemes, including to satisfy themselves that the IDSP has carried out an identity check on the employee/tenant, and to retain copies of the check.

For DBS checks, employers must use a certified IDSP.

3B And Yoti

Although we at 3B decided to integrate closely with Yoti , there are other vendors available to choose from. The list below is up to date as of the time of writing this article.

Name Website Schemes certified against
Yoti and Post Office EasyID www.yoti.com Right to work

Right to rent Disclosure and Barring service

HooYu Limited www.hooyu.com Right to work

Right to rent Disclosure and Barring service

TrustID Limited www.trustid.co.uk Right to work

Right to rent Disclosure and Barring service

Digital Identity Net UK Limited www.digiidnet.co.uk Disclosure and Barring service
Paycasso Verify Ltd trading as Xydus www.xydus.com/right-to-work Right to work

Right to rent Disclosure and Barring service

Sterling (EMEA) Limited www.sterlingcheck.co.uk Right to work

Disclosure and Barring service

T4 Communications UK Ltd T/A Rightcheck www.rightcheck.io Right to work

Disclosure and Barring service

Deloitte LLP N/A Right to work
Credas Technologies Ltd www.credas.com Right to work

Right to rent

Amiqus Resolution Ltd www.amiqus.co/ Right to work

Disclosure and Barring service

Digidentity B.V. www.digidentity.eu Right to work

Right to rent Disclosure and Barring service

CDD Services Ltd T/A Spotlite Business Services www.cdd.services/ Right to work

Disclosure and Barring service

OCR Labs Global Limited www.ocrlabs.com/ Right to work

Right to rent Disclosure and Barring service

uComply Limited www.ucomply.co.uk Right to work
GB Group PLC www.gbgplc.com/en/ Right to work

Right to rent Disclosure and Barring service

Marston Holdings Ltd www.marstonholdings.co.uk/nsl/checking-services/ Right to work
Onfido Limited www.onfido.com/ Right to work
ID Pal Limited www.id-pal.com Right to work

Right to rent

Northrow Limited www.northrow.com/ Right to work
Atlantic Data www.atlanticdata.co.uk Right to work

Disclosure and Barring service

Checkback International Group incorporating Vetting Solutions Centre Ltd www.checkback.co.uk/ Right to work

Right to rent Disclosure and Barring service

Datachecker Limited www.datachecker.com Right to work

Right to rent

Thirdfort Limited www.thirdfort.com Right to work

Right to rent

The Integration Mechanism

 
Yoti technical workflow

This section describes the interactions for a web, mobile web and native mobile integration. Data Exchanges will occur securely between the 3B back end, Yoti and the client (the end user’s browser or mobile device).

A session represents one end-to-end use of the ID verification service. Each time the ID verification service is initiated (regardless of which specific tasks/checks are required) a unique session identifier is assigned by Yoti's backend.

Every time a user elects to supply an ID document through the 3B integration, we will need to create a session with Yoti to perform the ID checks.

Once the Yoti Client has launched, it will take the end user through the ID document capture flow, followed by a liveness check and any other check you have requested in the integration metadata.


When using 3B's integration with Yoti from a Document Pack, we can simply request an ID check as one of the steps of the onboarding process. Depending on how the integration is configured, here's a step-by-step guide of the candidate's worflow:

Step 1 - Candidate lands in the candidate portal or My Documents page for documents submission

Step 2 - One of the items requested as part of the Document Pack is an Identity Check.

Step 3 - Candidate clicks on the entry and the Yoti identity verification workflow is launched. A candidate must take a photo of their ID document and perform a liveliness check.

Step 4 - Identity verification workflow is completed, results are positive/negative. If results are negative, the candidate can re-submit and re-start the workflow. Automated email alerts drive this process.

If the identity verification was successful, a new Certificate will be created on the system with the OCR'd results from the ID Document provided. This certificate can then feed into the Compliance Engine in order to evaluate the candidate's compliance status.

Configuration

To set up the integration with Yoti, follow the steps below.

Setting up APIs

 
Metadata Setup Example

Head over to Setup -> Custom Metadata -> Identity Verification: Yoti Settings, click on "Manage Records" and create a new instance called "Identity Sample". This is the default instance required by the integration, but you can have multiple instances. Only one instance can be "Active" at a time, so use the sample provided as a template only.

You will need to have set up a Public Site (usually /Onboarding guest site) as we need to retrieve the results from the processing.

When you create a new instance, most of the fields will be pre-populated for you, however you need to populate the following fields yourself:

  • Requested Checks - a JSON configuration array for the types of checks requested. An example is given below.
[{"type": "ID_DOCUMENT_AUTHENTICITY","config": {"manual_check": "FALLBACK"}},
{"type": "LIVENESS","config": {"liveness_type": "ZOOM","max_retries": 1}},
{"type": "ID_DOCUMENT_FACE_MATCH","config": {"manual_check": "FALLBACK"}}]
  • Requested Tasks - a JSON configuration array for the types of tasks requested. An example is given below.
[{"type": "ID_DOCUMENT_TEXT_DATA_EXTRACTION","config": {"manual_check": "FALLBACK","chip_data": "DESIRED"}}]
  • Private Key - can be obtained by 3B or directly with Yoti
  • Client SDK ID Key - can be obtained by 3B or directly with Yoti
  • Results Callback - must be populated with the Public URL + REST Endpoint (/services/apexrest/b3y/IV_Yoti_Client/v1/results)

Once you have configured the Custom Metadata, head over to Custom Settings -> Onboarding Default Settings -> and set the IV Custom Metadata field to the name of your custom setting created with the permissions and JSON config.

Set up Public Site Permissions

Since we depend on the Public Site to get the results of the checks, you need to grant access to all of the APEX classes that start with b3y.IV_Yoti for the selected public site you are configuring with the integration

Set up Document Pack

Create a new Document Pack or edit an existing one. Create a new document and set the External URL to your Public Site + /b3y__IdentityVerification?contactId={0}&documentId={1}&applicationId={2}. Example: https://org.my.salesforce-sites.com/onboarding/b3y__IdentityVerification?contactId={0}&documentId={1}&applicationId={2}

Send as Link

Remember that you can also send the identity verification as a stand-alone link, not attached to a document pack, just make sure you merge the contactId variable with that of the intended recipient.

Identity Verification Record

 
Identity Verification Record

Once a candidate starts an Identity Verification workflow with Yoti, an Identity Verification record (b3o__Identity_Verification__c) is created against their contact record. The default status will be "New" unless configured otherwise.

Optionally, an LWC component "Identity Verification" will be placed on the app page that will be breaking down the results from the identity verification process.

Once the candidate completes the identity verification flow, the status of the Identity Verification record will be updated to "Complete", regardless of whether Yoti determined an approval or rejection.

The documents supplied during the collection stage will be visible against the record, however the actual files will not be stored in Salesforce.

If you want to pull the files into Salesforce, you would need to view the document by clicking on the "view" icon and then click on "Save to Salesforce". This will create the file and link it to the contextual Identity Verification record.

Versions

  • Version 1.7
  • Version 1.8
  • Version 1.9
    • Increase session TTL to 24hrs (maximum allowed)
    • Added logging of session responses from Yoti to identify missed sessions
    • Fix file saving - some files could be corrupted when saved.
 
Supplied Document View

Supported Languages

Supported languages are:

  • French (Français) 🇫🇷
  • Spanish (Español) 🇪🇸
  • Thai (ภาษาไทย) 🇹🇭
  • Russian (русский) 🇷🇺
  • Brazilian Portuguese (português brasileiro) 🇧🇷
  • Turkish (Türkçe) 🇹🇷
  • Vietnamese (Tiếng Việt) 🇻🇳
  • Czech (čeština) 🇨🇿
  • German (Deutsch) 🇩🇪
  • Canadian English 🇨🇦
  • Polish (polski) 🇵🇱
  • Italian (Italiano) 🇮🇹
  • Danish (Dansk) 🇩🇰
  • Finnish (Suomi) 🇫🇮
  • Norwegian (Norsk) 🇳🇴
  • Dutch (Dutch) 🇳🇱
  • Swedish (Svenska) 🇸🇪
  • Japan (日本) 🇯🇵
  • Romania (România) 🇷🇴