Published 05 December 2019

Abstract

On the Internet, “nobody knows you are a dog”. There was and is a fundamental trust problem on the Internet. Enterprises spend trillions of dollars every year trying to properly allocate and remediate business risk based on trusting 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.

Traditional trust models based on the assumption that “the possession and presentation of credentials equals entitlement” are no longer sufficient, and in 2016 we began to see a new Trust over IP (ToIP) model emerge; one based on Decentralized Identity and verifiable credentials. As we began this update to our research on this topic, we wanted to answer 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?

Based on TechVision’s previous research (Blockchain Identity – 2016, Identity is the New Perimeter – 2017), interviews with key players, the progress we have seen in standards, consortiums and enterprise investments, and most recently face-to-face discussions at our 2019 TechVision Chrysalis conference, we believe Decentralized Identity shows promise as a way provide scalable, peer-to-peer trust across the Internet. On this basis, we recommended that enterprises:

• First get acquainted with the groups working on standards and ecosystems for attribute exchange and interoperability. Also, begin to investigate the early vendor offerings understanding that there will be a lot of volatility.
• Begin mapping you Enterprise IAM architecture and into a capabilities-based framework, such and the TechVision Reference Architecture, and iterate based on requirements, business needs,  technology assumptions
  that will change as decentralized identity is added to the mix.
• “Get you feet wet”; education, pilots, POCs…this is a potential game-changer and enterprises should be well prepared for this new trust model.

Authors:

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

Doug Simmons 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. These “old school” IAM systems are limiting the ability of enterprises to embrace digital transformation and become a modern digital enterprise.

This report describes a Decentralized Identity (AKA, 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 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.

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 identifier that the credential was issued to, the credential hasn’t been tampered with, and it hasn’t been revoked. This establishes technical trust.
• Who issued the credential, what authority do they have to issue it, and what criteria were used to create the credential? This establishes human trust.

While this disruptive approach is still several 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.

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 to allow the owner (technically the controller) of the identifier to gather and maintain attributes – called credentials, associated with their identity. The goal is for specific credentials to be exchanged and verified as required in real-time within the context of the relationship and the transaction being executed. The credential exchange is driven by access policies based on entitlements, the sensitivity of the data, behavior patterns, 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 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 open source 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” and 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 mess we have today. The challenges aren’t related to just a lack of individual empowerment.

Our current IAM ecosystem is enterprise focused meaning that it is viewed as a one-way means for untrusted end-users to prove their “worthiness” in order to access enterprise resources, products and services. This enterprise-focused model is repeated within practically every organization. This fact forces individuals to acquire identities from every enterprise/service provider they interact with, and remember IDs/Passwords, answer security questions, set up MFA across hundreds of sites and applications.

The rub is that the end-user wants a consistent user experience. That does not mean that all end-users have the same user experience, but that a specific end-user wants to use the same identity “agent” over and over for each identity transaction with the enterprises and services he/she interacts with, similar to the interfaces we all see for saving and printing files regardless of the application.

Currently each enterprise (or service provider) provides its own user interface 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, every day access (i.e., web-based business applications and mobile apps). This enterprise 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 trumps compliance.

Unfortunately, the bad guys 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 and, as a result, opening up opportunities for compromises at an accelerating level. Breaches and phishing schemes aren’t just focused on the targeted enterprise victim, they are focused on using the stolen IDs to leverage access to every other enterprise/service provider that has a relationship with the end-user.

To better visualize the challenge we face on the Internet today, let’s think about something we all can relate to; 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. Then imagine the store 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 lack of trust.

While the above situation sounds crazy, this is basically what happens in many on-line interactions. 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 a 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.

As Dan Gisolfi, the CTO at IBM described in our 2019 Chrysalis conference panel on Decentralized Identity, 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. Dan described it as “Trust over IP Technology Stack” consisting of two layers 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 in Hyperledger Aries.

Figure 1 Trust Over IP Stack

It is important to understand that we are using the Trust over IP Stack as an example of a layered architecture and approach to building a Decentralized Identity ecosystem and governance model.  There are other approaches and there will be many additional models emerging over the next few years, but these basic layered architectural elements we believe will be a pattern repeated in most models.

Layer One: Decentralized Identifier (DID) Networks

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 required a new type of globally unique identifier called a Decentralized Identifier (DID). DIDs are designed to provide four core properties:

• 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.
• 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.
• Cryptographic verifiability. The cryptographic material in a DID document enables a DID subject to prove cryptographic control of a DID.
• 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.

DID Methods

DID methods are the mechanism by which a DID and its associated DID document are created, read, updated, and deactivated on a specific DID network. Each DID method is defined by its own specification that must include:

• The DID method name.
• The syntax of the DID method-specific string.
• The CRUD (Create, Read, Update, Delete) operations for DIDs and DID documents that conform to the specification.

The target system (called a DID registry) is the environment on which the DID method operates. Note that this is not limited to blockchains or distributed ledgers. DID methods can be designed for distributed databases, file systems, or other system that can serve as a cryptographic root of trust.

DIDs have already proved to be a popular solution to decentralized PKI (public key infrastructure). Over 33 DID methods have already been registered in the informal DID Method Registry hosted by the W3C Credentials Community Group. They include methods for:

• Permissionless blockchains such as Bitcoin (three methods), Ethereum (six methods), Veres One, IOTA, RChain, Ontology, etc.
• Permissioned ledgers such as the Sovrin ledger.
• Distributed file systems such as IPFS.
• Ledgerless Peer-to-peer networks such as git, JLINC, and peer DIDs.

Layer Two: DIDComm

The second layer of the Trust over IP stack is defined by the DIDComm secure messaging standards. This family of Aries specifications establish a cryptographic means by which any two software agents (peers) can securely communicate either directly edge-to-edge or via intermediate cloud agents.

Peer DIDs and DID-to-DID Connections

A fundamental feature of DIDComm is that by default all DID-to-DID connections are established and secured using pairwise pseudonymous peer DIDs as defined in the Peer DID Method Specification. These DIDs are based on key pairs generated and stored by the local cryptographic key management system (KMS, aka “wallet”) maintained by each agent[3]. Agents then 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.

Because all of the components of peer DIDs and DID-to-DID connections are created, stored, and managed at Layer Two, there is no need for them to be registered in a Layer One 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, every agent is paired with a digital wallet—or more accurately a KMS (key management service). This KMS can be anything from a very simple static file on an embedded device to a highly sophisticated enterprise-grade key management server. Regardless of the complexity, the job of the KMS is to safeguard sensitive data: key pairs, zero-knowledge proof blinded secrets, verifiable credentials, and the other cryptographic material needed to establish and maintain technical trust. These agents and wallets can also be paired with a hub.

Hubs

Agents may also be paired with a digital hub (something like DropBox, iCloud, or Google drive) – a data store with three special properties:

• It is controlled exclusively by the DID subject (person, organization, or thing) and not by any intermediary or third party.
• All the data is encrypted with private keys in the subject’s KMS.
• If a DID subject has more than one hub, they can be automatically synchronized according to the owner’s preferences.

Work on standardizing digital hubs is proceeding. Next we’ll look at a key to supporting trust at scale via Decentralized PKI (DPKI).

DPKI

Encryption, hashing, and digital signatures form the basis of technical trust and these capabilities rely on digital certificates and the established standards for public key infrastructure (PKI). However, the ToIP design eliminates dependence on centralized registries for identifiers as well as centralized certificate authorities for key management – the standard pattern in hierarchical PKI. In cases where the DID registry is a Distributed Ledger each entity may serve as its own root authority – an architecture referred to as Decentralized PKI.

In decentralized PKI, blockchain acts as a decentralized key-value storage. It is capable of securing the data being exchanged to prevent Man-in-the-Middle (MITM) attacks, and to minimize the power of third parties. By bringing the power of blockchain technology to the systems, DPKI resolves the security and control issues associated with traditional PKI systems.

The decentralized nature of the management framework can tackle the problems with the CA systems through certificate revocation, eliminating single points of failure, and reacting fast to misuses of CAs. Blockchain is able to make the process transparent, immutable, and prevent attackers from breaking in, thus effectively avoiding the MITM attacks.

DPKI ensures no third party can compromise the integrity and security of the system as a whole. In blockchain-powered DPKI, the new third parties become miners or validators. The trust is established and maintained based on consensus protocols. Third parties, miners or validators, will have to follow the rules of the protocol, which would limit their roles, and financially reward or punish these third parties to effectively prevent misbehavior in the blockchain.

Layer Three: Verifiable Credential Exchange

Layer One and Layer Two together enable the establishment of cryptographic trust (also called technical trust) between peers. By contrast, the purpose of Layers Three and Four is to establish human trust between peers—trust between real-world individuals and organizations and the things with which they interact (e.g., devices, sensors, appliances, vehicles, buildings, cities, etc.).

The Verifiable Credentials Data Model

Layer Three is currently the most advanced in terms of open standards. After several years of incubation within the W3C Credentials Community Group, the W3C Verifiable Claims Working Group (VCWG) was formed in 2017 and produced the Verifiable Credentials Data Model 1.0, which is currently a W3C Proposed Recommendation. Figure 2 is a diagram of the three core roles in verifiable credential exchange— often called the “trust triangle” as defined by the VCWG.

Figure 2 – the Verifiable Credentials Model

With fully interoperable verifiable credentials, any issuer may issue any set of credentials (or claims) 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.

Layer Four: Governance Frameworks

The top half of Figure 3 below shows the basic trust triangle architecture used by verifiable credentials. 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 3 Trust triangles

Governance Authorities

What the governance trust triangle represents is 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. They are developed, published, and enforced by many different types of governance authorities – private companies, industry consortia, financial networks, and of course governments. The same model can be applied to verifiable credentials simply by having those same governance authorities – or new ones formed explicitly to govern verifiable credentials – publish digital governance frameworks.

The basic principle of ToIP is that end users prove they control their identifier(s) and can present attributes that can be independently verified by the relying party and are provably linked to the identifier they control. Decentralized Identity is an extension of the concept of user centric identity that has been churning around over the past several years.

The Promise of Decentralized Identity

As Bob Blakley from Citigroup is fond of saying, “Authentication should be invisible to the account holder and extremely difficult, expensive, and confusing for the bad guy.” The ToIP goals of achieving both technical trust and human trust on the web moves us towards that goal.

For example, when ToIP is fully implemented and supported by a connected ecoystem you can expect to:

• Reduce your organization’s security and compliance remediation costs caused by identity-based fraud by dealing directly with the entity that controls the identity and the certifier of the attributes presented. Includes the reduced threat of data breach through dramatically lessening the need for data collection and storage.
• Address the escalating data accuracy challenges by collecting up-to-date verified details on a permissioned basis improving data quality for downstream operations, analytics, and AI/ML applications.
• Reduce attack surfaces through one-to-one peer connections rather than the many to many and/or proprietary IDP relationships presented today. Compromising one account does not allow access to others.
• Reduce support costs through true password-less access. No two factor, no auto-reset procedures, no call center support, no proprietary hardware fobs, just encrypted data exchange between peers.
• Reduce compliance costs (blockchain + DID document PKI enforcement + logs = compliance proofs) and the right to be forgotten is as easy as a PKI pair revocation.
• And ultimately, achieve one on one marketing goals through peer DID documents and trusted connections and rich datasets built over time between persistent identities.

But moving from where we are today to “fully implemented” is no easy task. That’s why we outline a set of recommendations later in this report to help you prepare for and deliver the promise of Decentralized Identity.

Decentralized Identity in the Physical World

The benefits of Decentralized Identity transcend the use-cases of the internet. Imagine how it would be to buy alcohol in a physical store with this system in place:

• You go into a liquor store while carrying your mobile device linked to your identity agent, containing your DID and Verifiable Credentials you have been collecting from issuers.
• After choosing a bottle of your favorite red wine, you go to the cashier in order to pay.
• You establish a secure communication channel between your agent and theirs, by using NFC, scanning a QR Code or any similar mechanism. The cashier’s agent initiates a handshake ceremony, asking you to disclose your DID and prove control over it via a cryptographic challenge. You respond to the challenge using a biometric (facial recognition or fingerprint) to activate your agent which responds to the challenge and establishes the Peer DID relationship.
• Using that same channel, the cashier’s agent then prompts for a credential, which could be a zero-knowledge proof residing on the blockchain, or a credential issued by the government’s DID, stating you are 21 or older.
• After your agent sends it, the cashier’s agent checks if the credential is authentic, by verifying that the cryptographic signature matches a public key listed in the government’s DID Document.
• If the signature is indeed valid, the cashier’s agent allows the purchase. Finally, your agent uses the same connection to pay for the wine using your bank’s credentials and proofs.

There was 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 to 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 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 being 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 organizations have faced by being locked into proprietary IAM solutions in the past. There are also products and services offered by most of the identity providers that bridge disparate environments, federate identities and provides 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 for virtually anyone to see. Pictures are on passports and ID cards, along with home or work addresses to validate 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. With computing power and software moving to the cloud, coupled with virtualization services, employees and consumers now have unprecedented flexibility.  And the need for a flexible and adaptive suite of IAM capabilities will accelerate as enterprises move more aggressively towards DevOps, microservices, cloud computing and movement towards the digital enterprise.

And it isn’t just flexibility enterprises and individuals seek; they also seek to protect their personal information currently under the control of someone other than the real owner.  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 great example of fixed, single purpose identities that include extraneous information can be found with standard credit cards. 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 with credit cards. 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 identity fraud. Another example is proving age using a driver’s license or passport; this includes extraneous data that isn’t relevant to the proof of age.

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 minimal disclosure of 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, providing a trusted, cryptographically verifiable credential (flexible) that you are 21 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 will be 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. 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 early 2020.

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 focus on 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. 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 most early Blockchain 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 1, below, identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. While this is the same definition we apply to people identity-oriented use cases, there are specific challenges as we’ve discussed in managing things and the relationships they support. This high-level template starts the journey.

Figure 4: Decentralized Identity 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 comes 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 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 5, 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 5: 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 self-sovereign 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 a subsequent, companion to this document, we will provide a DID-integrated IAM Reference Architecture drill-down.

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:

• Decentralized Identity Foundation (DIF)
• HyperLedger Indy, Aries
• Sovrin Foundation
• W3C

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.

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.

HyperLedger Indy/Aries

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 solutions 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 open source specifications, terminology, and design patterns that allow for the development of decentralized identity solutions. 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.

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 Sovrin 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 open source community for the coding

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

Figure 6: Sovrin Structure

The Sovrin Foundation is a non-profit organization supported by a Board of Trustees representing identity owners globally. 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.

W3C

The World Wide Web Consortium (W3C) formed a verifiable claims working group in April of 2017. They define their charter as “It is currently difficult to express banking account information, education qualifications, healthcare data, and other sorts of machine-readable personal information that has been verified by a 3rd party on the Web. These sorts of data are often referred to as verifiable claims. The stated mission of the Verifiable Claims Working Group is to make expressing, exchanging, and verifying claims easier and more secure on the Web. This charter focuses on use cases for education.

The W3C effort is important in that it mitigate some risk and move additional vendors towards (along with the DIF, Sovrin and Hyperledger) developing products and services in the Decentralized Identity arena.

We’ll next look at a few of the early vendors participating in the Decentralized Identity area. 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/Sovrin, IBM/SecureID, Microsoft, ShoCard and uPort 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

Civic is a personal identity verification tool that leverages distributed ledger technology to support the management of digital identities. TechVision interviewed J.P. Bedoy, the VP of Product Management and Design at Civic and he described their mission as “enabling people to take back control of their personal data”.  Civic was founded by South African Shark Tank investor and Internet entrepreneur, Vinny Lingham.

Civic 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.  The following figure shows how can be used instead of filling out the typical personal information once an enterprise decides to accept these credentials:

Figure 7: Civic User Experience

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 (at requisite surety levels) support.

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 and the CULedger (supporting a consortium of Credit Unions). Evernym is the original creator of Sovrin and a primary contributor of Hyperledger Indy.

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 8: Verity Dashboard

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

Figure 9: 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 open source initiatives.

Dan Gisolfi, IBM’s CTO for Trusted Identity participated in TechVision’s Chrysalis Conference in November 2019 and also provided some insight after the conference as to how and why IBM is participating in the Decentralized Identity “movement”. They characterize their involvement as in the spirit of “Open by Design” and that they are grounded in the standards initiatives. IBM, as a founding steward for the Sovrin Foundation subscribes to both Privacy by Design and the 10 core principles defined of Self-Sovereign Identity as described below:

Figure 10: Self-Sovereign Design Principles

One of the more visible initiatives that IBM announced back in March 2017 was their partnering with SecureKey Technologies to build a digital identity network in Canada with banks such as Bank of Montreal, Canadian Imperial Bank of Commerce, Desjardins Group, Royal Bank of Canada, Scotiabank and TD Bank.  Adam Gunther explained to TechVision in early 2019 that IBM’s design includes both advanced federated identity technology and blockchain technology specifically designed for regulated industries. The collaborative effort with SecureKey and IBM focused on developing a digital identity and attribute-sharing network using IBM’s BaaS built on top of the Linux Foundation’s open source Hyperledger Fabric.

IBM is also driving a program to support verifiable claims with Sovrin, Workday, the Canadian government and their employees. The technology and workflows are described in the following figure published by IBM.

Figure 11: Canadian Government Decentralized Identity Pilot

While IBM continues to make investments in this space and is actively working with their clients to support pilots and experimentation, it is a bit less clear what their actual go-to-market strategy is. This may be OK, given the nascent nature of Decentralized Identity, but this is an area we’ll follow-up on over the next few years to assess IBMs actual service offerings in this area.

Microsoft

For the past few years Microsoft has been incubating a blockchain/distributed ledger-based decentralized identity management program. TechVision recently interviewed Ankur Patel, the Principal Program Manager for Identity at Microsoft to gain insights into Microsoft’s efforts and plans in the decentralized, self-sovereign identity space. Ankur also participated in the TechVision Chrysalis conference panel on Decentralized Identity in November 2019.

It is clear based on this briefing, the panel discussion and in many other interactions and observations that TechVision’s team has made, 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, described, in their white paper entitled “Microsoft’s strategy for Decentralized Identity”, this ambitious undertaking as needing to “augment existing cloud identity systems with one that individuals, organizations and devices can own so they can control their digital identity and data”.  This self-owned identity must seamlessly integrate into our daily lives, providing complete control over what we share and with whom we share it, and—when necessary—provide the ability to take it back”. Dissecting this strategy and the comments made in the interview, Microsoft is focused on supporting a self-owned and controlled identity, extending this to data sharing and supporting the right to be forgotten in GDPR.

On 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 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 been building core blockchain technology and leveraging collaboration between Microsoft Azure and Consensys Ethereum. Ethereum on Azure is supporting partner applications in areas such as electronic voting, employee compensation programs, smart contracts enabled and supply chain management, but we’ll focus this review on their programs in the support of identity management.

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.

As Ankur described Microsoft’s approach, he explained that they started with a set of core design principles which we’ll expand upon. We’ll also give you TechVision’s take on Microsoft’s Decentralized Identity program/strategy and put in an enterprise context as follows:

Microsoft Design Principle	Additional Details/Analysis/Rationale
User can have one or more DIDs	The DIDs can represent “persona’s and be used/linked via pair-wise identifiers, zero knowledge proofs and pseudo-anonymous identifiers.
DIDs can be resolved across chains	Microsoft describes this as “chain agnostic” since they are a platform and don’t want to limit supported environments and Microsoft vies and uses blockchain as a “discovery service”.
DID permissions managed via keys	Keys are only accessible to user (can be user, organization, device). Microsoft says “there should be a DID for everything” and TechVision agrees with this.
Identity attributes stored off-chain	This is key for privacy, GDPR compliance and is consistent with Microsoft’s keeping PII off-chain/
Users can have 1 or more identity hubs	These can be stored locally, on a Microsoft cloud or another cloud.
User consent required to access claims	Microsoft explained that they are looking to simplify this and make the access and consent much more granular (to the data, version, schema and time-stamp level per Microsoft).
Claims are compatible with existing standards	Goal is (per Microsoft) to get standards agreements and they are approaching this via consortiums and community contributions initially. Leveraging and participating in DIF.

Table 1: Microsoft Decentralized Identity Design Elements

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.

Figure 12: Microsoft Decentralized Identity Flow

Ankur described the above summary model and Microsoft’s early focus as starting with the user experience; he explained that the user agent is key for engagement and is an application that is so critical Microsoft building it themselves. Another key element is what they refer to as the identity hub.

A key element of this (or any) digital collection mechanism is addressing the “discovery” problem. These efforts generally begin with the premise that discovery is about individual entities providing a mapping of their own service-specific API and data schemas. While you can certainly create a common format for expressing different APIs and data schemas, you are left with the same basic issue: a sea of services that can’t efficiently interoperate without specific review, effort, and integration. Hubs avoid this issue entirely by recognizing that the problem with data discovery is that it relies on discovery. Instead, Hubs assert the position that locating and retrieving data should be an implicitly knowable process.

Collections provide an interface for accessing data objects across all Hubs, regardless of their implementation. This interface exerts almost no opinion on what data schemas entities use. To do this, the Hub Collection interface allows objects from any schema to be stored, indexed, and accessed in a unified manner.

ShoCard

ShoCard creates a digital identity card, using an application optimized for mobile phones, based on a cryptographically signed scan of the person’s identity document. ShoCard is a digital identity service with stated goals to protect end user privacy and is meant to be as easy to understand and use as showing one’s driver’s license. ShoCard encrypts and hashes the identity data and stores the hash (not the PII which is typical of most vendors) on Bitcoin’s blockchain using an application that operates on top of the distributed database infrastructure. The information can be retrieved through the ShoCard application for businesses and web-based services are available to verify an identity by users sharing their public key. TechVision has the opportunity to interview ShoCard’s CEO/Founder Armin Ebrahimi and he summarized their goal as “providing digital IDs for the mobile world”.

The following figure describes the overall ShoCard architecture and flow.

Figure 13; ShoCard Identity Sharing Flow

Conclusions/Enterprise Recommendations

For decentralized identity to take root, both enterprise organizations and third-party identity providers need to view identity and relationship identifiers as two distinct constructs. People-based core identity can be decentralized and drive relationship identifiers for different organizations. However, each organization has to still manage its own corresponding relationship identifier for each person to address other identity governance and access management requirements.

So what should you be focusing on as you build out your decentralized identity program?

First 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.

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. Think about how Apple provides key management and end-to-end encryption. The user doesn’t know or care about the plumbing. They just know it works. ToIP needs to work in a similar manner.
• 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.
• 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. [4]

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.

[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] 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.