Gartner’s definition of identity proofing is rather strict. To put it another way, if you wish to bring an identity claim inside the scope of your organization’s risk tolerance, you must provide evidence that:
- There is indeed an actual identity in the real world.
- The individual claiming that identification is correct, and they are physically present on the other side of the internet.
As an outcome, the widely used and lengthy technique of requesting a user’s PII data (name, address, date of birth, government ID number, etc.) and then cross-referencing that information against multiple sources does not meet the Gartner definition of identity proofing. This method is known as data-centric identity affirmation; it can help with identity proofing but is not identity proofing itself. After all, anybody might be entering that personally identifiable information, right? You may lessen this risk by layering in steps that provide more risk and trust signals, but you’ll always have that lingering worry about whether the user is who they claim to be.
Document-centric identity proofing seems to be the only widespread thing available that fulfills the Gartner definition of identity proofing. This is called the ID+selfie procedure. You photograph your photo ID document, which is then examined for evidence of tampering or being a fraud, and you next photograph yourself, which is biometrically compared to the photograph on the ID document. Presentation attack detection (also known as liveness detection) is indeed an important part of a second phase as it checks for actual existence — in other words, it ensures that users aren’t wearing a mask or snapping a selfie of an image.
If individuals wish to create a bank account with you during the pandemic and are unable to go to your local bank office and show their ID in person, you must allow them to do so online. If you allow individuals to register for COVID-related payments and support online, you must ensure that fraudsters do not take advantage of the system.
Clients’ techniques are determined by their use case and the amount of risk they are ready to accept. Cost, user experience, level of assurance, integration complexity, and so on all play a role in the selection.