Demographic Bias in Identity Proofing

Demographic Bias in Identity Proofing

In Gartner’s Market Guide for Identity Proofing and Affirmation, the authors make special note of demographic bias in facial recognition. If the AI performing the facial recognition or face match has a bias with regards to gender, race, age or any other characteristic then that is wrong on a fundamental human level. Of course, there are business implications as well but our concern transcends those implications. 

This is an important topic and one that ID Dataweb takes very seriously. One of our identity proofing templates involves the user taking a selfie, doing a liveness detection, then comparing that photo to a driver’s license or government ID. We don’t control the AI that performs these actions but we do control which backend providers we use on our exchange for these functions. We want to ensure that every user has an equal ability with as little friction as possible to verify their identity to sign up for our customers’ services. 

What can we do to mitigate demographic bias?

Of course, we test our pass/fail rates internally for our BioGovID proofing workflow. Due to the nature of our services, we have no way to know the gender or race or age of our production customers but we can determine the demographics of our POC and internal testing. To date, we have had identical results for all of our internal testing through all demographic groups. With pass rates north of 90% in all groups, we are confident that within our company’s, our customers and our partners’ employee groups, there has been no demographic bias. 

But that isn’t enough. It’s a small sample size with technically astute users. We need to ensure that there is no bias with larger populations. From our production customers, we have never seen any abnormally low pass rates but that still isn’t enough to ensure that the bias isn’t hidden in the numbers. Thankfully, our attribute provider partners are aware of this issue and are taking steps to mitigate and solve the bias when they find it. I am going to provide Acuant’s Fairness Evaluation verbatim. When asked about it, they had an answer immediately and obviously put it at the forefront of their research and product development 

Acuant’s commitment to Responsible AI includes building AI services that work equally well for all supported demographic groups and scenarios. To achieve this, Acuant worked with stakeholders to establish the following fairness accountabilities for facial recognition: 

  1. Measure and mitigate error-rate differences between subpopulationsbased on race, ethnicity, skin tone, gender, and age. Differences should get smaller or stay the same as new and updated features and functions are released. For face verification and identification, Acuant has committed to a <3% performance discrepancy between gender, age, ethnicity, ethnicity x gender, ethnicity x age for the categories defined below.
  2. Plan to support fairness by evaluating key use cases for potential fairness issues. Particularly for new functions, identify use cases that should be restricted or prohibited, conduct research with key stakeholders to uncover key fairness-related concerns, and evaluate the impact of regulations and policies.
  3. Document known issues and influences on accuracy, as well as known remediations, specifically for the purpose of informing experience and solution builders. In addition, Acuant is building the product to minimize the amount of work required to properly use Acuant facial recognition AI.
  4. Provide access for third parties to audit external-facing APIs. Provide contact information for escalating any fairness issues that are discovered and establish an internal review process, including expected outcomes and a communication plan for responding to escalations.
  5. Participate in credible public fairness benchmark competitions and/or evaluate functions using datasets designed to support evaluating accuracy by subpopulations based on race, ethnicity, skin tone, gender, and age. Existing public datasets are small, unbalanced (<5,000 subjects per subpopulation), and contain labeling errors. 

Building a bias-free Identity Verification workflow

Even with all of these efforts in place, relying solely on selfie to government ID matching can be problematic. You not only have the potential AI bias in recognizing faces but also can have issues with disadvantaged populations being less likely to have a government ID. Economically disadvantaged users are less likely to have a smartphone with a high enough resolution camera causing matching discrepancies. 

This is one of the many reasons ID Dataweb recommends a two or three step workflow for identity verification:  

  • Start with a phone possession & ownership check – if the user gets the OTP and we can triangulate that it is indeed the user’s phone without any signs of fraud we consider the user verified. This step usually verifies 70-90% of users. 
  • If they not able to pass that step, we can then perform a dynamic KBA (knowledge based answer) with either a credit bureau or custom data. This step can verify 70-90% of users who didn’t pass the first step. 
  • If that step is not passed, we would step up the verification to the selfie to government ID match. This step again, usually verifies 70-90% of the remaining users. 

By taking this stepped workflow approach, you are able to bypass a vast majority of the demographic bias. Your users have a more frictionless process and your goal of allowing the correct people through while stopping fraudulent actors with sophisticated security tools built into ID Dataweb’s AXN platform. 

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on pinterest
Pinterest

Edward Killeen

Vice President of Marketing

Identity Verification Orchestration: Solving for Too Much Data

Identity Verification Orchestration: Solving for Too Much Data

There are a million use cases where you need identity verification. You need to know who your user is when setting up an account, you need to assess risk when granting access, you need to verify identity when recovering credentials, you need assurance of an identity when setting up MFA….the list is endless. 

Just as endless is the array of attribute providers and credit bureaus and risk services. Each use case listed above needs to call data from multiple sources to truly verify the user’s identity. You need to be able to verify phone possession and ownership. You need a risk score from a credit bureau and the ability to triangulate data about the user. You need to be able to scan a government ID and match its data to DMV data and a biometric. 

There are use cases where you need next to no friction while still having a reasonable idea that the user is who they say they are. There are highly secure use cases where you need undeniable proof of the user’s identity. You need to be able to design a system that checks three factors: what you know, what you have and what you are. And be able to mix and match with all of those attribute providers in the background.

Orchestration and Policy: Workflows Save the Day

An orchestration layer within your identity verification system simplifies this process, I’ll give an example. A gaming company is setting up accounts for their loyalty program; security is obviously paramount because money is involved, but ease of use is essential because customers are involved. And this is happening digitally so the old paradigm of showing an ID doesn’t work. 

The policy is set up in three phases:  

  1. Prove possession and ownership of the device being used. If not, 
  2. Answer dynamic knowledge-based questions. If failed, 
  3. Scan government ID and match to a selfie. 

There are legitimate reasons for not being able to pass each but if you do pass it, we have very good certainty that the user is who they say they are. You might be using a friend’s phone, you might not know how much your mortgage is, but if you don’t have a valid ID you should not get to have an account. 

The reason that the orchestration layer is so important is that process is fantastic for the customer and their users, but it requires a LOT of data from a lot of vendors. Having a single API to call into an orchestration network erases that complexity for the customer while retaining all of the benefits. 

The orchestration layer coordinates all of the backend attribute providers and feeds, streamlines the data, and gives back a very simple response as to the user’s identity. The enterprise only needs a single API and interface to verify the identity, despite all of the complexity happening behind the scenes. ID Dataweb’s Attribute Exchange Network (AXN) has built in templates to simplify the process and build the exact identity verification policy you need for the use case. 

The Power of a Network: Dynamic Backup of Attribute Providers

Guess what? Attribute providers go down. You don’t want to have your customer onboarding halted when that happens. By having a network of attribute providers, you can failover to a backup vendor for that data without missing a beat…or a customer. ID Dataweb’s Attribute Exchange Network (AXN) allows for having backup providers for almost every identity attribute that you are verifying. As an enterprise, you get the benefit of a single interface, a single contract, and dynamic backups with all of these attribute providers and feeds.  

Between the policy engine consolidating all of the varied attribute providers into a single interface and the exchange network providing backup vendors, the AXN platform makes a complex identity verification problem very simple. You get to know who your customers are when you need to. 

Between the policy engine consolidating all of the varied attribute providers into a single interface and the exchange network providing backup vendors, the AXN platform makes a complex identity verification problem very simple. You get to know who your customers are when you need to. 

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on pinterest
Pinterest

Edward Killeen

Vice President of Marketing

Zero Trust Maturity: Knowing Your User

Zero Trust Maturity: Knowing Your User

Rooted in the principle of “never trust, always verify,” Zero Trust is a strategic initiative that helps prevent successful data breaches by eliminating the concept of trust from an organization’s network architecture. Every aspect of an organization’s security infrastructure is affected by a Zero Trust approach, from the access management system to the network edge to the end points. 

To be successful, the system needs to apply verification at all access points and all lifecycle events. Verifying the identity of that user and confirming risk during all access events is necessary to truly comply with the principle of Zero Trust. This requires a flexible verification system with the right tools for each step in that process. How do you know that the user is who they say they are from registration to access? 

Digitally Verifying a User on an Ongoing Basis

Identity verification and risk based authentication solve the one time and ongoing needs for Zero Trust access. To “never trust and always verify,” the identity verification system needs one time detailed verification and ongoing checks on the user and device risk. A flexible exchange with policy trees is required to adapt workflows that meet the needs of both of these methods of verification and risk assessment. The suggested steps are biometric identity verification at onboarding, ongoing device risk during authentication and while accessing critical resources.

In the “old days,” an HR representative would look at the new employee during onboarding, glance at their passport and confirm that IT could create a new account for the user. That has to be replaced with a new system to verify the user digitally during remote onboarding. During the account creation process, a user will take a selfie, scan the passport or appropriate document, compare the images and verify the address and date of birth attributes on the document. Being in the onboarding flow eases the process while allowing for even greater security. 

Similarly, when a user is accessing resources in a zero trust environment, you can’t just grant access because the user knows a username and password, that is very last century! You wouldn’t go to the same level of scrutiny as during onboarding, but doing a device reputation check to ensure that the device is owned by the user in question and hasn’t been used in fraudulent activities is a frictionless method to verify that is indeed the correct user. 

Manage Zero Trust Verification with an Attribute Exchange

All of that verifying seems like a good idea but it has to be easy for an organization to manage. To make Zero Trust work for you, you have to make it frictionless for the user but flexible and powerful for the administrators. The most important aspect is to have powerful verification workflows that can be customized for the appropriate need. ID Dataweb has built identity verification templates that are easy to configure for each use case, decreasing the time to security for your organization. 

To truly take advantage of these powerful workflows, an organization needs to tailor the data sources to their specific needs. A credit bureau provides triangulation on address data, DMV data verifies the current information, a fraud consortium determines if the device has been up to no good, a mobile carrier verifies that the phone is owned by the user – each of these scenarios is woven into the correct template. Managing those backend relationships is not your business, ID Dataweb has an easy to use identity attribute exchange to pick primary and backup providers without having to manage the 100+ relationships on your own. 

Zero Trust stands zero chance if you don’t start with the building blocks. Before you start building out policies with your ZTNA provider, be certain that the user is the user, verify their identity. Verify once thoroughly during onboarding and every time tactically with adaptive authentication. Zero Trust is achievable but you have to always verify! 

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on pinterest
Pinterest

Edward Killeen

Vice President of Marketing