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

Securing Passwordless Credentials with Identity Verification

Securing Passwordless Credentials with Identity Verification

When an enterprise is offering passwordless authentication, they are offering convenience and usability without sacrificing security. The user’s phone becomes the user’s identity — this is smart because users protect their phone and protect its contents. It really is the user’s identity. 

Think about the three main authentication factors (what you know, what you have and what you are)….a password is usually the “what you know” factor, which is inherently the weakest. Passwords are re-used, written down, phished, stolen, and overly complicated or otherwise painfully easy to guess. Furthermore, with the growth of single sign-on (SSO), oftentimes, if the password is stolen, all systems are compromised. 

By utilizing the other two factors and going passwordless, security is increased while simultaneously increasing security. Win-win doesn’t even begin to describe this situation, it’s WIN-WINTo steal the other factors requires levels of felony that most hackers don’t want to do, stealing personal property and/or body parts. Tying the authentication to possession of a phone verified to be the user’s or a verified face biometric solves all of this. 

 

Vulnerability at Time of Passwordless Credential Issuance

But there is a fundamental vulnerability early in this process when pairing the phone with the user. It is during this critical phase that you NEED to ensure that the user pairing the device with the identity is the correct user. Identity verification during this phase ensures that the user pairing the phone is the correct user.  

Depending on the security needs, this can be a simple mobile match (the identity is the user who owns this phone) or KBA challenge (does the user pairing know what they should) or a government ID match (does the user pairing have an ID and matching biometrics for the identity). Ideally, a solution will step up a policy that checks each more secure method depending on the profile of the user or the ability to pass the earlier stages. 

When to Apply Identity Verification to Passwordless Credential Process

This verification process to pair the credential to the user happens during two lifecycle eventszero day onboarding and credential recovery. During zero day onboarding, the most stringent identity verification template should be used – MobileMatch and BioGovID Verify the user’s possession and ownership of the mobile device being used for the credential, then verify their identity with a government issued identification and matching selfie – you hit the two most secure factors in one flow. 

During credential recovery, you have already established the identity of the user during onboarding, now you can use a more streamlined template and just check MobileMatch. Determine that the user is indeed the legal owner of the phone, that it hasn’t been used for fraud, and that the user has actual possession of that phone. Then you can re-issue the credential. 

Passwordless is the wave of the future both for workforce and consumers. It is easier for the user, more secure for the enterprise, and intuitive and fast for authenticationThe important part is that you establish the match between the physical identity, the digital identity and the mobile device being used as an authenticator at the initial point of vulnerability. 

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