Published 08 June 2021

Abstract

The concepts of Decentralized Identity started with User-Centric Identity over 20 years ago and the basic concepts still resonate with those looking to control their digital experience. That said, we’ve covered this space for the last 5 years (Blockchain Identity – 2016, Identity is the New Perimeter – 2017, Decentralized Identity — 2019) and it is still “emerging”. This report analyzes why is it still emerging and what needs to happen to achieve more widespread adoption. We start with an update on the current state of Decentralized Identity and the related area of verifiable credentials.

This space is truly disruptive; traditional trust models based on the assumption that “the possession and presentation of credentials equals entitlement” are no longer sufficient, and approaches such as the Trust over IP (ToIP) model are emerging leveraging Decentralized Identity and verifiable credentials. As we began this update to our research on this topic, we are focused on answering these questions:

• Are Decentralized Identity services built on blockchain and leveraging verifiable credentials truly a better model?
• How should our enterprise clients factor these nascent technologies into their strategies and roadmaps?

We do believe that Decentralized Identity is a better model that provides scalable, peer-to-peer trust and verification across the Internet without traditional vendor lock in or location dependencies. While not yet ready for “prime time”, we do recommend clients to begin engaging with working groups and early vendor offerings, consider Decentralized ID in your IAM architecture, get educated, and engage in pilots and POCs. We’ll also cover key vendors, pilots and activities.

Authors:

Gary Rowe CEO & Principal Consulting Analyst [email protected] Gary Zimmerman Principal Consulting Analyst [email protected]

Doug Simmons Principal Consulting Analyst [email protected] Phil Windley Principal Consulting Analyst [email protected]

 

Executive Summary

Digital transformation and the proliferation of identities and identifiers are placing new demands on Identity and Access Management (IAM) services. Traditional IAM models are centralized, inflexible and siloed and not easily integrated with many of the newer technologies and business models. Such “old school” IAM systems are limiting the ability of enterprises to embrace digital transformation and become modern digital enterprises.

What is needed is an effective bridge between the analog and digital worlds. This report describes a Decentralized Identity (also known as Self-Sovereign Identity or SSI) movement TechVision sees as an attractive proposition for identity consumers that are overwhelmed by the current approach as well as an opportunity to better mitigate risk for the enterprise. Identity may be the new perimeter, but that doesn’t mean that the enterprise needs to retain so many identifiers and associated personal attributes; they simply need to incorporate distributed identities into their own ecosystems. The Decentralized Identity value proposition is even more compelling as the world has dealt with a global pandemic and further exposed the flaws in legacy hierarchical IAM models.

The current model for establishing an identity and granting unique credentials is a process that must be replicated for each site an individual connects with. This results in too many IDs and passwords for the average human to remember. To ease this burden, credentials have been shared using federation, Single Sign On (SSO), social login and a myriad of authentication and authorization schemes. But most of these solutions are not solving the fundamental problem—the lack of trust on the Internet.

As we documented in our report, “Digital Trust”, this lack of trust causes enterprises to spend trillions of dollars every year trying to properly allocate and remediate business risk based on trusting the identity attributes (credentials) presented by employees, customers, and partners. And the problem is ready to take an exponential leap in complexity as billions (some say trillions) of connected devices and services present and consume identity credentials sans human intervention.

Enterprises are looking for a flexible, adaptive and secure IAM foundation and incorporating decentralized identities into this new foundation is a likely outcome—but the challenge is determining when this movement will occur and what the underlying technologies and ecosystems will be.

Decentralized Identity is a disruptive approach to addressing the trust problem at its core— determining how to prove control, technical trust and human trust as follows:

• The presenter of the attribute (credential) has control of the unique identifier that the credential was issued to, the credential hasn’t been tampered with, and it hasn’t been revoked. This establishes technical trust.
• The issuer of the credential has the authority to issue it, and explains the criteria used to create the credential. This establishes human trust or provenance.

While this disruptive approach may be a few years away from wide-scale adoption, the impact is so deep and broad that most enterprises should be examining this area and considering how to incorporate a trusted decentralized identity ecosystem within their intermediate to long term planning horizons.

Consider that one of the consistent areas of guidance TechVision has given our enterprise clients is that future state IAM services should be flexible, scalable and open/inclusive. This can be achieved with a loosely coupled architecture and incorporating Decentralized Identifiers (DIDs) as a means of enabling the owner (technically the controller) of the identifier to gather and maintain attributes – called verifiable credentials, associated with their identity. Such verifiable credentials can be digital equivalents of employee identification cards, birth certificates, passports, education certificates, or anything issued by one entity and verified by another. The goal is for specific verifiable credentials to be exchanged and verified as required in real-time within the context of the relationship and the transaction being executed. The credentials required are driven by access policies based on entitlements, the sensitivity of the data being accessed, transactional risk, external verification data and other supporting information.

Identity can be thought of as a new layer in the OSI protocol stack; one that helps to identify users, resources, rights and to validate credentials. When we examine the current Internet protocol stack and architecture, we find that virtually everything from physical access to transport, to presentation and applications are represented, but identity and credentials are not explicitly included. TechVision believes that the lack of this “identity layer” is a fundamental flaw that decentralized identity services and/or other identity standards have the potential to remediate.

The Problem; Achieving Trust at Internet Scale

The problem has existed since the early days of the commercialization of the Internet; how to achieve trust at scale in a way that isn’t too taxing on the individual and too risky for the organization providing services. We have figured out how to achieve scale via the widely adopted opensource implementation of the TCP/IP stack. This offers the capability for any two peer devices to form a connection and exchange data packets regardless of their local network. Without a doubt, the various TCP/IP implementations have driven a tremendous amount of innovation over the last 30 years. However, there remains a significant and widely recognized gap in Internet architecture: a means for peers to establish trust over these digital connections. This gap has often been referred to as “the Internet’s missing identity layer”. Kim Cameron (former Microsoft Identity leader and global IAM expert) raised this issue a few decades ago and we believe the need for this identity layer is accelerating as individuals and organizations become more and more dependent upon being “always connected” as the complexity of these connections grow.

This “Layer 8 identity service” can provide a means for individuals and organizations to establish and manage the identifiers they own. This capability can be a conduit for a new type of individual control and empowerment that doesn’t exist at scale today, and this lack of an identity layer is at least partially responsible for the massive proliferation of identities we have today. The challenges aren’t related to just a lack of individual empowerment.

IAM environments, whether enterprise or customer focused, are implemented as a one-way means for untrusted end users to prove they are who they say they are in order to access the digital realm: enterprise IT resources or online products and services. This basic authentication model is repeated within practically every organization around the globe. Typically, such a model forces individuals to acquire identities from every enterprise and online service provider they interact with, and remember IDs/Passwords, answer security questions, perhaps set up Multifactor Authentication (MFA) across hundreds of sites and applications and provide personal identifying information (PII) in the form of specific attributes that describe who the person is, where they live, preferences and often financial information. It then becomes burdensome for each of the organizations a person interacts with to store and protect this information in response to ever-present privacy regulations and acceptable IT hygiene.

The rub is that most end-users want a consistent user experience (UX) that can leverage a digital identity across the spectrum of employment, banking, consumer, government interactions and more. In other words, end-users want to use the same trusted identity “agent” for each identity transaction with the enterprises and services he/she interacts with – a concept we often refer to as Bring Your Own Identity (BYOI).

Unfortunately, every enterprise or service provider presents its own identification scheme and attribute data requirements, which means the end-user is learning a new interface, sometimes for one-time use (e.g., site registration), sometimes for sporadic use (once a year for electronic tax filing), and on other occasions, for everyday access (i.e., web-based business applications and mobile apps). This organization-unique identity focus makes the end-user look for shortcuts to create a similar user experience across many enterprises/service providers like:

• Using the same user ID and password across several enterprises/services (for example, an active email address that is easy for the user to remember, and practically guaranteed to be unique).
• Relying on third party Identity Provider’s (IDPs) for identity proofing. Again, a single ID and password to provide a consistent experience.
• Using the same “something you know” security questions/answers across multiple enterprises.

And no matter how much the industry preaches password hygiene and rails against user ID and password reuse, convenience tends to override compliance.

Unfortunately, criminal hackers know this all too well. The lack of this consistent identity layer has resulted in individual and business data being spread around like fertilizer on a global field of iniquity and, as a result, exacerbates opportunities for compromises at an accelerating level.

To better visualize the challenges, we face on the Internet today, let’s think about something we all can relate to, such as going to a shopping mall. Imagine if we had to prove our identity in order to enter the mall. Then we had to produce (or register) a separate, unique physical ID and password for each store we entered while in that mall. And then we had to produce yet another form of ID (a credit card) in order to complete a transaction within the store. If we are employed at one of the stores, we’ll need a separate set of credentials for that one, too. Then imagine the stores placing hidden trackers on us (let’s call them cookies, because that doesn’t sound so bad) to watch where we’ve gone and what we looked at, even if we didn’t buy anything. Sounds rather familiar, doesn’t it?

So, what would the above scenario mean for individuals shopping in a conventional mall or shopping center? First, the mall would be a less attractive place to go. Second, it would be hard for every consumer to keep track of the large number physical IDs and passwords that would be required to visit and conduct business in each store. Third, the personal data provided to get the IDs and passwords from each store could damage both the individuals that supplied the data and the organizations keeping the data if it were compromised. Ultimately, it sets up an adversarial relationship between the store and the individual as each battles the tension between convenience, security, service, and privacy; all because of a mutual (and well-earned) lack of trust.

While the above situation sounds unwieldy, this is basically what happens in almost every on-line interaction. It is a fundamentally flawed system at so many levels because individuals that heavily engage online need to remember IDs and passwords from possibly hundreds of sites and share personal information with the owners of each site (i.e., business establishment, social network or service provider) requiring said credentials. Furthermore, these enterprises need to do the same thing with their business partners.

This lack of trust has created a system that:

• Has generated nearly $2 trillion annually in security and compliance remediation costs caused by identity-based fraud.[1]
• Created a yearly $3 trillion data accuracy problem in downstream operations, analytics, and AI applications. [2]
• Exponentially increased attack surfaces through the social and/or proprietary IDP relationships shared and presented across systems today.
• Increased support costs related to two factor authentication, auto-reset procedures, call center support, proprietary hardware fobs that may be required by proprietary IAM solutions.
• Increased compliance costs as regulators weigh in on consumer privacy issues.

Now that we’ve highlighted the problem, the balance of this report will describe a possible viable and scalable solution: Decentralized Identity services and the four-layer architecture of a Decentralized Identity service.  We’ll provide context for our clients to decide if this is the right solution to address the trust problem and when/how an enterprise can move in this direction.  We’ll start by describing the basics of Decentralized Identity, then consider a path towards Decentralized Identity, evaluate the state of the industry and conclude with some specific recommendations.  We’ll now provide a brief tutorial on the basics of Decentralized Identity.

A Decentralized Identity Level-Set

So, how do we solve the challenge of achieving trust at scale across the web? It starts with what Phil Windley described at the TechVision Chrysalis Conference in November 2019 as an “Identity Meta-system”. This includes an encapsulating protocol, a consistent user experience and a modular approach that provides user choice. The goal is to have a “life-like” Identity System across the Internet. In looking at identity in this manner we separate the identity component from the rest of the application architecture. This allows us to optimize the end-user experience while minimizing the risks for the enterprise by treating identity proofing as part of the plumbing, not a problem requiring a proprietary solution.

To achieve the above goals, we need to turn the notion of an enterprise centric IAM architecture (I “rent” you an ID) into a peering paradigm (We share IDs that each of us can prove we control). What does that mean? It means that end-users and enterprises negotiate their digital relationship as peers rather than supplicants or adversaries. That is the underlying foundation of decentralized identity.

Toward this end, initiatives such as the Hyperledger Aries project, the Decentralized Identity Foundation, the Ethereum Foundation, and the W3C Credentials Community Group are all working together to build the standards that define, and the tools to implement the missing identity meta system. This has been described as the “Trust over IP” stack consisting of two layers of the stack focused on technical trust and two layers focused on human trust; all of which are necessary to fully resolve the trust problem. What follows is an excerpt from the currently defined Trust over IP Technology Stack (ToIP) RFC draft being defined by Hyperledger Aries. Note that what this illustrates is actually a “dual stack” that incorporates both technology and governance – underscoring the fact that digital trust cannot be achieved by technology alone, but only by people and technology working together.

Figure 1: Trust Over IP Stack

The Trust over IP Stack as an example of a layered architecture and approach to building a Decentralized Identity ecosystem and governance model. A brief description of each layer follows.

Layer 1: Public Utilities for Decentralized Identifiers (DIDs)

Layer 1 is the base of the Trust over IP stack and is fundamentally made possible by new advancements in cryptography and distributed systems, including blockchains and distributed ledgers. Offering high availability and cryptographic verifiability enables strong roots of trust that are decentralized so there will not be single points of failure. This layer consists of a new type of identifier called a decentralized identifier (DID), a globally unique identifier in which the control of the identifier can be proved using cryptography.

Decentralized Identifiers

Adapting these decentralized systems to be the base layer of the ToIP stack requires a new type of globally unique identifier called a Decentralized Identifier (DID). DIDs are designed to provide four core properties:

1. Permanence – A DID effectively functions as a Uniform Resource Name (URN), i.e., once assigned to an entity (called the DID subject), a DID is a persistent identifier for that entity that should never be reassigned to another entity.
2. Resolvability – A DID resolves to a DID document—a JSON data structure describing the public key(s) and service endpoint(s) necessary to engage in trusted interactions with the DID subject.
3. Cryptographic verifiability – The cryptographic material in a DID document enables a DID subject to prove cryptographic control of a DID.
4. Decentralization – Because they are cryptographically generated and verified, DIDs do not require centralized registration authorities (think central point of failure, compromise, or expense) like those needed for phone numbers, IP addresses, or domain names today.

DIDs and DID documents are not the only cryptographic data structures needed to support the higher layers of the ToIP stack. Others include:

1. Schemas define the claims (attributes) that can be included in verifiable credentials (Layer Three).
2. Credential definitions specify the claims and related metadata needed by an issuer of verifiable credentials (Layer Three).
3. Revocation Registries are cryptographic accumulators that enable credential issuers to revoke credentials while still protecting the privacy of the credential holder (Layer Three).
4. Agent Authorization Policies are also cryptographic accumulators that enable credential holders to activate and deactivate agents operating on their behalf at Layer Two

In summary, any DID registry that supports all of these data structures should work with any agent, wallet, and secure data store that operates at Layer 2.

Governance Frameworks

ToIP architecture requires is that the governance model conform to the requirements of the ToIP Governance Stack to support both interoperability and transitive trust. This includes transparent identification of the governance authority, the governance framework, and participant nodes or operators; transparent discovery of nodes and/or service endpoints; and transparent security, privacy, data protection, and other operational policies.

Utility governance frameworks that conform to the ToIP Governance Stack model support standard roles for all types of utility governance authorities. For example, the role currently supported by public-permissioned utilities such as those based on Hyperledger Indy include:

1. Transaction Authors: initiate transactions
2. Transaction Endorsers: permission transactions for Transaction Authors
3. Stewards: operate a node of the ledger

Layer 2: The DIDComm Protocol

The second layer of the Trust over IP stack is defined by what is referred to as the DIDComm secure messaging standards. This establishes a cryptographic means by which any two software agents (peers) can securely communicate either directly edge-to-edge or via intermediate cloud agents, as shown here:

Figure 2: Peer-to-peer Agents Using DIDComm

Peer DIDs and DID-to-DID Connections

All DID-to-DID connections are established and secured using pairwise pseudonymous peer DIDs based on key pairs generated and stored by the local cryptographic key management system (KMS, a part of the “wallet”) maintained by each agent[3]. Agents use the DID Exchange protocol to exchange peer DIDs and DID documents in order to establish and maintain secure private connections between each other—including key rotation or revocation as needed during the lifetime of a trusted relationship. Consider that agents are apps on user devices that act as the principal user interfaces for authentication and authorization to a broad range of unrelated digital sites – the incarnation of BYOI.

Because all of the components of peer DIDs and DID-to-DID connections are created, stored, and managed at Layer 2, there is no need for them to be registered in a Layer 1 public DID network. In fact, there are good privacy and security reasons not to – these components can stay entirely private to the peers. This also means that, once formed, DID-to-DID connections can be used for any type of secure communications between the peers. Furthermore, these connections are capable of lasting literally forever. There are no intermediary service providers of any kind involved. The only reason a DID-to-DID connection needs to end is that one or both of the peers no longer wants it. We’ll next look at how these connections can be accessed and managed via agents and wallets.

Agents and Wallets

At Layer Two, the technology components are called agents and wallets. These two logical components are implemented in different ways within the solutions we mention later in this report, but they all rely on common standards and protocols.

Agents

As mentioned earlier, the agent acts as an endpoint for all of the peering connections for the DID controller. However, it does much more as part of managing this connection.

• DID Creation – Establishing DIDs, DID Documents, Credential Templates, and Anonymous Credentials
• DID Authentication– The Agent negotiates the exchange of proofs and credentials for authentication of both public and private DID pairs.
• DID Document Management – Manages the content of DID documents (including key exchange, rotation, and revocation) as part of its efforts to establish and maintain trust
• DID Authorization – Enforces permissioned-based data exchange or command execution between connected peers using techniques such as creating and exchanging verifiable presentations of underlying credentials / claims.
• DID instance recovery – Support data and key recovery and resilience for the DID controller on behalf of the subject

Wallets

Every agent is logically paired with a digital wallet that performs security and storage functions for keys and credentials.

• Decentralized Key Management – A decentralized key management system (DKMS) is an approach to cryptographic key management where there is no central authority. DKMS leverages the security, immutability, availability, and resiliency properties of distributed ledgers to provide highly scalable key distribution, verification, and recovery. The wallet manages the key generation, inventory, distribution, rotation, and replacement separate and distinct from the DID itself.
• Secure Data Management – generate, store, and safeguard sensitive data: key pairs, zero-knowledge proof blinded secrets, verifiable credentials, and claims. These data can be stored locally on the device or remotely in a secured cloud-based data store.

Layer 3: Verifiable Credential Exchange

Layers 1 and 2 together enable the establishment of technical trust (cryptographic) between peers. On the other hand, the purpose of Layers 3 and 4 is to establish human trust between peers. Layer 3 is currently the most advanced in terms of open standards. As Figure 3 below shows, there are three core roles in a verifiable credential exchange – which is also referred to as the “trust triangle”.

Figure 3 – The Verifiable Credentials Model’s Trust Triangle

The core goal of the Verifiable Credentials standard is to enable the digital equivalent of the physical credentials we store in our physical wallets to provide proof of our identity and attributes every day. One key difference is in how the credentials are presented. The driver license in your wallet is a multipurpose credential. You, of course, use it to prove you are authorized to drive a car, but you also use it to open a bank account, board an airplane, and buy a drink. However, in the world of verifiable credentials, the presentation of those credentials is tailored to the needs of the verifier. That means the data requested for verification is packaged by the holder into a credential presentation comprised of claims (select details contained in a credential) and cryptographic proofs of authenticity the verifier needs to make a trust decision.

With fully interoperable verifiable credentials therefore, any issuer may issue any set of credentials to any holder who can then prove them to any verifier. This is a fully decentralized system that uses the same trust triangle as the physical credentials we carry in our physical wallets today. This simple, universal trust model can be adapted to any set of requirements from any trust community. In most cases will not require new “trust infrastructure” at all – but will simply enable existing physical credentials to be transformed into a much more flexible and useful digital format.

The Verifiable Credentials Data Model 1.0 supports several different cryptographic assertion formats:

1. Linked Data Proofs – Linked Data Proofs offer more flexibility and are thus more scalable for global decentralized networks. Due to their native compatibility with JSON-LD, they encourage adoption of an open-world data model and reusable schema definitions that make JSON-LD so powerful as part of the semantic web.
2. JSON Web Tokens (JWTs) secured using JSON Web Signatures – JWTs offer a simple and straightforward way to express data with a limited semantic vocabulary. JWTs are widely used in the JOSE stack and federated identity infrastructure.
3. Zero Knowledge Proofs (ZKPs) using Camenisch-Lysyanskaya Signatures – enable credential holders to selectively disclose claims (or predicates) to verifiers without unintentional correlation—a significant advancement in Privacy by Design architecture that simplifies compliance with the EU General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and similar data protection regulations.

These assertion formats are based on the underlying syntax formats used. JWT is based on JSON, Linked Data Proofs are based on JSON-LD. ZKPs are implemented as additional level of abstraction within both schemas to facilitate selective disclosure. While the selection of JSON or JSON-LD determines the assertion format, W3C is working on standards that allow assertions presented in differing syntaxes to be interoperable.

Layer 4: Application Ecosystems

Layer Four is the layer where humans interact with applications in order to establish trusted interactions that serve a specific business, legal, or social purpose. Just as applications call the TCP/IP stack to communicate over the Internet, applications call the ToIP stack to register DIDs, form connections, obtain and exchange verifiable credentials, and engage in trusted data exchange using the protocols in Layers 1, 2, and 3.

For example, the top half of Figure 4 below shows the basic trust triangle architecture used by verifiable credentials[4]. The bottom half shows a second trust triangle—the governance trust triangle – that can solve a number of problems related to the real-world adoption and scalability of verifiable credentials.

Figure 4: Technical and Governance Trust Triangles

The governance trust triangle in Figure 4 represents the same governance model that exists for many of the most successful physical credentials we use every day: passports, driving licenses, credit cards, health insurance cards, etc.

These credentials are “backed” by rules and policies that in many cases have taken decades to evolve. These rules and policies have been developed, published, and enforced by many different types of existing governance authorities—private companies, industry consortia, financial networks, and of course governments. This is how Mastercard and Visa—two of the world’s largest trust networks—have scaled – any bank or merchant can verify in seconds that another bank or merchant is a member of the network and thus bound by its rules. With the ToIP stack, this governance architecture can be applied to any set of roles and/or credentials, for any trust community, of any size, in any jurisdiction.

Decentralized Identity in the Physical World

There have been countless essays written regarding how an unambiguous, provable digital identity that effectively becomes one’s digital DNA is necessary if we are going to effectively bridge the analog and digital worlds. By now, it may be apparent how Decentralized Identity can affect a BYOI revolution, but the benefits of this approach transcend the use-cases solely of the Internet. For example, imagine how it would be to present a COVID-19 “vaccine passport” with this system in place:

• Upon receiving your vaccine, the hospital, clinic, pharmacy, etc. creates a verifiable credential that is linked to your digital wallet via your DID.
• You go to the airport in order to fly to a country that requires non-citizens to provide proof of vaccination. Your mobile device is linked to your identity wallet (agent), containing your Verifiable Credentials you have been collecting from issuers – including your digital “health pass” that shows your vaccination status.
• Before departure, upon checking in, you scan a QR code on your phone. The gate computer’s agent initiates a handshake ceremony by presenting a cryptographic challenge. You respond to the challenge using a biometric (facial recognition, voice or fingerprint) to activate your agent which responds to the challenge that establishes a secure communications channel via a Peer DID relationship between your phone and the gate computer.
• Using that same channel, the gate computer’s agent then prompts for an assertion stating you are currently vaccinated against COVID-19.
• After your agent presents the assertion, the gate computer’s agent checks if the assertion is authentic and has not been revoked, by verifying the proofs contained in the presentation.
• If the proof is indeed valid, the gate computer’s agent allows the check-in process to proceed and sends the verification to the destination country’s visitor database or some such thing.

In this scenario, no human intervention involved, except for the “scan and tap” that set up the communication channel. While this may seem really complicated, think of this as a protocol-level “Apple Pay”; everything beyond the initial handshake happened behind the scenes in a standardized and auditable way. The overall experience was much more convenient, transparent and secure than what’s currently being done.

Building on a Trusted Relationship; Integrating with Existing Systems

While the decentralized identity model seems very different and is certainly disruptive, there are some similarities with how identity services work today. Most current identity services start by establishing a trusted relationship with an organization that represents an identity and attributes associated with that identity within the context of that specific organization. This is easier with an employee or someone the organization already knows something about but is increasingly important in establishing trusted connections with customers and prospective customers. Once the identity is established and data is collected, the organization can then make access and entitlement decisions based on the attributes stored and other pertinent data; but this is generally a one-to-one connection between an individual and each organization they engage with.

The movement to Decentralized Identity isn’t occurring in a vacuum. IAM has been (and will continue to be) fundamentally changing to support the proliferation of mobile devices, the movement to the cloud and the breakdown of the traditional security perimeter. This is being supported by an overall sea change from fixed to more flexible digital identities that we’ll describe in the next section. This can be thought of as a necessary prerequisite for Decentralized Identity models and we can think of this as Phase 1 of this transition.

Phase 1: The Transition from Fixed to Flexible Identity Services

Before we examine Decentralized Identity in detail, it is important to understand that there are already fundamental changes in the IAM space – and this progression has been unfolding for the past few decades. One of the key changes that is occurring is the movement to increasingly flexible and adaptive identity services. This has been made possible by the movement of identities and identity services to the cloud and driven by the challenges that organizations have faced by being locked into proprietary IAM solutions in the past. There are also products and services offered by solutions providers that bridge disparate environments, federate identities, and provide virtual directory and connector capabilities. Vendors such as Ping Identity, ForgeRock, Radiant Logic, One Identity, Micro Focus, Microsoft, Okta and several others offer on premise and cloud-based services including this “connective tissue” to bridge these disparate identity and data repositories.

As we think about decentralized identity services, we should understand that these concepts are not new. Throughout history there have been static and persistent forms of identification that pertain to very specific expectations. For instance, at birth there is often some form of national identifier (e.g., social security number, birth certificate) attached to each citizen. An individual’s physical attributes such as height, weight, eye and hair color are later published on drivers’ licenses that are revealed with every request. Pictures are on travel passports and ID cards, along with home or work addresses are used to validate that the holder of the identity is in fact the rightful owner. In many ways, society has been functioning by using physical, fixed attributes as the primary form of identification for centuries.

The movement from fixed, static models to more flexible, open models isn’t, of course, limited to Identity Management; virtually every type of infrastructure is moving to a more adaptive, flexible and inclusive model. These services are also increasingly decentralized, often moving to the edge of the networks they occupy. With computing power and software moving to the cloud, coupled with virtualization services, organizations now have unprecedented flexibility.  And the need for a flexible and adaptive suite of IAM capabilities to identify their constituents will accelerate as organizations move more aggressively towards DevOps, microservices, cloud computing and continued expansion of the digital enterprise.

But it isn’t just flexibility that individuals seek – they also expect their personal information currently under the control of someone other than the real owner to be appropriately protected.  In a digital world, sharing unnecessary sensitive information for each transaction should be minimized as it creates undo risk for the enterprise. Sharing extraneous information (information not required for a given transaction) increases the liability of the organization collecting that information and can result in customer negativity towards a brand as well as escalating regulatory penalties.

A clear example of fixed, single purpose identities that include extraneous information can be found with standard credit card handling. Individual names are displayed on credit cards, and an individual’s name along with the associated credit card number and PIN is traditionally all that is needed to purchase goods or services. Individuals (and regulators) are starting to question why merchants, service providers or even employers need more data than is necessary to conduct a transaction. Isn’t the fact that the credit card has available credit for the merchant to receive funds from a customer’s account the only important piece of information the merchant needs? The same is true with taxi drivers, hotel clerks and most transactions that individuals conduct every year.  A name is stamped on the card for ‘identification purposes’, but it is apparent that in today’s digital world, that information (personal name) is a rather meaningless form of verification, and in fact only puts the individual at risk of identity fraud.

Historically speaking, it was important to have multiple attributes available to merchants, service providers and employers so that they could theoretically “triage” this information into some form of assurance that the identity is genuine. Another concept often coupled with shared attributes and establishing trust is ‘reputation’. Questions like “who knows this person?”, “has he or she successfully performed a similar transaction in the past?”, etc. are factored in the decision-making process as to whether to trust the individual. How well this pile of personal information – including reputation, was actually triaged (and protected from misuse) varies widely.  And, with the onset of the global Digital Enterprise, the sharing of this information and its subsequent proliferation has radically increased the opportunity for identity theft and fraud.

TechVision believes there is a better way, and it starts with the transition from fixed to flexible identities and involves only selective disclosure of only the information necessary for a transaction. This is already occurring as enterprises accommodate personal devices, mobile, and other means of identifying employees, partners and customers in a more flexible and accurate way. The point is that there is not one static Identity repository locked into a device or physical location anymore, but many ways to identify people, devices, services and things. Flexibility is the key for every IAM program. So, instead of showing your passport (fixed) to prove your age or the fact that you have been vaccinated, providing a trusted, cryptographically verifiable credential (flexible) that acts as an unambiguous proof is where IAM is headed.

This is also critical in walking the fine line of providing secure identities when needed without sharing data that isn’t necessary for a particular use case. While we’ll introduce some new technologies (at least to some readers) and new approaches in this report, we can start by considering how some of the existing technologies and processes can be intelligently orchestrated to move us towards our goal of establishing identity under the control of the true owner of that identity. This applies to individuals, but also to establishing control of identities and personas for enterprises as well. TechVision believes that decentralized identity services will be part of this new foundation. So, as organizations continue the movement from fixed to flexible identities, we’ll now consider how decentralized identity can add to this movement.

Phase 2: Understanding, Preparing for and Testing/Piloting a Decentralized Identity Approach

As your organization embarks upon the transition from fixed to flexible IAM it is time to consider at least preparing for a Decentralized Identity Program. While this transition is a logical extension to the era of “flexible IAM” in that we are just introducing a new type of object, it is important to understand that this technology we are describing, and the supporting ecosystems are disruptive and rapidly evolving. Even the early pilots will, in all likelihood, be very different from your long-term Decentralized Identity service. In fact, the long-term Decentralized Identity service could eventually become the primary way your organization supports customers, trading partners and – even employees and contractors. Decentralized Identity has to potential to change the IAM and privacy landscape and we believe most large organizations should at least be in the preparation and education stage by 2021.

Before considering preparation and piloting, lets define (per Microsoft, IBM, Sovrin Foundation, W3C…) the high-level goals of Decentralized or Self-Sovereign Identity Services as follows:

• Decentralization: Eliminate the requirement for centralized authorities or single points of failure in identifier management, including the registration of globally unique identifiers, public verification keys, service endpoints, and other metadata.
• Control: Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities.
• Privacy: Enable entities to control the disclosure of their information, including minimal, selective, and progressive sharing of attributes or other data.
• Security: Enable sufficient assurance for relying parties to depend on DID Documents for their required level of assurance.
• Proof-based: Enable the DID subject to provide cryptographic proof (of identifier control and information veracity) when interacting with other entities.
• Discoverability: Make it possible for entities to discover DIDs for other entities to learn more about or interact with those entities.
• Interoperability: Use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability.
• Portability: Be system and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID Methods.
• Simplicity: Favor a reduced set of simple features in order to make the technology easier to understand, implement, and deploy.
• Extensibility: When possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.

In terms of preparation for Decentralized Identity, there are several areas we recommend organizations place their focus over the next year:

• Accelerate your movement from fixed to flexible IAM as described in the previous section. This will make incorporating Decentralized Identity much easier.
• Educate your team in Decentralized IAM including understanding the rapidly evolving standards, vendor offerings and the emerging ecosystems/governance models. TechVision Research can certainly help in this quest, and you are already making progress in this area by reading this report.
• Assess your business needs and possible use cases for Decentralized Identity experimentation.
• Evaluate industry-centric consortiums, vendor sponsored initiatives and collaborative efforts as candidates to engage and/or participate in pilots.
• Factor in future-state Decentralized Identity into your overall IAM reference architecture.

Throughout this report we describe some of the industry efforts you may want to engage with, early vendors participating in this space, how to factor Decentralized Identity into your IAM reference architecture and additional education opportunities.

Building and Architecting a Decentralized Identity Program

TechVision has been working with several large clients that are building their IAM strategies, reference architectures, vendor evaluations and implementation plans so we’ll provide insights here based on both real-world experience and combine that with our research and analysis of the Decentralized Identity technology and market. While Decentralized Identity is still a future direction for most of our clients, it is being experimented with and factored into long term plans and roadmaps today. We estimate that there are several hundred significant pilots currently underway in this space. But how should Decentralized Identity be factored into your future state plans and architectures? We’ll address that by describing key strategies, major architectural elements and design guidelines to consider in defining, architecting and building your Decentralized Identity program.

These programs are often initiated by major customer and employee facing digital programs and support engaging and supporting stakeholders with the proper balance between security, privacy and business goals. To be sure, the increasingly punitive privacy regulations such as GDPR, CCPA, HIPAA and others have become major drivers for ‘building a better mousetrap’ when it comes to IAM. In many ways, privacy regulations scream for Decentralized Identities where the user/consumer/citizen/employee has control over what credentials or attributes are shared with whom and how this information is used, managed or retained (if at all).  In a nutshell, the basic rationale for undertaking a thorough Decentralized Identity strategy is that the expectations of all external stakeholders, whether employees, contractors, partners or consumers/customers, have gone up dramatically in terms of the user experience, user data privacy and appropriate, secure access to relevant online resources.

Once this epiphany is recognized, there will soon follow a tremendous effort to plan for supporting integration with, and migration to, Decentralized Identity services. Efforts from large platform suppliers such as Microsoft and IBM (discussed later in this report) may ease some of these challenges and most large integration firms are investing significant resources in this (and many emerging blockchain and distributed ledger use cases) space.

TechVision recommends starting any Decentralized Identity program (or any key infrastructure initiative) by engaging key stakeholders and developing a baseline set of requirements. Using our assessment of typical Decentralized Identity requirements, we find that stakeholders are often better equipped to modify a unique, organization-specific baseline set of requirements than to start from scratch. We’ll provide this guidance in the next section.

Development of a Decentralized Identity Reference Architecture

After assembling a team of key stakeholders, assessing the current state and collecting prioritized requirements, we generally recommend organizations develop a reference architecture taking our templates (or your favorite reference architecture model) and mapping these requirements into the key capabilities associated with a Decentralized Identity solution.

The TechVision Research Reference Architecture for IAM is this starting point; a master template, shown in Figure 5 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 5: TechVision IAM Reference Architecture Master Template

The capabilities that frame the Decentralized Identity architecture illustrated above are described at a high-level as:

Interact – how end-users and application developers interact with the IAM platform. In the case of decentralized identity this will involve how users, and applications use agents to establish permanent relationships, exchange messages within those relationships, and provide for trustworthy information/credential exchange.

Access – the rules that define the roles, rights, and obligations of any actor or proxy wishing to access individual, enterprise or connected assets. With decentralized identities and verifiable credentials, security and compliance come down to defining the combination of credentials that must be exchanged (and verified) to minimize individual transaction risk between peers.

Change – the capability to define and manage the relationships between the user and the enterprise, as related to access to IT assets. For decentralized identity this means developing a set of listening and discovery capabilities that allow agents to obtain and manage verifiable credentials and to establish (and revoke) trusted peer relationships.

Manage – the capabilities required to manage and upgrade the IAM solution including support of interoperability and portability capabilities of Decentralized Identity and their impact on the embedded base of identity infrastructure.

Measure – the capabilities required to audit and improve IAM activities which now include the capture of activity at all four layers of the ToIP stack.

Store – the capabilities required to share identity information and relationships between the components of the IAM solution. The shared governance frameworks, scale, and responsiveness requirements for connected devices, relationship data, distributed ledgers, verifiable claims and related PII are all factored in.

Figure 6, below, highlights our more detailed capabilities portfolio to consider in the context of technical interactions between the typical components comprising a comprehensive Decentralized Identity ecosystem.

Figure 6: Elements of a Combined Portfolio Architecture

Generally, enterprises should consider Decentralized Identity in the context of their overall IAM program, but as we have said – it is important to understand the specific context of and risks associated with engaging customers, employees and partners and accepting verifiable credentials. It is also important to recognize that the reference architecture patterns of interfaces, authentication, authorization, lifecycle management, persistent storage, and analytics are still being supported, although the control may be different in using a Decentralized Identity model. In the next section, we provide a Decentralized Identity-integrated IAM Reference Architecture drill-down.

Capabilities of the Combined Portfolio Architecture

The next level of the architecture outlines the functional capabilities that are the foundation for a best-in-class IAM Reference Architecture. Each category is broken up into multiple capabilities at a level of greater detail. For example, interfaces can be for applications / developers (APIs, messaging services), Lines of Business, self-service or even robotic processes. This applies to each category and, based on stakeholder input, use cases and priorities can be further developed into Reference Architecture patterns or templates for specific services.

Remember, the Reference Architecture is not focused on the actual implementation of things that carry out these controls. Rather it is a model of what the controls are, how they work, and how they interact to assure the utility of content. As ultimately implemented, different enterprises use different IAM capabilities in different ways to meet different protection needs. And they do so differently for different content and business functions because of the different risks and potential consequences associated with failures and costs associated with protection. One size does not fit all.

Once the required business capabilities are identified, the next layer of the TechVision Research Reference Architecture for IAM allows us to explore each of the specific technology or process elements comprising each capability in the form of a combined portfolio architecture. This is illustrated in Figure 7, below.

Figure 7: Combined Portfolio Architecture

From this point, we can begin to identify the specific capabilities we need to develop an effective Decentralized Identity pattern, described next.

Decentralized Identity Capabilities Map

In the pattern below, we’ve illustrated the IAM capabilities required for decentralized identity integration – removing all other IAM capabilities that are not directly supporting the service.

Figure 8: IAM Capabilities for Decentralized Identity

The capabilities necessary to support Decentralized Identity have been color-coded as follows:

• Red – requires significant investment over next 2 years. The organization currently does not support these IAM capabilities.
• Orange – requires investment over next 2 years. The organization either currently does not support these IAM capabilities or they may require additional investment and deployment in order to achieve a requisite level of functionality.
• Yellow – medium priority; indicates the organization will want to implement the capability but it is not a high or critical priority.
• Grey – indicates capabilities that the organization’s IAM has in place in some capacity, although it could be likely that some augmentation may be required to improve functionality and ubiquity to fully meet requirements.

 

With this in hand, the decentralized identity IAM capabilities are used as input to the development of the Reference Architecture pattern illustrated below.

Decentralized Identity Pattern

Figure 9: Sample Decentralized Identity Reference Architecture Pattern

In this Decentralized Identity pattern, digital identities consist of “peer relationships” between credential issuing institutions (including employers) and end users, along with whatever credentials these and the end user. To create a peer relationship, they each generate a Peer DID and send it to the other, along with the associated public key. These identifiers are self-certifying, and each party can use the information associated with the DID to authenticate the other.

1. In the example illustrated above, the Healthcare Institution will be issuing COVID-19 vaccine passports: credentials that can be given to various patients, caregivers and so forth. To start the process, since the Institution will be issuing a credential, they write a Public DID and credential definition to the Distributed Ledger/Blockchain.
2. An end user enters into a “peer relationships” with the credential issuing institution using her digital wallet.
3. The institution issues a credential, such as the COVID-19 vaccine proof to the end user’s wallet.
4. The end user establishes a DID relationship with a Travel Site.
5. The end user attempts to book a flight that requires proof of vaccination.
6. The Travel Site requests proof of COVID-19 vaccination from the end user.
7. The end user authorizes her wallet to share the vaccination proof.
8. The Travel Site cryptographically validates the vaccination proof and can verify that the credential remains effective with the Institution, without contacting the institution because of the distributed ledger.

As organizations progress towards digital transformation, people, organization, and even things need to be able to transmit instantly verifiable claims (e.g., about their location, accomplishments, value and so forth) to other entities, providing electronic proof that the claim is valid. These 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. 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 Decentralized Identity pattern above, the Distributed Ledger is used to store and timestamp public keys and credential definitions. The ledger serves as the distributed “root of trust” that allows the recipient of a credential to confirm the credential sent by the Holder was properly cryptographically signed by the proper Issuer, was issued to the Holder, and has not been revoked.

In the IAM model illustrated here, a user (or device) selects which verifiable claims to share with specific service provider entities to enable the triaging of ‘identity proofing’ artifacts necessary to properly register, authenticate and authorize access in conformance with the trust triangle described previously.

Key Industry Initiatives

There are several key industry initiatives, early ecosystems and consortiums that are valuable in helping to develop decentralized identity-related standards/services and also provide opportunities for enterprises to gain education and early experience. These organizations are doing some of the early foundational work that can ultimately lead to standards and foundational ecosystems. The initiatives we’ll briefly describe in this section are:

• W3C
• Decentralized Identity Foundation (DIF)
• Trust over IP Foundation
• HyperLedger Indy, Aries, Ursa
• Sovrin Foundation

These are a few of many initiatives that are focused on self-sovereign or decentralized identity, and we believe significant in the advancement of this space for enterprise clients.

W3C

The World Wide Web Consortium (W3C) has formed two groups supporting decentralized identity, a verifiable credentials working group in April of 2017 and a decentralized identifier working group in 2019.

The mission of the Verifiable Credentials Working Group is to make expressing, exchanging, and verifying claims easier and more secure on the Web. The Working Group maintains the Verifiable Credentials Data Model specification, which provides a mechanism to express a verifiable credential on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

The mission of the Decentralized Identifier Working Group is to standardize the Decentralized Identifier (DID) URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the exchange and use of DIDs (authentication, cryptography, endpoint discovery, etc.), and the requirements for DID Method specifications[5].

The W3C efforts are important in that they are defining common language, syntax, and standards for Decentralized Identity implementation and interoperability. In doing so, they provide a foundation for the other industry initiatives (DIF, Sovrin and Hyperledger) and mitigates some risk as vendors develop products and services in the Decentralized Identity arena.

Decentralized Identity Foundation (DIF)

The Decentralized Identity Foundation is consortium that has gained rapid momentum over the past 18 months. DIF describes its charter as “an engineering-driven organization focused on developing the foundational elements necessary to establish an open ecosystem for decentralized identity and ensure interoperability between all participants”. They gained 56 members in the first year including IBM, Microsoft, Mastercard, Aetna, RSA, Sovrin, Civic, uPort, Blockstack, Accenture, Evernym and SecureKey.

An area of focus for the DIF is the DID Authorization Working Group (DID AuthN) and their strategy to integrate DID AuthN with other standards. Their recognition that there are not many “greenfield” environments is particularly attractive to large end uses with a large number of legacy systems and federation/integration approaches. Much as we discussed earlier, the ability to integrate DIDs into existing processes and identity repositories is critical in gaining adoption.

The DIF also plans to leverage an SSI wallet, e.g., a smartphone app, on the web; this differs from common SSO approaches in that it will preserve the user’s privacy by preventing third parties from having the ability to track which web applications a user is interacting with.

A key outcome is a dedicated DID AuthN profile for a Self-Issued Open ID Connect Provider (SIOP). This profile has two goals:

• Staying backward compatible with existing Open ID Connect (OIDC) clients that implement the SIOP specification which is part of the OIDC core specification.
• Adding validation rules for OIDC clients that have DID AuthN support to make full use of DIDs.

The DIF is an organization that enterprises wanting to get their feet wet with respect to Decentralized Identity may want to participate in.

Trust over IP (ToIP) Foundation

On 5 May 2020, the Linux Foundation announced a new addition to its roster of global opensource ecosystem projects: the Trust over IP Foundation. The mission of this new Foundation is to simplify and standardize how trust is established online so that everyone can feel safe, secure, and private in all of our digital interactions—whether between individuals, businesses, governments, or any “thing” on the Internet of Things.

The Linux Foundation is already the home of two directly related peer projects:

1. Hyperledger, the umbrella organization hosting over a dozen projects for advancing blockchain technology for business. Three Hyperledger projects—Indy, Ursa, and Aries—implement key components of the ToIP stack.
2. Decentralized Identity Foundation (DIF), a membership organization building foundational components of open, standards-based decentralized identity. DIF is currently the home of the DIDComm Working Group—the “narrow waist” protocol at the heart of Layer Two of the ToIP stack. DIF also hosts several other Working Groups focused on DIDs, secure data storage, and other aspects of the stack.

Note that the ToIP mission is not to develop all of the standards or components included in the ToIP stack—rather it is to specify how these elements can be combined to fulfill the requirements of all four layers of the stack, for both governance and technology. This means the ToIP Foundation will work closely with other standards development organizations (SDOs), industry foundations, and other consortia to combine their open standards, architectures, and protocols into a complete and coherent stack for Internet-scale digital trust infrastructure.

Whereas early versions of the ToIP stack reflected its historical origins—technology on the left followed by governance on the right—real-world experience soon taught us to reverse it (see Figure 1 in this report). Governance first. In other words, implementing ToIP-based solutions should begin with business requirements, then move to policy requirementstransparently communicated in governance frameworks. Only then should you choose the technology components required to implement those policies. To that end, the ToIP and Sovrin Foundations have announced a cooperative agreement to further the governance aspects of the ToIP stack.

HyperLedger Indy/Aries/Ursa

HyperLedger Indy is one of several projects under the Linux Foundation. Hyperledger Indy is a distributed ledger, purpose-built for Decentralized Identity. Developers can use the tools and libraries from Hyperledger Indy to create identity ledgers that are interoperable across jurisdictions and agencies. This interoperability allows developers to create cross-industry solutions such within, for example, FinTech and Healthcare that can all work together and obey each other’s regulatory standards. Hyperledger Indy has complete opensource specifications, terminology, and design patterns that allow for the development of decentralized identity solutions. Hyperledger Indy describes the technical aspects and hosts the opensource code for the level 1 utility layer of the ToIP stack. While this project supports the development of independent ledgers, most enterprises will most likely work within an established network with an operational utility rather than developing a separate network.

Hyperledger Aries provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. It is infrastructure for blockchain-rooted, peer-to-peer interactions. There are several SDKs, opensource modules, and third-party applications (agents/wallets) supporting the layer 2 and 3 stacks of the ToIP framework.  Frankly this is where enterprises should be concentrating their efforts as they look to operationalize Decentralized Identity as part of their IAM

Cryptography is hard for most developers and that’s where Hyperledger Ursa helps. Hyperledger Ursa is a shared cryptographic library, it enables implementations to avoid duplicating other cryptographic work and hopefully increase security in the process. The library is an opt-in repository to place and use crypto. Hyperledger Ursa consists of sub-projects, which are cohesive implementations of cryptographic code or interfaces to cryptographic code.

Sovrin Foundation

The Sovrin Foundation describes its mission as to “enable access to permanent digital identity for all—both people and organizations—by building, administering, and promoting a decentralized, public, global identity utility”. They expect to achieve this by:

• Ensuring ubiquitous access to the Sovrin Network as a “utility”
• Protecting individual privacy by not being beholden to a government or entity
• Supporting the infrastructure of Sovrin by the Sovrin trust network via “Sovrin Stewards” to operate the network and opensource community for the coding

The basic structure of the Sovrin can be viewed in the following figure:

Figure 10: Sovrin Structure

The Sovrin Foundation is a non-profit organization of volunteers supported by a Board of Trustees representing a global set of organizations working on identity systems and standards. This is intended to be provide governance without being beholden to a single organization or government agency. It is built on a public, permissioned Blockchain in which the verifying nodes are known (nodes that operate the network and approve transactions before being written to the Blockchain), but it is publicly accessible. This approach has been compared to an ATM network with public access but control of the verifiers.

What is most notable about the Sovrin Network is that it is a production version of an Hyperledger Indy ledger that enterprises are currently using to implement key use cases. Beyond the technical infrastructure, Sovrin has addressed the level 1 governance side of the ToIP stack by defining the policies, agreements, and enforcement mechanisms used within the network. This governance foundation is part of the contribution Sovrin made to the cooperative agreement on governance with the ToIP Foundation.

We’ll next look at a few of the early vendors participating in the Decentralized Identity market. There may be opportunities to participate in pilots with these vendors and discuss how these services may fit within their existing portfolio.

Early Market Leaders

In characterizing how and why vendors are on this shortlist, our primary considerations include the investments they are making in the Decentralized Identity area, the planned scalability of the solutions, the strength of the user experience, early pilots, standards support, global support, security/compliance controls, GDPR/privacy support, consent management, single sign on support, federation, integration tools, how effectively contextual information is used, the sophistication of the relationships that are being managed and the accessibility of information to users. Remember this space is early, so a big factor is just that they are committed to this space and making substantive investments. This list includes a few major technology firms and several early-stage companies.

From this point of view, Civic, Evernym, IBM/SecureID, IdRamp, Microsoft, Ping Identity and 1Kosmos are early players in this space worth taking a look at. These are vendors that may be candidates to participate in pilots with and to meet with their product managers. We’ll provide a brief background on each shortlist vendor and a brief description of their solution in alphabetical order.

Civic

San Francisco based Civic is a personal identity verification tool that leverages distributed ledger technology to support the management of digital identities. Civic was founded by South African Shark Tank investor and Internet entrepreneur, Vinny Lingham, and focuses on identity verification for individuals with a goal to make it easily transferable from one service to another. Civic accomplishes this by utilizing their own token built on the Ethereum blockchain.

Civic provides a standalone SDK that customers can integrate into their own app or website. End users can register for DIDs using Civic’s QR code on the enterprise’s web site or a direct link for users to download and follow onboarding instructions in the Civic app. There are no personally identifiable information (PII) databases to manage. The user retains their own PII and may selectively share their verified identity information. Communication between the device and other services uses AES-256 encryption and TLS protocol.

Civic uses a public, permissioned blockchain and has their own application for establishing identities within their ecosystem. This ecosystem works with the application to support users on the front-end, validators to approve transactions and service providers that can offer a range of back-end services such as KYC confirmation and identity attestation support (at requisite surety levels).

Validators are also responsible for verifying identities for the network, both on the blockchain and for service providers. If a user wants to submit personal identifying data to a service provider (e.g., an exchange, a bank, or other service), they could submit the relevant info from their Civic app to a validation contract. These smart contracts act as escrow services for the transaction and provide validators with the identity data. After attesting that the information is authentic, the validators hash it and record the transaction on the network. It’s relevant to mention that in theory a validator could be the service provider itself, and for a user identity’s first interaction with the network, it likely would be.

Additionally, in order to confirm a user’s identity, validators need to crosscheck their information with some other source (e.g., public records, financial records). A government, for instance, could provide a wealth of information as an identity authenticator. Once a validator has verified the identity data, other service providers can buy access rights to this information on behalf of a user with CVC, Civic’s utility token.

Evernym

Evernym is an early player in the Decentralized Identity Space. Evernym’s Decentralized Identity program supported by the Sovrin Foundation ecosystem boasts early customers (generally POCs) including Barclaycard, Irish Life, Novartis, Telus, Bonifii[6] (formerly CULedger) supporting a consortium of Credit Unions, and the International Air Transport Association (IATA)[7]. Evernym is the original creator of the Sovrin codebase and a primary contributor to Hyperledger Indy, Aries, and Ursa.

Evernym has a particular focus in the area of verifiable claims (credentials) around identity, and once in place, supports capabilities such as anonymous payments. Evernym envisions identity as a collection of claims as online trust is established and enhanced as claims are aggregated.

Core Sovrin capabilities supported by Evernym include zero knowledge proofs, pairwise pseudonymous decentralized identifiers (DIDs), self-sovereign identity, and verifiable claims. In terms of specific products/services Evernym is leading with an authorization/digital credential platform called Verity. This is supported by their Verity: Auth authentication service. Evernym also has an on-boarding product called Verity Onboard and a user digital wallet application called connect.me.  The following is a snapshot of the Verity dashboard:

Figure 11: Evernym Verity Dashboard

Next, we’ll look at the Verity: Auth screen.

Figure 12: Evernym Verity Authorization View

Evernym also has a free, smart phone-based digital wallet application called Connect.me that allows end users to collect and present identity data. Evernym is also offering Quick Start and Early Access plans to help enterprises with education, engagement and piloting of their solutions.  They currently have 100 organizations in this program as organizations want to get early experience with Decentralized Identity.

IBM

IBM has been one of the leading proponents of Decentralized Identity and Blockchain/Distributed Leger for the past several years.  IBM has also made substantial investments in Decentralized Identity including a Blockchain as a Service infrastructure, becoming a founding steward for the Sovrin Foundation, proactively supporting standards and leading and providing code/services for several opensource initiatives.

IBM stepped into the vaccine passport discussion this year with the announcement of its blockchain centric Digital Health Pass. This solution is designed to enable organizations to verify health credentials for employees, customers and visitors entering their site based on criteria specified by the organization. It can allow an individual to manage their information through an encrypted digital wallet on their smartphone and maintain control of what they share, with whom and for what purpose. This is one of the solutions in IBM’s “Watson Works” suite of workplace solutions.

Aligned with W3C standards, Digital Health Pass is a hybrid cloud solution comprised of the following:

• Cloud services to address core requirements of credential generation, exchange and verification
• Mobile and cloud software development kits (SDKs) to fast-track solution development
• Applications that address standard use cases for those who do not want to build their own

The high-level architecture appears below:

Figure13: IBM Digital Health Pass Architecture

Currently, IBM offers IBM Verify Credentials as part of a global, public permissioned blockchain ledger – enabling known, trusted issuing organizations to issue credentials to individuals. In turn, those individuals can hold and present credentials to verifying organizations of their choosing, in concert with the BYOI model we’ve been describing. This solution is currently only in Alpha test, so potential customers can play with it in a sandbox. It does, however, leverage the Digital Health Pass architecture described above.

That being said, IBM is clearly very bullish on blockchain and distributed ledger technology, as much of its newest commercial offerings for enterprises is based on this model. TechVision encourages customers considering their proof-of-concept or pilot testing strategy to consider IBM based on their blockchain ‘heritage’ and strong integration technology chops.

IdRamp

IdRamp provides a decentralized identity platform that incorporates the Sovrin distributed ledger for self-sovereign identity. Through distributed authentication, IdRamp aims to secure identity threats by eliminating the need for public network facing identity and access management systems; and removing the need for passwords.

The IdRamp Passport identity wallet and credential management service is built on the open source Hyperledger Aries Framework. Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It’s not a blockchain and it’s not an application, but it does include:

• A blockchain interface layer (known as a resolver) for creating and signing blockchain transactions.
• A cryptographic wallet for secure storage (the secure storage tech, not a UI) of cryptographic secrets and other information used to build blockchain clients.
• An encrypted messaging system for off-ledger interactions between clients using multiple transport protocols.
• An implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found in Ursa.
• An implementation of the Decentralized Key Management System (DKMS) specification currently being incubated in Hyperledger Indy.
• A mechanism to build higher-level protocols and API-like use cases based on the secure messaging functionality described earlier.

IdRamp is a member of the Sovrin Foundation and provides a free digital wallet to help its enterprise customers manage digital credentials and secure connections from any mobile device.

Figure 14: IdRamp Passport Mobile Device Wallet

As illustrated in the mobile device screenshots show above, end users can create multiple wallets for stewardship and self-administration; and use multiple networks for automated credential issuance and verification.

IdRamp has a number of influential partners, including Amazon Web Services, Apple, Google, Microsoft/Azure, SAP, Oracle, Sovrin, Hyperledger Indy and Trust Over IP Foundation (of which they are a founding steering committee member). Deployments are ramping up, and TechVision sees the company as a first mover in the pragmatic deployment of DID. With this in mind, we encourage our customers who are interested in beginning a proof-of-concept or pilot to consider the solution.

Microsoft

For the past few years Microsoft has been incubating a blockchain/distributed ledger-based decentralized identity management program. At its Ignite conference in March 2021, Microsoft announced the launch a public preview of its “Azure Active Directory verifiable credentials”. The solution is initially focusing on university transcripts, diplomas, and professional credentials, allowing end users to add these verifiable credentials to the Microsoft Authenticator app along with two-factor codes. Among pilot programs it is participating in, the Microsoft solution is being tested with the Belgian government and with the United Kingdom’s National Health Service.

Based on ongoing briefings TechVision has had with the company it is clear that Microsoft is committed to investing in this space and has some unique advantages. Microsoft can have a substantial impact on moving decentralized identity from a “science experiment” to the new norm over time given their massive infrastructure.

Microsoft is actively collaborating with members of the Decentralized Identity Foundation (DIF), the W3C Credentials Community Group, and the wider identity community. The company is working with these groups to identify and develop critical standards, and the following standards have been implemented in our services.

• W3C Decentralized Identifiers
• W3C Verifiable Credentials
• DIF Sidetree
• DIF Well Known DID Configuration
• DIF DID-SIOP
• DIF Presentation Exchange

The illustration below shows the overall concept shared by Microsoft that supports identifiers that are owned by the user, a user agent to manage keys associated with such identifiers, and encrypted, user-controlled datastores.

Figure 15: Microsoft’s DID Ecosystem

The illustration above is described as follows:

1. W3C Decentralized Identifiers (DIDs) – Using the Microsoft Authenticator app, 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.
2. Decentralized system: ION (Identity Overlay Network) – ION, which launched in March 2021, is a Layer 1 open, permissionless network based on the purely deterministic Sidetree protocol, which requires no special tokens, trusted validators, or other consensus mechanisms; the linear progression of Bitcoin’s time chain is all that’s required for its operation. Microsoft has open sourced a node package manager (npm) package to make working with the ION network more straightforward for integrating into enterprise apps and services. Libraries include creating a new DID, generating keys and anchoring DIDs on the Bitcoin blockchain.
3. DID User Agent/Wallet: Microsoft Authenticator App – Enables end users to use decentralized identities and Verifiable Credentials. Authenticator creates DIDs, facilitates issuance and presentation requests for verifiable credentials and manages the backup of each DID’s seed through an encrypted wallet file.
4. Microsoft Resolver -An API that connects to Microsoft’s ION node to look up and resolve DIDs using the did:ionmethod and return the DID Document Object (DDO). The DDO includes DPKI metadata associated with the DID such as public keys and service endpoints.
5. Azure Active Directory Verified Credentials Service – An issuance and verification API and open-source SDK for W3C Verifiable Credentials that are signed with the did:ion method. They enable identity owners to generate, present, and verify claims. This forms the basis of trust between users of the systems.

This last bit is interesting, as TechVision feels that one of the more significant aspects of Microsoft jumping into this space is their potential (and stated intent) to integrate Distributed Identifiers into Active Directory (AD) and Azure AD environments which can help more gracefully transition many Global 2000 organizations to this new DID centric model. TechVision also believes that Microsoft “could” leverage the 500 million LinkedIn users to better connect the personal world, to the professional world, to the at-work world. This could be incredibly powerful, and we’ll stay tuned to see.

Microsoft has paid particular attention to building a new model for digital identity focused on individual privacy, data protection and security that spans the physical (IoT) and digital worlds. Microsoft characterizes self-sovereign identity as “essential”, and they stress their commitment to allow individuals to own and control all elements of their digital identity. Microsoft plans to achieve this via a secure encrypted digital hub where identity owners can store their identity data and easily control access to it.

These principles are supported by the following vision as to how Microsoft envisions this coming together to form an ecosystem to make decentralized identity services a reality.

Ping Identity

Denver-based Ping Identity has been an IAM market leader for several years. Ping’s identity platform provides IAM capabilities including single sign-on (SSO), multi-factor authentication (MFA), dynamic access control and large-scale directory services with a variety of cloud deployment options including identity-as-a-service (IDaaS), containerized software and more. In October, 2020, Ping announced the acquisition of ShoCard, a company we first looked at in 2017 as the Decentralized Identity market first started to take shape. Ping refers to their ShoCard-based solution as PingOne Verify, which is a cloud-based customer identity verification service aimed at combining facial recognition technology with validation of government-issued identity documents, such as driver’s licenses and passports.

In March 2021, Ping joined the Decentralized Identity Foundation (DIF) in order to eventually bring their solution into DIF’s stated “open ecosystem for decentralized management of digital identities and ensure interoperability between all participants.” Indeed, TechVision views this as an important step toward establishing a multi-vendor, interoperable and scalable DID ecosystem. Ping is also currently working with major healthcare systems to develop a “vaccine passport” that leverage PingOne Verify.

PingOne Verify creates a digital identity card, using an application optimized for mobile phones, based on a cryptographically signed scan of the person’s identity document. PingOne Verify manages the identity documents and the keys to encrypt them in a secure enclave on the mobile device. Facial recognition of the end user (e.g., subject) is used to access the PingOne Verify app and present secure documents to requesting parties. The following figure describes the overall architecture and flow.

Figure 16: PingOne Verify Identity Sharing Flow

As illustrated above, the end user provides a live face capture using their mobile device to prove they are a real, live person. Then the end user is prompted to scan their government-issued ID. The live face capture is compared with the image on the government ID. If they match, the ID document is validated for authenticity to ensure it hasn’t been tampered with or modified.

Once validation is complete, a signed credential is created using cryptography and passed to the PingOne Verify app. Finally, all personally identifiable information (PII) that was passed to the PingOne Verify service or third-party servers is deleted. The PII data and the signed credentials are only available on the mobile app within the SDK and are maintained in encrypted form.

As mentioned previously, Ping is now becoming more active in the DIF (and W3C) communities to grow this initial use case pattern into a more holistic and interoperable DID ecosystem. With continued integration with Ping Identity’s authentication, SSO, dynamic authorization and APIs, we see an opportunity for Ping to become an eventual leader in pragmatic DID deployment and the eventual ushering in of a BYOI economy – across both Customer Identity and Access Management (CIAM) and Enterprise IAM realms.

1Kosmos

New Jersey-based 1Kosmos is a growing startup that received $15 million in Series A funding from ForgePoint in February 2021. Founded by a team with roots in Sun, Vaau, Saviynt and others, the company’s flagship solution, BlockID combines digital identity proofing with biometrics and passwordless authentication, while storing user data encrypted in a private, permissioned blockchain.

BlockID creates a decentralized identifier (DID) in compliance with the W3C guidelines. When enrolling with BlockID, the user performs a form of biometrics 1Kosmos calls a “liveness test.” This biometric identifier eliminates any risk of facial spoofing, which is the task of creating false facial verification by using a photo, video, mask or a different substitute for an authorized person’s face. The liveness test is then leveraged for authentication.

The user’s private key is stored inside the secure enclave of the user’s smartphone. The secure enclave is a secure coprocessor that includes a hardware-based key manager, which is isolated from the main processor for an added layer of security. The key data is encrypted in the secure enclave system on a chip that includes a random number generator.

1Kosmos leverages a private distributed ledger to securely store users DIDs, as well as IPFS to store linked identity data (including credentials) with access controlled by the user (GDPR compliant) as well as a layer of privacy built around Ethereum to execute smart contracts that define the rules of data exchange between agents/brokers (a proprietary analog of DIDcomm). BlockID stores each user’s identity information in their own digital identity safe encrypted on the highly secure BlockID Blockchain. The immutability of a distributed ledger is leveraged to record service provider-customer interactions. The document can never be modified, leaving an auditing trail, and therefore creating trust between all parties involved.

Figure 17: 1Kosmos BlockID High-Level Overview

The company claims that the 1Kosmos BlockID cloud-first architecture “allows for deployment within an organization in 30 minutes.” By building the platform on container technology like Kubernetes, BlockID can be run entirely in-cloud, hybrid or on premise. Note the hybrid model allows for interaction with on-prem resources without any unencrypted PII or other user data being stored in the cloud.

Of note is the fact that ForgeRock has partnered with 1Kosmos to deliver its own decentralized identity platform. This is significant in that ForgeRock, like Ping and Microsoft, is one of the leading IAM vendors in the world today.

Given the company’s founding members’ heritage and recent funding, along with the solution’s scalable, standards-based and interoperable approach and enterprise IAM focus, 1Kosmos BlockID is a very good candidate for POC deployment and testing.

Conclusions/Enterprise Recommendations

TechVision believes that Decentralized Identity is at an inflection point. From a user perspective it is a fundamentally better model than most current centralized and even federated IAM solutions. The extent to which Decentralized Identity is simplified from a user experience perspective and the ecosystems grow to include greater numbers of verifiers and organizations will determine the timing. There are also challenges in terms of adopting Decentralized Identity into existing identity architectures. This requires most large organizations to rethink several assumptions that are built into the current IAM infrastructure. Some areas to consider are:

• Redefining the relationship between the identity subject and the enterprise to one between peers rather than client / server. That means connecting and maintaining relationships, issuing credentials, providing proof, etc. is performed in ways beyond the traditional web-based duplex request-response protocols (i.e., API calls). The deployment of agents, services that interact at a peer level, on both sides of the transaction are required to manage this new way of connecting.
• Refining transaction data requirements so organizations providing services to individuals can reduce their risk of data theft by collecting only the data they need. This is achieved by using credentials only as needed and not requiring additional data
• Determine how DID-based identifiers will exist and be used within current IAM environments. We need to be careful not to introduce another disparate category but look to integrate DIDs into existing IAM ecosystems. With Microsoft, Ping, IBM and other large IAM providers investing in Decentralized Identity there is a path towards bridging this future gap and it is important to consider as you move forward with your early Decentralized Identity program. The nature, functionality, and focus of the IAM system will change from managing organization-issued identifiers to interacting with self-certifying identifiers brought to the organization by people over time and enterprises will need to manage this new model.

So, how should your organization participate in this new area at the right level at this time? While some industries have been early in this process (such as banking and health care), most organizations should begin to prepare for this disruptive approach and some ideas as how to proceed may serve as guidelines for moving forward:

1. Get acquainted with the groups working on standards for attribute exchange and interoperability as these are in different states of maturity. Also, it would be prudent to examine the different vendors with the assumption that things may change as the ToIP stack matures.
2. Learn the concepts of Decentralized Identity and the implications it has established methods and assumptions imbedded in the enterprise IAM architecture.
3. Establish a sandbox environment to practice and learn the SDKs and opensource code associated with DIDs.
4. Look for a use case that benefits both the user and the enterprise as a first experiment. For instance, Bonifii’s Member Pass was conceptualized as a means to deepen the relationship between the CU member and the institution across the entire relationship lifecycle. However, the first use case implemented was a simple one, the replacement of UserID/ Password authentication. Customers benefitted by not having to remember and maintain passwords and repeat verification steps throughout a transaction, and the CU benefitted because they could reduce customer service and support costs associated with the traditional exchange and reverification of identity data.

This will not be an easy transition for most large organizations and that success will largely depend on solving the following issues:

• End-user adoption: At present, end users are trained apathetically to “put up with” multiple User IDs and Passwords. If the decentralized identity experience is not significantly more convenient, it will be hard to get them to move. New DID-based solutions need to be automatic, much easier to use, as well as offer significant, measurable improvements in protecting personal information. Many of the current vendor offerings use biometrics (live facial recognition) to establish control over the DID and to give permission for data exchange. Others use QR codes to establish the links between agents to exchange credentials. No UserID/passwords. No MFA. No challenge phrases. No reentry of identity data. The user shouldn’t know or care about the plumbing; they should just trust it works. As the enterprise rolls out capabilities it needs to keep this in mind.
• Business adoption: If a critical mass of end-users does not adopt DIDs, then it just becomes another proprietary IDP solution, not a standard. Beyond that, for businesses to adopt decentralized identity, there has to be an easily conceived benefit. Removing much of the risk of significant fines and brand damage from theft of customer/citizen/employee personal data is certainly significant benefit – if the cost of migration balances appropriately with the reduction in risk. Likewise, the cost reduction of a much leaner IAM infrastructure that does not portend to maintain and protect ‘everything about everybody’ can be a key driver to business adoption. Finally, replacing traditional credential exchange with something much easier for customers to use can reduce transactional friction and enhance the customer experience, clear differentiators in a competitive market.
• Customer Data: Businesses are not willing to share/relinquish data about customers. Customer data is often considered proprietary and an often highly monetized, competitive advantage. Those data collected in establishing identities is leveraged, exchanged, and correlated to support marketing programs, sales efforts and business initiatives. A shift to a user-centric, consent-driven model requires the business to rethink how it stores and uses identity data. For instance, efforts to depersonalize and abstract data that still allows pattern analysis, prediction, and prescription need to be the norm, not the exception.
• Embedded solutions: Enterprises spend billions each year on their IAM and security infrastructure. Rooting out and replacing the traditional systems is a challenge. Even if the decentralized identity model is embraced around the globe, it will take a few years for embedded IAM environments to be migrated. Enterprises should begin using verifiable credentials as a part of their proofing process and phase them in as they prove to be better/less risky choices over traditional sources.

We’ll close with some final thoughts about vendor selection and how TechVision can further support our clients in this area. First, the decentralized identity space is moving at Internet speed and updated vendor information is always available from TechVision for our clients via dialogues/inquires. We developed the vendor short-list summary in this report to provide a summary assessment of the vendors as a starting point, but we have deep information and additional perspectives on virtually every vendor in this space. TechVision is also available for more detailed consulting including education seminars/workshops, development of RFIs/RFPs, supporting the collection of cross-functional requirements and to support the development of your decentralized identity strategy and reference architecture. Our team has done over 1,000 enterprise consulting engagements in the IAM space and we are happy to further support our clients in all areas related to decentralized identity, new security models and IAM in general. [8]

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

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 (IAM), Decentralized Identity, 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.

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 Zimmerman is an experienced executive known for helping companies deliver new offers and expand markets. Accomplishments include launching four companies, 20+ products, building high-performance organizations, and generating millions in sales.

His experience at Neustar, Respect Network, and Sovrin allows him to provide a broad perspective on a variety of subjects including self-sovereign identity, blockchain, enterprise data management, and the data brokerage industry.  His experience both enterprise and startup product development give him a unique perspective on innovation.

Phillip J. Windley, Ph.D. is a Principal Engineer at Brigham Young University. Dr. Windley is a frequent author and speaker on the digital identity, decentralization, blockchains and ledgers, microservice architectures, domain driven design, internet of things, and event-driven systems. He is the co-founder and organizer of the Internet Identity Workshop. Dr. Windley is the author of the books The Live Web published by Course Technology in 2011 and Digital Identitypublished by O’Reilly Media in 2005. Dr. Windley is also an Adjunct Professor of Computer Science at Brigham Young University.

[1] 2018 Cost of Data Breach Study: Impact of Business Continuity Management – Ponemon Institute

[2] Bad Data Costs the U.S. $3 Trillion Per Year – (2018) Harvard Business Review

 

[3] An agent is an addressable network service that serves as a persistent P2P messaging endpoint, coordinates messages and state across multiple clients/edge devices (smartphones, laptops, cars, etc.), maintains an encrypted Key Management backup to simplify key recovery, and simplifies and automates the process of encrypting, storing and sharing data.

[4] Note: There are two different proof flows to the verifier. The main proof flow from holder to verifier is used to establish trust.  The secondary flow between verifier and issuer is used to check status of a credential (i.e. has it been revoked)

[5] A DID Method is a specification that defines how the DID is implemented in a particular DLT network (i.e. Sovrin, Ethereum, Blockchain, etc.)

[6] Bonifii’s MemberPass is the first Evernym technology-based solution and is in production within several Credit Unions participating in the network.

[7] IATA’s Travel Pass is in trial with several airlines for use as a certification of COVID testing and vaccination status for international travel. The trial is scheduled to run through the summer.

[8] Disclosure: Gary Rowe was previously CEO/Chairman of Respect Network, which merged with Evernym and he still has minority equity interest in Evernym. Gary Zimmerman, former CMO of Respect Network also has a minority interest in Evernym.