This chapter covers Microsoft Entra Verified ID, a decentralized identity solution that enables verifiable credential issuance and verification without centralized identity providers. For the SC-900 exam, this topic appears in approximately 5-8% of questions under objective 2.5 (Describe the capabilities of Microsoft Entra). Understanding how Verified ID works, its components (issuer, verifier, holder), and its relation to decentralized identifiers (DIDs) and verifiable credentials (VCs) is essential. This chapter provides a deep dive into the architecture, configuration, and exam-critical details.
Jump to a section
Imagine you need to prove you are a licensed driver to rent a car in a foreign country. You have a physical driver's license issued by your home state's DMV. The rental company doesn't know how to verify your license's authenticity because they don't trust your state's DMV directly. Instead, you visit a notary public who is licensed by the state. The notary checks your license, confirms it's valid by calling the DMV, and then issues a notarized statement that says 'This person is a licensed driver as of today.' The rental company accepts the notary's statement because they trust the notary's authority. In this analogy: You are the 'user' (subject), your driver's license is a 'verifiable credential' (VC) issued by the DMV (issuer), the notary is the 'verifier' who checks the credential, and the notarized statement is a 'verifiable presentation' (VP) that the rental company (relying party) accepts. The key is that the rental company does not need to contact the DMV directly—they trust the notary's verification, which is based on cryptographic proofs, not direct communication. In Microsoft Entra Verified ID, the issuer signs the VC with a decentralized identifier (DID) and a private key. The verifier (like the notary) uses the issuer's public key (resolved from the DID) to cryptographically verify the credential's integrity and issuer authenticity without needing to contact the issuer directly. This is the core mechanism: trust is established via a decentralized public key infrastructure (DPKI) anchored on a blockchain or distributed ledger, not via direct issuer-verifier communication.
What is Microsoft Entra Verified ID?
Microsoft Entra Verified ID is a managed service that allows organizations to issue and verify verifiable credentials (VCs) based on open standards (W3C Decentralized Identifiers and Verifiable Credentials). It is part of the Microsoft Entra portfolio, focusing on decentralized identity. Unlike traditional identity systems where a central authority (like a domain controller or identity provider) asserts identity, Verified ID uses a distributed model where issuers, holders, and verifiers interact without needing a direct trust relationship. The trust is anchored in a decentralized public key infrastructure (DPKI) stored on a blockchain (e.g., ION, a layer 2 network on Bitcoin).
Why Decentralized Identity?
Traditional identity systems suffer from several problems: (1) The identity provider becomes a single point of failure and a high-value target for attackers. (2) Users have little control over their own identity data—the provider owns it. (3) Verifying a credential often requires contacting the issuer directly, which is inefficient and privacy-invasive. Decentralized identity solves these by giving users control over their own identifiers (DIDs) and credentials (VCs), and by enabling cryptographic verification without direct issuer contact.
Core Components
Issuer: An entity (organization, person, or thing) that issues a verifiable credential to a holder. The issuer signs the VC with its private key. Examples: a university issuing a digital diploma, a government issuing a digital driver's license.
Holder: The entity that receives and stores the VC, typically in a digital wallet app (e.g., Microsoft Authenticator). The holder controls the VC and presents it to verifiers.
Verifier: An entity that requests and verifies a VC from a holder. The verifier uses the issuer's public key (from the DID document) to verify the credential's signature and integrity.
Decentralized Identifier (DID): A globally unique identifier that is created and controlled by the entity without a central registry. DIDs are stored on a distributed ledger (like ION) and resolve to DID documents containing public keys and service endpoints.
Verifiable Credential (VC): A tamper-evident set of claims (attributes) signed by the issuer. The VC follows the W3C standard and includes metadata like issuer DID, issuance date, expiration date, and cryptographic proof.
Verifiable Presentation (VP): A bundle of one or more VCs presented by a holder to a verifier. The VP is also signed by the holder to prove control of the DID.
How It Works: Step-by-Step Mechanism
Setup: The issuer creates a DID and registers it on the ION network. This involves generating a key pair and publishing the DID document (containing the public key) to the blockchain.
Issuance: The holder requests a VC from the issuer. The issuer validates the holder's identity (e.g., via existing authentication). The issuer then creates a VC, signs it with its private key, and sends it to the holder's wallet. The wallet stores the VC.
Presentation: The holder wants to prove something to a verifier (e.g., age > 21). The verifier sends a presentation request specifying what claims are needed. The holder creates a VP containing the relevant VC(s) and signs it with their own private key (to prove control of the DID). The VP is sent to the verifier.
Verification: The verifier receives the VP. It extracts the issuer's DID from the VC, resolves the DID document from the ION network, obtains the issuer's public key, and verifies the VC's signature. It also checks the holder's signature on the VP. If both signatures are valid and the VC is not expired or revoked, the verifier accepts the proof.
Key Technical Details
ION (Identity Overlay Network): A Layer 2 network on top of Bitcoin that provides a decentralized DID registry. ION uses the Bitcoin blockchain to anchor DID operations, but does not store full DID documents on-chain (to save space and cost). Instead, it uses a sidechain and IPFS (InterPlanetary File System) for content storage. ION is permissionless and does not require a central authority.
DID Document: A JSON-LD document that contains public keys, authentication methods, and service endpoints. Example structure:
{
"@context": ["https://www.w3.org/ns/did/v1"],
"id": "did:ion:EiDf...",
"verificationMethod": [{
"id": "did:ion:EiDf...#key-1",
"type": "EcdsaSecp256k1VerificationKey2019",
"controller": "did:ion:EiDf...",
"publicKeyJwk": {
"kty": "EC",
"crv": "secp256k1",
"x": "...",
"y": "..."
}
}],
"authentication": ["did:ion:EiDf...#key-1"]
}Verifiable Credential Schema: The VC structure includes @context, type, credentialSubject, issuer, issuanceDate, expirationDate, and proof. The proof is a JSON Web Signature (JWS) that ensures tamper evidence.
Revocation: VCs can be revoked by the issuer using a revocation registry (e.g., a Bitstring Status List). The verifier checks the registry during verification. If the VC's index is set to revoked, verification fails.
Authentication vs. Verification: In Verified ID, the holder authenticates to the verifier by proving control of their DID (via signing the VP). This is different from traditional authentication (username/password). The verifier does not need to know the holder's identity; they only need to verify the claims.
Configuration in Microsoft Entra
To use Verified ID, an organization must: 1. Create a Verified ID service in the Azure portal. 2. Register a DID for the organization (e.g., using the Microsoft Entra admin center). 3. Define credential schemas (e.g., "Employee Credential"). 4. Issue VCs to users via the Verified ID issuance API. 5. Configure verification policies for verifier applications.
The issuance and verification flows use REST APIs. Example issuance request:
POST https://verifiedid.did.msidentity.com/v1.0/verifiableCredentials/createIssuanceRequest
Content-Type: application/json
{
"authority": "did:ion:Ei...",
"registration": {
"clientName": "Contoso University"
},
"callback": {
"url": "https://contoso.com/api/callback",
"state": "abc123",
"headers": {
"api-key": "my-api-key"
}
},
"type": "VerifiedEmployee",
"manifest": "https://beta.did.msidentity.com/v1.0/abc/manifest"
}Integration with Other Entra Services
Microsoft Entra ID (Azure AD): Verified ID can be used to issue VCs that attest to directory attributes (e.g., employee ID, department). This bridges traditional identity with decentralized identity.
Microsoft Entra Permissions Management: Not directly related, but Verified ID can be used for decentralized authorization claims.
Microsoft Entra External ID: Verified ID can enable self-sovereign identity for external users (e.g., customers) without requiring them to create accounts.
Exam-Critical Details
The SC-900 exam focuses on the *concept* and *benefits* of Verified ID, not deep technical configuration. Understand the roles (issuer, holder, verifier), the use of DIDs, and how trust is established without a central authority.
Know that Verified ID uses open standards (W3C) and that ION is the underlying decentralized network (based on Bitcoin).
Be aware that Verified ID is part of Microsoft Entra, not a separate product.
Common exam scenario: A company wants to issue digital badges to employees that can be verified by third parties without contacting the company. Verified ID enables this.
Trap Patterns
Wrong answer: "Verified ID requires a central identity provider like Azure AD." Reality: It is decentralized; no central provider is needed for verification, though Azure AD can be used as an issuer.
Wrong answer: "Verifiable credentials are stored in Azure AD." Reality: They are stored in the holder's wallet (e.g., Microsoft Authenticator).
Wrong answer: "The verifier must contact the issuer to verify the credential." Reality: Verification is done cryptographically using the issuer's public key from the DID document.
Wrong answer: "DIDs are stored in Azure AD." Reality: DIDs are stored on a decentralized ledger (ION).
Summary of Key Values
DID method: did:ion
Blockchain: Bitcoin (via ION)
Signature algorithm: ECDSA with secp256k1 curve (for ION)
VC format: W3C Verifiable Credential (JSON-LD)
Wallet: Microsoft Authenticator (or any compatible wallet)
Revocation: Bitstring Status List (W3C standard)
Issuer creates DID and key pair
The issuer generates a new DID using the `did:ion` method. This involves creating a key pair (private and public key) using the ECDSA algorithm (secp256k1 curve). The issuer then constructs a DID document containing the public key and other metadata. This document is anchored to the ION network by submitting a create operation to an ION node. The operation is batched and eventually written to the Bitcoin blockchain as a small transaction. The DID becomes resolvable globally. The issuer retains the private key securely, typically in Azure Key Vault.
Holder requests a verifiable credential
The holder (user) initiates a request for a VC, usually by scanning a QR code or clicking a link from the issuer's app or website. The request includes the holder's DID (generated by their wallet app, e.g., Microsoft Authenticator). The issuer receives the request and validates the holder's identity through existing means (e.g., Azure AD authentication, email verification). Once validated, the issuer creates a VC object conforming to the W3C standard. The VC includes the holder's DID as the subject, claims (e.g., name, email), issuance date, expiration date, and the issuer's DID.
Issuer signs and sends VC to holder
The issuer signs the VC using its private key, producing a JSON Web Signature (JWS) that is embedded in the `proof` field of the VC. The signed VC is then sent to the holder's wallet via a secure channel (e.g., HTTPS). The wallet stores the VC locally and may display it to the user. The holder now has a tamper-evident credential that can be presented to any verifier.
Verifier sends presentation request
A verifier (e.g., a website requiring age verification) sends a presentation request to the holder. This request specifies the type of VC required, the claims needed, and optionally a domain binding (to prevent replay attacks). The request is typically delivered via a QR code or a deep link. The holder's wallet parses the request and prompts the user to consent to sharing the required claims.
Holder creates and sends verifiable presentation
The holder's wallet constructs a verifiable presentation (VP) containing the requested VC(s). The VP is signed by the holder using their private key to prove control of their DID. The VP is sent to the verifier's endpoint (e.g., a REST API). The VP includes the original VC and the holder's proof.
Verifier resolves issuer's DID and verifies signatures
The verifier extracts the issuer's DID from the VC in the VP. The verifier resolves the DID document from the ION network (via an ION node or a DID resolver). From the DID document, the verifier obtains the issuer's public key. The verifier then cryptographically verifies the VC's signature using that public key. It also verifies the holder's signature on the VP using the holder's public key (which can be obtained from the holder's DID, if known, or from the VP itself if the holder includes their DID). If both signatures are valid and the VC has not expired or been revoked, the verifier accepts the claims.
Enterprise Scenario 1: Digital Employee Badges
A large multinational corporation wants to issue digital employee badges that can be verified by external partners (e.g., building access for visitors). Instead of creating a federated trust relationship with each partner, the company uses Microsoft Entra Verified ID. The company acts as the issuer, creating a "Verified Employee" credential schema. Employees use Microsoft Authenticator to receive their badge (VC). When an employee visits a partner site, they scan a QR code at the entrance. The partner's verification system requests a VC proving employment. The employee's wallet creates a VP and sends it. The partner's system verifies the VC signature using the company's DID (resolved from ION). No direct communication with the company's Azure AD is needed. This scales to thousands of partners without per-partner configuration.
Enterprise Scenario 2: University Digital Diplomas
A university wants to issue tamper-proof digital diplomas that graduates can share with employers. The university registers a DID and issues VCs containing degree information. Graduates store the diploma VC in their wallet. When applying for a job, the graduate presents the VC to the employer's HR system. The employer's system verifies the diploma's authenticity by checking the university's DID on ION. This eliminates diploma fraud and reduces verification time from weeks (calling the registrar) to seconds. The university can revoke diplomas if needed (e.g., for disciplinary reasons) via the revocation registry.
Common Pitfalls in Production
DID resolution failures: If the ION node used for resolution is unavailable, verification fails. Organizations should run their own ION node or use a reliable resolver service.
Key management: If the issuer's private key is lost or compromised, all VCs issued with that key become untrustworthy. Using Azure Key Vault with HSM-backed keys is recommended.
Revocation latency: Revocation updates may take minutes to propagate through the ION network. For time-sensitive scenarios (e.g., terminated employee access), additional revocation mechanisms (like short-lived VCs) should be considered.
User onboarding friction: Users must install a compatible wallet and understand how to use it. For enterprise scenarios, pre-provisioning wallets via MDM can help.
What SC-900 Tests on Verified ID
SC-900 objective 2.5 (Describe the capabilities of Microsoft Entra) includes a sub-objective on "Microsoft Entra Verified ID." The exam expects you to:
Understand the concept of decentralized identity and verifiable credentials.
Identify the roles: issuer, holder, verifier.
Know that DIDs are used and that they are anchored on a decentralized system (ION/Bitcoin).
Recognize that Verified ID is part of Microsoft Entra.
Understand that verification does not require contacting the issuer.
Common Wrong Answers and Why Candidates Choose Them
"Verified ID stores credentials in Azure AD." Candidates confuse Verified ID with traditional identity stores. Reality: Credentials are stored in the user's wallet.
"The verifier must contact the issuer to check validity." This is how traditional verification works (e.g., credit card authorization). But Verified ID uses cryptographic verification, so no direct contact is needed.
"DIDs are managed by Microsoft." DIDs are decentralized; Microsoft does not control them. The ION network is permissionless.
"Verified ID replaces Azure AD." It complements Azure AD; it does not replace it. Azure AD can be used as an issuer.
Specific Numbers, Values, and Terms That Appear on the Exam
ION: The decentralized network used (based on Bitcoin).
W3C: The standards body for DIDs and VCs.
Microsoft Authenticator: The primary wallet app for holders.
Verifiable Credential (VC) and Verifiable Presentation (VP).
Decentralized Identifier (DID).
Edge Cases and Exceptions
Revoked credentials: If a VC is revoked, verification fails even if the signature is valid. The verifier must check the revocation registry.
Expired credentials: VCs have an expiration date; expired VCs are invalid.
Holder DID rotation: If the holder changes their DID, existing VCs referencing the old DID may become unverifiable unless the holder updates them.
How to Eliminate Wrong Answers
If an answer says "centralized" or "requires a central authority," it is likely wrong for Verified ID.
If an answer says "stored in the cloud" (Azure AD), it is wrong; they are stored in the wallet.
If an answer says "the verifier calls the issuer," it is wrong.
Look for keywords: "decentralized," "cryptographic verification," "user-controlled."
Microsoft Entra Verified ID enables decentralized identity using W3C standards for DIDs and VCs.
The three roles are issuer, holder, and verifier.
Trust is established cryptographically via DIDs resolved from the ION network (based on Bitcoin).
Verifiable credentials are stored in the holder's wallet (e.g., Microsoft Authenticator), not in Azure AD.
Verification does not require contacting the issuer; the verifier uses the issuer's public key from the DID document.
Revocation is handled via a Bitstring Status List; expired or revoked VCs are invalid.
ION is a Layer 2 network on Bitcoin; it is permissionless and decentralized.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Entra Verified ID
Decentralized: trust is established via DIDs and cryptographic proofs on a blockchain (ION).
No central identity provider required for verification; verifier resolves issuer's DID.
User controls their own identity data; credentials stored in user's wallet.
Open standards: W3C DIDs and Verifiable Credentials.
Privacy-preserving: verifier only gets the claims they request, not the user's full identity.
Azure AD (Traditional Identity)
Centralized: trust is established via a central authority (Azure AD tenant).
Verifier must trust Azure AD or use federation; direct communication with Azure AD often needed.
Identity data is stored and managed by the organization in Azure AD.
Proprietary protocols (e.g., SAML, OAuth) with Microsoft extensions.
Verifier often receives tokens containing user attributes; potential for over-sharing.
Mistake
Verifiable credentials are stored in Azure Active Directory.
Correct
Verifiable credentials are stored in the holder's digital wallet (e.g., Microsoft Authenticator). Azure AD can act as an issuer but does not store the credentials after issuance.
Mistake
The verifier must contact the issuer to verify a credential.
Correct
Verification is done cryptographically by resolving the issuer's DID document from the ION network and using the public key to verify the credential's signature. No direct communication with the issuer is needed.
Mistake
Decentralized identifiers (DIDs) are managed by Microsoft.
Correct
DIDs are created and controlled by the entity (issuer or holder). They are registered on a decentralized network (ION) and are not owned or managed by Microsoft.
Mistake
Microsoft Entra Verified ID replaces Azure AD.
Correct
Verified ID complements Azure AD. They serve different purposes: Azure AD is a centralized identity provider, while Verified ID enables decentralized identity. They can be used together (e.g., Azure AD as an issuer).
Mistake
Verifiable credentials are only for users, not devices or services.
Correct
Verifiable credentials can be issued to any entity that has a DID, including devices, services, and organizations. The W3C standard defines a credential subject as any entity.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A verifiable credential (VC) is a set of claims signed by an issuer (e.g., a digital diploma). A verifiable presentation (VP) is a package that a holder creates to present one or more VCs to a verifier. The VP is signed by the holder to prove control of their DID. In short: VC is the raw credential; VP is the holder's presentation of that credential to a verifier.
Yes, but indirectly. Verified ID uses the ION network, which is a Layer 2 network anchored on the Bitcoin blockchain. The DID documents are stored on IPFS and anchored to Bitcoin via ION operations. This provides a decentralized, tamper-evident registry without storing full documents on-chain.
Yes. While Verified ID is part of Microsoft Entra, it does not require Azure AD for its core functionality. The issuer can be any entity (e.g., a university) that registers a DID and issues VCs. However, the Verified ID service in Azure provides management tools for creating DIDs, credential schemas, and APIs.
Revocation is typically done using a Bitstring Status List, a W3C standard. The issuer maintains a list of credential indices, and each VC includes a reference to this list. When verifying, the verifier checks the list to see if the credential's index is marked as revoked. The list is updated by the issuer and published to a public endpoint.
The holder's DID is used to identify the holder and to prove control of the VC. When the holder creates a VP, they sign it with their private key, which corresponds to their DID. The verifier can then verify the holder's signature using the holder's public key from their DID document. This ensures that only the rightful holder can present the VC.
No, it is a paid service. Pricing is based on the number of verifiable credentials issued and verified. However, for SC-900 exam purposes, you only need to know the concept and features, not pricing details.
If the ION network is unavailable, DID resolution may fail, preventing verification. However, verifiers can cache DID documents to mitigate this. In practice, ION is designed to be highly available, but temporary outages can occur. Microsoft recommends using multiple ION nodes or a resolver service.
You've just covered Microsoft Entra Verified ID — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?