In today’s increasingly connected landscape, proving who you are shouldn’t mean sacrificing your privacy or handing over control of your personal data. Welcome to the world of Decentralized Identity (DI), a fundamental shift designed to empower individuals and organizations alike.
Table of Contents
The Growing Crisis in Digital Identity
Our digital and physical lives are becoming thoroughly interconnected through the apps, services, and devices we use every day. While this enhanced connectivity has opened a world of possibilities, it also brings a significant downside: a greater risk of identity theft and data breaches. These security incidents can be devastating to both our personal and professional lives.
Currently, our entire digital identity, everything we say, do, and experience, from purchasing event tickets to checking into a hotel, is highly dependent on third parties. In many cases, this dependency exists without our knowledge. Every day, users grant apps and devices access to their data, and it takes a great deal of effort for us to keep track of exactly who has access to which pieces of information.
Enterprises also face complexity, requiring “high-touch orchestration” to securely exchange data with consumers and partners while trying to maintain security and privacy for all parties involved. To solve these interwoven challenges, we need a new form of identity that delivers key attributes like self-ownership and censorship resistance, capabilities that are difficult to achieve using existing systems.
What is Decentralized Identity (DI)?
Decentralized Identity technologies provide a secure and private way to manage identity data without relying on centralized authorities or intermediaries. This new system is designed to unlock a set of experiences that give users and organizations greater control over their data and deliver a higher degree of trust and security for service providers.
Microsoft is not developing this solution in isolation; they are actively collaborating with members of the Decentralized Identity Foundation (DIF), the W3C Credentials Community Group, and the wider identity community. This commitment to open standards is critical, ensuring broad adoption and interoperability.
The Microsoft services implement several important open standards:
– W3C Decentralized Identifiers
– W3C Verifiable Credentials
– DIF Sidetree
– DIF Well-Known DID Configuration
– DIF DID-SIOP
– DIF Presentation Exchange
The Core Building Blocks: DIDs and VCs
Decentralized Identity is built on two primary technical concepts: Decentralized Identifiers and Verifiable Credentials.
Decentralized Identifiers (DIDs)
Before DIDs, traditional identifiers like email addresses or social network IDs were used for collaboration, but were overloaded to serve as control points for data access across many scenarios. The fundamental problem is that access to these traditional IDs could be removed at any time by the third party who controls the system.
Decentralized Identifiers (DIDs) are different. They are user-generated, self-owned, globally unique identifiers rooted in decentralized trust systems. DIDs possess unique, crucial characteristics, including greater assurance of immutability, censorship resistance, and tamper evasiveness. These attributes are essential for any ID system intended to provide self-ownership and user control.
Technically, DIDs are globally unique identifiers that are linked to Decentralized Public Key Infrastructure (DPKI) metadata. This metadata is composed of JSON documents that contain public key material, authentication descriptors, and service endpoints.
Verifiable Credentials (VCs)
We use physical IDs constantly in our daily lives. We use driver’s licenses to prove we can operate a car, diplomas to prove our education level, and passports to prove our identity to foreign authorities. Verifiable Credentials (VCs) are the digital framework for securely handling these types of scenarios over the internet while respecting users’ privacy.
In short, VCs are data objects consisting of claims made by an issuer attesting to information about a subject. The claim includes the DID of both the issuer and the subject. Crucially, the issuer’s DID produces a digital signature as evidence of their attestation to this information. This digital signature is key to verifying the credential’s authenticity.
Microsoft Entra Verified ID: The Technical Foundation
To deliver on the promises of DI, such as self-ownership and censorship resistance, a specific technical foundation is required, including user-owned identifiers, a user agent to manage keys, and encrypted, user-controlled datastores.
The self-owned IDs that users create, own, and control independently of any organization or government.
Trust System
To resolve DID documents, DIDs are typically recorded on an underlying network. Microsoft currently supports the DID web trust system. This is a permission-based model that allows trust using a web domain’s existing reputation.
DID User Agent/Wallet (Microsoft Authenticator App):
This is the application that enables real people to use decentralized identities and Verifiable Credentials. The Microsoft Authenticator app creates DIDs, facilitates requests for issuance and presentation of VCs, and manages the backup of the DID’s seed through an encrypted wallet file.
Microsoft Resolver
This is an API that looks up and resolves DIDs using the did web method. It returns the DID Document Object (DDO), which includes DPKI metadata associated with the DID, such as public keys and service endpoints.
Microsoft Entra Verified ID Service
This is an issuance and verification service in Azure, offered as a REST API for W3C Verifiable Credentials that are signed with the DID web method. This service enables identity owners to generate, present, and verify claims, forming the basis of trust between users of the systems.
DI in Action: Roles and a Real-World Scenario
In a verifiable credential solution, there are three primary actors. We can see how they interact using a sample scenario involving Alice, her employer (Woodgrove Inc.), and a vendor (Proseware):
The Roles
User (Alice)
The person or entity requesting a VC. When Alice needs to provide proof of employment, she grants access to the credential in her Authenticator app by signing a verifiable presentation (VP) with her DID.
Issuer (Woodgrove Inc.)
An organization that creates an issuance solution to verify the user’s identity. The Issuer attests that the proof the user provided is accurate and creates a VC signed with their DID for which the user’s DID is the subject.
Verifier (Proseware)
A company or entity that needs to verify claims from one or more trusted Issuers. The Verifier validates the credential by matching the presentation against the public key placed in the DPKI.
The Scenario Flow
Issuance (Woodgrove to Alice)
Alice (User) requests a proof of employment VC from Woodgrove Inc. (Issuer). Woodgrove validates her existing credentials (e.g., an ID token from her username/password sign-in). Once validated, Woodgrove creates a VC that includes claims about Alice and is signed with Woodgrove’s DID.
Storage (Alice’s Wallet)
Alice accepts this signed VC and stores it securely in her digital wallet application (the Authenticator app).
Presentation (Alice to Proseware)
Alice wants to receive corporate discounts from Proseware (Verifier). She presents the VC to the Proseware site. She must sign a verifiable presentation (VP) with her DID and send it to the Verifier, proving she is the owner of the DID and the credential.
Verification (Proseware)
Proseware trusts that Woodgrove accurately verified its employees’ identities. Proseware uses open standards, such as Self-Issued OpenID Provider (SIOP) and Presentation Exchange, to request the specific VC from Alice. Proseware can use the verifiable credentials service API or SDK, or configure their own Microsoft Entra tenant, to verify the authenticity of the verifiable presentation.
Result
Upon successful verification, Alice qualifies for the discount. The entire transaction is logged in Alice’s wallet application, helping her track where and to whom she presented her proof of employment.
Key Takeaways
– The Problem: Current digital identity systems rely heavily on centralized third parties, leading to a high risk of breaches and a lack of user control over who accesses their data.
– The Solution: Decentralized Identity (DI) provides a secure, private framework that eliminates reliance on intermediaries.
– DIDs: Decentralized Identifiers are self-owned, globally unique IDs that are immutable and tamper-resistant, unlike traditional usernames or emails.
– VCs: Verifiable Credentials are digitally signed data objects, analogous to a diploma or driver’s license, used to attest to specific claims about a subject.
– Microsoft’s Role: Microsoft Entra Verified ID implements open standards (W3C, DIF) and provides necessary tools like the Authenticator App (Wallet) and the Entra Verified ID Service to enable issuance and verification.
Building Trust Without Centralization: Inside Microsoft Entra Verified ID
In today’s increasingly connected landscape, proving who you are shouldn’t mean sacrificing your privacy or handing over control of your personal data. Welcome to the world of Decentralized Identity (DI), a fundamental shift designed to empower individuals and organizations alike.
Table of Contents
The Growing Crisis in Digital Identity
Our digital and physical lives are becoming thoroughly interconnected through the apps, services, and devices we use every day. While this enhanced connectivity has opened a world of possibilities, it also brings a significant downside: a greater risk of identity theft and data breaches. These security incidents can be devastating to both our personal and professional lives.
Currently, our entire digital identity, everything we say, do, and experience, from purchasing event tickets to checking into a hotel, is highly dependent on third parties. In many cases, this dependency exists without our knowledge. Every day, users grant apps and devices access to their data, and it takes a great deal of effort for us to keep track of exactly who has access to which pieces of information.
Enterprises also face complexity, requiring “high-touch orchestration” to securely exchange data with consumers and partners while trying to maintain security and privacy for all parties involved. To solve these interwoven challenges, we need a new form of identity that delivers key attributes like self-ownership and censorship resistance, capabilities that are difficult to achieve using existing systems.
What is Decentralized Identity (DI)?
Decentralized Identity technologies provide a secure and private way to manage identity data without relying on centralized authorities or intermediaries. This new system is designed to unlock a set of experiences that give users and organizations greater control over their data and deliver a higher degree of trust and security for service providers.
Microsoft is not developing this solution in isolation; they are actively collaborating with members of the Decentralized Identity Foundation (DIF), the W3C Credentials Community Group, and the wider identity community. This commitment to open standards is critical, ensuring broad adoption and interoperability.
The Microsoft services implement several important open standards:
The Core Building Blocks: DIDs and VCs
Decentralized Identity is built on two primary technical concepts: Decentralized Identifiers and Verifiable Credentials.
Decentralized Identifiers (DIDs)
Before DIDs, traditional identifiers like email addresses or social network IDs were used for collaboration, but were overloaded to serve as control points for data access across many scenarios. The fundamental problem is that access to these traditional IDs could be removed at any time by the third party who controls the system.
Decentralized Identifiers (DIDs) are different. They are user-generated, self-owned, globally unique identifiers rooted in decentralized trust systems. DIDs possess unique, crucial characteristics, including greater assurance of immutability, censorship resistance, and tamper evasiveness. These attributes are essential for any ID system intended to provide self-ownership and user control.
Technically, DIDs are globally unique identifiers that are linked to Decentralized Public Key Infrastructure (DPKI) metadata. This metadata is composed of JSON documents that contain public key material, authentication descriptors, and service endpoints.
Verifiable Credentials (VCs)
We use physical IDs constantly in our daily lives. We use driver’s licenses to prove we can operate a car, diplomas to prove our education level, and passports to prove our identity to foreign authorities. Verifiable Credentials (VCs) are the digital framework for securely handling these types of scenarios over the internet while respecting users’ privacy.
In short, VCs are data objects consisting of claims made by an issuer attesting to information about a subject. The claim includes the DID of both the issuer and the subject. Crucially, the issuer’s DID produces a digital signature as evidence of their attestation to this information. This digital signature is key to verifying the credential’s authenticity.
Microsoft Entra Verified ID: The Technical Foundation
To deliver on the promises of DI, such as self-ownership and censorship resistance, a specific technical foundation is required, including user-owned identifiers, a user agent to manage keys, and encrypted, user-controlled datastores.
Microsoft’s verifiable credential solution is built on five key technical components:
W3C Decentralized Identifiers (DIDs)
The self-owned IDs that users create, own, and control independently of any organization or government.
Trust System
To resolve DID documents, DIDs are typically recorded on an underlying network. Microsoft currently supports the DID web trust system. This is a permission-based model that allows trust using a web domain’s existing reputation.
DID User Agent/Wallet (Microsoft Authenticator App):
This is the application that enables real people to use decentralized identities and Verifiable Credentials. The Microsoft Authenticator app creates DIDs, facilitates requests for issuance and presentation of VCs, and manages the backup of the DID’s seed through an encrypted wallet file.
Microsoft Resolver
This is an API that looks up and resolves DIDs using the did web method. It returns the DID Document Object (DDO), which includes DPKI metadata associated with the DID, such as public keys and service endpoints.
Microsoft Entra Verified ID Service
This is an issuance and verification service in Azure, offered as a REST API for W3C Verifiable Credentials that are signed with the DID web method. This service enables identity owners to generate, present, and verify claims, forming the basis of trust between users of the systems.
DI in Action: Roles and a Real-World Scenario
In a verifiable credential solution, there are three primary actors. We can see how they interact using a sample scenario involving Alice, her employer (Woodgrove Inc.), and a vendor (Proseware):
The Roles
User (Alice)
The person or entity requesting a VC. When Alice needs to provide proof of employment, she grants access to the credential in her Authenticator app by signing a verifiable presentation (VP) with her DID.
Issuer (Woodgrove Inc.)
An organization that creates an issuance solution to verify the user’s identity. The Issuer attests that the proof the user provided is accurate and creates a VC signed with their DID for which the user’s DID is the subject.
Verifier (Proseware)
A company or entity that needs to verify claims from one or more trusted Issuers. The Verifier validates the credential by matching the presentation against the public key placed in the DPKI.
The Scenario Flow
Issuance (Woodgrove to Alice)
Alice (User) requests a proof of employment VC from Woodgrove Inc. (Issuer). Woodgrove validates her existing credentials (e.g., an ID token from her username/password sign-in). Once validated, Woodgrove creates a VC that includes claims about Alice and is signed with Woodgrove’s DID.
Storage (Alice’s Wallet)
Alice accepts this signed VC and stores it securely in her digital wallet application (the Authenticator app).
Presentation (Alice to Proseware)
Alice wants to receive corporate discounts from Proseware (Verifier). She presents the VC to the Proseware site. She must sign a verifiable presentation (VP) with her DID and send it to the Verifier, proving she is the owner of the DID and the credential.
Verification (Proseware)
Proseware trusts that Woodgrove accurately verified its employees’ identities. Proseware uses open standards, such as Self-Issued OpenID Provider (SIOP) and Presentation Exchange, to request the specific VC from Alice. Proseware can use the verifiable credentials service API or SDK, or configure their own Microsoft Entra tenant, to verify the authenticity of the verifiable presentation.
Result
Upon successful verification, Alice qualifies for the discount. The entire transaction is logged in Alice’s wallet application, helping her track where and to whom she presented her proof of employment.
Key Takeaways
Categories
Recent Posts