Acceptance Assurance Framework
The most common question we hear in relation to identity acceptance is “how do I know which digital IDs to trust?” This is a worthwhile question--every digital ID is created differently. In this page we outline how to think about "trust" in the context of Identity Acceptance using a concept called assurance levels. Then we outline the framework we've developed at Trinsic to help businesses apply this concept to scale digital ID acceptance.
The purpose of identity verification is to provide additional information and assurances required to make a risk decision. As has been said many times before, the only way to guarantee 0 fraud is to turn off all new signups! Because no vendor or technology is foolproof, identity verification is an optimization between several key factors, namely fraud, user friction, and costs.
Levels of Assurance
Identity Acceptance through Trinsic works by enabling businesses to express their risk tolerance in a simple way. Trinsic then filters the universe of digital IDs down to only the ones that meet those requirements.
So, how should you think about your risk tolerance? There are three factors to levels of assurance:
- Strength of verification at enrollment/creation of digital ID
- Which kinds of checks were completed?
- What is the confidence level associated with each of the checks?
- Strength of authentication into wherever digital ID is stored
Let’s go through a few examples. Government databases with ID numbers are a classic example of a strong enrollment but weak authentication. It takes a lot of legit documentation to obtain a social security number in the US or Aadhaar number in India. But once I have the number, anybody else who knows the number can impersonate me. On the other hand, you can imagine why the other extreme doesn’t make sense either (think of a super lightweight verification requiring an extreme level of authentication like a Yubikey).
In the US, NIST has standards for both Identity Assurance Level (IAL) and Authentication Assurance Level (AAL):
Level | IAL | AAL |
---|---|---|
Level 1 | Knowledge-based authentication | Single-factor authentication |
Level 2 | Document verification | Two-factor auth or synced passkeys |
Level 3 | In-person ID proofing | Hardware keys, including unsynced passkeys |
It’s very important to understand that a chain is only as strong as its weakest link. It doesn’t matter if you have a strong verification if you have weak authentication. And it doesn’t matter if you have really good doc scanning if you have bad liveness detection. Any digital ID is only as strong as its weakest element.
Trinsic's Acceptance Assurance Framework
Trinsic partners with dozens of sources of digital IDs to make them easy for businesses to accept. As a part of the partnership process, we dive in to understand how each digital ID is created and accessed. We then map the universe of digital IDs into the following buckets.
Level | Title | Description | Explanation |
---|---|---|---|
Level 1 | Derived ID | 3rd-party ID | These are IDs that represent a verification, but aren’t a verification themselves. For example, authenticating into a bank account proves the owner of the account passed the bank’s verification process. But because the bank's verification process is opaque, trustworthiness is limited. Furthermore, in general these derivative IDs cannot be relied on for compliant KYC. |
Level 2 basic | Photo-based IDV | ID document front + selfie | A basic IDV process includes document capture and selfie match. This requires a photo of the front of a photo ID matched against a selfie. At this basic level, uploading images to APIs is an acceptable mechanism to collect user input (e.g. little replay/injection attack protection). |
Level 2 standard | Standard IDV | ID document front/back + liveness | A standard IDV process adds more robust fraud prevention technology to document and biometric capture. This typically requires both front & back of a document (to utilize a barcode or equivalent) and video-based liveness detection instead of a simple photo match. At this level, technical measures are taken to avoid replay/injection attacks. |
Level 2 enhanced | Enhanced IDV | ID document + liveness + authoritative data source | Enhanced IDV adds third-party data sources to a standard IDV process. This could include data sources such as AAMVA, credit bureaus, sanctions/PEP screens, telco data, or other data sources that can corroborate the attributes present in the captured ID. |
Level 3 | Gov’t digital ID | Verifiable government-issued digital ID | Cryptographically verifiable digital credentials issued by a government entity represent a high level of assurance. These IDs can be authenticated in real-time using cryptography. Examples include government-issued mDLs, verifiable credentials, and eIDs. |
Level 4 | In-person IDV | In-person ID proofing | In-person vetting requires a trained professional to authenticate a live human in-person against at least 2 forms of ID (one of which must be government-issued, one of which must be photo ID). Often additional checks will be completed as well. |
Optimizing your Results with ID Acceptance
Trinsic doesn't impose any mandates on identity providers in our ecosystem to issue/create digital IDs according to any particular identity proofing standard (or technical standard). Rather, our only requirement is that the methods used to create the digital IDs are transparent, so accurate risk decisions can be made by the businesses accepting them. We encourage ID providers to create IDs according to their own dictates, and ensure businesses only accept the relevant IDs.
When it comes to identity acceptance, an inherent trade-off exists between high-assurance and high-adoption. Trinsic's team will help you set your risk tolerance, usually to match your existing IDV process, so you can accept the largest number of reusable IDs without loosing your trust standards.
To see an illustration of how this could look, feel free to click around the interactive element below. Click on a verification level to see the current adoption numbers.
Updated 28 days ago