From ION to did:web: The Seven-Year Compromise Behind Microsoft Entra Verified ID

1. One Trust System#

In May 2019, the Microsoft Identity Division opened a corporate blog post with this sentence:

"We believe every person needs a decentralized, digital identity they own and control, backed by self-owned identifiers that enable secure, privacy preserving interactions." ^[1]

In December 2023, a one-line entry in the Microsoft Entra Verified ID changelog read:

"The option of selecting did:ion as a trust system is removed. The only trust system available is did:web." ^[2]

Both sentences are Microsoft. Both are about identity. Both are about decentralization. Both are official. They are six years apart and they contradict each other.

This article is the story of what happened in between, and what it tells us about the gap between any decentralized-identity vision and any decentralized-identity product that actually ships. It is not a Microsoft product tour, and it is not a polemic. It is an analysis of which trade-offs the seven-year journey made and why each trade-off was reasonable at the time it was made.

By the end you will know three things: what was promised in 2019, what is actually shipping in May 2026, and what may yet change under the EU's 24 December 2026 wallet deadline ^[3]. Each of those three answers turns on a single architectural decision that the rest of the story will keep coming back to: where the trust root sits.

To see how Microsoft got from one sentence to the other, we have to start two decades earlier, before there was a "decentralized identity" movement to join.

2. Cameron's Long Shadow: Microsoft's 20-Year Identity Detour#

Microsoft did not arrive at decentralized identity in 2019. It arrived for the second time.

The first arrival was in May 2005, when Kim Cameron, then identity architect at Microsoft, published The Laws of Identity on his personal weblog ^[4]. The seven laws read like an early draft of every self-sovereign identity manifesto that would follow: User Control and Consent; Minimal Disclosure for a Constrained Use; Justifiable Parties; Directed Identity; Pluralism of Operators and Technologies; Human Integration; Consistent Experience Across Contexts.

"Technical identity systems MUST only reveal information identifying a user with the user's consent." -- Kim Cameron, The Laws of Identity, First Law ^[4]

Cameron's first product expression was CardSpace, Microsoft's user-controlled "information card" selector that shipped with Windows Vista. It died in February 2011 ^[6]. The cause of death was not cryptographic. CardSpace was Windows-only at a moment the web was going mobile. It sat on top of WS-* protocols at a moment the industry was migrating to JSON over HTTP. And it asked relying parties to integrate a new identity layer in the same year Sign-in-with-Facebook and Sign-in-with-Google were eating the relying-party adoption budget.

Two ideas survived the wreckage: the user as the holder of their own credentials, and Cameron's seven Laws as a recurring design checklist.

Five years after CardSpace was discontinued, the movement rebooted in public. In April 2016 Christopher Allen, a co-author of the IETF Transport Layer Security (TLS) Security Standard ^[9], published The Path to Self-Sovereign Identity ^[5]. The essay named the four eras of online identity (centralized, federated, user-centric, self-sovereign), gave the new model the name that stuck, and offered ten SSI principles drawn line by line from Cameron's Laws.

The Decentralized Identity Foundation (DIF) was organized in 2017 as a project of the Joint Development Foundation, with Microsoft as a founding member ^[10]; the Joint Development Foundation itself joined the Linux Foundation at the end of 2018.

Microsoft committed in writing on 12 February 2018, in a strategy post by Ankur Patel naming four building blocks the company would invest in: decentralized identifiers, verifiable credentials, identity hubs for off-chain personal data, and a universal resolver for any DID method ^[11]. Fifteen months later, in May 2019, Alex Simons and Daniel Buchner turned that strategy into an architectural commitment: Microsoft would invest in a Bitcoin-anchored Layer-2 network it called ION, built on the DIF Sidetree protocol, and presented as a way to scale decentralized identifier writes to the rate of public adoption ^[1].

By 2019 Microsoft had committed to the architecture in writing. It had not yet committed any production code. The next question was what trust root the new system would use, and that answer would change three times in the seven years that followed.

flowchart LR
A["2005 Cameron publishes Laws of Identity"] --> B["2006 CardSpace ships with Vista"]
B --> C["2011 CardSpace discontinued"]
C --> D["2016 Allen names SSI"]
D --> E["2017 DIF founded"]
E --> F["2018 Patel strategy post"]
F --> G["2019 Simons and Buchner announce ION"]
G --> H["2022 Entra Verified ID GA"]

3. The Federation Stack and the SSI Premise#

To understand why anyone thought SSI was a successor architecture, picture the most boring identity flow you have: signing into a third-party app with your work email.

The OpenID Connect (OIDC) protocol that almost every modern federation flow speaks works by having your employer's identity provider (the IdP) mint a short-lived signed ID Token, audience-scoped to one specific relying party (RP), the moment you log in ^[12]. The RP redirects you to the IdP, the IdP authenticates you, the IdP returns a JWT addressed only to that RP, and the RP verifies the IdP's signature against a JSON Web Key Set the IdP publishes at a well-known URL. SAML and WS-Federation differ in syntax but not in shape.

Federation works. It is what every meaningful enterprise login uses today. It is also engineered around three structural choices that the SSI movement called out as compromises:

1. The IdP is online at verification time. Each RP-IdP pair re-runs the dance. The IdP knows every login: where, when, to whom. That is a powerful surveillance vantage and a single point of compromise.
2. The user never holds the credential. You cannot take a Microsoft-issued "employed at Microsoft" assertion and show it to a relying party your employer did not pre-integrate. The IdP authorizes each RP, not the user.
3. There is no story for selective claim disclosure. An OIDC ID Token reveals every claim in the audience-specific payload to that RP. There is no engineering hook for "prove you are over 18 without revealing your birthdate."

The structural answer the SSI movement proposed is simple to state. If the user could hold a signed assertion that any verifier could check against the issuer's public key, without the issuer being online during verification, all three complaints dissolve. The credential becomes a portable object the user carries from verifier to verifier. The issuer's role collapses to a one-time signing event plus a way to publish a public key and a revocation status. The verifier's role collapses to fetching that key and checking the signature.

That observation is the entire intellectual content of the Verifiable Credentials movement, and the W3C Verifiable Credentials Data Model 1.0 (19 November 2019) is its first standardised expression ^[13]. The standard explicitly permits two on-the-wire encodings of the same abstract data model: a JSON-LD document with a Data Integrity proof, and a JSON Web Token signed under JWS. Microsoft would later pick the second of those two encodings, and the choice would matter more than the standard's authors anticipated.

VCs solve the user-as-holder problem, but only if the verifier has some way to resolve the issuer's public key when the issuer is not online. That addressing problem is what DIDs are for, and choosing the DID method is where every decentralized-identity vendor's architecture begins.

flowchart LR
subgraph Fed["Federation (OIDC, SAML)"]
UF[User] -->|"1. login"| IdP[Identity Provider]
IdP -->|"2. ID Token, RP-scoped"| RP[Relying Party]
IdP -.->|"online during every verification"| RP
end
subgraph VC["VC model"]
Iss[Issuer] -->|"1. issue VC (once)"| Holder[Holder Wallet]
Holder -->|"2. present VC"| Ver[Verifier]
Ver -.->|"3. resolve issuer public key out-of-band"| DID[DID Resolution]
end

4. Five Generations of Verified Identity#

Five generations of architecture lead to the product Microsoft ships today. Two of them belonged to Microsoft. The middle one was Microsoft's most ambitious bet, and the one Microsoft retired first.

G1: The Whitepaper Era (2018-2019)#

Patel's February 2018 strategy post named the four building blocks (DIDs, Verifiable Credentials, Identity Hubs, Universal DID Resolver) but committed to no concrete trust root ^[11]. Fifteen months later the trust root arrived, named, in the Simons and Buchner blog post: a Layer-2 network on Bitcoin called ION, built on the DIF Sidetree protocol ^[1]. The original 2019 design target was "tens of thousands of operations per second" on the public mainnet. There was no production code yet, only a public-preview wallet (Microsoft Authenticator) and a public commitment to ship.

G2: ION Mainnet (2020-2021)#

The June 2020 ION beta gave way to the v1 mainnet launch on 25 March 2021 ^[16]. Buchner's announcement post on the Microsoft Identity Standards blog framed it as the moment "decentralized identifiers, anchored on Bitcoin via Sidetree" became real infrastructure ^[17].

The DIF ION project page documents the demonstrated capacity as "thousands of DID operations per second across the network" with a strongly eventually consistent model ^[18]. The earlier "tens of thousands" figure had been the 2019 design target, not the demonstrated mainnet capacity, and the public liftoff post itself recorded the "thousands of operations per second" figure once mainnet was live ^[19].

Microsoft Authenticator served as the preview holder wallet; an ION operator ran a public node; Bitcoin transaction fees and IPFS pinning paid the operational cost of the trustless anchoring story. The ION repository on GitHub remains live as a DIF project ^[20].

G3: Entra Verified ID GA (2022)#

Fourteen months after launching ION on Bitcoin, Microsoft made two architecturally decisive choices that did not look decisive at the time.

On 14 June 2022, an entry in the Verified ID whats-new changelog added did:web as a supported trust system alongside did:ion ^[2]. On 8 August 2022, the product went generally available under the new Entra brand ^[21].

The second decisive choice was the credential format. The W3C VC Data Model permits both JSON-LD with Data Integrity Proofs and JSON Web Tokens; Microsoft picked JWT-VC, an artifact signed end-to-end under JWS ^[22]. Both choices were small in the changelog and load-bearing for the pivot that followed.

G4: The Pivot (2023-2024)#

The product's first marquee deployment landed on 12 April 2023: LinkedIn's Workplace Verification feature, built on Entra Verified ID, launched with "more than 70 organizations representing millions of LinkedIn members, including companies like Accenture, Avanade, and Microsoft" ^[24].

Eight months later, in December 2023, the changelog carried the sentence the entire seven-year arc had been building toward: "The option of selecting did:ion as a trust system is removed. The only trust system available is did:web." ^[2].

In early 2024, Microsoft's public ION node was wound down. No primary Microsoft source pins a specific day, so the conservative wording is "early 2024" with the December 2023 admin-portal removal as the milestone the official record actually attests.

G5: The Buildout (2024-2026) and the EUDI Forcing Function#

Quick Setup, which auto-provisions a did:web DID for a tenant, went GA in April 2024. Face Check, an Azure AI face-matching add-on, went GA on 12 August 2024. did:web:path (supporting per-tenant DID paths under one host) opened on request in September 2024 ^[2]. On the standards side, OpenID for Verifiable Presentations 1.0 was approved as a Final Specification in July 2025 ^{[25] [26]}, and OpenID for Verifiable Credential Issuance 1.0 followed in September 2025 ^{[27] [28]}. Account recovery with Verified ID reached GA in May 2026; the legacy secp256k1 signing algorithm is scheduled for retirement on 1 July 2026 ^[2].

Meanwhile, on 20 May 2024, Regulation (EU) 2024/1183 (eIDAS 2) entered into force, setting a 24-month deadline for every Member State to provision at least one European Digital Identity Wallet, and an 18-month follow-on for mandatory private-sector acceptance ^[3]. The EUDI Architecture and Reference Framework, currently at v2.9 (May 2026), mandates SD-JWT VC and ISO/IEC 18013-5 mdoc as the two baseline credential formats ^{[29] [30]}. Neither is currently issued by Entra Verified ID.

Two generations are in production today. One is the one Microsoft ships. The other is the one the EU is preparing to mandate. They do not yet agree on a credential format. That gap is the central open question of the article's last third.

flowchart LR
G1["G1 (2018-2019) Whitepaper four blocks: DIDs, VCs, hubs, resolver"] -->|"add Bitcoin anchoring"| G2["G2 (2020-2021) ION mainnet Sidetree on Bitcoin"]
G2 -->|"add did:web, JWT-VC; brand as Entra"| G3["G3 (Aug 2022) Entra Verified ID GA"]
G3 -->|"remove did:ion (Dec 2023)"| G4["G4 (2024-2026) did:web-only Entra"]
G4 -->|"open: add SD-JWT VC + mdoc?"| G5["G5 EUDI-aligned (TBD by Dec 2026)"]

5. The Breakthrough: Why did:web Was the Pivot#

The decisive sentence in the entire Entra Verified ID story is not in a press release. It is in the Introduction of a W3C Community Group draft:

"DIDs that target a distributed ledger face significant practical challenges in bootstrapping enough meaningful trusted data around identities to incentivize mass adoption. We propose a new DID method using a web domain's existing reputation." ^[31]

That is the W3C did:web Method Specification arguing, in its own opening paragraph, that the trust-bootstrapping problem ledger-anchored DIDs were designed to solve is the same problem that prevents ledger-anchored DIDs from being adopted at scale. The proposed alternative reuses something the world already has: DNS plus the X.509 certificate-authority system.

What did:web actually does#

A did:web:example.com resolves, by the algorithm in the spec, to https://example.com/.well-known/did.json. The file is a plain JSON DID Document containing the subject's public keys and service endpoints. A did:web:example.com:tenants:acme resolves to https://example.com/tenants/acme/did.json. That is the whole resolution algorithm. There is no ledger to query, no Sidetree batch to replay, no anchor transaction to wait for, no IPFS pin to refresh.

// Convert a did:web identifier into the URL where its DID document lives.
function didWebToUrl(did) {
if (!did.startsWith('did:web:')) throw new Error('not a did:web');
const methodSpecific = did.slice('did:web:'.length);
// Split on ':' (path separator). Percent-decode each segment.
const parts = methodSpecific.split(':').map(decodeURIComponent);
const host = parts[0];
const pathSegments = parts.slice(1);
if (pathSegments.length === 0) {
  return 'https://' + host + '/.well-known/did.json';
}
return 'https://' + host + '/' + pathSegments.join('/') + '/did.json';
}

console.log(didWebToUrl('did:web:example.com'));
// https://example.com/.well-known/did.json
console.log(didWebToUrl('did:web:example.com:tenants:acme'));
// https://example.com/tenants/acme/did.json
console.log(didWebToUrl('did:web:port-example.com%3A8443:tenants:acme'));
// https://port-example.com:8443/tenants/acme/did.json

Why this collapsed ION's complexity#

Walk through the ION costs that disappear. No Bitcoin full node to run. No IPFS pinning service to maintain. No Sidetree daemon batching CRUD operations. No per-batch on-chain fee. No 60-minute eventual-consistency window before a key rotation propagates. No public-node retirement risk. Key rotation is a JSON file edit; resolution is one HTTPS GET. Microsoft Learn now describes its production identifier system in exactly those terms: "Microsoft currently supports the did:web trust system. The did:web trust system is a permission-based model that allows trust using a web domain's existing reputation." ^[32].

Why every enterprise issuer already had everything did:web requires#

This is the moment to state the load-bearing argument of the whole article plainly. Enterprise issuers, banks, universities, hospitals, government agencies, and employers already own DNS names. They already pay for X.509 certificates. They already have publicly known organisational identities tied to those names. They have published HR-system endpoints, OAuth issuers, and JWKS URLs on those names for years. The trustless permissionless discovery story that ION solved is a story about new issuers showing up without prior reputational anchors. The customers who actually wrote cheques for Entra Verified ID are exactly the population whose reputational anchor was already on DNS.

Enterprise issuers never needed permissionless issuer discovery. They already had publicly known organisational identities anchored to DNS and the certificate-authority system. ION solved a problem this population did not have, while imposing operational costs (full-node operation, IPFS pinning, anchoring fees, eventual-consistency latency) that this population did have. did:web did not lose to ION on cryptography; it won on operational fit.

The honest concession#

did:web is "decentralized" only in the loose sense that there is no central registry of issuers. The trust sits squarely on DNS plus the certificate-authority system. If your registrar suspends your domain, your DID document is unreachable. If a certificate authority mis-issues for your domain, an attacker can stand up a competing DID document at the same identifier.

The W3C did:web spec's Security and Privacy Considerations name this inheritance directly: all DNS security considerations apply, and all TLS security considerations apply ^[31]. SSI purists consider this a concession that empties the SSI label of meaning. They are not wrong to make that argument; they are choosing a different definition of "decentralized" than the operational one that won.

Binding the DID back to the domain#

There is one extra step did:web needs at the application layer that ION did not. The DID Document at https://example.com/.well-known/did.json is served by the domain owner; nothing inside the JSON, by itself, proves that the domain owner is the same entity as the DID subject. The DIF Well-Known DID Configuration document closes that loop with a signed JSON file at https://example.com/.well-known/did-configuration.json containing one or more domain-linkage credentials issued by the DID and asserting "I, this DID, claim this domain" ^[33]. Verifiers fetch both files, check the linkage, and accept the binding.

flowchart TD
subgraph ION["ION resolution (G2, retired)"]
I1[Verifier wants issuer key] --> I2[Query ION node]
I2 --> I3[Read Bitcoin anchor txn]
I3 --> I4[Fetch Sidetree batch from IPFS]
I4 --> I5[Replay operation history]
I5 --> I6[Reconstruct DID Document]
end
subgraph WEB["did:web resolution (G4, current)"]
W1[Verifier wants issuer key] --> W2["HTTPS GET /.well-known/did.json"]
W2 --> W3[Parse JSON, read public key]
end

Two production deployments shipped on this architecture. LinkedIn Workplace Verification runs at the scale of hundreds of millions of LinkedIn profiles ^[24]. The NHS Digital Staff Passport ran on it across a four-Trust pilot, after migrating from a Sovrin-anchored architecture to did:web ^[34].

A third, smaller deployment proved out the same stack for higher education: RMIT University engaged Condatis and Microsoft on a Proof of Value covering digital student cards, training-certificate issuance, and alumni-transcript verification on Entra Verified ID ^[35]. Neither of the production-scale deployments would have shipped on ION; all three shipped on did:web. The next question is what those deployments are doing under the hood.

6. The Stack Microsoft Ships in May 2026#

The "supported standards" table on Microsoft Learn is the most honest single document Microsoft publishes about Verified ID. It lists exactly what ships and is silent on everything else ^[36]. Walking it row by row, in the order the wire flow uses each layer, gives the cleanest possible picture of the May 2026 product.

Identifier#

did:web only, with did:web:path available on request since September 2024 ^[2]. did:ion is gone. did:key and did:jwk are not listed as trust systems. The Microsoft Resolver is scoped to did:web ^[32].

Data model#

W3C VC Data Model v1.1 (3 March 2022) ^[23]. Microsoft Entra Verified ID has not yet adopted v2.0, which became a W3C Recommendation on 15 May 2025 ^[37]. The one-version lag is documented and small in scope; v1.1 remains in widespread production use industry-wide.

Credential format#

JWT-VC: a JSON payload signed under JWS (RFC 7515 ^[22]), encoded according to section 6.3.1 of the VC Data Model v1.1 ^[23]. JSON-LD Data Integrity Proofs are absent from Microsoft's supported-standards table. The fairest framing is that this is a documented omission rather than a public rejection; the consequence (no JSON-LD-native context handling, no canonicalisation step, no semantic web integration) is the same in either case.

Issuance protocol#

OpenID for Verifiable Credential Issuance (OpenID4VCI). Microsoft Learn currently references Implementer Draft 11 of the specification ^[36]; the Final 1.0 was approved by the OpenID Foundation in September 2025 ^[27], with the spec itself at ^[28]. Final 1.0 is closely compatible with Draft 11 in the wire shape but tightens several optionalities.

Presentation protocol#

OpenID for Verifiable Presentations 1.0, Final, July 2025 ^{[25] [26]}. The verifier sends the wallet a presentation_definition (using DIF Presentation Exchange semantics) and receives back a Verifiable Presentation containing one or more credentials.

User-authentication leg#

Self-Issued OpenID Provider v2 (SIOPv2), the OpenID-Connect-style layer that authenticates the holder to the verifier inside the OpenID4VP flow ^[38].

Query language#

DIF Presentation Exchange v2.0.0, ratified 3 November 2022 ^[39]. The verifier expresses what it wants ("a VC of type WorkplaceCredential issued by an issuer in this list"); the wallet returns a presentation submission mapping its held credentials onto the request.

Domain binding#

DIF Well-Known DID Configuration, as described in section 5 ^[33]. The verifier downloads the issuer's /.well-known/did-configuration.json and confirms the bidirectional binding between the DID and the DNS host.

Revocation#

W3C VC Status List 2021. Microsoft Learn currently references the Working Draft WD-vc-status-list-20230427; W3C has since published the Bitstring Status List Recommendation as the canonical evolution of the same bitstring revocation construction ^[40]. Microsoft has not migrated to the Recommendation URL; the underlying mechanism is the same compressed bitstring construction in both.

Algorithms#

ES256K (secp256k1, legacy, scheduled for deprecation 1 July 2026 ^[2]), EdDSA, and ES256 (P-256, the default for credentials created after February 2024). All three are JWS algorithm identifiers; there are no algorithm choices outside the JOSE family.

Holder wallet#

Microsoft Authenticator on iOS and Android. There is no third-party wallet support at GA ^[32].

Premium add-on#

Face Check, an Azure AI face-matching service that scores a live selfie against a photo claim on the credential, available as a premium add-on. Face Check went GA on 12 August 2024 ^{[2] [41]}.

What is NOT in the table#

The list of items Microsoft Learn does not list as supported is short and worth stating out loud: SD-JWT VC; BBS signatures; ISO/IEC 18013-5 mdoc; JSON-LD Data Integrity Proofs; selective disclosure of any kind; third-party wallets.

// Pseudocode for the verifier's job. A real implementation uses a JOSE library.
async function verifyJwtVc(jwtVc) {
const [headerB64, payloadB64, sigB64] = jwtVc.split('.');
const header = JSON.parse(atob(headerB64));
const payload = JSON.parse(atob(payloadB64));
// 1. Pull the issuer DID from the VC payload.
const issuerDid = payload.iss || payload.vc.issuer;
// 2. Resolve did:web to a URL and fetch the DID document.
const url = didWebToUrl(issuerDid);
const didDoc = await fetch(url).then((r) => r.json());
// 3. Find the verification method whose id matches the JWS kid.
const vm = didDoc.verificationMethod.find((m) => m.id === header.kid);
const jwk = vm.publicKeyJwk;
// 4. Verify the JWS signature over header.payload using the JWK.
const ok = await joseVerify(headerB64 + '.' + payloadB64, sigB64, jwk);
// 5. Check the status list entry to confirm the VC is not revoked.
if (payload.vc.credentialStatus) await checkStatusList(payload.vc.credentialStatus);
return ok;
}

The verifier needs a JOSE library and an HTTPS client. That is the whole moving-parts inventory. The simplicity is precisely what won.

sequenceDiagram
participant Iss as Issuer Backend
participant Auth as Microsoft Authenticator
participant Ver as Verifier
participant DNS as Issuer did:web host
Iss->>Auth: OpenID4VCI credential offer
Auth->>Iss: redeem code, request credential
Iss->>Auth: signed JWT-VC
Note over Auth: wallet stores VC
Ver->>Auth: OpenID4VP presentation_definition
Auth->>Ver: VP JWT containing VC
Ver->>DNS: HTTPS GET /.well-known/did.json
DNS->>Ver: DID Document with issuer JWK
Ver->>Ver: verify VC signature, check status list
Ver->>Auth: accept or reject

7. The Other Wallets Microsoft Has to Live With#

Microsoft Entra Verified ID is not the only wallet a relying party in 2026 has to think about. There are four competing stacks, each with a different theory of where the trust root sits, and each of them is shipping in production today.

M-B: The EUDI Wallet (European Union)#

The EU's European Digital Identity Wallet is a regulatory product, not a single vendor's product. Regulation (EU) 2024/1183 (eIDAS 2) requires every Member State to provision at least one wallet within 24 months of the relevant implementing acts entering into force, and to lift mandatory private-sector acceptance to all regulated relying parties 18 months after that ^[3].

The EUDI Architecture and Reference Framework, currently published as v2.9 (May 2026), mandates two baseline credential formats: SD-JWT VC (a draft IETF profile on top of the SD-JWT primitive, RFC 9901 ^{[42] [43]}) and ISO/IEC 18013-5 mobile documents (mdoc) ^{[44] [29] [30]}. BBS-style unlinkable signatures are listed as optional and future.

The trust-list machinery is set out in Commission Implementing Regulation (EU) 2025/849, which requires each Member State to publish its list of certified wallet solutions in machine-readable form for inclusion in a consolidated EU list ^[47]. Four EU-funded Large-Scale Pilots are exercising the architecture: POTENTIAL (general public services), DC4EU (digital credentials for education), EWC (cross-border wallet interop), and NOBID (Nordic-Baltic payments) ^{[48] [49] [50]}.

M-C: Apple Wallet ID-in-Wallet and Google Wallet Digital ID#

The two consumer mobile-OS wallets converge on ISO/IEC 18013-5 mdoc as the credential format and X.509 IACA (Issuing Authority Certificate Authority) trust chains as the trust root ^[44]. In-person presentation uses the QR-plus-BLE handover defined by ISO/IEC 18013-5; the new online-presentation profile is defined by ISO/IEC TS 18013-7, with an AAMVA Special Alert published on the October 2024 release ^{[45] [46]}.

In North America, the AAMVA Digital Trust Service (DTS) operates the public-key trust list for state-issued mDLs ^{[51] [52]}. The California DMV's TruAge consumer feature, built on SpruceID, is the visible North American example of an mDL-in-wallet age-verification flow ^[53]. The Secure Technology Alliance maintains a public tracker of mDL implementation status state by state ^[54]. Inclusion in Apple Wallet or Google Wallet is platform-mediated.

M-D: Hyperledger Aries and AnonCreds#

The SSI-purist lineage is alive and shipping, just not at Microsoft. AnonCreds v1.0 is the current canonical specification, hosted at the AnonCreds Working Group's GitHub Pages site after the move from Hyperledger to LF Decentralized Trust ^[55]. The cryptographic core is documented in the Khovratovich, Lodder, and Parra Ursa AnonCreds paper ^[56].

The credential is issued under a Camenisch-Lysyanskaya or BBS-style signature. Presentations use a zero-knowledge proof that re-randomises the signature, delivering unlinkability across presentations as a theorem rather than as a best-effort engineering claim. DIDComm v2 is the transport, offering a peer-to-peer messaging substrate that does not depend on HTTPS redirects ^[57]. Type-3 cryptographic accumulators handle revocation at scale without leaking the holder's identity to the issuer.

The trade-offs are presentation latency in the tens to low hundreds of milliseconds, proof sizes in the kilobytes, and a smaller pool of conformant verifier implementations than the OpenID4VP world has.

M-E: Third-party multi-format vendors#

Mattr, SpruceID, and Trinsic each ship issuers and verifiers that handle multiple formats (SD-JWT VC, JWT-VC, ISO mdoc, BBS-VC) over the same OpenID4VP transport.

Mattr powers the New Zealand Department of Internal Affairs' NZ Verify product, which checks ISO 18013-5 mobile driver licences from 18 US states, Puerto Rico, and Queensland ^[58]. SpruceID's Success Stories list names the California DMV, the Utah Department of Government Operations, and the U.S. Department of Homeland Security as headline deployments ^[59], with the DHS Silicon Valley Innovation Program write-up at ^[60]. Trinsic announced a February 2026 partnership with IDEMIA Public Security to accept mDLs across New York, Arkansas, Iowa, West Virginia, and Kentucky ^{[61] [62]}.

These vendors are the parties who, if Microsoft does not add SD-JWT VC or mdoc issuance to Entra Verified ID, will fill the EUDI-interop gap for Microsoft-tenant relying parties.

Four stacks, four trust roots, four credential formats. The technical layer is converging on OpenID4VP. The format layer is fragmenting. The trust-framework layer (which issuers are authoritative for which credentials in which jurisdiction) is still wide open.

8. The Theoretical Limits of Atomic JWT-VC#

There are three things JWT-VC cannot do that the original 2019 vision said the new architecture would do. None of the three is a bug. All three are theorems about the format.

Concession 1: No selective disclosure#

A JWS computes a signature over a fixed payload ^[22]. To verify, the verifier reconstructs the exact bytes that were signed, recomputes the signature, and compares. If even one bit of the payload changes, verification fails. That property is what makes the JWS authentic; it is also what makes selective disclosure impossible inside a JWT-VC. You reveal every claim, or none.

The two production-ready ways to escape this constraint each pick a different cryptographic trick. SD-JWT VC keeps the signature whole but replaces each disclosable claim in the signed payload with a salted SHA-256 hash; the verifier receives the salt-value pairs only for the claims the holder chooses to disclose, and recomputes the hashes to confirm they appear in the signed payload ^{[42] [43]}. BBS signatures go further: the holder can re-randomise the signature itself at presentation time and prove knowledge of a signature on a subset of messages without ever revealing the original signature ^[63].

Both routes change the on-the-wire format. Neither is reachable from inside JWT-VC. Microsoft's "no selective disclosure today" is therefore a format-migration decision, not a cryptographic engineering decision. The Anonymous Credentials companion article treats the mathematical structure of the three families (hash-disclosure, CL signatures, BBS signatures) in depth.

Concession 2: Linkability across presentations#

The same JWT-VC presented to two different verifiers produces two bit-identical signed payloads. The signature itself is a global correlator: any pair of verifiers who collude can match the two presentations to the same holder credential, and a single verifier who sees the holder's presentation twice can match the holder across the two events. SD-JWT VC and mdoc both inherit this property; only signature schemes that re-randomise at presentation time defeat it.

The escape route is a positive construction, not an impossibility result. The Camenisch and Lysyanskaya 2004 paper on signatures from bilinear maps ^[64] showed how to build anonymous credentials that dodge the constraint: each presentation is a fresh zero-knowledge proof of knowledge of a signature, not a transcript of the signature itself. The CL family (and its BBS descendant) costs presentation latency in the tens to low hundreds of milliseconds and a verifier that needs more than a JOSE library. The payoff is that unlinkability becomes a theorem of the protocol rather than a line in a privacy policy.

Concession 3: DNS as the trust root#

did:web inherits DNS and the X.509 certificate-authority system as its security base. A registrar suspension can erase any issuer's DID; a certificate-authority mis-issuance can let an attacker publish a competing DID document at the same identifier; a DNS cache poisoning can redirect resolution. The W3C did:web Security and Privacy Considerations state this inheritance directly, naming DNS and TLS as the load-bearing layers ^[31]. SSI advocates point to this as the single largest concession compared to a ledger-anchored trust root, and they have a point: the two cannot be combined inside one DID document.

"DNS presents many of the attack vectors that enable active security and privacy attacks on the did:web method and it's important that implementors address these concerns via proper configuration of DNS." -- W3C did:web Method Specification, DNS Security Considerations ^[31]

The three things JWT-VC cannot do (selective disclosure, unlinkability, ledger-anchored trust) are not bugs in Microsoft's implementation. They are theorems about the format. Any vendor who picked JWT-VC inherited the same three concessions. The gap between the 2019 promise and the 2026 product is a fixed-format trade-off, not a Microsoft engineering shortfall.

Two of the three concessions can be fixed in the format layer. SD-JWT VC and BBS exist. The third cannot be fixed without a ledger anchor or an alternative trust root, and the operational case for that alternative is the one ION lost. The question for the EUDI roadmap is whether Microsoft will adopt the format-layer fixes, and whether the third concession is one Microsoft now considers a feature of the operational model rather than a cost.

9. Open Problems and the EUDI Deadline#

On 24 December 2026, every EU Member State must have provisioned at least one European Digital Identity Wallet. Eighteen months later, on 6 December 2027, every regulated private-sector relying party in the EU must accept presentations from those wallets ^[3]. Microsoft Entra Verified ID currently issues neither of the two credential formats the EUDI ARF mandates.

That single regulatory clock is the spine of every open problem the product faces. There are five.

1. Will Microsoft add SD-JWT VC and ISO mdoc issuance to Entra Verified ID?#

The "supported standards" page on Microsoft Learn, refreshed in March 2026, lists JWT-VC and is silent on SD-JWT VC and mdoc ^[36]. The "what is new" changelog through May 2026 records no roadmap commitment to add either format ^[2].

Microsoft staff participate in the OpenID Foundation's Digital Credentials Protocols Working Group and in the IETF OAuth Working Group. The standards bridge that would make the integration least painful (the OpenID for Verifiable Credentials High-Assurance Interoperability Profile, HAIP 1.0-02, published January 2025 ^[65]) is published and stable. Microsoft has not publicly signalled it will adopt HAIP. This is the article's load-bearing open question.

2. Will Microsoft Authenticator open up to third-party wallets?#

The EUDI ARF assumes wallet pluralism: any conformant wallet on any platform can present credentials to any conformant verifier ^[29]. OpenID4VP is wallet-agnostic by design ^[26]. The Microsoft Verified ID Request Service currently accepts presentations only from Microsoft Authenticator ^[32]. No public commitment to support third-party wallets has been located in the Microsoft Learn whats-new archive ^[2]. The Condatis-built OIDC bridge that the NHS Digital Staff Passport pilot used to talk to other wallets is the only documented production workaround ^[34], and the NHS pilot itself was retired in December 2025 ^[66].

3. Selective disclosure inside the current format#

Any verifier scenario that needs partial-claim disclosure (age-over-18 verification without a birthdate, role-scoped credentials without an employee ID) has two workarounds under the current Entra Verified ID stack: issue multiple narrow credentials per role (operational blowup; one VC per claim subset), or wait for SD-JWT VC support. The cryptographic question is also the format-layer question: SD-JWT VC delivers selective disclosure but not unlinkability, BBS delivers both ^[63], and the AnonCreds family already ships both today ^[55]. No single ship-now option gives both inside the JOSE stack.

4. Revocation at nation-state scale#

W3C VC Status List 2021, in either its Working Draft or its Bitstring Status List Recommendation form, is a bitstring-compressed revocation register that scales comfortably to roughly $10^6$ credentials per list ^[40]. EU Member-State Person ID populations are $10^7$ or $10^8$ individuals.

Type-3 cryptographic accumulators (the construction documented in the Ursa AnonCreds paper) are the only known scalable revocation mechanism that preserves holder privacy ^{[56] [55]}. No W3C, IETF, or ISO accumulator-revocation specification has reached working-group final status as of May 2026. The arithmetic suggests that any vendor planning national-scale issuance will need to either shard the bitstring or adopt an accumulator scheme that does not yet have a standardised wire format.

5. Cross-jurisdictional trust frameworks#

The EUDI Trust List (per CIR 2025/849 ^{[47] [30]}), the AAMVA Digital Trust Service ^{[51] [52]}, the UK Digital Identity and Attributes Trust Framework ^[67], and Microsoft's per-tenant issuer trust list each define their own issuer registries; on the survey above, none of the four specifications publishes a cross-framework interoperability bridge at the trust-framework layer as of May 2026. The DIF Trust Establishment Working Group specification carries an "Editor's Draft" status header ^[68] and the IETF SPICE Working Group charter does not commit to a final-spec date ^[69]; neither venue has yet published a convergence timeline. Until then, a verifier in 2026 has to maintain a different trust list per jurisdiction.

gantt
title EUDI Wallet vs Entra Verified ID format readiness
dateFormat YYYY-MM-DD
axisFormat %Y-%m
section eIDAS 2 regulation
Entry into force         :milestone, m1, 2024-05-20, 1d
Member State wallet provisioning deadline :milestone, m2, 2026-12-24, 1d
Mandatory private-sector acceptance       :milestone, m3, 2027-12-06, 1d
section Entra Verified ID format
JWT-VC GA (no SD-JWT VC, no mdoc) :a1, 2022-08-08, 2025-12-31
Open: SD-JWT VC + mdoc issuance?  :crit, a2, 2026-01-01, 2027-12-06

The architecture of Entra Verified ID has changed twice already. Whether the EUDI deadline forces a third change toward SD-JWT VC and mdoc issuance and third-party wallet support, or whether Microsoft chooses to interoperate only as a verifier (consuming EUDI credentials it does not itself issue), is the open question that defines the next two years of the product.

10. How to Issue and Verify a Credential Today#

For all the architectural drama, the day-to-day developer experience is small. The Microsoft Learn quickstart can take a tenant from "no Verified ID configured" to "first issued VC" in about ten minutes, and the working code that an enterprise verifier needs is short enough to fit on one screen.

Tenant setup#

Quick Setup, GA since April 2024, is a single admin-portal button that provisions a did:web DID, generates a P-256 signing key, publishes https://<tenant-host>/.well-known/did.json, and posts the DIF Well-Known DID Configuration document that binds the DID back to the host ^{[2] [33]}. The fallback for hosts the tenant administers itself is to publish the same two JSON files at the same well-known paths; the resolution algorithm is the one shown in section 5.

Defining a credential type#

Each Verifiable Credential type is described by two JSON files in the Verified ID admin portal: a displayContract that controls how the credential renders in Microsoft Authenticator, and a rulesFile that lists the claim names, their types, and how they are sourced from the issuer's identity provider. The claim set is opaque JSON, not a JSON-LD @context graph; the JWT-VC encoding will keep the claims as flat top-level fields inside the vc.credentialSubject object.

Issuance API#

The issuer backend calls POST /verifiableCredentials/createIssuanceRequest on the Verified ID Request Service. The response carries an OpenID4VCI credential offer URL the wallet can consume, plus a short numeric PIN the user enters in Authenticator to confirm they are the same person who started the flow on the issuer's web page ^[28]. The signing of the JWT-VC itself happens inside Microsoft's service; the issuer's signing key never leaves the tenant's HSM-backed key vault.

Presentation API#

The verifier backend calls POST /verifiableCredentials/createPresentationRequest with a presentation_definition describing which credentials to ask for (DIF Presentation Exchange v2.0.0 ^[39]) and an idTokenHint describing who the verifier expects on the other side of the wallet. The response is an OpenID4VP request URI rendered as a QR code (cross-device) or a deep link (same-device); Authenticator handles the rest and returns a Verifiable Presentation containing the requested credentials, signed and bound to the verifier's challenge ^[26].

// Skeleton of the JSON payload an enterprise verifier sends to the
// Verified ID Request Service. The service returns an OpenID4VP request URI.
const presentationRequest = {
authority: 'did:web:verifier.contoso.com',
callback: {
  url: 'https://verifier.contoso.com/api/vc/presentation-callback',
  state: 'corr-id-12345',
  headers: { 'api-key': process.env.VC_CALLBACK_API_KEY },
},
registration: { clientName: 'Contoso Hiring Portal' },
includeQRCode: true,
requestedCredentials: [
  {
    type: 'WorkplaceCredential',
    purpose: 'Confirm employment',
    acceptedIssuers: [
      'did:web:verifications.linkedin.com',
      'did:web:hr.contoso-supplier.com',
    ],
    configuration: { validation: { allowRevoked: false, validateLinkedDomain: true } },
  },
],
};

// POST presentationRequest to:
// https://verifiedid.did.msidentity.com/v1.0/verifiableCredentials/createPresentationRequest

Cost and rate-limit considerations#

Microsoft Learn states that "there are no special licensing requirements to issue verifiable credentials" ^[70]. Face Check is documented as a premium feature that requires either a Microsoft Entra Suite licence or an explicit Face Check Add-on linked to an Azure subscription ^[41]. The Verified ID Quick Setup tutorial documents a per-tenant default of two requests per second for combined issuance and verification ^[71]; high-volume issuers should design backoff into the call sites. The LinkedIn Workplace Verification deployment, with its 70-plus founding organizations and millions of LinkedIn members on the holder side, is the worked end-to-end example of what the architecture can sustain in production ^[24].

flowchart LR
Iss[Issuer or Verifier Backend] -- "createIssuanceRequest / createPresentationRequest" --> VRS[Verified ID Request Service]
VRS -- "QR code or deep link" --> Auth[Microsoft Authenticator]
Auth -- "issuance response or VP" --> VRS
VRS -- "callback with VC or VP" --> Iss
VRS -- "optional Face Check call" --> Face[Azure AI Face Check]

The simplicity of this developer experience is the strongest practical evidence that the architectural decisions of 2022 through 2024 were correct. The same simplicity is the constraint that makes the EUDI second pivot architecturally awkward, because doing it "as a developer convenience" is exactly what Microsoft has spent four years optimising for.

11. Frequently Asked Questions#

12. Reading the Pattern#

Three quiet pivots define the seven-year arc. In June 2022, Microsoft added did:web to the supported-trust-system list alongside did:ion ^[2]. In December 2023, Microsoft removed did:ion and left did:web as the only option ^[2]. A third pivot is pending: whether the EUDI Wallet deadline of 24 December 2026 ^[3] forces Microsoft to add SD-JWT VC and ISO mdoc issuance to Entra Verified ID, or whether the product holds the current trade-offs and limits itself to verifier-only interop on the EUDI side.

Each pivot traded an SSI-vision property for an operational property. Permissionless ledger anchoring traded for one HTTPS GET. JSON-LD elegance traded for JOSE ubiquity. Selective disclosure (still pending) may yet trade for cross-jurisdictional regulatory acceptance.

The product team kept the original vocabulary in the marketing copy while the architecture moved underneath it. That is not unique to Microsoft. It is how every long-running platform engineering effort looks from outside the building. The interesting question is which of the original properties the engineering team eventually defended, and which they let go.

What ships in May 2026 is not the 2019 vision. It is also not a betrayal of the vision. It is the part of the vision that an enterprise identity team has so far been able to defend in front of a quarterly engineering review against a finite operations budget.

The two are different things, and they have always been different things. Reading the Entra Verified ID story as a chronicle of failure misses the point; reading it as a chronicle of unconstrained success also misses the point. The honest reading is that decentralized identity, as it exists in production at Microsoft scale, is the intersection of what the 2019 manifesto wanted, what the 2023 customer pipeline would pay for, and what the 2024 standards stack could ship without a research project.

Whether the EUDI deadline forces the third pivot (toward SD-JWT VC, ISO mdoc, and wallet pluralism) or did:web plus JWT-VC plus Microsoft Authenticator turns out to be the local maximum at which decentralized identity actually shipped at scale, is the question the next two years will answer. Both outcomes preserve the workforce-verification use case the product was built for. Only one preserves Microsoft's relevance to consumer and national-identity issuance.

The seven-year arc of Microsoft Entra Verified ID is not a story of an architecture that failed. It is a story of an architecture that was systematically downgraded to whatever the next quarter's engineering review would actually approve, with the original vision serving as a north star the team has kept reorienting toward as the operational constraints came into focus.

May 2019: "We believe every person needs a decentralized, digital identity they own and control, backed by self-owned identifiers that enable secure, privacy preserving interactions." ^[1]

December 2023: "The option of selecting did:ion as a trust system is removed. The only trust system available is did:web." ^[2]

Both sentences are true. Both are official Microsoft. Reading them as a sequence rather than as a contradiction is what understanding Entra Verified ID actually means.