Published 24 August 2020

Abstract

Zero Knowledge Authentication and Authorization (ZKA²⁾ can transform how businesses connect, interact, and transact with their customers. ZKA² empowers faster, easier, and more secure user experiences and is often coupled with intelligent authentication and authorization. ZKA² can help to execute on a frictionless security strategy critical to engaging customers and citizens.

The foundation of a Zero Knowledge environment is that it assures that no one (sender, receiver, or observer) can misuse private information because by design, it is never revealed.  ZKA² helps weed out many of the potential risks associated with the use of less secure and outdated password-only authentication protocols and the transmission of sensitive identity data, such as Patient Health Information (PHI) or Personal Identifiable Information (PII). ZKA² helps bolster the security of a person’s online transactions and public cloud accounts by limiting the types of sensitive information used to verify “I am who I say I am”.

There have been significant improvements over the past two years in bringing the concepts of ZKA² to market. Vendors have invested heavily in developing workable, scalable and desirable solutions with several early solutions being ready-to-deploy. Even if it takes a few years for critical mass to develop surrounding ZKA², the direction being set, and the value proposition is clear.

This report starts by looking at the building blocks and use cases for ZKA², then evaluates early ZKA² approaches and reviews of our vendor/solution short-list. We then conclude with a set of recommendations and next steps.

Authors:

Doug Simmons                                                   Gary Rowe

Principal Consulting Analyst                                 CEO / Principal Consulting Analyst

[email protected]                        [email protected]

Executive Summary

Zero Knowledge Authentication and Authorization (ZKA²⁾ can transform how businesses connect, interact, and transact with their customers. Also commonly known as intelligent authentication and authorization, ZKA² empowers a faster, easier, and more secure user experience. 

The foundation of a Zero Knowledge environment is that it assures that no one (sender, receiver, or observer) can misuse private information because by design, it is never revealed. Although this may appear very abstract at first, the principles are centered on the Zero Knowledge Proof model, whereby the underlying IAM system enables a Prover to convince a Verifier of the validity of a statement, such as “I am who I say I am”. In other words, the transaction – which could be simply logging in to a network or application, yields nothing beyond the validity of the statement “I am who I say I am”. Technically, a Zero Knowledge Proof can be as simple as a digital signature  and key exchange challenge protocol that allows for data to be privately shared and verified between two parties without the use of a password or any other information (e.g., identity attributes) associated with the transaction.

By definition, Zero Knowledge Proofs (ZKP) are the basis for Zero Knowledge Authentication and Authorization (ZKA²), which allow for a transfer of information to take place between two parties without the originator having to use a password or reveal any “something I know” validation data related to him/her. For instance, this helps weed out many of the potential risks that are involved with the use of password-only authentication protocols, such as phishing and replay attacks. Additionally, ZKA² also help in bolstering the security of a person’s online transactions and public cloud accounts.

It is important to understand that ZKA² is much more than Multi-Factor Authentication (MFA). In January, 2019, TechVision Research published a report titled “Multi-Factor Authentication (MFA): Enterprise Strategy and Market Assessment”, which went into significant detail regarding the many approaches to MFA and the high degree of general availability of very easy-to-use MFA solutions that can significantly improve an enterprise security posture when interacting with both employees and consumers. ZKA² takes this to a new level, and not only emphasizes a passwordlessand even usernameless paradigm, but also an extensive authorization framework that leaves traditional attribute-based access control in the dust.

There have been significant improvements over the past two years in bringing the concepts of ZKA² to market. Large and small IT / IAM vendors such as Microsoft, IBM, Ping Identity, ForgeRock, Trusona, Evernym, Sovrin and many others have invested heavily in developing workable, scalable and desirable solutions that may really surprise you in terms of being ready-to-deploy. Even if it takes a few years for critical mass to develop surrounding ZKA², the direction being set is clear; we are moving to a world where only minimal disclosures of PII (if any!) will be necessary in support of highly secure but user-friendly authentication and authorization decisions.

This report starts by looking at the basic components and use cases for ZKA², then evaluates the types of ZKA²approaches currently being deployed and provides a review of our short-list of vendors and solutions. We then conclude with a set of recommendations and next steps.

Introduction

Cyber threats are becoming increasingly sophisticated and include a variety of techniques that involve guessed, hacked, or stolen physical or digital credentials. These threats expose the inherent weakness within traditional username/password-based authentication schemes. Accounts that have been compromised can create even greater damage as individuals use the same credentials, or a limited pool of credentials and identity attributes to authenticate and access services across multiple sites. Increasingly elaborate large-scale data breaches are directed towards extracting replicated/repeated login credentials as well as stealing treasure troves of PII attributes that can be used to pose as someone else.

What is needed is a means to mitigate the sharing of usernames and passwords and limit damage if they are compromised. ZKA² makes it harder and more expensive for bad actors to compromise an organization. Bad actors can steal PII and passwords by:

1. Brute Force – Phishing thousands of users, hoping one will make a mistake
2. Targeting – Going after a specific user and trying to brute force guess their username and password, getting an associate to divulge this information, video surveillance such as a hidden camera or using their smart phone to record logging in. Keystroke loggers fit into this category
3. Purchase – Buying user information from other bad actors, for example an electronic health record (EHR) that has more permanent personal information such as a user’s social security number, address, phone number, workplace, birth date, payment and banking details, health details, and other verifiable information that is unlikely to be deleted and rebuilt as a simpler compromised username/password combination might be.

The most common risk of stealing someone’s account information is in the process of creating or modifying the account, especially password resets, change of physical address or change in mobile phone number.  In essence, redirecting transactional communications and outcomes away from the real user to the “bad guy”.  Enterprises should ensure that extra steps in support of identity protection are taken when account information is being modified.

With such threats and attacks in mind, organizations are adopting multi-layered adaptive authentication and authorization approaches and TechVision believes this is a prudent strategy. The pervasive approach is to integrate a second and 3rd security layer employing additional factor(s) before authenticating and/or providing access to resources (authorizing) as defined within enterprise security policies.

As more and more people interact in the digital world through online banking, online healthcare and education, remote work and so forth, they often need to submit highly sensitive personal or financial information via the Internet. Given this effect, the need for ensuring data privacy and protecting personally identifiable information (PII) has also become critical.

Data privacy has become the focus of the international community and is reflected in the various governmental data protection laws and privacy regulations. From a regulatory perspective, the legal obligation to ensure compliance with all these laws is left for interpretation by an organization’s Legal Counsel. In short, even when viewed outside of the international body of governing privacy law, virtually every organization has some level of data privacy and protection responsibility. Preventing unauthorized or unintentional (e.g. accidental and fraudulent) access or release of an employee’s, customer’s or patient’s financial, health, and other forms of confidential and sensitive PII or business information is a key strategic security underpinning. Providing access security measures at multiple-layers (e.g., adaptive) at an infrastructure and policy-level will be needed for complying with future privacy initiatives. These privacy initiatives continue to advance, build, and evolve, at state, federal, and international levels.

In summary, the factors driving the need for adding additional levels of security to the existing logon credentials (i.e., passwords) and sharing of PII include the following goals:

• Ensuring that the endpoints (user or thing) on both sides of the transaction are who they say they are,
• Facilitating equitable and reliable access for all employees, business partners or customers from anywhere,
• Preventing unauthorized access to sensitive enterprise data ranging from trade secrets to an individual’s account commensurate with protections postulated by Risk Management,
• Preventing unauthorized or unintentional release of sensitive corporate data and individuals’ personally identifiable information, financial data, and other stored data, and
• Satisfying the organization’s dedication to the goal of enhanced digital trust.

 

What is ZKA²?

The concept of Zero Knowledge Authentication and Authorization is really quite simple: don’t collect or require any identity information in authenticating or authorizing other than what is explicitly required for account connection and access determination. ZKA² is part of a Zero Trust trend in security to move identity proofing to the network edge. Similar to passwordless, MFA, and Decentralized Identity, ZKA² distributes the proofing details for identity and access to the client side rather than centralizing them on the server side.

ZKA² is commonly supported by passwordless authentication and intelligent authorization and it empowers a faster, easier, and more secure user experience while limiting the risk of exposure. The foundation of a Zero Knowledge environment is that it assures that no one (sender, receiver, or observer) can misuse private information because by design, it is never revealed. Although this may appear very abstract at first, the principles are centered on the Zero Knowledge Proof model, whereby the underlying IAM system enables a Prover to convince a Verifier of the validity of a statement, such as “I am who I say I am”. In other words, the transaction – which could be simply logging in to a network or application, yields nothing beyond the validity of the statement “I am who I say I am”. Technically, a Zero Knowledge Proof can be as simple as a digital signature and key exchange challenge protocol that allows for data to be privately shared and verified between two parties without the use of a password or any other information (e.g., identity attributes) associated with the transaction.

By definition, Zero Knowledge Proofs (ZKP) are the basis for Zero Knowledge Authentication and Authorization (ZKA²), which allow for a transfer of information to take place between two parties without the originator having to use a password or reveal any “something I know” validation data. This helps weed out many of the potential risks that are involved with the use of password-only authentication protocols. Additionally, ZKA² also help in bolstering the security of a person’s online transactions and public cloud accounts.

The Continuing Evolution of ZKA²

Passwordless authentication, adaptive authentication, decentralized identity (DID), zero knowledge proofs (ZKP) and the intelligent use of meta and contextual data being collected are contributing the evolution of ZKA². As technology advances, we’ll be more adept at authenticating and determining access based on information other than sensitive PII. We’ll start with a look at passwordless authentication.

Passwordless Authentication

Passwordless authentication starts the path towards ZKA². as the elimination of the password eliminates a form of shared knowledge that is no longer necessary. While MFA is often connected with a passwordless approach to authentication, the user still initiates an online experience with an initial password or PIN (personal identifying number). This is the “something I know” factor of a multi-factor authentication experience. MFA then augments the password or PIN by sending a cryptographic token that corresponds with “something I have”, like a mobile phone, smart card or other device registered to that person only. This is the second factor. A third factor is typically a biometric scan to authenticate to the device that acts as the second factor. This is typically how we extend from two-factor authentication (2FA) to MFA.

From the authentication standpoint, ZKA² eliminates the password or PIN from the picture because passwordless authentication relies on a cryptographic key pair – a private and a public key. The public key is provided during registration to the authenticating service (remote server, application or website) while the private key is kept on a user’s device and can only be accessed when a biometric signature, hardware token or other passwordless factor is introduced. In most common implementations, users are asked to enter their public identifier (username, mobile phone number, email address or any other registered ID) and then complete the authentication process by providing a secure proof of identity in the form of an accepted authentication factor. These factors classically fall into two categories:

1. Something the user has, such as a mobile phone, one-time password (OTP) token, smart card or a hardware tokensuch as a FIDO-compliant[1] key fob.
2. Something the user is, such as fingerprints, iris scans, face or voice recognition and other biometric identifiers.

Many emerging passwordless authentication designs also accept a combination of other meta data and contextual factors such as geo-location, network address, behavioral patterns and gestures and so on. All are considered passwordless as long as no memorized password or PIN is involved.

Passwordless authentication approaches provide numerous benefits over traditional password-based authentication methods:

• Improved security – passwords are known to be a weak authentication approach due to reuse, sharing, cracking, etc. and are regarded as the top attack vector responsible for a high percentage of security breaches.
• Improved user experience – End users aren’t required to remember complicated passwords and comply with different password policies – and they are also not required to periodically renew passwords. This removes perhaps one of the biggest aggravations end users can have.
• Reduced IT costs – since no password storage and management is needed, IT teams are no longer burdened by setting password policies, detecting leaks, resetting forgotten passwords, and complying with password storage regulation, which is especially burdensome with multiple password hashing approaches littered across the enterprise IT landscape.
• Elimination of Shared Credentials – because credentials are tied to a specific device or inherent user attribute, they can’t be shared across multiple users. This is especially important from a system administrator activity monitoring standpoint.
• Scalability – the enterprise and the end users, whether employees, partners or customers, no longer have to manage multiple logins that lead to password fatigue and over-complicated registration.

While it is clear that passwordless authentication leads to IT cost savings in the long term, deployment costs can be a hindrance for some potential users if mobile device ubiquity isn’t already in place. In these cases, there are additional hardware costs to deploy devices that can facilitate passwordless authentication, such as token fobs, mobile devices, etc.

There is also a cost of training and expertise that would be incurred while moving to a passwordless ecosystem. Myriad user types will need to be brought up to speed with the new paradigm, including end users, system administrators and application developers, to name a few.

But change does not always come easy. TechVision believes these costs are relatively minor for most of the organizations we have worked with over the many years, and the upside is well worth the effort.

To be clear, however, be aware that there is still no magic pixie dust that allows passwordless authentication to be deployed without a well-thought-out strategy that weighs the risks, costs and usability. The good news is that we are moving in a direction in which passwordless authentication is more cost effective and deployable across a broad spectrum of use cases – both internal enterprise and consumer-facing. But an enterprise strategy must consider the association between authentication cost and risk reduction. For further details on passwordless authentication, see TechVision’s research report “Zero Passwords in a Zero Trust World”.

Adaptive Authorization

Adaptive authorization is another tool to support “smart authorization”. It is based on contextual awareness as it pertains to the ability of the identity management system to determine certain characteristics about a user during runtime authentication and authorization and then use this information to:

1. Measure the risk associated with the device, location, information sensitivity, etc. during the authentication and authorization request and
2. Enforce specific policies regarding the type of authentication and identity information required to access the desired resource to better combat fraud.

For instance, if an end user wants to access her employer network, adaptive authorization provides more detail about the current circumstances beyond simply identifying the user. This can be accomplished by enabling the IAM infrastructure to determine the device that is being used and whether it is trusted or managed by the enterprise, the location she is attempting to authenticate from and even the level of sensitivity for the employer IT resource she wants to access. Taken together, this is the contextual information that can determine the level of risk involved and can step up the level of identification for the required level of identity assurance.

In our emerging model, contextual awareness becomes a service enabled by the IDP that is transmitted on secure assertions, along with any specific verifiable claims. To reiterate, we are advocating an access control risk framework that triages multiple data points during runtime to better establish the credibility of the identity being presented.

Leveraging the capabilities described above are great first steps towards the foundational changes needed in Internet-based IAM. PKI and digital signatures, storing identities where needed (on device, in the cloud, or locally), maintaining consistency of identity information, generating easily accessible, on-demand views of this information, leveraging greater contextual awareness and achieving stronger passwordless authentication are all ingredients that will contribute to the new identity model. But it isn’t enough to achieve the broad changes we seek; for that there needs to be some additional secret sauce and we’ll describe the additional ingredients in the next section.

Decentralized Identity and Zero Knowledge Authorization

Decentralized Identity combined with Verified Credentials supports a pervasive set of services that supports the sharing of only the necessary and relevant bits of verifiable information necessary to perform specific transactions. The goal is to maintain a digital satchel of non-repudiable and trustworthy attributes that can be shared individually with the entity engaged in the transaction or communication. In fact, some of these attributes can and should be based on reputation – the ongoing establishment of authenticity over time, vouched for by third parties that the service provider recognizes as verifiable and accurate. We’ll now consider the value and roles that verifiable claims, reputation, distributed identifiers on a Distributed Ledger (Blockchain) with supporting AI services can play in zero-knowledge authorization.

You have probably been hearing that Distributed Ledgers/Blockchain can somehow be an important part of a better, faster, cheaper IAM approach, but we’ll examine the potential role it plays and, perhaps more importantly, what role doesn’t it play in supporting zero-knowledge authentication / authorization. Services built on Blockchain can provide broader identity discoverability and secure connections to the data needed to support a transaction. Daniel Bucher, the head of distributed identity at Microsoft stated at our latest conference in that “Blockchain-anchored identifiers linked to identity hubs, encoded with semantic data, are the agar upon which apps and services will grow”.

So, distributed ledgers can provide the identity anchor, allow for discovery and be the immutable unforgeable record to link an identifier to an object. But what it can’t do without help is to determine what is needed for a particular transaction to be satisfied – for instance, am I old enough to purchase alcohol, am I credit worthy, do I live in Wyoming…for this we need something more. This is something more is called a verifiable credentials. Conceptually, consider that each block in one’s blockchain may contain “pointers” to the location of encrypted and digitally signed verifiable credentials, which may be a certificate, achievement, quality, or piece of information about an entity’s background such as a name, government ID, payment provider, home address, or university degree. In other words – an individual’s PII!

These verifiable credentials or claims describe a quality or qualities, property or properties of an entity that can be used establish its existence, uniqueness and qualifications. Entities (people, organizations, devices) need to make many kinds of claims as part of their everyday activities. The difference with a verifiable credential leveraging a Blockchain-based ecosystem is that the credential can be validated by the authoritative source such as the university that granted the degree. This allows the enterprise to better quantify the risks associated with the transaction based on the verification sources used for then credential / claims.

As organizations progress towards becoming Digital Enterprises, there is a need to be able to transmit instantly verifiable credentials / claims (e.g., about their location, accomplishments, value and so forth) providing electronic proof that the assertion is valid. These credentials can support the next generation of IT applications as they provide the basis for authorizing entities to perform actions based on rich sets of credentials issued by trusted parties – but not stored locally where they can be stolen or misused. Human- and machine-mediated decisions about job applications, account access, collaboration, professional development, consumer preferences (and on and on) depend on filtering and analyzing growing amounts of data. It is essential that data be 100% verifiable when the use case requires this verification. Therefore, standardization of digital credential technologies makes it possible for us to issue, earn, and trust these essential records about their counterparties, without being locked into proprietary platforms.

In a zero-knowledge authorization model, a user (or device) selects verifiable credentials they agree to share with specific service providers to enable the triaging of ‘identity proofing’ artifacts necessary to properly register, authenticate (passwordless) and authorize access.

The W3C Draft Specification titled “Decentralized Identifiers (DIDS) 1.0 – Data Model and Syntaxes for Decentralized Identifiers”, updated July 14, 2020, is foundational to the advancement of zero-knowledge authorization. While this isn’t the only approach, it is a good representation of how distributed identifiers will work and support portable, self-sovereign, and user-controlled identities.

In this continuously updated specification, DIDs (decentralized identifiers) are defined as follows:

• DIDs are intended for verifiable digital identity that is “self-sovereign” and therefore fully under the control of the identity owner and not dependent on a centralized registry, identity provider, or certificate authority.
• DIDs resolve to DDOs (DID “descriptor objects”), which are simple JSON documents that contain the metadata needed to locate and prove ownership and control of a DID. Specifically, a DDO contains a set of key descriptions, which are machine-readable descriptions of the identity owner’s public keys, and a set of service endpoints, which are resource pointers necessary to initiate trusted interactions with the identity owner.

The foundation of the DID architecture is the concept of this decentralized identifier.  Each identity owner can be identified on a distributed ledger with a key-value pair. The index key is a DID (decentralized identifier) and the value is its associated DDO (DID description object). Together these form a DID record. Each DID record is cryptographically secured by private keys under the control of an identity owner (in the case of an owner-managed identity) or a guardian (in the case of a guardian-managed identity). A corresponding public key is published in the DDO using a key description. A DDO may also contain a set of service endpoints for interacting with the identity owner. Following the principles of Privacy by Design (which TechVision supports), each identity owner may have as many DID records (i.e. key pairs) as necessary, to respect the identity owner’s desired separation of identities, personas, and contexts.

This design eliminates dependence on centralized registries for identifiers as well as centralized certificate authorities for key management—the standard pattern in hierarchical PKI. Because DID records are on a distributed ledger, each identity owner may serve as its own root authority—an architecture referred to as DPKI (decentralized PKI).

Note that DID methods may also be developed for identities registered in federated identity management systems. For their part, federated identity systems may add support for DIDs. This creates an interoperability bridge between the worlds of centralized, federated, and decentralized identity.

It is very important to understand that a DID and DDO do not inherently carry any PII, and this is a key design principle that makes zero-knowledge authorization possible. As defined in the specification, a DID must be persistent and immutable (i.e., bound to an identity owner once and never changed). Ideally, a DID is a completely abstract decentralized identifier that can be bound to multiple underlying distributed ledgers or networks over time, thus maintaining its persistence independent of any particular ledger or network. Hence is born the concept of Bring Your Own Identity (BYOI).

Enterprise Requirements and Reference Architecture for ZKA²

So, we’ve just described the case for deprecating or minimizing the use of passwords and limiting the need for requiring PII while improving security. A well thought out ZKA² program provides the avenue upon which to begin this journey. A ZKA² program needs business stakeholder involvement and appropriate funding in order to be successful. Typically, and enterprise’s ZKA² program is driven by business needs such as —

• Business Facilitation and the need to improve interoperability and efficiency through interconnected systems to support employees, affiliates, business partners and customers.
• Enhancing User Experience by simplifying the process of authentication and authorization and letting the end user not have to remember another password or provide anything more than basic PII.
• Cost Containment planning to reduce the cost of management of multiple disparate authentication and authorization systems and processes.
• Security Effectiveness and IT Risk Management improving the level of assurance that maps to an identity for appropriate authentication and authorization as well as reducing liability by not maintaining unnecessary PII.
• Support Administrative and End-user Efficiency and Effectiveness By consolidating the authentication/authorization infrastructure and better defining and reducing the number of access points.

These high-level business requirements are the basis for a ZKA² architecture per the following core foundational principles.

Architectural Principles

In principle, the organization should seek to implement a flexible, extensible, risk-aware enterprise authentication strategy that will accommodate current and future business needs and technologies. Typical future-state vision includes authentication services that—

1. Support a strong user experience, are easy to use, sustainable and cost-effective.
2. Ensure compliance and mitigate IT risks by addressing the full range of assurance levels identified by the organization along with associated requirements.
3. Support ZKA² from a suitably wide range of devices. Provide authentication and authorization for the organization’s people, applications, devices and services regardless of platform and architecture, hosted both within organization’s networks and external to them.
4. Enable the organization’s business processes and workflows.

With these principles as a backdrop, let’s look into the TechVision IAM Reference Architecture with our ZKA² glasses on. The TechVision Research Reference Architecture for IAM is this starting point; a master template, shown in Figure 1, below, identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. ­­­ This high-level template starts the journey:

Figure 1: IAM/MFA Master Template

The capabilities illustrated above are described at the highest level as:

Interact – how end-users and application developers interact with the IAM platform. In the case of ZKA², this will involve a variety of diverse people and technology interactions.

Access – the rules that define the roles, rights, and obligations of any actor wishing to access enterprise or connected external assets.

Change – the capability to define and manage the relationships between the user/ application developer and the enterprise assets.

Manage – the capabilities required to manage and upgrade the IAM solution itself.

Measure – the capabilities required to audit and improve IAM activities.

Store – the capabilities required to share identity information and relationships between the components of the IAM solution.

The Reference Architecture’s second level is depicted in Figure 2, below.

Figure 2 – Second Level: IAM Portfolio Capabilities supporting a ZKA² program

As discussions progress into deeper levels of discovery, this master template organizes discussions beginning with the high-level interfaces associated with both end-user and application developer IAM service consumption. From either of these perspectives, organizations can navigate deeper into the runtime functionality requirements for:

• Access (e.g., authentication, authorization, federation, privileged access, etc.). The authentication and authorization interfaces are where ZKA²
• Identity lifecycle management (e.g., joiner/mover/leaver, change orchestration, and governance). ZKA² must be configured for end users and devices registered through identity lifecycle management interfaces.
• IAM infrastructure administration, including ZKA² configuration and user administration.
• IAM data management and reporting. ZKA² solutions provide various types of reports recounting user interaction, suspicious activity, performance and reliability statistics and so forth.

Once the required capabilities are identified, the next layer of the TechVision Research Reference Architecture for IAM allows us to explore each of the specific IAM Capability in the form of a combined portfolio architecture, as illustrated in Figure 3, below.

Figure 3 – Third Level: IAM Capabilities of the Combined Portfolio Architecture

Time of Access Operations rely on Time of Change Operations, such as identity lifecycle management (identity registration, provisioning, workflow) and identity orchestration (identity correlation, synchronization, transformation) to provide contextual information about users and their current state, permissions, and entitlements. For example, an authorization system may implement the policy that a user must authenticate with ZKA² to be granted access to specific applications or services.

An access policy enforcement infrastructure such as Policy Enforcement Points (PEPs) provides authentication of subjects – ranging from user ID and password to the elements of ZKA² (i.e., passwordless authentication and DID with verifiable credentials). Some of the emerging ZKA² tools that we describe further on in this document are tightly integrated with services that provide authorization and reduced sign-on/single sign-on (SSO) through components such as policy decision points (PDPs) that make authorization decisions on behalf of PEPs.  Because access policy enforcement systems usually support reduced sign-on/SSO, the centralized access services either proxy the access for the user, or generate Kerberos tickets, federation tokens, session cookies, or other session information that the resource can natively recognize.

TechVision Runtime ZKA² Reference Architecture Pattern

Users of any IT systems, whether employees, contractors, system administrators, customers, 3^rd parties or technology suppliers must authenticate themselves before being granted authorization (i.e., access). We need to remember that ZKA²should be part of an overall authentication and authorization program and provide the right support and context for authorization decisions without collecting any unnecessary personal information.

We’ll now describe a ZKA² reference architecture pattern using Decentralized Identity as a model for how this might work. There may be many approaches to achieving ZKA², but Decentralized Identity can be used to show the type of approach and pattern we expect the industry to move towards in achieving stronger security with minimal user friction and minimal disclosure of private data.

To recap, Decentralized Identity is an update or extension to the concept of User Centric Identity that has been discussed over the past few decades. The concept is that rather than have every business or organization an individual connects to establish an identity specific to each organization (and under their terms), an individual could create a portable identity to use multiple places under the control of the individual. The challenge is in verifying the person’s digital ID is associated with the person they claim to be.

In the emerging decentralized identity model, identities may contain “pointers” to the location of encrypted and signed verifiable credentials. A verifiable credential is a certificate, achievement, quality, or piece of information about an entity’s background such as a name, government ID, payment provider, home address, or university degree. Such a credential describes a quality or qualities, property or properties of an entity that establish its existence, uniqueness, and qualifications. Entities (people, organizations, devices) need to make many kinds of claims as part of their everyday activities.

As organizations progress towards becoming Digital Enterprises, they need to be able to instantly accept and transmit verifiable credentials and provide electronic proof that the credential is valid. These credentials / claims can support the next generation of web applications as they provide the basis for authorizing entities to perform actions based on rich sets of credentials issued by trusted parties. Human- and machine-mediated decisions about job applications, account access, collaboration, and professional development will depend on filtering and analyzing growing amounts of data. It is essential that data be verifiable. Therefore, standardization of digital claim technologies makes it possible for us to issue, earn, and trust these essential records about their counterparties, without being locked into proprietary platforms.

In the ZKA² model, the user will typically authenticate to his or her device via passcode or biometrics, then the private key on the device is used to generate token that is authenticated by the service provider using the public key of the user’s device. These bits of important information can be stored in the user device’s digital wallet, as shown below. Like any effective PKI, the public key must be digitally signed by a trusted Certificate Authority (which could be a traditional CA for centralized PKI or another trusted source in the evolving decentralized PKI model).  The public key is generated during registration to the Identity Provider, while the private key is kept on a user’s device and can only be invoked when a code or biometric signature is introduced. In most common implementations, users are asked to enter a familiar identifier (username, mobile phone number, email address or any other registered ID) and then complete the authentication process by providing a secure proof of identity in the form of the token generated by the user’s device. This is the equivalent of a login and never has to be done again unless there is a need to revoke the keypair and dissolve the connection.

The Reference Architecture pattern shown in the following figure illustrates a runtime ZKA² Reference Architecture pattern.  While this happens to use Decentralized Identity, Verifiable Credentials and it built on a Distributed Ledger, there will be other mechanisms and ecosystems for validating credentials in real time.

Figure 4:  DID-based Zero Knowledge Authentication & Authorization Service Pattern

This process starts with a Time of Change activity (i.e., to provision or register) in which the Distributed Ledger interface creates a DID, which is the at the head of the Blockchain. Following DID generation, Institutions such as a person’s employer, financial institution, health care provider and so on can connect with the DID and create and digitally sign verifiable credentials pertaining to that DID. How to interpret these credentials are stored in subsequent blocks on the blockchain and the credential itself is stored in the user’s digital wallet. The PII itself is not stored on ledger or blockchain or on the user’s device.

The Distributed Ledger / Blockchain is used to store and timestamp public keys and this allows the ledger to be the distributed “root of trust” that allows the recipient of a credential to confirm the credential sent by the user was cryptographically signed by the proper issuer. From an IAM Reference Architecture standpoint, the Distributed Ledger/Blockchain is just another type of Identity Repository, as illustrated on the right side of the Level 3 Combined IAM Portfolio Architecture.

In the Reference Architecture pattern illustrated here, a user (or device) during Time of Access (runtime) selects which verifiable credentials to share with specific service provider entities (such as corporate lines of business) to enable the triaging of ‘identity proofing’ artifacts necessary to properly register, authenticate and authorize access. As shown above, the Access Control function will have a PDP/PEP that interfaces with Distributed Ledger / Blockchain through an Identity Service API. This enables the verification of the verifiable claims, including the authenticity of the associated DID.

Remember, this pattern enables user consent-driven sharing of verifiable credentials rather than the PII itself. A very good overview of verified claims and typical use cases can be found in the W3C’s Verifiable Credentials Use Cases document: https://www.w3.org/TR/vc-use-cases/.

We are starting to see this gain more widespread acceptance as privacy regulations such as GDPR and the CCPA are forcing IAM’s hand at finding better ways of enabling a scalable and secure user centric means of identity management. Taken together with contextual awareness, IAM systems and service providers become much more security and privacy-focused, while the true spirit of regulations such as GDPR and CCPA become imminently attainable within this model.

We’ll now examine how some key vendors are approaching this ZKA² pattern.

How Vendors Are Approaching ZKA²

The good news is that a great deal of investment and time is going into developing many of the ZKA² approaches we have described.  The investment is being driven by enterprise customers socializing their strategies and requirements for their Zero Trust programs. While there are many factors to consider in evaluating vendors in this space, we’ll look to net out some of the key elements or each vendor’s program and direction in this short-list summary.

Do consider that the ZKA² strategy for a customer-facing internet-based commerce environment is often not the same strategy for an employee-facing solution and will vary widely based on privacy and regulatory controls. What might be an excellent fit for one environment may be overly risky for another and every organization should start with an understanding of their current state, key requirements and target future state as we described earlier. With that background, TechVision feels that the following vendors are strong candidates for consideration in that they address key enterprise ZKA² requirements and have a solid future state plan:

• Microsoft
• IBM
• ForgeRock
• Ping
• Trusona
• Okta
• Beyond Identity

Microsoft

Microsoft has been making steady progress on a number of IAM fronts, and in particular with their focus on ‘replacing’ the decades-old “username / password” paradigm. For background, Microsoft first introduced MFA several years ago, stemming from its dominance in the Network Operating System (NOS) directory infrastructure market with AD coupled with a relatively similar dominance in the office application market. The company’s first foray into the “passwordless” landscape was with the Microsoft MFA server, introduced in 2014 as an on-premise server integrated with AD. Not surprisingly, as the mass migration from on-premise AD and Office infrastructure to Azure commenced, the company later announced it was going to discontinue Microsoft MFA Server as an on-premise solution and only offer Azure Multi-Factor Authentication (MFA) – a fully cloud-based solution.

But much more has occurred at Microsoft since then. Passwordless authentication, as defined by Microsoft, “is a form of multi-factor authentication that replaces the password with a secure alternative. This type of authentication requires two or more verification factors to sign in that are secured with a cryptographic key pair. The device creates a public and private key when registered. The private key can only be unlocked using a local gesture such as a biometric or PIN. Users have the option to either sign in directly via biometric recognition—such as fingerprint scan, facial recognition, or iris scan—or with a PIN that’s locked and secured on the device.”

The genesis for Microsoft’s original MFA offerings stem from their acquisition of PhoneFactor nine years ago providing MFA server support with voice, text, hardware and software tokens. Subsequently, Microsoft invested in this base code to eventually bring this solution to Azure. In our interviews with Microsoft over the past 18 months, they have been increasingly adamant that the use of passwords is nearing its end. In the near future, the use of passwords to authenticate to Azure-based services will be deprecated in favor of passwordless authentication. While this may appear to be quite a stretch, we applaud the fact that Microsoft recognizes the inherent risks associated with continued use of passwords – and if any vendor can pull off this sea change, Microsoft is one of the leading candidates.

Microsoft’s current passwordless strategy is comprised of the following offerings:

1. Windows Hello for Business replaces passwords with strong multi-factor authentication on Windows 10 platforms, including PCs and mobile devices. This authentication consists of a new type of user credential that’s linked to a device and uses a biometric or PIN. It lets you sign in with your face, iris scan, fingerprint, or a PIN, and enables you to authenticate to enterprise applications, content, and resources without a password being stored on your device or in a network at all. The biometric data is only used locally and never leaves the device.

The Windows Hello provisioning process generates a cryptographic key pair bound to the Trusted Platform Module (TPM) on a device. Access to these keys and obtaining a signature to validate user ownership of the private key is enabled only by the PIN or biometric gesture. Taking place during Windows Hello enrollment, the two-step verification creates a trusted relationship between the identity provider and the user. When a user makes the gesture through the device, the provider is able to verify the identity from the combination of Hello keys and the gesture. This activates an authentication token that allows Windows 10 to access resources and services.

2. Microsoft has also been working with partners to ensure FIDO2 security devices work on Windows, the Microsoft Edge browser, and online Microsoft accounts, to enabling strong passwordless authentication. For shared device scenarios, security keys allow you to carry your credential with you and safely authenticate to an Azure AD joined Windows 10 device that’s part of your organization. You can use any shared Windows device belonging to your organization and authenticate securely—without needing to enter a username and password or set up Windows Hello beforehand. Unlike traditional passwords, these keys rely on high-security, public-key cryptography to provide strong authentication. Plus, these keys have all the benefits of a secured enclave to store credentials while also being portable, enabling more use cases for deskless and kiosk workers.
3. The Microsoft Authenticator app enables users to verify their identity and authenticate to their work or personal account. Microsoft Authenticator can be used to augment a password with a one-time passcode or push notification. The app can also be used to verify multiple factors and replace the need for a password. Instead of using a password, users confirm their identity using your mobile phone through fingerprint scan, facial or iris recognition, or PIN. Built on secure technology similar to what Windows Hello uses, this tool is packaged into a simple app on a mobile device making it a convenient option for users. The Microsoft Authenticator app is available for Android and iOS. In place of encountering a password prompt after entering a username, users get a push notification to verify presence. In the app, users confirm their presence by matching a number on the sign-in screen, then providing a face scan, fingerprint, or PIN to unlock the private key and complete the authentication. This multi-factor verification method is more secure than a password and more convenient then entering a password and a code.

With this as a backdrop of Microsoft’s zero-knowledge authentication strategy, we look at their Decentralized ID strategy, next. Below is an illustration of one of Microsoft’s basic use cases that provides an overview of their Decentralized ID flow.

Figure5: Microsoft Decentralized ID Overview

The components are described by Microsoft as follows:

• DIDs – IDs users create, own, and control independently of any organization or government. DIDs are globally unique identifiers linked to Decentralized Public Key Infrastructure (DPKI) metadata composed of JSON documents that contain public key material, authentication descriptors, and service endpoints.
• Blockchains and Ledgers – —DIDs are rooted in decentralized systems that provide the mechanism and features required for DPKI. Microsoft is participating in the development of standards and technologies that are being developed by the community to allow for a vibrant ecosystem of DID implementations that support a variety of blockchains and ledgers.
• DID User Agents – applications that enable real people to use decentralized identities. User Agent apps aid in creating DIDs, managing data and permissions, and signing/validating DID-linked claims. Microsoft offers a Wallet-like app that can act as a User Agent for managing DIDs and associated data.
• DIF Universal Resolver—a server that utilizes a collection of DID Drivers to provide a standard means of lookup and resolution for DIDs across implementations and decentralized systems and that returns the DID Document Object (DDO) that encapsulates DPKI metadata associated with a DID.
• DIF Identity Hubs—a replicated mesh of encrypted personal datastores, composed of cloud and edge instances (like mobile phones, PCs or smart speakers), that facilitate identity data storage and identity interactions.
• DID Attestations—DID-signed attestations are based on standard formats and protocols. They enable identity owners to generate, present, and verify claims. This forms the basis of trust between users of the systems.
• Decentralized apps and services— DIDs paired with Identity Hub personal datastores enable the creation of a new class of apps and services. They store data with the user’s Identity Hub and operate within the confines of the permissions they are granted.

By combining Microsoft’s passwordless capabilities (e.g., Windows Hello for Business, Authenticator app or FIDO 2 security) with their DID infrastructure, companies can embark on their ZKA² journeys. While it may still be early days for DIDs, the writing is on the wall that Microsoft is taking its customers in a forward-looking direction. TechVision believes Microsoft customers will eventually begin this journey, so there’s no time like the present to become well-aware of their ZKA² strategy and start to plan for it.

IBM

If you search IBM’s website for the phrases ‘decentralized identity’ and ‘passwordless authentication’, you may be surprised at how much information you find.  For this report, TechVision had the opportunity to speak with Sean Brown, the Program Director for IBM’s Identity and Access Management solutions. It became apparent that IBM has been very busy in the IAM space, gradually replacing its legacy IAM products with the IBM Cloud Identity platform, just renamed IBM Security Verify. As the initial name implies, the IAM platform has been completely re-engineered to deploy in cloud or hybrid cloud environments.

Passwordless authentication is now at the core of the IBM Security Verify platform.  The solution works with key identity standards, including FIDO 2 and SAML, to unify access controls for IT services hosted both on-premises and in the cloud. Using a FIDO 2 biometric key fob (USB) such as Yubico Yubikey along with the IBM Verify mobile application, enterprises can deploy Touch ID/Fingerprint as the method that IBM Verify uses to verify users’ identities.

With the many prebuilt connectors included with the platform, organizations can quickly and easily enable access to the most popular SaaS applications using passwordless authentication methods. The solution is also designed to directly integrate with the unified endpoint management platform, IBM MaaS360, to establish more ‘seamless’ digital workspace experiences to end users. The simplicity and breadth of support offered by IBM Security Verify is designed to help organizations to responsibly introduce passwordless authentication technologies that will boost user productivity while enhancing security effectiveness.

IBM Security Verify is also building a comprehensive model for Decentralized Identity (DID).  Over the past several months, TechVision has been briefed extensively on IBM’s Decentralized Identity product agenda, and during our briefing on their ZKA² capabilities, it became even more apparent that IBM is taking the possibility (probability?) of a Bring Your Own Identity world based on DID very seriously. IBM offers a Tech Preview installation kit that allows customers to start prototyping on this platform now, making use of cryptographically secure verifiable claims to passwordless authenticate and authorize (based on claims data) both enterprise and customer users. A snapshot from the DID briefing IBM provided us is show below.

Figure 6: IBM Security Verify DID Offerings

The first thing one can see is the relationship with Indy Peer Hosting.  Indy is part of Hyperledger Greenhouse, an open-source consortium for developing business blockchain technologies that is hosted by the Linux Foundation. Within the greenhouse, diverse global communities can collaboratively develop open-source projects that address enterprise blockchain challenges. These technologies can cross-pollinate and inter-operate, just as the communities driving the projects collaborate in an open and neutral environment.

Hyperledger Indy is one of the frameworks provided by the Hyperledger Greenhouse. It is a distributed ledger that provides tools, libraries, and reusable components for creating and using independent decentralized identities. Indyrepresents the idea of a self-sovereign identity that eliminates multiple usernames and passwords – as in BYOI. Based on a distributed ledger, this identity interoperates across several domains, applications, and organizational silos. Indy puts control of the identity in the hands of the user, not the organization. That is, individuals will not have to rely on big organizations to store and share their personal data. Instead, the user can determine what data is accessible and for how long. This is illustrated further below, with the Indy Distributed Ledger Technology (DLT) providing the underlying blockchain-based credential and claims repository foundation.

Figure 7: IBM Security Verify 3-Layer DID Model

From our perspective, this is one of the most advanced ‘sandboxes’ an enterprise can find to begin their DID on distributed ledgers journey. Combined with their passwordless authentication capability, IBM Secure Verify has fast become a leader in the ZKA² market, and we encourage our customers to investigate IBM’s capabilities as a viable means to transcend legacy, password-based and PII-centric IAM / security models.

ForgeRock

ForgeRock is an identity and access management software company that develops commercial open source identity and access management products for Internet of Things, customer, cloud, mobile, and enterprise environments.

ForgeRock has built a scalable platform TechVision had the opportunity to recently interview Peter Barker, ForgeRock’s Chief Product Officer, who provided an overview of the soon-to-be-released Version 7.0 of the ForgeRock IAM platform as well as his vision for ZKA².  We also had the opportunity to speak with Andy Hall, ForgeRock’s Director of Product Management, who provided us with more insight into the platform’s Intelligent Access capabilities.

ForgeRock’s IAM market share continues to grow substantially, as many organizations continue to modernize their IAM infrastructures (both EIAM and CIAM), migrate their IAM workloads to the public cloud and embark further on their digital transformation journeys. ForgeRock envisages the future of identity management as a combination of people, services and things that are increasingly context-aware and, based on this combination of elements, allow different levels of access. ForgeRock asserts that the next generation IAM will become identity relationship management (IRM) with a focus on establishing end-to-end IAM solutions with identity management coupled with IoT, consent and privacy controls.

As illustrated below, the ‘AI-powered’ ForgeRock Identity Platform is intended to be an autonomous IAM solution that can be implemented across an organization for all identities (workforce, consumers, things), and offers feature parity across all delivery options, including on-premises, any cloud environment, and as a service.

Figure 8: ForgeRock’s IAM Platform Overview

Via Intelligent Access, IAM system configurators can use an intuitive interface to design ‘authentication trees’, which create the logic associated with various user authentication stories. This drag-and-drop interface allows configurators to integrate the decision logic associated with user and device types and the parameters that can take the authentication journey across multiple paths depending on input signals that may include geo-location, device identity, time-of-day and a wide range of signals that would affect the authentication path.

With ZKA² in mind, Intelligent Access enables key features in their 7.0 release that include usernameless and passwordless authentication, which leverages the biometric capabilities of the user’s registered/known mobile device (iOS and Android, FIDO 2 devices). This can allow for the omission of a user ID during authentication, while the end user can then select the user ID/account to use after authenticating biometrically without providing a user ID or password. The user ID/account information is stored in OpenDJ, the backend ForgeRock directory service.

The capabilities are built using the W3C and FIDO Web Authentication (WebAuthn) standard ratified in 2019 and backed by major vendors like Google, Apple, PayPal, Mozilla, Microsoft, Okta, ForgeRock, Yubikey and Qualcomm. It aims at defining a web-browser API for the creation and use of strong authentication credentials based on public key cryptography. The driving force behind the standard is to increase security for the authentication process by removing or complementing password-based authentication while remaining convenient for end-users.

Using WebAuthn, ForgRock creates a public and private key pair upon user device registration, storing the user’s private key within the Trusted Platform Module (TPM) on the user’s devices. The end user authenticates biometrically to the device via fingerprint or faceprint, and the device creates an authentication token digitally signed with the user’s private key to the ForgeRock Open Access Manager (OpenAM). The public key, stored in OpenDJ and accessible by OpenAM is then used to validate the authentication token, removing the need for a password.

While ForgeRock doesn’t offer a discreet DID-centric solution directly, they have partnered with Ontario, Canada-based 1Kosmos, who has developed their BlockID platform to offer a range of solutions from password-less authentication to identity proofing, including verifiable claims.

Figure 9: 1Kosmos DID Model Built on ForgeRock and Ethereum

1Kosmos leverages a Distributed Ledger to securely store users’ identity information, with access controlled by the user(GDPR compliant) as well as a layer of privacy built around Ethereum to execute smart contracts. This is the BlockID Private Blockchain ecosystem.

As per W3C DID standards, BlockID solutions use public key cryptography to protect the user’s identity data by encrypting and digitally signing it. The data is also signed when it’s verified by a trusted third-party certification service using BlockID Verify and when it’s exchanged between users and the enterprise or service providers.

It is very important to note however, that ForgeRock recently completed a new round of funding nearing $100M (announced April 21, 2020), some of which is slated to be used toward developing its own Decentralized Identity solution. TechVision Research has assisted several large, global enterprises architect and deploy ForgeRock EIAM and CIAM components on public clouds (e.g., AWS and GCP) and on-premise. Overall, the experience has been positive, and we feel that ForgeRock’s improvements in their 7.0 release will only enhance this experience. With that said, we urge interested customers to watch ForgeRock closely for emerging DID-centric IAM capabilities. In the meantime, the passwordless and usernameless features available in Release 7.0 are very serviceable toward helping organizations move to zero knowledge authentication today.

Ping Identity

TechVision had to the opportunity to have a briefing with Andrew Goodman, Director of Product Marketing at Ping Identity. As a public company, Ping has shown good growth, which we feel bodes well for its customers, given that a strengthening revenue stream is an important metric for long-term vendor viability. 60% of their customers are in the Fortune 100, and they have a strong footprint in the largest US banks, pharmas and retail organizations.

The IAM market share for Ping is growing around their Ping Cloud offering, which exists in both a public and private SaaS model, and is built on the PingOne platform. They have a sizeable number of channel partnerships, including Accenture, PwC, Deloitte, Optiv – reporting over 300 such partnerships worldwide.

While discussing their plans for the near future, Andrew shared the following high-level Product Roadmap Themes illustration.

Figure 10: Ping IAM Product Roadmap Themes

The in-cloud or on-premise models can be deployed selectively, in a hybrid manner. The key takeaway from Ping’s strategy is the ability for their customers to selectively deploy software and services in an architecture that best fits their customers’ organizations (i.e., cloud, on-premise, SaaS, etc.). It is apparent that Ping is continually investing in developing their cloud platform on PingOne in order to better meet their customers’ requirements for a flexible and effective IAM platform.

Figure 11: Ping Platform/Capability Alignment

The foundational IAM object (user, thing) database resides within Ping Directory, intended to enable centralized user profile management. Taking an “API first” approach, the platform is supports microservices and DevOps automation in support of application development. APIs for all services make it relatively straightforward for embedding IAM functionality into applications, including MFA, passwordless authentication, continuous and adaptive authentication, consent management, self-service and so forth.

Adaptive authentication features allow end users to link and manage trusted devices so they can securely login to applications using a face scan, fingerprint and other authentication methods. Using their mobile SDK, Ping’s customers can use their own branded mobile applications to enable passwordless sign-on without having to download or use a third-party MFA application.

Expanding their vision of customer-centricity, Ping, who acquired ShoCard in 2019, will be investing in the Decentralized Identity (DID) model. ShoCard is a digital identity and authentication platform built on a public blockchain data layer, using public/private key encryption and data hashing to safely store and exchange identity data, which includes biometrics such as fingerprint, facial, iris and voice. ShoCard’s approach to identity is different than existing solutions in that the user owns and carries her own data within her mobile app and is the sole person who decides with whom to share it with and which pieces of identification to share. The blockchain is then used to validate that information and confirm other third parties who have definitively certified the identity of the user. There is no privately held central location that holds user’s private information and pieces of a user’s identification does not need to be spread in other services in order to authenticate or prove ownership of an account. The mobile app was originally developed to be as easy and intuitive to use as a driver’s license, but secure enough for a bank. While details of how this will help inform Ping’s product roadmap are not yet available, TechVision will be watching these developments closely and will keep you appraised of Ping’s direction in the DID space.

We’ve seen Ping get much more aggressive over the past year and they appear to be moving in the right direction in 2020 with their hybrid deployment model and much improved focus on key Zero Trust requirements. It appears Ping Identity is now more clearly focused, their solutions have matured to better meet the needs of the industry and their channel partnerships have grown and strengthened to the point that we feel Ping will likely be a viable option for many organizations navigating the ZKA² IAM market. While Ping’s significant ShoCard acquisition is currently being assessed as to the future developments and fit within the company’s portfolio, we think this is an important stake they are putting in the ground.

Trusona

Trusona is one of the pioneers in passwordless authentication. Trusona was founded in 2015 by cybersecurity expert Ori Eisen, is funded by Kleiner Perkins and M12 (Microsoft Ventures).  Over 200 organizations, including some of the world’s largest financial services and health care companies, rely on Trusona’s solutions. TechVision had the opportunity to interview Ori to get more details about Trusona’s progress and plans for the future.

The most basic use case is also the one most of Trusona’s customers deploy. Users must download the Trusona app to their mobile device. The app opens to the phone scanner and the user must scan the QR code from the Trusona registration page, which is completely brandable. Once the QR is read, the user must authenticate to their phone with their fingerprint. This creates a link between the user and the cryptographic keys created by the Trusona app. When the user logs into a Trusona-integrated website, the Trusona app generates a push notification on the phone and the user authenticates to the phone with their fingerprint to authenticate and then swipes the ‘accept’ button on the push notification. Viola, passwordless authentication.

Trusona has implemented an anti-replay design that takes a snapshot of the user’s behavior and device data such as date and time, finger pressure and a number of other factors that are converted into a hashed nonce. The nonce represents a point in time that cannot be repeated.

Trusona is linked to all of the U.S. Department of Motor Vehicles so that all drivers’ licenses can be verified in real time, providing a three-factor authentication scheme. The first step is described above (biometric and push notification), with the third factor being the capability to scan one’s driver’s license into the Trusona app. Via the linkage with DMVs, the bar code on the back of the license is this ‘third factor’.  This capability is a strong means of identity proofing.

Trusona provides SDKs for integration with many of the leading IAM solutions and service, such as:

• Azure Active Directory B2C and B2E
• Okta Cloud IAM
• Ping Federate
• ForgeRock
• Thycotic Privileged Access Management
• CyberArk PAM
• BeyondTrust PAM
• Zoom

They also provide mobile SDKs for iOS and Android; Server SDKs for Java, .Net, Ruby and Javascript; and a Web SDK for TruCode.

TechVision is impressed with the level of thought that has gone into the user experience as well as the technical design of the Trusona solution. While Trusona is a passwordless, zero-knowledge authentication approach, it can be readily integrated with zero-knowledge authorization solutions to enable a strong ZKA² candidate for many customers.  Recall that both Microsoft, as well as Akamai (Janrain CIAM) are significant investors in Trusona, and this should translate to strong market adoption in the coming months and years.

Okta

Founded in 2009 by a team of former Salesforce executives, Okta is a cloud-based identity and access management platform built on Amazon AWS. Okta was one of the first IAM solutions built ‘in the cloud’ from the ground up, rather than a cloud-instantiated on-premise solution suite. Their solution has gained a good deal of traction with enterprise customers over the past five years, as more and more companies look to migrate much of their IT infrastructure – including IAM, to the cloud. During our recent interview with Okta’s Product Marketing Leader, Swaroop Sham, we discussed Okta’s ZKA2 vision.

To begin with, Okta’s MFA solution, Okta Verify, is an MFA factor type designed for end user identity verification with the Okta IDaaS service. Okta Verify is available for iPhone, Android, and Windows devices. Okta Verify supports Touch ID technology to guard against unauthorized use of Okta Verify. Administrators can configure an end-user fingerprint request, which appears after the initial MFA challenge. Okta also supports FIDO2-compliant USB fobs such as Yubico’s Yubikey.

Perhaps of utmost interest was the announcement in April 2019 of the launch of Okta Ventures, a $50 million investment fund. Okta Ventures will invest in and nurture cutting edge technologies aimed at solving challenges across the modern technology landscape, focusing specifically on identity, security, and privacy. In addition to announcing the creation of the fund, Okta also announced its first investment in Trusted Key, a blockchain-based digital identity company.

Founded in 2016 by former executives from Microsoft, Oracle, and Symantec, Trusted Key has built a decentralized digital identity solution to enable organizations that work together as ecosystems to share strongly proofed user identities with user consent. Combining mobile and blockchain technologies, Trusted Key’s approach appears to be resonating with customers in healthcare, finance, and retail ecosystems.  Said Amit Jasuja, Trusted Key’s CEO as part of the fund’s announcement, “Decentralized identity marks a profound change for the identity industry, and we believe we are in the early stages of this change. Joining the Okta Ventures portfolio gives us a chance to access more than just funds to build our business, as Okta’s experience and depth of knowledge in the identity space will be invaluable as we move forward.”

For organizations that are already deployed on Okta, you have been warned. We advise you to dust off your IAM strategies and get ready for IAM v2 based on ZKA2.

Beyond Identity

Beyond Identity is a relatively new company on the scene that is gaining traction quickly. Publicly announced in April, 2020, and founded by well-known tech entrepreneur Jim Clark and Tom Jermoluk, founders of Silicon Graphics (SGI), Netscape and several other well-known and successful companies, Beyond Identity announced a $30 million in Series A funding from co-leads Koch Disruptive Technologies, LLC (KDT) and New Enterprise Associates (NEA). The company’s sole aim is to deliver a “fundamentally secure solution (based on industry-standard certificate chains) for passwordless identity management that requires no changes to security infrastructures, completely removes login friction for end users, and provides consumers with a much more secure alternative to password managers.”

Headquartered in NYC with development offices in Dallas, the currently 60-person company is developing and promoting the concept of a user-manageable personal certificate authority coupled with self-signed certificates. The cloud-native platform provides a secure method of authenticating users and devices without passwords, by using X.509 certificates and the TLS protocol to  create a Chain of Trust™ that includes user and device identity and a real-time snapshot of a device’s security posture in an immutable package that is signed by a provably secure certificate. Their core and enabling technology is illustrated below.

Figure 12: Beyond Identity Core and Enabling Technology

The system is compatible with FIDO2, but uses the public-private key pairs embedded within X.509 certificates to establish a chain of trust that is maintained by the Beyond Identity App. This is intended to simplify recovery from lost keys and enables the user to manage a set of keys for multiple devices, such as tablets, computers, and perhaps other family members’ devices. The user’s actual identity is associated with the root certificate of the chain, while intermediate links in the chain of trust signify other devices, and the terminal leaf of any chain represents individual certificates for sites/services being visited. The private keys are securely stored in device enclaves and are neither exportable nor centrally maintained anywhere. A TLS handshake does a few things each time a connection is made between a client and server:

1. Establish a secure connection. Key exchange algorithms such as Diffie-Hellman or RSA can be used.
2. Each side of the connection presents their whole certificate chain to the other side.
3. Each side challenges the other side to prove that they own the private key corresponding to the presented public key in the leaf cert. (Encrypt a short token with the opposite side’s public key, which they have to decrypt with their private key and send back.)
4. Validate the other side’s whole certificate chain to ensure it is properly signed — done by verifying the signature of each cert in the chain, using its signer’s public key. Its chain must end in a self-signed root certificate.
5. Each side then must check if the root certificate is acceptable. Client-side (browser) acceptance means it is one of the groups approved by the CA/B Forum (released in a list with the OS, itself signed).

TLS ensures that the presenter is the owner of the private key corresponding to the leaf certificate. All vulnerabilities of passwords are eliminated because there is no shared secret. It is replaced with a public key (in a certificate) whose secret private key is never shared. In fact, it is forever stored in the device’s secure enclave and is not even available for export. The public key is shared, but TLS guarantees that the presenter is its owner because only they can possibly know the private key of the leaf.

Beyond Identity provided the following illustration of how their passwordless solution is integrated with enterprise IT environments to support single sign-on.

Figure 13: Beyond Identity SSO-Based Login Flow

In the scenario illustrated above, the Beyond Identity cloud is configured as a standard delegated identity provider in the SSO chain. The Beyond Identity App creates and manages the private key. It is an on-device authenticator that signs the certificate and presents the chain to the connection the first time when the user registers with the site. The site does step 3 along with the others, then stores any part of the SHA-256 encoded certificate chain similar to how it would have stored a password. Similar configurations can support CIAM as well as EIAM.

Beyond Identity has quickly established partnerships with Okta, Ping and ForgeRock. They are also currently working with Microsoft to develop a Beyond Trust custom authenticator that can be invoked with Windows Hello. The solution is priced aggressively, in line with current MFA solutions such as Cisco DUO. Given their pedigree, funding and seemingly elegant technological approach, TechVision feels Beyond Trust is definitely worth a good look for customers embarking on their ZKA² journey beginning with passwordless authentication.

Other Vendors

Google is a vendor that many of our customers ask about with respect to ZKA² offerings. As of this writing, the Google Authenticator MFA solution is still used somewhat, but the market is clamoring for more from Google. Behind the BeyondCorp moniker, Google has added biometric support for Android users to authenticate to Google services and applications via fingerprint, incorporating their Titan Security Key product into Android. So, Google is on the passwordless experience journey, but today is a laggard, not a leader. And, they have not publicly stated any DID direction, leaving their ZKA2 plans as yet unknown. Still, they are Google and bear watching closely.

Other leading IAM vendors such as MicroFocus, CA (Broadcom), iDaptive (Centrify), OneLogin and Oracle are each venturing into ZKA2 at their own paces – some more aggressively. Some have MFA solutions that have recently become passwordless through biometric integration. It is understandable that the move toward DID is daunting and requires much product planning. Some of the companies with deeper pockets (e.g., Microsoft, IBM) may be able to lay the groundwork and help prove out the concepts before these vendors can justify doing more. That is not necessarily a sign of dispassion, but perhaps more of a sign of pragmatism.

Conclusions and Recommendations

We don’t want to have to say we told you so. Beginning in 2016, TechVision Research has been advising our customers to stay abreast of the advancements in Decentralized Identity leveraging distributed ledgers and blockchain. Admittedly, there was much confusion around blockchain and bitcoin and questions such as ‘how can bitcoin affect IAM?’ We were never talking about bitcoin, but the capabilities of the blockchain itself to become a widely distributed yet trusted means of storing and selectively sharing information.

In our view, DID can possibly be viewed as Phase Two of the ZKA² IAM revolution. Phase One is clearly passwordless authentication. For the past couple of years, we have been reporting that MFA is rapidly becoming the default standard for authentication; the combination of increased scale, the lack of well-defined perimeters, increasingly sophisticated threats and improvements in MFA offerings are influencing this evolution. MFA services are getting better, smarter and easier to use and that is accelerating a more wide-spread movement to MFA. Given the increasing adoption of MFA, it is logical to make the leap from SMS-based One-Time-Passwords (OTP) or PIN-based authentication to biometrics embedded in the users’ devices. This is the dipping your toe in the water approach to ZKA²: first you do away with passwords, and tie users’ (and things’) identities to their mobile devices, which act as hardware tokens. In a nutshell, this is the first step toward BYOI.

For Phase Two, DIDs can be created now using the very-well designed and supported tools from long-trusted vendors like Microsoft, IBM, Okta, Ping and ForgeRock. These can help you quickly spin up a distributed ledger and begin working with verifiable claims. This process helps you get plugged into the community of DID, BYOI and self-sovereign ID like Sovrin, Evernym, Indy, Ethereum and so forth. Don’t wait. Because, you’ve been warned. This is where IAM is headed. Three years ago, you may have been able to call our bluff, but today it is clear the ZKA² train is leaving the station.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM.  Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include identity and access management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, AI, new IT/business models and organizational strategies.

He was President of Burton Group from 1999 to 2010, the leading technology infrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President at Gartner.

[1] The FIDO (“Fast IDentity Online”) Alliance is an open industry association launched in February 2013 whose mission is to develop and promote authentication standards that help reduce the world’s over-reliance on passwords.