Skip to main content
Table of Contents
< All Topics
Print

Developing a Decentralized Identity Reference Architecture

Initial Publication Date: 08 March 2024

Abstract

Centralized Identity and Access Management (IAM) systems and services have been the foundation for digital identity over the past 40 years. Centralized IAM is attractive to enterprises and service providers since they maintain control of the identity, but with increasing user demands, privacy requirements, scalability challenges and new use cases, Decentralized Identity (originally called User Centric Identity) is emerging as a viable option that enterprises should at least be evaluating.

This report outlines a Decentralized Identity Reference Architecture to guide enterprises seeking to enable user control, ensure privacy, leverage cryptography for security, and build trusted ecosystems using open standards. The architecture aims to define the capabilities necessary to deliver resilient, portable digital identities without passwords, provide flexible access management, reduced risk, and enable regulatory compliance. This builds on TechVision’s Reference Architecture approaches for Enterprise IAM, Customer IAM (CIAM), PAM, Security, IGA and several other related capabilities-based reference architectures.

Recommended near-term steps for enterprise adoption include running decentralized identifier (DID) method pilots, cataloging identity attributes for credentials, designating internal trusted issuers, evaluating identity wallets, updating applications for DID support, implementing selective disclosure, co-building proofs-of-value, and contributing to standards maturation. This measured approach allows incremental decentralization while minimizing user disruption during ecosystem maturation towards broader readiness.

Authors:

Gary Zimmerman

Principal Consulting Analyst

[email protected]

 

Executive Summary

Before blockchain and user centric approaches to identity management, digital identities were (and continue to be) largely managed by centralized entities (global platforms, enterprises, etc.). Individuals, organizations, or things (Subjects) have little control over their personal data, leading to privacy concerns and risks of data breaches. These concerns are persistent despite decades of investment in digital identity, cybersecurity, and privacy capabilities. This is partly based on the reality that the largest technology vendors, governments and enterprises want to maintain control of user data and often view this data as proprietary. User centric identity has the potential of leveling the playing field.

A 2022 international survey reveals that Internet users’ trust in the Internet has dropped significantly since 2019. That is among the key findings of a 20-country Ipsos survey[1] released by The NEW INSTITUTE in Hamburg, Germany.

Only six in ten (63%) Internet users on average across the 20 countries said they trust the Internet. That perception is even worse in the US where only half (54%) of the users trust it.

Respondents indicated that the most effective policies to improve trust in the Internet should include:

  • Protection of user privacy (65%).
  • Protection of users’ personal data (65%).
  • The establishment of standards detailing how Internet companies collect and make use of user data (62%).
  • The establishment of policies allowing users to control their own data (62%).

Clearly today’s approaches are not delivering on trust in the minds of consumers and citizens.

The advent of blockchain technology, with Bitcoin in 2009, laid the groundwork for decentralized identity. Blockchain’s core features of decentralization, security, and immutability presented a novel way to manage digital identities without central authorities. While blockchain is not necessarily the foundation for all of the decentralized identity offerings (like Microsoft’s for example), it has accelerated the opportunity for viable decentralized approaches to IAM and a platform for verifiable credentials (VCs).

Decentralized identity represents a shift from traditional, centralized models of identity management towards user-centric and blockchain-based approaches. This concept aims to empower individuals with control over their own identity, data, and credentials, rather than relying on centralized authorities to manage and control personal identity information.

This Decentralized Identity Reference Architecture was developed to guide enterprises that are looking to enable user control over digital identities without depending on centralized authorities, ensure privacy by minimizing personal data disclosure, leverage cryptography for security, and build trusted ecosystems with open standards.

The goals are to provide frictionless authentication without passwords, selective data sharing that minimizes exposure, interoperability across domains, and regulatory compliance.

If correctly implemented, the architecture will facilitate Subject-owned credentials, resilience to outages, identity portability, flexible access management, and reduced risk exposure by strengthening consent, auditability, credential integrity, and avoiding vendor lock-in. Overall, the principles and goals focus on decentralization, ownership, privacy, resilience, and enterprise integration.

Near Term Steps

While many enterprises have been experimenting with the technologies of Blockchain and Web3 to manage document exchange and asset management, adoption of decentralized identity is limited. As outlined in our Digital Identity Wallet report by David Goodman, momentum is building, especially in Europe. Here are some practical, near-term steps enterprises can take within a decentralization roadmap:

  • Run DID method pilots: Evaluate different DID methods by issuing ephemeral test credentials to a small group of employees and partners. Measure ease of integration, key management overhead etc.
  • Inventory attributes: Catalog all internal and external identity attributes, credentials, and databases. Prioritize use cases to transition to verifiable credentials.
  • Certify issuers: Designate trusted issuers within the organization that can start asserting verifiable claims internally about employees, customers etc. in a GDPR-compliant fashion.
  • Explore enterprise wallets: Evaluate suppliers such as Spherity, Affinidi, 1Kosmos, Thales, PingOne Neo, and others to verify they can support the necessary capabilities.
  • Update applications: Modify login, profile and consent flows within websites and apps to display and interact with DID-based decentralized identity records where available. Gracefully fallback for non-DID users.
  • Try selective disclosure: Implement zero-knowledge proofs or selective disclosure for localized use cases to preserve privacy. For example, allowing age verification without sharing exact birth date.
  • Co-build prototypes: Jointly develop proof-of-value prototypes with ecosystem partners leveraging aligned decentralized identity standards to solve real business problems like paperless trade finance.
  • Contribute to open standards: Actively participate in maturation of decentralized identity standards at W3C and other bodies based on implementation experience. Help build critical mass.
  • Begin to investigate how decentralized identity services can be integrated with and fit within the context of the full range of IAM systems and services you have within your enterprise.

This balanced approach allows rational incremental decentralization while insulating end-users from disruption until ecosystem readiness reaches maturity based on evidence from practical integration and deliberative partnerships.

Introduction

A brief background on decentralized identity

Decentralized identity represents a paradigm shift in the way individual identities are managed, moving away from centralized authorities (like governments or corporations) towards a model where individuals have greater control over their personal information. This approach to identity management is built on the principles of decentralization, often leveraging blockchain and distributed ledger technology (DLT) to provide a secure, transparent, and immutable foundation for identity verification and management.

It Began with The Laws of Identity

Nearly 20 years ago (2005) The blog post by Kim Cameron, titled “The Laws of Identity,” discussed the essential need for a unified identity system on the Internet, which currently lacks a native identity layer, causing security vulnerabilities and inefficiencies. Cameron outlined the dynamics causing digital identity systems to either succeed or fail and introduced the concept of an identity metasystem to provide a secure, universal identity layer. This metasystem aimed to enhance web-based services and interactions, ensuring users’ safety, privacy, and trust in their online engagements. The ideas were refined through extensive discussions across the computer industry and private communications, emphasizing collaboration and the collective effort to address digital identity challenges. [2] Kim outlined these laws:

  1. User Control and Consent: Technical identity systems must only reveal information identifying a user with the user’s consent.
  2. Minimal Disclosure for a Constrained Use: The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.
  3. Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
  4. Directed Identity: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
  5. Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
  6. Human Integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
  7. Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

Putting all the laws together, we can see that the request, selection, and proofing of identity information must be done such that the channel between the parties is safe. The user experience must also prevent ambiguity in the user’s consent and understanding of the parties involved and their proposed uses. These options need to be consistent and clear. Consistency across contexts is required for this to be done in a way that communicates unambiguously with the human system components.

Today’s Approaches

Before blockchain and the proliferation of decentralized models, digital identities were (and continue to be) largely managed by centralized entities (global platforms, enterprises, etc.). Individuals, organizations, or things (Subjects) have little control over their personal data, leading to privacy concerns and risks of data breaches. These concerns are persistent despite decades of investment in digital identity, cybersecurity, and privacy capabilities.

A 2022 international survey reveals that Internet users’ trust in the Internet has dropped significantly since 2019. That is among the key findings of a 20-country Ipsos survey[3] released by The NEW INSTITUTE in Hamburg, Germany.

Only six in ten (63%) Internet users on average across the 20 countries said they trust the Internet. That perception is even worse in the US where only half (54%) of the users trust it.

Respondents indicated that the most effective policies to improve trust in the Internet should include:

  • Protection of user privacy (65%).
  • Protection of users’ personal data (65%).
  • The establishment of standards detailing how Internet companies collect and make use of user data (62%).
  • The establishment of policies allowing users to control their own data (62%).

Clearly today’s approaches are not living the Laws of Identity.

A Different Approach

The advent of blockchain technology, with Bitcoin in 2009, laid the groundwork for decentralized identity. Blockchain’s core features of decentralization, security, and immutability presented a novel way to manage digital identities without central authorities.

Decentralized identity represents a shift from traditional, centralized models of identity management towards user-centric and blockchain-based approaches. This concept aims to empower individuals with control over their own identity, data, and credentials, rather than relying on centralized authorities to manage and control personal identity information. This approach is generally well received by individuals, privacy advocates and regulators, but faces roadblocks from large enterprises and dominant technology vendors.

Key Concepts and Technologies

Self-Sovereign Identity (SSI): At the heart of decentralized identity is the concept of SSI, where Subjects have responsibility and control over their own digital identities. This includes managing the storage, disclosure, and security of their own identity records without needing an intermediary.

Blockchain and Distributed Ledger Technology[4] (DLT): Blockchain serves as the foundational technology for many decentralized identity systems. It provides a secure, immutable ledger where identity transactions (such as the creation, verification, and revocation of identity claims) can be recorded without a central authority.

Decentralized Identifiers (DIDs): DIDs are a new type of identifier that enables verifiable, self-sovereign digital identities. DIDs are fully under the control of the DID Subject, independent from any centralized registry, identity provider, or certificate authority. They are typically used in conjunction with blockchain technology to ensure the integrity and security of identity data.

Verifiable Credentials: This concept allows for the digital equivalent of physical credentials (like a passport or business license) to be shared online in a way that is secure, private, and verifiable. Once validated by a trusted source, verifiable credentials can be issued, presented, and verified online without the need for a central verifying authority.

Cryptography: This capability plays a pivotal role in the infrastructure of decentralized identity, ensuring the security, privacy, and integrity of digital identities themselves and the exchanges between them. Extensive use of cryptography underpins the trustworthiness and functionality of decentralized identity systems, allowing for secure data storage, communication, authentication, and authorization.

Advantages

Enhanced Privacy and Security: By giving Subjects control over their identity data, decentralized identity systems reduce the risk of data breaches and identity theft associated with centralized databases.

Interoperability: Decentralized identity systems are designed to be interoperable across different organizations, jurisdictions, and applications, enabling a seamless and universal way to use digital identities across various services.

Reduced Dependency on Third Parties: Eliminating the need for intermediaries not only reduces potential security vulnerabilities but also lowers costs and streamlines processes for verifying identities.

Challenges and Considerations

While the standards and technologies have matured, the issues beyond the technology have not changed since we started covering this space five years ago. Some of these are:

Adoption and Standardization: For decentralized identity to become widely used, there needs to be widespread adoption and agreement on standards and protocols across industries and governments.

Usability: Ensuring that decentralized identity solutions are easy to use and understand by the individuals is crucial for their success. And there needs to be a compelling reason for users to change to the new model.

Regulatory Compliance: Navigating the complex identity landscape of global privacy, reciprocity, and liability regulations to ensure that decentralized identity systems comply with laws can pose significant challenges.

Decentralized identity is still an evolving field, with ongoing research and development efforts aimed at addressing these challenges and unlocking the potential of a more secure, private, and user-controlled digital identity ecosystem.

Purpose, goals, and benefits for enterprises to use a reference architecture approach

Purpose

The purpose of this proposed reference architecture is to provide a standardized blueprint for implementing decentralized identity capabilities that, in aggregate, enable Subjects to own and control their identities, while facilitating trusted and seamless transactions to access services.

Goals

  • Enable persistence and portability of digital identities across different systems and jurisdictions.
  • Improve Subject control and privacy of identity attributes and data.
  • Simplify integration between identity systems through modular open standards.
  • Ensure consistency of core identity functions and behaviors across implementations.
  • Incorporate mechanisms for Subject consent, audit trails, and regulatory alignment into all layers of the decentralized identity stack.
  • Accelerate adoption by establishing clear technical standards and models.

Benefits

  • Privacy: Selective disclosure through verifiable credentials enhances privacy and reduces unnecessary data sharing. Signatures prevent tampering of identity evidence.
  • Security: Cryptographically verifiable claims and protocols mitigate theft through decentralized infrastructure. Removes the single point of failure risk.
  • Consent: Facilitates dynamic consent where Subjects authorize data sharing across contexts through signed permissions reducing unauthorized access.
  • Portability: Vendor neutral formats and protocols enable reusability of digital credentials across different identification systems and organizations, generating cost and time savings by reducing integrations between identity systems.
  • Persistence: Allows the Subject to maintain and use identity data and credentials across all digital relationships without identity provider lock-in.
  • Responsiveness: Supports flexibility to add innovative services on a standard identity backbone.

This proposed decentralized identity reference architecture aims to set consistent guidelines for the use of this emerging technology within the enterprise as it preserves privacy, increases user control, and reduces risk. It focuses on driving these benefits through open standards that can integrate both centralized and decentralized systems in an interoperable manner.

Differences from Centralized and Federated Models

Unlike centralized models where single providers control Subjects’ digital identities, and federated models that rely on centralized identity hubs for federated login, decentralized identity removes such consolidation of control and trust assumptions. Control rests with sovereign individuals rather than external authorities.

  • Unlike centralized models, decentralized identity eliminates single point of failure by distributing identity data storage and removal of centralized brokers.
  • Provides users more direct control compared to federated identity models where identity providers manage user identities.
  • Does not require intermediary identity providers to broker identity-based transactions. It allows direct peer-to-peer authentication.

By eliminating centralized points of control or federation hubs, decentralized models afford Subjects improved control over digital identities and transactions enhancing privacy, security, consent rights and interoperability.

The following table outlines the differences between the centralized, federated, and decentralized identity models.

Centralized Federated[5] Decentralized[6]
Identity provider Service provider is the identity provider. Subject creates an account at the service provider. One of the major platforms (e.g., Google, Apple, Meta, LinkedIn, the service formerly known as Twitter…). Identity providers are Subjects in cooperation with verifiable credential issuers (e.g., government, healthcare provider, etc.).
Service provider[7]

(Relying Party)

Provides the application. Also, the identity provider in this case. Provides the application. Relies on the external identity provider to authenticate user and provide claims. Provides the application. Relies on the user (through their wallet) to authenticate and provide claims (from VCs issued by trusted sources).
Authentication Subject authenticates to service provider with username/password or MFA. Subject authenticates to identity provider with username/password or MFA. Service provider receives an authentication token from identity provider (e.g., SAML, OpenID Connect). Subject can authenticate to both the identity providers and service providers using public key cryptography based on cryptographic keys, verifiable claims, and DIDs in the wallet.
Subject PII Subject provides their PII to service provider –typically, email, mobile phone number, credit card, name, birthdate … Subject provides their PII to identity provider – typically, email, mobile phone number, credit card, name, birthdate … Service provider will request PII data from identity provider. Subject approves release of PII to service provider during VCs proof presentation protocol.
Claims (information about the Subject) Service requests Subject supply PII directly. Service provider requests PII data from identity provider. Service provider receives token with claims from identity provider (e.g., SAML, OpenID Connect). Claims about the Subject are held in VCs in their wallet. Subject is in control of the release of the PII to service provider during presentation protocol.
Policy Set by service provider. Can be based on role, group, or user attributes. Used for employees and customers. Set by service provider. Can be based on role, group, or user attributes. Used mostly for customers. Set by service provider. Attribute-based access control is the dominant access control model. Could be used for employees and customers.
Trust Service provider only. No external trust required. Service provider trusts the identity provider. Identity provider provides signed tokens to the service provider. In some cases, the identity provider issues tokens directly to the Subject who then can decide whether to present them to the service provider. Service provider trusts the Subject’s DID. Issuers create VCs for the Subject. Service provider can verify the VC without needing to contact the issuer (by checking Issuer DID, schema and credential definition stored on ledger).

Table 1 – The differences between identity models

Proposed Reference Architecture for Decentralized Identity

A reference architecture is a standardized architectural framework that provides a template or blueprint for designing systems within a particular domain, technology, or industry. It outlines the key components, their relationships, and the functional requirements necessary to support the system’s objectives. Reference architectures are developed to guide and align the design and implementation of systems that share similar requirements, constraints, and goals.

 Importance of a Reference Architecture

A reference architecture:

  • Accelerates Development: Provides a proven framework that accelerates the design and development process by reducing the need to create a system architecture from scratch.
  • Ensures Consistency and Interoperability: Ensures that systems developed within the same domain or industry are consistent, making them more easily interoperable and able to share data or services.
  • Risk Reduction: By leveraging established best practices and patterns, it reduces the risk of architectural flaws that could lead to security vulnerabilities, performance issues, or scalability limitations.
  • Facilitates Communication: Serves as a communication tool among stakeholders, including architects, developers, business analysts, and clients, by providing a common language and understanding of the system.
  • Adaptability and Evolution: Although it provides a standard framework, a reference architecture is designed to be adaptable, allowing for evolution as technologies advance and business needs change.

In summary, a reference architecture acts as a blueprint for system design, offering a mix of flexibility and standardization that supports the development of robust, secure, and efficient systems across various domains and technologies.

Design Principles

Here are the design principles this reference architecture was developed to support.

  • Subject control: Enable Subjects to own and control their digital identities without central authorities.
  • Privacy by design: Architect for minimal disclosure of personal data.
  • Security through cryptography: Leverage verifiable claims, zero-knowledge proofs (ZKPs), and mutual authentication.
  • Trusted ecosystems: Establish governance for decentralized components to ensure reliability and interoperability.
  • Standards-based: Adhere to leading standards from W3C, DIF, ISO and other bodies around key components (keys, IDs, claims, proofs) and more.
  • Legacy integration: Bridge new decentralized paradigms with existing IAM systems.

Goals

If the technological underpinnings of the architecture are implemented correctly the following goals will be met:

  • Subject-managed credentials: Subjects control professional credentials on personal devices.
  • Frictionless authentication: Eliminate passwords and repetitive multi-factor authentication cycles with cryptographic authentication and dynamic/contextual sharing of verifiable credentials.
  • Selective attribute disclosure: Fine-grained data sharing minimizing exposure.
  • BYOID (Bring your own ID): Subjects use their own self-sovereign DIDs for identity verification and credential sharing.
  • Regulatory compliance: Meet privacy regulations around consent, data minimization.
  • Resilience against outages: Identifiers persist without centralized points of failure.
  • Interoperability across networks: Achieve seamless identity portability between domains.
  • Access management flexibility: Support authentication from any device to any application.
  • Reduced risk exposure: Minimize data exposure, strengthen credential integrity, enhance consent & auditability, and avoid vendor lock-in through the adoption of DID standards.

The principles and goals of the architecture focus on decentralization, ownership, privacy, and resilience while still integrating with legacy enterprise infrastructure.

Figure 1 – The roles and information flows forming the basis for the W3C Verifiable Credentials Model.

Anyone that has studied decentralized identity is familiar with the above diagram. However, turning this into a workable solution is not so simple. As an enterprise begins its use of decentralized identity, it will initially focus on the role of Verifier. However, as it scales and matures its use cases, enterprises are most likely to be in all these roles over time. That raises many questions such as:

  • What capabilities are needed to issue VCs? What credentials do we want to issue?
  • How should we manage holder relationships and credentials for the corporation and employees?
  • What do we need to request and verify credentials presented to us? How do we know the presented credential and its issuer are valid?
  • Where should the decentralized identity and related registries reside? How much control do we want to exert?

This proposed reference architecture begins to address these and other questions.

Architectural components and protocols

Here is a definition of some of the key architectural components and protocols of a decentralized identity reference architecture:

  • Decentralized Identifier (DIDs): A new type of unique identifier that does not require a central authority because it is registered on distributed ledgers or blockchains. Enables self-sovereign identity.
  • DID Document: Contains metadata associated with a DID, including public keys, authentication protocols, and service endpoints. Help establish connections.
  • Verifiable Credential (VCs): Tamper-evident credentials that encode claims and are cryptographically signed by the issuer. Enable portability across contexts.
  • Zero-Knowledge Proof (ZKP): Allow selective disclosure of attributes in a verifiable credential without sharing the underlying data. Enhances privacy.
  • DIDComm Messaging: A protocol for establishing trusted peer-to-peer communications between entities through encrypting messages using DID key material.
  • Wallet/Agent: Software through which users can store Decentralized Identifiers, DID documents, verifiable credentials, sign requests, and mediate authentication.
  • Distributed Ledger: The underlying technology utilized to anchor DIDs using timestamping and records not controlled by a single centralized entity. Examples: Sovrin, Indy ledgers (Hyperledger) or blockchains (Bitcoin, Ethereum, Polkadot, etc.).
  • Identity Bridge: Interoperability layers that bridge siloed identity networks (decentralized and legacy) through mapping different identifiers and translating between standards.

Figure 2 – A Decentralized Identity Reference Architecture Template

The Identity Wallet

TechVision Research recently published an in-depth report titled “Digital Identity Wallets” where we described:

  • The digital identity wallet value proposition and the opportunities and challenges for the enterprise
  • TechVision Research’s analysis of digital identity wallet providers
  • Seven steps an enterprise should take to best leverage digital identity wallets.

The Digital Identity Wallets report goes into great depth on the efforts at standardization and regulation around the connections between people and digital / physical services, especially in Europe. It is a great report to help you form your strategy around decentralized identity.

This report focuses on the capabilities that a wallet application needs to interact with the diversity decentralized identity ecosystems and legacy identity applications.

A decentralized identity wallet is a digital tool that enables individuals or organizations to securely store and manage their digital identities and related credentials. Unlike traditional wallets that hold physical items like cash and credit cards, or even digital wallets that store payment information and digital currencies, a decentralized identity wallet focuses on managing digital identity assets. These assets include Decentralized Identifiers (DIDs), verifiable credentials (VCs), and other personal data that can be used to prove identity and attributes online in a secure, private, and user-controlled manner.

This architecture doesn’t show the wallet as an entity in and of itself because various implementations can have the wallet “application” executing the underlying capabilities in a mixture of on device, in a hosted environment, online, or offline. The capabilities that underpin the wallet are covered in the Key Services and Agent Services described later in this section. Despite the complex technology underlying them, these wallets provide a human-friendly interface for managing and sharing digital identities and credentials while managing the complexity underneath the surface.

Key Services

Cryptography and key management play pivotal roles in the infrastructure of decentralized identity, ensuring the security, privacy, and integrity of digital identities. These concepts underpin the trustworthiness and functionality of decentralized identity systems, allowing for secure communication, authentication, and authorization without relying on centralized authorities.

Cryptography in Decentralized Identity

Cryptography is the practice of securing communication in the presence of third parties called adversaries. In the context of decentralized identity, it is used to:

  • Encrypt and Decrypt Data: Protecting the confidentiality of identity data as it is stored or transmitted across potentially insecure networks.
  • Sign and Verify Digital Signatures: Ensuring the authenticity and integrity of data, including identity credentials and other digital transactions. Digital signatures prove that a message or document was created by a particular entity and has not been altered.

Key Management in Decentralized Identity

Key management refers to the secure handling of cryptographic keys that are used in the encryption and decryption processes, as well as in the creation and verification of digital signatures. In decentralized identity systems, key management involves:

  • Generation, Storage, and Destruction of Keys: Securely generating, storing, and eventually safely destroying cryptographic keys. This includes both public keys (which can be shared openly) and private keys (which must be kept secret and secure).
  • Control and Access: Ensuring that only authorized individuals or entities have access to private keys and that this access is securely managed throughout the lifecycle of the identity.
  • Recovery Mechanisms: Implementing mechanisms to recover keys if they are lost or compromised, without undermining the security of the identity system.

Significance of Cryptography and Key Management

  • Subject Control and Sovereignty: By enabling Subjects to generate and control their own cryptographic keys, these technologies empower Subjects with true ownership and control over their digital identities.
  • Security and Trust: Cryptography ensures that identity data is secure and tamper-proof, while key management ensures that only authorized parties can access or use this data. Together, they form the basis of trust in decentralized identity systems.
  • Interoperability: Standards-based cryptographic algorithms and key management practices facilitate interoperability between different decentralized identity systems, enabling Subjects to use their digital identities across various platforms and services.

Challenges

While cryptography and key management are foundational to the security and efficacy of decentralized identity systems, they also introduce challenges such as:

  • Complexity: Managing cryptographic keys can be complex for humans, potentially leading to loss of access to digital identities if the keys are lost or compromised.
  • Scalability: As the number of digital identities and transactions grows, scalable key management solutions that do not compromise security become essential.
  • Usability: Balancing the security provided by cryptographic techniques with human-friendly interfaces is crucial to encourage widespread adoption of decentralized identity systems.

Agent Services

A decentralized identity agent plays a few key roles in managing digital identities:

  • Identity owner representative: The agent acts on behalf of the identity owner to interact with other parties and systems. It mediates access and sharing of identity data based on the owner’s preferences.
  • Identity/data source: The agent stores identity attributes, credentials, and other data related to the identity owner in a secure way. This decentralized storage approach gives the owner more control over their data.
  • Credential presenter: The agent can present verifiable credentials that attest to different identity attributes and share these with other agents/parties upon the owner’s request.
  • Relationship manager: It establishes peer-to-peer trusted connections and encrypted communication channels with other agents on the identity owner’s behalf. These relationships enable selective disclosure of identity details when accessing services.
  • Reputation Tracking: In reputation based decentralized identity systems, the agent may keep track of reputation scores, ratings, or reviews associated with a decentralized identity to enable trust and accountability.

Decentralized identity agents serve as secure proxies to manage identities, data sharing, credentials and relationships following self-sovereign principles centered around Subject control and consent. They are a core component enabling the reliability and portability of decentralized digital identity systems.

DID Management

The agent/wallet must support creating and managing DIDs with compatible DID methods like those compliant with the W3C DID specification. This includes generating DID-linked keypair(s) and invoking the DID method’s blockchain (or another registry) to anchor the DID.

Credential Request

A credential request in decentralized identity refers to a request made by an entity to ask for verifiable credentials from an issuer. A credential request allows holders to request (from an issuer) and selectively disclose information as verifiable credentials (to a verifier) enabling holder consent and minimizing data sharing.

Credential Exchange

Implement standardized protocols like the W3C Credential Handler API to facilitate credential offers, requests, and exchanges with other agents. Two of the most prominent formats are defined by the Open ID and Decentralized Identity Foundations.

There are some tradeoffs to consider when deciding between OpenID Connect (OIDC) and Decentralized Identity Foundation (DIF) Manifest for decentralized credential exchange:

Reasons to prefer OpenID Connect:

  • More widespread adoption currently
  • Integrates easily with traditional client-server infrastructure
  • Standardized security mechanisms and session handling
  • Ecosystem of certified implementations
  • Aligns with login/authentication use cases

Reasons to prefer DIF Manifest:

  • Purpose-built for decentralized identity
  • No central authorities or single points of failure
  • Metadata allows automated service/endpoint discovery.
  • Richer descriptive capabilities with JSON-LD
  • Showcases relationships between identities.
  • More decentralized vision of credential ecosystem

The DIF approach is newer and has more decentralized ideals in theory. But OIDC is more established and may integrate better into existing systems in practice.

For hybrid approaches:

  • OIDC for authentication
  • DIF for the rest of credential lifecycle management
  • Build a bridge between the two ecosystems.

Bottom line, OIDC has adoption today, DIF has greater decentralization promise. Hybrid strategies combining these standards offer a pragmatic path leveraging benefits of both. The optimal choice depends on the specific environment and use case.

Selective Presentation

Allow holders to selectively create verifiable presentations that disclose information from stored credentials from a variety of sources without necessarily revealing the entire credential. These presentations prove claims to verifiers.

Signature Creation and Verification

Cryptographically sign presentations and credentials. Verify signatures on received presentations/credentials to establish authenticity.

Messaging

DIDComm (Decentralized Identifier Communication) is a protocol standard for secure messaging between entities that have Decentralized Identifiers (DIDs). It enables privacy-preserving communication by using cryptographic techniques to encrypt messages and verify the identities of the communicating parties.

Some key aspects of DIDComm:

  • Uses DIDs and Verifiable Credentials for authentication and authorization between entities, eliminating centralized authorities.
  • Messages are end-to-end encrypted with mechanisms like AES encryption to ensure confidentiality.
  • Leverages existing standards like HTTPS and JSON to maximize interoperability.
  • Supports various messaging patterns like pairwise conversations, group chats, broadcasts etc.

DIDComm is a standard protocol for secure, decentralized communication between DID entities. It is optimized for identity ecosystems. Alternatives like HTTP/REST and Matrix offer decentralized messaging but lack DIDComm’s built-in security, privacy, and support for verifiable credentials. Quantum security promises unbreakable communication in future. However, DIDComm remains the best open standard for trusted, private messaging with verified claims.

So, in essence, good DIDComm alternatives exist for specific use cases but likely work best in a complementary role rather than a complete replacement for the workhorse protocol.

Credential Storage

Securely store issued verifiable credentials that encode identity claims about their holder. These credentials should adhere to specs like W3C’s Verifiable Credentials.

DID Services

Here are some of the key capabilities necessary to support the full DID lifecycle:

  • Creation: The ability to create a new, unique Decentralized Identifier (DID) along with its associated key pair(s). This requires a DID method with support for cryptographic generation and registration of new DIDs.
  • Authentication: Using the associated keys and endpoints, the ability to cryptographically authenticate entities that prove control/ownership of a DID. This establishes trust in assertions made about a DID.
  • Registration: DID registration is the process of initializing a new Decentralized Identifier (DID) and recording the associated DID document on the target ledger or registry.
  • Update: Once initially registered, the DID document can subsequently be updated by the controller as authentication methods and endpoints and other metadata associated with the DID changes over its lifetime.

Updating, revoking, and adding/rotating keys associated with a DID document. Requires access control enforcement to restrict updates only to entities authorized to update the DID.

  • Revocation: Adding revocation support using revocation lists, timestamps, or other schemes to disable compromised DIDs. Prevents loss of control over compromised DIDs.
  • Decommissioning: The ability to establish an explicit expiration date/time on registered DIDs and enforce their lifecycles.
  • Recovery: Systems to back up key material securely and recover control over a DID if keys are lost. Provides continuity of ownership over a DID.
  • Resolution: Resolve DIDs by discovering associated DID Documents which contain metadata like authentication suites and service endpoints. This helps establish trust.

Credential Services

Issuer Management[8]

Enterprises should vet and organize trusted credential issuers into a registry to streamline verification. Recommendations include maintaining a database of issuer DIDs, categorizing them by industry/domain, defining issuer approval policies based on reputation and data sharing agreements, keeping an audit trail of permissions granted, and enforcing periodic re-approval and expiry of access. This system enables enterprises to easily lookup and validate credentials from verified issuers.

Selective Content Generation

Selective content generation refers to the ability to dynamically control what information is disclosed from a verifiable credential when sharing it with a verifier. This allows maintaining privacy while still conveying the necessary verified claims. Some ways selective content generation can work with verifiable credentials:

  • Attribute-level claims filtering: Only share certain credential attributes that are minimally essential for the transaction while omitting other sensitive attributes encoded in the credential. For example, share that you are over 21 without disclosing full date of birth.
  • Predicate-based claims: Share a derived claim stating you satisfy a condition without the original data. For example, share a verified predicate that your age is over 18 without the actual age.
  • Zero-knowledge proofs: Selectively generate a mathematical proof that credentials satisfy certain properties without sharing the actual data within the credentials.
  • Predicate encryption: Encrypt different claims within a credential under policies so they are only decryptable when specific conditions are met by the verifier.
  • Oblivious attribute certificates: Credential claims are hidden behind commitments that only open to reveal the claim if associated policies and attributes are proven.

In all cases, the verifiable nature of the credential persists across generations to maintain trust and authenticity guarantees on the credential issuer while increasing privacy for the holder through selective disclosure. The content itself evolves based on the context.

Credential Issuance

Credential issuance involves issuer identification via DIDs, defining credential schemas, securely managing private signing keys, digitally signing and transmitting credentials per standard protocols, updating or revoking existing credentials when necessary, and governance frameworks for auditing, quality assurance, security and privacy risk assessments. Robust processes establish issuer legitimacy and credential integrity.

With robust implementation of these technical and governance capabilities, issuers can securely instantiate and provide controls around verifiable credentials bound to their identities.

Verification

Issuers are tasked with vetting any attributes they wish to include in a Verifiable Credential. An issuer’s verified attributes or claims refer to assertions the issuer makes about a Subject after having validated evidence or proof of those attributes. Some key points:

  • Attributes represent characteristics, qualities, details, or capabilities that describe a Subject. For example, date of birth, educational qualifications, employment history, etc.
  • The verification process establishes the evidentiary basis for the issuer to credibly make claims about those attributes being true for a Subject. Issuers verify attributes by validating evidence or proof documents from trusted sources. For example, passports, business licenses, etc.
  • Claims are attestations about attribute details made by the issuer after verification. For example, “Date of birth is March 3rd 1990” or “Authorized to do business in this jurisdiction”.
  • The verified claims can be encoded into verifiable credentials by the issuer and cryptographically signed to assert their validity.

While most enterprises will begin their decentralized identity journey through the role of verifier, eventually they will need to be capable of performing the duties of an issuer, translating validated attributes into credible issuer claims, the basis for verifiable credentials.

Anchoring

The practice of anchoring hashes of credential and issuer registries to a blockchain addresses several critical challenges in managing digital credentials, including security, trust, transparency, and fraud prevention. It harnesses the strengths of blockchain technology to create a more reliable, efficient, and secure digital identity ecosystem, paving the way for widespread adoption of decentralized identity solutions.

Verified Data

Credential Registry

A credential repository in the context of an issuer of verifiable credentials within a decentralized identity ecosystem refers to a secure and structured storage system where digital credentials are maintained. These credentials certify the attributes or claims about a Subject, and are essential components of decentralized identity systems, which aim to enable secure, verifiable, and privacy-respecting digital identity management.

The credential repository plays a critical role in decentralized identity ecosystems by ensuring that credentials are securely stored, easily manageable, and readily verifiable. This enhances the trustworthiness and efficiency of the identity verification process, essential for a wide range of applications from access control and secure online transactions to privacy-preserving user authentication.

Issuer Registry

An Issuer Registry organizes and validates credential issuers by maintaining a database of trusted issuer DIDs, categorizing them by sector, defining issuer approval policies based on reputation, data sharing agreements, and access permissions, keeping an audit trail of consent, requiring periodic re-approval and setting expiry dates on access. This system builds trust in issuers and credentials.

Blockchain or Other Persistent / Immutable Trust Anchor

A trust anchor registry enables discovery and recognition of validated trust anchors in decentralized identity systems. Key functions include anchor identifier resolution, metadata exchange, vetting for legitimacy, reputation tracking, compliance assurances through auditing, and portability of issued credentials across partners. A well-governed public registry provides accountability and oversight to scale the web of trust.

Conventional and Web-based DIDs

Decentralized Identifiers (DIDs) are a foundational element of decentralized identity systems, providing a unique, persistent identifier that does not require a centralized registration authority. DIDs are typically resolved on distributed ledger technology (DLT) platforms or other decentralized networks, enabling verifiable, self-sovereign identity. There are various DID methods, including conventional DLT-based DIDs and ‘did:web’ DIDs, each with its own set of advantages depending on the use case and requirements. Here’s a comparison focusing on the advantages of conventional DLT-based DIDs versus ‘did:web’ DIDs.

Advantages of Conventional DLT-based DIDs

  • Decentralization: Conventional DLT-based DIDs leverage the decentralized nature of blockchains, which means no single entity controls the issuance, revocation, or management of these identifiers. This enhances security and reduces the risk of censorship or centralized points of failure.
  • Interoperability: DLT-based DIDs are designed to be interoperable across different networks and systems, provided they adhere to the DID specification. This makes them versatile for use in a wide range of applications and services across different sectors.
  • Tamper-Proof: The immutable nature of blockchain technology ensures that once a DID is recorded on a blockchain, it cannot be altered, providing a tamper-proof record of the DID and associated DID Document.
  • Enhanced Privacy and Control: DLT-based DIDs support a higher degree of privacy and user control, enabling individuals to manage their own identities without relying on third parties. Users can selectively disclose information linked to their DID, enhancing privacy.
  • Global Reach and Accessibility: DLT-based DIDs can be accessed and verified from anywhere in the world, making them suitable for global applications that require universal access to identity verification services.
  • Ecosystem Support: There is a growing ecosystem of tools, libraries, and services designed to support DLT-based DIDs, facilitating their integration into various applications and systems.

Advantages of ‘did:web’ DIDs[9]

  • Ease of Use and Deployment: ‘did:web’ utilizes standard web infrastructure (DNS, HTTPS) for DID resolution, making it easier and more cost-effective to deploy and manage compared to setting up infrastructure on a blockchain.
  • Integration with Existing Web Infrastructure: Since ‘did:web’ DIDs leverage existing web technologies, they can be easily integrated into current web services and identity systems, lowering the barrier to entry for organizations looking to adopt DIDs.
  • Lower Operational Costs: Unlike DLT-based DIDs, which may incur transaction fees for operations such as updates or revocations on some blockchains, ‘did:web’ DIDs can be updated or revoked with minimal operational costs, as they rely on web servers.
  • Faster Resolution: ‘did:web’ DIDs can be resolved quickly using standard web protocols, without the need for the additional processing time that may be required to interact with a blockchain.
  • Control by Web Domain Owners: ‘did:web’ allows organizations to utilize their existing domain names for DID purposes, offering a straightforward way to link their decentralized identities with their established web presence.

Choosing between conventional DLT-based DIDs and ‘did:web’ DIDs depends on the specific requirements of the application, including considerations of decentralization, privacy, interoperability, cost, ease of use, and integration with existing systems. DLT-based DIDs offer robustness in terms of security, decentralization, and global accessibility, making them suitable for applications that require high levels of trust and independence from centralized control. On the other hand, ‘did:web’ DIDs provide a pragmatic and cost-effective approach for leveraging Decentralized Identifiers within the current web infrastructure, ideal for organizations seeking to adopt DIDs with minimal disruption and lower costs.

Claim Sources

Identity and Fact Repositories

Identity and fact repositories in the context of producing verifiable claims are fundamental components in the infrastructure of decentralized identity systems. These repositories store and manage digital attributes and claims that issuers use to generate verifiable credentials (VCs). The distinction between identity repositories and fact repositories is primarily in the type of information they hold:

Identity Repositories

Identity repositories store digital records of identity attributes. These attributes can be any piece of information related to the identity of an individual, organization, or object. Identity repositories are crucial for:

  • Storing Identity Attributes: Such as names, addresses, organizational affiliations, biometric data, etc.
  • Maintaining Privacy and Security: They ensure that sensitive identity information is stored securely and is accessible only under authorized conditions.
  • Providing a Source of Truth: Serve as a reliable source for identity attributes that issuers use to generate verifiable credentials.

Fact Repositories

Fact repositories, on the other hand, focus on storing verified facts or assertions about individuals, organizations, or things that are not strictly identity attributes. These can include:

  • Qualifications and Certifications: Such as academic degrees, professional licenses, training certificates, etc.
  • Transactional Histories: Records of transactions, interactions, or events involving the Subject.
  • Status Information: Such as membership statuses, employment statuses, or any other condition that can be asserted about a Subject.

Identity and fact repositories provide the essential information issuers need to produce accurate and verifiable claims. These repositories’ roles are critical in the decentralized identity ecosystem, enabling issuers to generate trustworthy credentials while ensuring the Subjects’ privacy and security.

Identity Bridging

Integrating legacy Identity and Access Management (IAM) systems with decentralized identity systems through Verifiable Credentials (VCs) is an evolving area of digital identity and security. A Presentation Request for Verifiable Credentials is a way for a service (verifier) to ask for specific information (claims) from a user’s digital identity, which are held in a secure and privacy-preserving manner, often leveraging Decentralized Identifiers (DIDs) and blockchain technology.

These integration capabilities would allow authentication with DIDs and verification of credentials for authorization to corporate resources and apps by enabling interoperability with legacy identity and access management (IAM) solutions.

  • Identity Translation: Translate Decentralized Identifiers and verifiable credentials into legacy formats like SAML, OAuth, OpenID that legacy IAM systems rely on. This lets legacy systems consume modern identity artifacts.
  • Attribute Mapping: Map attributes across identifiers. For example, mapping a verified “email” claim for a DID to the same attribute for a legacy user profile on traditional IAM systems. This allows translating credentials across domains.
  • Identity Anchoring: Utilize on-ledger anchors or smart contracts to associate legacy identifiers like phone numbers or usernames with new decentralized identifiers owned by the user. This links old ids to new self-sovereign identities.
  • Authentication Support: Support authentication with legacy credential formats like username-password directly while porting only authorization aspects to decentralized models. Allows gradual decentralization.
  • Bridging protocols: Bridge web protocols like OIDC/OAuth used by legacy IAM systems to decentralized identity protocols like DIDComm that facilitate decentralization.

Several IAM and digital identity solutions are pioneering the integration of decentralized identity systems with traditional identity management frameworks. These efforts aim to bridge the gap between legacy systems and modern decentralized architectures, enhancing privacy, security, and user control over personal data.

Key Vendors to Consider

Radiant Logic fits into this movement by providing a bridge to connect disparate identity data sources across an enterprise’s complex IT environment, aggregating identity information into a master record that provides a 360-degree view of all users and non-person entities. A challenge for early decentralized identity use cases is how it fits within the context of existing IAM, Security and Data Repositories. This capability allows the platform to correlate relationships and context across on-prem, cloud, and external systems, serving as an integration hub to feed authoritative, up-to-date identity data to security and access management applications in their required formats and protocols. In this way, Radiant Logic aims to connect both legacy and modern infrastructure components to enable policy-based conditional access and zero trust architectures that secure resources in today’s distributed hybrid IT ecosystems. Its capabilities are tailor-made to bridge decentralized identity and legacy systems.

1Kosmos BlockID bridges identities across disconnected systems. It connects on-premises directories with cloud apps through robust identity synchronization, allowing unified access across environments. BlockID federates multiple identity stores into a single provider, breaking down identity silos. It also maps user identities and attributes between systems to maintain accuracy. Additionally, BlockID synchronizes credentials like permissions and access rights so users have consistent rights across all systems. Finally, it enables single sign-on across federated apps and domains for a streamlined login experience. In summary, BlockID delivers comprehensive identity federation and bridging for seamless hybrid IT access and improved security.

Microsoft Entra Verified ID is a cloud-based managed service that integrates decentralized digital identity with Active Directory portfolio. It automates validation of verifiable identity credentials issued by trusted sources to streamline enrollment and access for users like employees, partners, and customers. The integration works by synchronizing with Active Directory user identities and attributes to Microsoft Entra cloud identity services utilizing Entra Connect Sync server. This bridges AD and modern decentralized identity standards, delivering simplified identity verification while maintaining integration with legacy AD infrastructure crucial for enterprise environments. Overall, Entra Verified ID enables enterprises to augment existing AD-based access management with decentralized capabilities to strengthen trust while accelerating secure access across online and on-prem systems.

IBM, with its IdentityNEXT initiative, is focusing on integrating decentralized credentials with traditional IAM solutions. IBM’s strategy includes embracing open by design principles, contributing to the development of open-source designs, and participating in standard initiatives like the Trust over IP (ToIP) framework. IBM’s approach is geared towards creating an interoperable decentralized identity architecture that supports the exchange of digital credentials across various industries and use cases.

PingOne Neo enables enterprise identity bridging through verifiable credentials sourced from trusted issuers and stored securely on user devices. Flexible identity proofs suit diverse populations beyond government IDs. Tight integration with PingFederate allows identity verification in user flows. Privacy-preserving credentials share only essential attributes, minimizing exposure. These interoperable digital credentials facilitate efficient identity interactions across channels without complex infrastructure. By bridging credentials and integrating systems, Neo simplifies identity management while empowering users with privacy-first decentralized identity capabilities.

Implementation Considerations

Integration touchpoints with legacy IAM systems

TechVision has defined and published an IAM Reference Architecture defining the capabilities necessary to support a robust IAM foundation, and in our report “Decentralized Identity and Verifiable Credentials” we outlined the potential impacts of decentralized identity within that reference architecture. This report refines some of those impacts.

Here are some of the key integration touchpoints between decentralized identity systems and legacy identity and access management (IAM) systems:

  1. Identity Provisioning
    1. Provision Decentralized Identifiers (DIDs) for existing users in legacy IAM systems.
    2. Onboard new users directly into decentralized identity system first
  2. Identity Translation & Mapping
    1. Map proprietary legacy user IDs (email, username, employee IDs) to DIDs
    2. Translate legacy identity attributes into verifiable credentials.
  3. Authentication & Access Control
    1. Use DIDs as alternative login mechanism for legacy apps and services, mapped to legacy credentials internally.
    2. Exchange authentication signals like OAuth tokens bi-directionally
  4. Auditing & Compliance Reporting
    1. Correlate user activity logs across both systems
    2. Leverage verifiable credentials for compliance reports required by legacy IAM.
  5. Administration & Lifecycle Management
    1. Harmonize lifecycles for users and credentials across systems.
    2. Integrate workflows for automated provisioning/deprovisioning.
  6. Consent & Privacy Management
    1. Store user consent decrees or consent receipts[10] granted on legacy IAM as verifiable credentials.
    2. Allow users to exercise privacy rights from decentralized ID wallet.

Bridging the functional touchpoints for core login, access control, provisioning and monitoring while translating identifiers, attributes and protocols creates a foundation for interoperability between legacy designs and emerging paradigms.

Decentralized identifier (DID) strategies

Here are some potential DID topics to consider in your specific enterprise decentralized identity reference architecture:

  1. DID Ledger Selection
    1. Evaluate public blockchains like Bitcoin, Ethereum or private distributed ledgers to anchor enterprise DIDs based on factors like scalability, confidentiality, governance etc.
  2. DID Issuance and Propagation
    1. Develop centralized capabilities for generating and disseminating DIDs across enterprise systems.
    2. Allow multiple departments to anchor DIDs independently across approved ledgers.
  3. DID Ownership Model
    1. Enterprise-managed – organization issues and manages DIDs on behalf of employees/customers.
    2. BYODID – Employees or customers can register their own DIDs and link to enterprise credentials and services.
  4. DID Control Mechanisms
    1. Consider smart contracts to enable dynamic permissioning, automated DID operations, and transfers based on enterprise policies embedded directly on-ledger.
  5. DID Lifecycle Management
    1. Institute policies for recovering lost key material, transferring DID ownership during offboarding, resolving DIDs to employees during audits.
  6. Interoperable Resolvers
    1. Leverage open community resolvers like Universal Resolver or operate proprietary enterprise resolvers to translate DIDs into legacy employee IDs.

Evaluating tradeoffs and aligning DID approaches to the enterprise environment, user population, and existing identity lifecycle processes is crucial for integration with legacy IAM systems. The DID method chosen also impacts overall system decentralization.

Verifiable credential formats

Here are some potential verifiable credential format options to evaluate for an enterprise decentralized identity reference architecture:

  1. W3C Verifiable Credential Standard
    1. Emerging decentralized standard with wide community adoption. Provides baseline interoperability.
    2. Supports JSON-LD encoding. Encryption extension available.
  2. Hyperledger Indy Cred Spec
    1. Mature credential specification optimized for self-sovereign identity.
    2. Syncs with Indy ledger, uses anoncreds cryptographic protocols.
  3. DIF Credential Manifest
    1. Custom credential format built for privacy-preserving credentials leveraging blinding.
    2. Focused on selective disclosure flows.
  4. JWTCred – JWT-based credential format
    1. Encodes verifiable credentials as JSON Web Tokens. Good for implementers experienced with JWTs.
  5. Zero-knowledge Credentials
    1. Leading zero-knowledge standards like the Zero-knowledge Proofs Markup Language (ZPML) can be utilized to design enterprise credentials that minimize disclosure.

The credential format chosen impacts portability, privacy features, and verifier adoption. Tradeoffs exist between ease of integration and support for advanced cryptography like zero-knowledge proofs. A combination of formats may be required to serve all edge cases. As you work with vendors, make sure you understand which credential format(s) they use.

Where to Start

Think about deploying Decentralized Identifiers (DIDs)for employees first. There are a few key reasons why enterprises may want to focus on adopting DIDs for employees, before other uses:

  • Allows testing and refining the system at smaller scale: Rolling out employee DIDs helps work out technical and process kinks before expanding to much larger customer/partner populations. Starting small reduces disruption risk.
  • Employees more open to new technologies: Employees generally are more willing and flexible about adopting new solutions, especially with top-down directives. Enables developing change management best practices.
  • Significant authentication and credential management benefits: Employee authentication, corporate access and permissions tied currently to cumbersome centralized directories, and passwords stand to improve drastically. Better security and user experience.
  • Builds internal DID skills and cost savings: Developing the expertise needed for managing employee DIDs and credentials creates the capabilities to expand the systems more easily to customers/partners later. Saves external vendor costs.
  • Internal use cases like access controls easier to address: Employee interactions cover a more homogenous and predictable set of identity/access use cases, making them simpler to address with a minimum viable DID approach initially.

Employees serve as an ideal testing ground to develop skills, refine processes, build momentum, and demonstrate benefits before expanding DIDs to external stakeholders. A crawl-walk-run adoption strategy leveraging internal use provides flexibility and risk mitigation.

Decentralized Identity approaches

Here are some ways that decentralized identity approaches can be incorporated into an enterprise decentralized identity architecture:

  1. Employee-managed credentials
    1. Issue verifiable credentials to employees and allow them to control storage in personal identity wallets rather than enterprise databases.
  2. Allow BYOID (Bring Your Own Identity)
    1. Employees can register their own Decentralized Identifiers (DIDs) and link them to corporate-provisioned identities for authentication to internal systems and resources.
  3. Employee convenience signatures
    1. Issue credential signing keys directly to employees to sign documents, approvals, logs etc. rather than using centrally managed keys.
  4. Employee privacy control
    1. Provide tools for employees to selectively disclose information from personal devices to enterprise apps rather than sharing full profiles.
  5. Confidential computing credentials
    1. Issue credentials enabling access confidential computing resources while preserving employee privacy via trusted execution environments.
  6. Credential lifecycle autonomy.
    1. Employees manage lifecycles of work-related verifiable credentials independent of centralized IT while syncing revocation status.

The decentralized identity pattern empowers employees to own and manage identities and credentials directly on personal agents and devices while integrating with enterprise infrastructure. Within the context of IAM, the enterprise issues the claims and credentials needed to access corporate resources necessary to perform one’s job. The creation and management of these credentials are the responsibility of the company and under their governance and control. While the employee manages credential sharing, the enterprise places restrictions around sharing (e.g. only accepting requests from known enterprise DIDs) to avoid compromising security.

Employee DID WorkFlow

Here is a workflow that describes how decentralized identities can be initiated and managed as you roll out various use cases. This section outlines the areas that require refinement and process development. It is not intended to be a prescription but a suggestion.

  • Onboarding: During signup/account creation, the user generates a DID and public/private key pair using a supported DID method in a wallet app. The DID and public key act as the user’s identifiers.
  • Identity Proofing: The enterprise verifies the real-world identity of the Subject through appropriate know-your-customer (KYC) or know-your-business (KYB) procedures. This links their DID to their real identity.
  • Credential Issuance: After identity proofing, the enterprise issues a verifiable credential to the Subject’s wallet that includes identity claims about them. This credential is digitally signed by the enterprise’s DID.
  • Authentication: When the Subject needs to access enterprise systems, they use their wallet to create a verifiable presentation that selectively discloses claims from the enterprise-issued credential. This links their DID to their verified identity.
  • Verification & Access: The enterprise uses public keys and DID resolution to verify the credential presentation’s authenticity and integrity. If valid, the Subject is authenticated based on their verified identity claims and granted appropriate access permissions.
  • Monitoring: The enterprise monitors DID/credential validity and revocation status through blockchains or other external sources to handle access revocation if needed.

This DID-based workflow allows the enterprise to authenticate users in a self-sovereign, secure, and privacy-respecting manner leveraging decentralized networks. The enterprise itself acts as a credential issuer and verifier.

Potential Employee Use Cases

Employing the Self-sovereign identity approaches and DID workflow like the ones described above allows the enterprise to offer various services such as:

  • Privacy
    • Anonymous attestations: Employees could get validated for certain attributes like “employee of X company” without revealing their full identity.
    • Selective disclosure: Employees could selectively share subsets of credentials with others to preserve privacy.
  • Security
    • Background checks – Credentials confirming background checks have been performed where required by policy.
    • Access control – Employees can prove they work at the company to gain access to facilities and tools.
    • Access card replacement – Buildings/garage access using Bluetooth communication between wallet app and sensors.
    • Authentication – Employee DIDs used for login to various IT systems and services.
    • Authorization – Use DID and verified employee credentials for resource access approval.
    • Contextual Authorization – Use DID and additional credentials for step-up authentication to authorize advanced access to company resources.
    • Access delegation – Provision temporary access by delegating control over a restricted DID.
    • Credential revocation: Revocation of credentials could be supported to disable access when needed.
    • Digital signatures – Employees can digitally sign documents and verify using their DIDs.
  • People Operations
    • Paperless onboarding – new employees are issued verified company credentials as part of digital onboarding.
    • Professional profiles – Teams can view credentials & skills of other employees.
    • Internal talent management – Employee skills and experience can be validated to enable internal mobility.
    • Company badges – The wallet manages virtual badges associated with employee roles, awards etc. that can be selectively shared.
    • Certifications – Issuing credentials for internal certifications, external qualifications etc. that employees can easily share.
    • Team credentials – Departments could issue verified credentials for new joiners.
    • Directories – Publish verified metadata like contact info mapped to employee DIDs.

Conclusion and Next Steps

This Decentralized Identity Reference Architecture was developed to guide enterprises that are looking to enable user control over digital identities without depending on centralized authorities, ensure privacy by minimizing personal data disclosure, leverage cryptography for security, and build trusted ecosystems with open standards.

The goals are to provide frictionless authentication without passwords, selective data sharing that minimizes exposure, interoperability across domains, and regulatory compliance.

If correctly implemented, the architecture will facilitate Subject-owned credentials, resilience to outages, identity portability, flexible access management, and reduced risk exposure by strengthening consent, auditability, credential integrity and avoiding vendor lock-in. Overall, the principles and goals focus on decentralization, ownership, privacy, resilience, and enterprise integration.

Near Term Steps

While many enterprises have been experimenting with the technologies of Blockchain and Web3 to manage document exchange and asset management, adoption of decentralized identity is limited. As outlined in our Digital Identity Wallet report, momentum is building, especially in Europe. Here are some practical, near-term steps enterprises can take within a decentralization roadmap:

  • Run DID method pilots: Evaluate different DID methods by issuing ephemeral test credentials to a small group of employees and partners. Measure ease of integration, key management overhead etc.
  • Inventory attributes: Catalog all internal and external identity attributes, credentials, and databases. Prioritize use cases to transition to verifiable credentials.
  • Certify issuers: Designate trusted issuers within the organization that can start asserting verifiable claims internally about employees, customers etc. in a GDPR-compliant fashion.
  • Explore enterprise wallets: Evaluate suppliers such as Spherity, Affinidi, 1Kosmos, PingOne Neo, and others to verify they can support the necessary capabilities.
  • Update applications: Modify login, profile and consent flows within websites and apps to display and interact with DID-based decentralized identity records where available. Gracefully fallback for non-DID users.
  • Try selective disclosure: Implement zero-knowledge proofs or selective disclosure for localized use cases to preserve privacy. For example, allowing age verification without sharing exact birth date.
  • Co-build prototypes: Jointly develop proof-of-value prototypes with ecosystem partners leveraging aligned decentralized identity standards to solve real business problems like paperless trade finance.
  • Contribute to open standards: Actively participate in maturation of decentralized identity standards at W3C and other bodies based on implementation experience. Help build critical mass.

This balanced approach allows rational incremental decentralization while insulating end-users from disruption until ecosystem readiness reaches maturity based on evidence from practical integration and deliberative partnerships.

The Laws of Identity revisited

Circling back to the beginning, here is a summary of how Decentralized Identifiers (DIDs) and DID systems align with and support Kim Cameron’s Laws of Identity:

  • User control & consent – DIDs put users in charge of their digital identity, enabling consent-based selective disclosure of attributes.
  • Minimal disclosure – DID agents mediate judicious sharing of verifiable claims to prevent overexposure. Standards enable data minimization.
  • Justifiable parties – DID communication protocols allow declarative policies around information access based on the justified requirements of requesters.
  • Directed identity – DIDs can represent public personas while also supporting private peer-to-peer identity exchange using unidirectional identifiers.
  • Pluralism of operators – DID infrastructure standards allow interoperability between different technologies from various identity providers.
  • Consistent experience – Universal DID resolution, verifiable credentials and DIDComm protocols guarantee consistent representation of self across contexts.

Decentralized identity aligns with user-centric principles around consent, minimalism, control, and context-based customized disclosure while also allowing technological and operational pluralism. – enabling the next generation privacy-preserving identity layer for the decentralized future.

 

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 skills 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 Author

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 in both enterprise and startup product development gives him a unique perspective on the application of new technologies.

 

Appendices

Appendix A: Standards Bodies and Initiatives

Decentralized identity standards bodies and initiatives play a crucial role in the development, adoption, and interoperability of decentralized identity technologies. These organizations work towards creating open, interoperable standards and protocols that ensure secure, private, and user-controlled digital identity systems. Here are some of the key standards bodies and initiatives involved in decentralized identity:

World Wide Web Consortium (W3C)

The World Wide Web Consortium (W3C) develops standards and guidelines to help everyone build a web based on the principles of accessibility, internationalization, privacy and security.

  • Decentralized Identifiers (DIDs): W3C has published the Decentralized Identifiers (DIDs) v1.0 specification, which defines a framework for creating globally unique identifiers that do not require a centralized registration authority and are fully under the control of the DID Subject.
  • Verifiable Credentials (VCs): The W3C Verifiable Credentials Data Model is another critical standard that specifies a method for representing claims made about a Subject in a way that is cryptographically secure, privacy-respecting, and fully verifiable.

Decentralized Identity Foundation (DIF)

DIF is a consortium of industry leaders and organizations working together to establish and promote an ecosystem of interoperable, decentralized identity. Key initiatives include:

  • Sidetree Protocol: A protocol for creating scalable DID networks that can operate atop existing decentralized networks without requiring additional consensus mechanisms.
  • Universal Resolver: A project aimed at creating a tool for resolving a wide range of DID methods across different blockchains and networks.
  • Credential Manifest: A Credential Manifest is a document, hosted by an Issuer and consumed by Agent services, codifying the credentials that it issues in terms of pre-requisites and inputs. These can be static or dynamic, but their form and usage are detailed in this specification.

Trust over IP Foundation (ToIP)

The ToIP Foundation is focused on defining a complete architecture for Internet-scale digital trust that combines cryptographic trust at the machine layer and human trust at the business, legal, and social layers. It aims to enable trustworthy exchange and verification of data across digital networks. ToIP Foundation – Emerging standards like Identity Over IP (IOIP) focusing on interchain identity operations across ledgers, payment systems and fabrics to unify identity.

Trust over IP (ToIP) Stack – Technology agnostic interoperability components enabling reliable exchange of verifiable credentials between any two agents.

Hyperledger

Hyperledger is an open-source collaborative effort created to advance cross-industry blockchain technologies. Within the context of decentralized identity, Hyperledger Indy is a distributed ledger specifically built for decentralized identity. Other projects like Hyperledger Aries and Hyperledger Ursa support the creation and management of decentralized identities and cryptographic operations, respectively.

Internet Engineering Task Force (IETF)

The IETF works on internet standards, including those that impact decentralized identity. For example, the Secure Identity Across Networks (SIAN) working group focuses on standards for secure and privacy-preserving identity management across different networks.

OpenID Foundation

Though primarily focused on centralized identity protocols, the OpenID Foundation has also explored decentralized identity aspects. Its work on OpenID Connect, a widely adopted identity layer on top of OAuth 2.0, provides important context and infrastructure that decentralized identity systems can leverage for broader adoption and compatibility with existing web authentication mechanisms.

Importance and Impact

These organizations and their initiatives are critical for the development of a universally accepted, secure, and interoperable framework for decentralized identity. By establishing standards and protocols, they facilitate:

  • Interoperability: Ensuring that decentralized identity systems can work across different platforms, networks, and applications.
  • Security and Privacy: Defining the mechanisms for secure and privacy-preserving identity management and verification.
  • Adoption: Providing a standardized approach that can be widely adopted by technology providers, enterprises, and governments.
  • Innovation: Fostering an environment for continuous improvement and innovation within the decentralized identity space.

The work of these standards bodies and initiatives is foundational to the success and widespread adoption of decentralized identity technologies, enabling a future where individuals and entities have greater control and sovereignty over their digital identities.

Interoperability standards and frameworks

Here is a definition of some of the key interoperability standards and frameworks that enable decentralized identity systems to work together:

  • W3C Decentralized Identifier (DID) Standard – Provides common syntax and operations for DIDs anchored to any distributed ledger or network. Enables interoperability across different DID methods.
  • W3C Verifiable Credentials Standard – Defines common data model and encoding formats for verifiable credentials to ease sharing across apps and organizations. Enables portability.
  • DIF Universal Resolver – Technology agnostic interoperability layer for resolving DIDs across any ledger system and translating between identifiers. Crucial for reducing fragmentation.
  • DIF Credential Manifest – A specification of a presentation that allows collected credentials for a Subject to be bundled with verifiable metadata for sharing or presentation to credential consumers like verifiers or other third parties.
  • Hyperledger Indy – Modular open-source framework providing base components for decentralized identity including DIDs, protocols, credential formats. Promotes interoperability.
  • ToIP Foundation – Emerging standards like Identity Over IP (IOIP) focusing on interchain identity operations across ledgers, payment systems and fabrics to unify identity.
  • Trust over IP (ToIP) Stack – Technology agnostic interoperability components enabling reliable exchange of verifiable credentials between any two agents.

The standardization of foundational components like DIDs, data models, resolvers and communication protocols via these global initiatives and bodies will be key to prevent vendor silos and fragmentation in decentralized identity adoption. Compliance to these standards is necessary for any reference architecture.

 

Related Reports

The following reports might be helpful in your continued exploration of this domain:

  • Digital Identity Wallets by David Goodman.

Digital identity wallets emerge amid decentralized identity trend, with EU investing heavily. The report examines wallet value proposition, provider analysis, and recommendations for enterprises to leverage wallets in a disruptive identity landscape.

  • Decentralized Identity and Verifiable Credentials by Gary Rowe, Doug Simmons, Phil Windley, and Gary Zimmerman

The report analyzes why decentralized identity remains emerging despite its promise. Covers current state, evaluates its merits as a trust model, outlines the impacts on a capabilities-based IAM Reference Architecture, and provides recommendations for enterprises to begin adopting it.

  • Decentralized, Blockchain-Enabled Identity Services Gain Traction by Gary Rowe, Doug Simmons, and Gary Zimmerman

Traditional identity trust models are becoming insufficient for a digital-first age. The report explores decentralized identity using blockchain and verifiable credentials as potential scalable solution. Enterprises advised to investigate and prepare for this new trust model.

  • Blockchain-based Identity Management by Gary Rowe and Doug Simmons

The report explores blockchain’s potential for identity management ecosystem, enabling trusted identities distribution without centralized authority. Covers identity management perspective and blockchain’s evolution supporting various identity use cases.

[1] https://www.ipsos.com/sites/default/files/ct/news/documents/2022-11/NEW%20INSTITUTE%20Ipsos%20-%20Trust%20in%20the%20internet%20-Press%20Release_0.pdf

[2] https://www.identityblog.com/?p=352

[3] https://www.ipsos.com/sites/default/files/ct/news/documents/2022-11/NEW%20INSTITUTE%20Ipsos%20-%20Trust%20in%20the%20internet%20-Press%20Release_0.pdf

[4] Some implementations are shying away from DLT technologies. The technology is new, evolving, and requires a different strategy around control and trust. Regardless, the need for a tamper resistant, immutable, and auditable log of verified transactions is required for decentralized identity.

[5] It is possible to implement federated IAM in a way that the identity provider doesn’t track the user’s access to services, but historically federations haven’t been created in this way.

[6] Work is underway on the option of reducing the need for a decentralized ledger. The did:web method is anchored in the X509 SSL certificate as the security around a DID Documents.

[7] In some cases, the identity provider and service provider may be the same enterprise, such as when a single company issues credentials for their own employees’ access.

[8] Eventually, a similar management system may need to be established for Verifiers to prevent unintended disclosure.

[9] Microsoft Entra Verified ID uses the DID:web method

[10] https://ieeexplore.ieee.org/document/9730898

Tags:

We can help

If you want to find out more detail, we're happy to help. Just give us your business email so that we can start a conversation.

Thanks, we'll be in touch!

Stay in the know!

Keep informed of new speakers, topics, and activities as they are added. By registering now you are not making a firm commitment to attend.

Congrats! We'll be sending you updates on the progress of the conference.