Pressure is growing on businesses to ensure a continuous substantial assurance level when interacting with users over time. Compliance requirements are becoming more stringent and user integrity is increasingly at risk from fraud and theft. Businesses have two options: Managing complex and costly end-to-end processes on their own which hurts user experience, or working with an external authentication app that integrates identity proofing and continuous authentication with all the necessary security safeguards out-of-the-box.
Unraveling Challenges in Identity Proofing and Authentication for Access Management
It is crucial for many services to understand who the real person behind their users are. Many are obliged to by law and many suffer hard from a growing misuse of digital identities, both by ill-will and sloppiness. On the other hand there is also a fear that a more complex access management process imposes a hit on user experience ultimately resulting in drop-off.
In order to reach Substantial Level of Assurance, it is not enough to have a solid Identity Proofing process - you also must establish a sufficient Authentication process. In other words, it is not enough to only verify an identity when a user first signs-up for a service - you also need an authenticator that reaches the same level of trust whenever the user returns.
“Substantial” is defined in eIDAS (EU regulation) and it corresponds to IAL2 / AAL2 in NIST (US standard). NIST contains far more crisp definitions and a clear distinction between Identity Proofing and Authentication. IAL (Identity Assurance Level) defines what is expected of Identity Proofing processes - AAL (Authenticator Assurance Level) defines what is expected of an Authentication process.
Most businesses that need to address this problem focus all-in on Identity Proofing, to reach IAL2 - but leave the Authentication challenge aside (stay on AAL1). This even though most identity frauds are targeting the authentication process.
There are obviously needs to stay secure and compliant - but most businesses cannot afford compromising with user experience. Users will measure simplicity in relation to session-aware social login with single-sign-on or browser-facilitated password-manager driven sign-in. Whatever has to be done to reach AAL2 cannot add a significant complexity compared to that baseline.
The Case for Cryptographic Software Authenticators with MFA
NIST, just as other standards and regulations, are pretty clear upon what conceptual options there are - and by just a quick glance it is obvious that we need something referred to as a Cryptographic Software Authenticator - ideally with built-in MFA.
Other options are disqualified since an authenticator must allow users to authenticate themselves in apps on their hand held device. One cannot expect users to keep anything but the phone in their pocket and SMS/E-Mail doesn’t qualify as an additional MFA factor, since it hardly ever fulfills the criteria of being out-of-band (and honestly, even if we could enforce out-of-band it would not be very user friendly).
With a Cryptographic Software Authenticator, authentication is accomplished by proving possession and control of a cryptographic key managed in a FIPS 140-2 certified module. The Trusted Execution Environment (TEE) on all modern smartphones are FIPS 140-2 certified - hence the authenticator can be (and is ideally) made available through an app. The TEE typically holds a private key, and the corresponding public key is used by the device to identify itself. Proof of possession can then be achieved through signed messages.
How to ensure that no one else has taken control of the authenticator? The cryptographic software authenticator is “something you have” and access to the cryptographic key must be additionally protected with either “something you know” (memorized secret) or “something you are” (biometrics) in order to achieve MFA - hence reach AAL2.
The Role of Authenticators and Identity Proofing in Digital Security
How to ensure that the authenticator belongs to the same person as was originally onboarded? The public key of the device must be securely associated with the digital identity, either at an IdP/CSP or as an immutable credential in the “digital wallet” of the user.
Identity Proofing is best achieved after the authenticator is registered and inside an authenticated session. It is crucial that the identity proofing process has safeguards in place to verify the integrity of the authenticator - to protect both users and services from spoofing and other fraudulent threats.
Services do not benefit from engineering this themselves! Although it likely includes facilitating third-party software and provided services - the service provider will become the asserting party of the digital identity. This covers the full responsibility of compliance including engineering and maintenance around all technological, data and cryptographic challenges needed to reach Substantial level of assurance.
Further, the users need to go through a service-specific identity proofing process and they likely need to maintain at least a service-specific memorized secret.
The only feasible and user-friendly option to reach Substantial assurance level for digital identities on the internet is to partner up with someone who takes the full responsibility around identity proofing and authentication. Someone who can take the user through the (often quite extensive) identity proofing flow only once - and where they can seamlessly authenticate themselves towards all integrated services through a user friendly cryptographic software authenticator - all packaged in one app.
We have learned how to authenticate users with optimized user experience without in any way compromising security and compliance. Businesses need a partner - it is simply too costly and complex to maintain an inhouse solution, and there is no other way to achieve the level of simplicity expected by today’s internet users.
And before picking a partner, be aware that we have just scratched the surface of identity management as a whole. Substantial assurance level is a good starting point, but then we also have to manage identity data. Privacy! Consents! Integrity! Quality! Monitoring! GDPR! - but those are all topics of their own.