Parag Mali - tag: zero-knowledge-proofs

The Age Gate That Doesn't Know Your Age: How Anonymous Credentials Finally Crossed the Deployment Chasm

noreply@paragmali.com (Parag Mali) — Wed, 20 May 2026 00:00:00 GMT

Anonymous credentials -- cryptographic schemes that prove a claim about a person without revealing identity -- spent forty years in academic papers and have, in the last eighteen months, crossed the deployment chasm. The Privacy Pass family (IETF RFCs 9576, 9577, and 9578, all June 2024) now serves anti-abuse attestation at internet scale across Cloudflare, Apple, Google Chrome, and Microsoft Edge. For multi-attribute credentials, four schemes are racing for the EUDI Wallet and mDL slot -- BBS, SD-JWT (RFC 9901, November 2025), the ISO/IEC 18013-5 mdoc baseline, and Google's open-sourced Longfellow-zk SNARK-over-ECDSA library -- with the EU age-verification app, announced "technically ready" on 15 April 2026, the first population-scale test. Revocation under unlinkability, post-quantum security, and cross-platform interop remain unsolved.

1. A Press Conference, Forty-One Years Late

On 15 April 2026, Ursula von der Leyen stood at a Commission lectern in Brussels and announced that the European Union's age-verification app was "technically ready." The app, she said, is "completely anonymous, works on any device, and is fully open source"[@ec-2026-age-app].

Forty-one years earlier, in October 1985, a Berkeley cryptographer named David Chaum had described the same idea in Communications of the ACM: a system in which a citizen could prove a fact about themselves -- over eighteen, holds a driver's licence, has paid the toll -- without revealing who they are, and without two presentations of that proof being linkable to each other[@chaum-1985-doi].

For four decades Chaum's framing lived almost entirely in cryptography conferences. In the last eighteen months it has shipped into every major browser, into IETF Standards-Track RFCs, into Google's open-source zero-knowledge library, and -- if Brussels delivers on its 24 December 2026 deadline -- into roughly 450 million European pockets[@eidas2].

Two days after the Commission press conference, the Johns Hopkins cryptographer Matthew Green published Part 2 of his Anonymous Credentials: An Illustrated Primer, an unusual two-part deep-technical exposition aimed at engineers. Part 1, published 2 March 2026, lays out the formal Issuer / User / Resource model and the unlinkability requirement[@green-2026-part1]. Green's framing in Part 2 has since become the field's working summary: Privacy Pass, the IETF anti-abuse token scheme deployed by Cloudflare and Apple and shipped into Chrome and Edge, "is the most widely-deployed anonymous credential standard in the world"[@green-2026-part2].

Privacy Pass... is the most widely-deployed anonymous credential standard in the world. -- Matthew Green, *Anonymous Credentials: An Illustrated Primer (Part 2)*, 17 April 2026

Three layers of the stack shipped at different times for different reasons.

At the hardware layer, the Trusted Computing Group first specified Direct Anonymous Attestation in the TPM 1.2 Main Specification in 2005 using an RSA-based construction (Brickell-Camenisch-Chen) -- the first anonymous credential primitive ever burned into commodity silicon -- and re-defined it in elliptic-curve form (ECDAA) in the TPM 2.0 Library Specification in October 2014[@tpm-2-spec][@daa-2004-doi]. It sat largely dormant because the algorithm is optional and consumer-TPM vendors did not enable it.

At the network layer, Cloudflare engineers in 2017 took an academic primitive called a verifiable oblivious pseudorandom function and built a one-bit anonymous token that proves a client solved a CAPTCHA. That scheme became Privacy Pass, became three IETF RFCs in June 2024, and now sits behind Apple's Private Access Tokens, Chrome's Private State Tokens, and Cloudflare's anti-abuse pipeline[@rfc9576][@rfc9577][@rfc9578].

At the application layer, four multi-attribute credential schemes are racing for the European Digital Identity Wallet and mobile driving licence slot, with the EU age-verification app as the first population-scale test case. The contenders are BBS pairing signatures, SD-JWT, the ISO/IEC 18013-5 mdoc baseline, and Google's Longfellow-zk -- a SNARK that proves "I know an ECDSA signature on a credential that says I am over eighteen" without revealing the signature or any other attribute[@google-2025-zkp-blog].

Why did the deployment take so long? What finally broke the pattern? And what can the cryptography still not do? To understand any of that, start with the person who first described the problem.

2. The Move That Started Everything

In 1982, David Chaum was a doctoral candidate at Berkeley looking at the emerging computerised payment system and seeing something that disturbed him: a dossier-building machine. Account-based authentication, the model that banks were quietly digitising, left a stable identifier on every transaction. The merchant knew who you were. The bank knew what you bought. The state, given a court order or a National Security Letter, knew both. Chaum's contribution to the 1982 CRYPTO proceedings, and then to Communications of the ACM three years later, was the first formal way out.

The 1982 paper introduced a primitive called the blind signature -- a signature scheme in which the signer signs a message they cannot read.

A signature scheme in which the signer produces a signature on a message it never directly sees, by virtue of the user multiplicatively masking the message with a blinding factor before requesting the signature. After the signer signs the masked value, the user un-blinds the result and is left with a valid signature on the original message -- but the signer cannot link the issued signature to its signing act.

The RSA construction is the easiest one to picture. The signer holds the standard RSA key pair $(N, e, d)$. The user wants a signature on a message $m$ but does not want the signer to learn $m$.

The user picks a random blinding factor $r$, computes the blinded message $m' = m \cdot r^e \bmod N$, and sends $m'$ to the signer. The signer, who sees only a uniformly random element of $\mathbb{Z}_N^*$, signs as usual: $s' = (m')^d \bmod N$. The user un-blinds by dividing out the blinding factor: $s = s' \cdot r^{-1} \bmod N$.

Because $(m \cdot r^e)^d = m^d \cdot r$, what comes out is $s = m^d \bmod N$, a valid RSA signature on the original $m$. The signer held a valid signature in their hand for an instant -- and cannot match it to any later appearance.

sequenceDiagram participant User participant Signer User->>User: pick random r, compute m' = m · r^e mod N User->>Signer: send blinded message m' Signer->>Signer: sign s' = (m')^d mod N Signer->>User: return s' User->>User: unblind s = s' · r^(-1) mod N User->>User: hold valid signature s = m^d mod N on m

That single move is the cryptographic kernel of every anonymous credential system since. Privacy Pass token type 0x0002 in RFC 9578 is Chaum's blind RSA signature with a 2048-bit modulus and an RSA-PSS padding wrapper; the RFC's text explicitly credits "Chaum83"[@rfc9474][@rfc9578]. The construction is forty-four years old and is on the wire today.

In 1985 Chaum extended the framing from payments to a general theory in his Comm. ACM paper "Security without Identification: Transaction Systems to Make Big Brother Obsolete"[@chaum-1985-doi]. The manifesto's claim is the one Brussels was making in 2026: a citizen should be able to prove a transaction-relevant fact (over eighteen, holds a licence, has paid) without revealing identity, and without two presentations being linkable to each other. The article uses the term anonymous credential in the modern sense.

A cryptographic credential that lets a holder prove a fact about themselves -- for example, "I am over 18" or "I am licensed to drive" -- without revealing identity, and without two presentations of the same credential being linkable to each other across verifiers (or, in stronger formulations, even across the issuer and a colluding verifier).

There are two things to notice about this framing in 1985.

First, it is forty years early. The post-GDPR, post-Snowden privacy concerns the credential model implicitly addresses had no political constituency in 1985. The deployments Chaum was writing about -- electronic payments, toll roads, public-transit cards -- mostly did not exist yet. The standards bodies that would eventually publish RFCs on this topic had not been formed.

Second, a bare blind signature is not yet a credential system. A blind signature signs a single opaque message. To prove "I am over 18" without revealing my date of birth, you need a way to sign multiple attributes -- name, date of birth, licence class, expiration -- separately, then prove a predicate over the bundle ("the date-of-birth field, whatever it is, satisfies birth_year < 2008") without disclosing the field itself. A naked blind RSA signature on a single value cannot do that. The field would spend the next sixteen years trying to solve the multi-attribute version of the same problem.

Chaum's own attempt to commercialise the payment variant was DigiCash, founded by Chaum in 1989 and bankrupt by 1998[@wiki-digicash].The cryptography of DigiCash worked. ING discussed a partnership; Deutsche Bank licensed the technology; both declined to launch consumer-scale deployments[@wiki-digicash]. What did not exist was a merchant network. DigiCash's tokens were redeemable at only a few hundred merchants worldwide at the company's peak (about 300, with roughly 5,000 users by 1998)[@wiki-digicash]. It is the canonical "right cryptography, wrong substrate" failure -- the first one in this story, but not the last.

Chaum had named the problem. The field would now spend two decades trying to extend the primitive to a full multi-attribute credential system, and would quietly fail to ship anything outside research code.

3. The Multi-Attribute Decades

Between 1993 and 2014, the academic literature produced two complete family trees of multi-attribute anonymous credential schemes, each of them correct cryptography, neither of them deploying at scale. The drumbeat of these two decades is a single sentence: the math worked, and nobody used it.

Brands and the Wallet-with-Observer

Stefan Brands, working in Amsterdam and later at Microsoft Research, gave the CRYPTO '93 paper that defined a deployment architecture twenty-five years too early[@brands-1993-doi]. His scheme combined a restrictive blind signature with what he called a "wallet with observer" -- a tamper-resistant chip that holds a per-user secret, plus a host computer that runs the privacy-preserving protocol around it. The chip's job is to prevent the user from double-spending or copying credentials; the host's job is to compute the unlinkable presentation. Double-spending mathematically reveals the user's identity (a feature, not a bug).

Note: Brands' 1993 architecture -- a tamper-resistant chip that holds a per-user secret, plus a host that computes the privacy-respecting transformation -- is structurally identical to the EUDI Wallet's secure-element-plus-on-device-prover architecture in 2026. The chip is the observer, the host is the wallet. The architecture was right; the hardware -- a programmable secure element with attestation, present in every smartphone -- was decades late.

Brands founded Credentica in the early 2000s to commercialise the construction; Microsoft acquired Credentica on 6 March 2008 and renamed the technology U-Prove[@wiki-brands][@microsoft-uprove]. Microsoft folded U-Prove into the CardSpace identity selector, then announced on 15 February 2011 that CardSpace 2.0 would not ship[@wiki-cardspace]. The Microsoft Research project page still documents U-Prove as of 2026, but no Microsoft product ships it[@microsoft-uprove]. It is the second canonical "right cryptography, no relying-party demand" deployment death.

The lowercase "a" in abhi shelat's name -- the Northeastern professor who, with Matteo Frigo, designs Longfellow-zk in Section 5 -- is intentional and consistent across his publications.

Camenisch-Lysyanskaya and the CL Signature Family

In 2001, Jan Camenisch and Anna Lysyanskaya at IBM Zurich gave the first practical and provably-secure multi-show anonymous credential system at EUROCRYPT[@cl2001-doi]. CL signatures use a Strong-RSA assumption to sign a committed vector of messages; the holder then proves possession of the signature in zero knowledge using a Sigma protocol. The construction anchored the field's pedagogy for the next decade. Two properties matter here.

The property that a credential holder can reveal an arbitrary subset of the attributes on the credential while keeping the rest hidden, with a cryptographic proof that the revealed subset is consistent with the issuer's signature on the full credential. The property that two or more presentations of the same credential -- by the same holder, to the same verifier or to colluding verifiers -- cannot be cryptographically linked to each other. The holder can present the credential many times, and each presentation looks fresh.

CL signatures gave both properties. IBM built a production-quality library on top called Idemix and open-sourced it in the early 2010s[@idemix-ibm].The exact open-source release date is folk-knowledge-ambiguous. The IBM Zurich identity-mixer project page (still live as of 2026 and now serving as Hyperledger Fabric Idemix documentation) confirms the project but does not pin the release year. Multiple secondary sources say "around 2010"; no canonical IBM press release survived. Idemix is the ancestor of every "self-sovereign identity" deployment today; the Hyperledger AnonCreds specification is its direct production descendant[@anoncreds-spec].

Why didn't Idemix deploy at internet scale? Two reasons that the field would meet again and again. Per-presentation proofs were kilobyte-scale and the Sigma-protocol verification was substantially slower than ECDSA on 2010 hardware -- the PoPETs 2018 Privacy Pass paper later wrote that prior CL-based approaches "require an order of magnitude more computational resources than our protocol"[@popets-2018]. And, more importantly than either: no browser parsed a CL credential, no website asked for one, no operating system surfaced a credential picker UI. The cryptography was twenty years ahead of the relying-party layer it needed to ride.

DAA: A Credential System on Every TPM (Almost)

In 2004, Ernie Brickell, Jan Camenisch, and Liqun Chen adapted a CL-family scheme into something a Trusted Platform Module could compute, calling it Direct Anonymous Attestation[@daa-2004-doi]. DAA targeted TPM 1.2 chips (shipped from 2005)[@daa-2004-doi]. When the TCG redrew the TPM 2.0 Library Specification in October 2014, they re-defined the scheme in elliptic-curve form -- ECDAA on pairing-friendly curves -- and folded it into the spec as an optional algorithm[@tpm-2-spec].

A TPM-deployable anonymous-credential primitive (Brickell, Camenisch, and Chen, 2004) that lets a TPM prove it is a genuine TPM certified by its manufacturer without revealing which specific TPM. ECDAA, the elliptic-curve form, is standardised in the TPM 2.0 Library Specification (TCG, October 2014) as an *optional* algorithm.

The hardware-root anonymous credential genuinely shipped. By 2026, every PC sold in the last several years carries a TPM 2.0[@tpm-2-spec] capable of running ECDAA[@daa-2004-doi] -- Microsoft has required a TPM 2.0 on every Windows 11 device since October 2021[@win11-tpm-req], putting billions of chips in the field (see the corpus TPM in Windows post for the deployment-scale figure). In practice almost none of them do.

The TCG made ECDAA optional, and the major consumer-TPM vendors mostly did not enable it. Intel's firmware TPM, AMD's fTPM, the Infineon, STMicroelectronics, and Nuvoton discrete TPMs in the retail channel -- the relying-party-side software simply does not issue DAA challenges, so the TPM-side implementation is dead code at best and absent at worst. WebAuthn, which lets a browser identify a device with consent and trades anonymity for usability, became the deployed device-attestation protocol because it has a relying-party-side consumption story. The pre-existing post in this corpus on DAA gives the long-form treatment.

BBS: Eighty-Byte Signatures, Nobody to Sign Them

The other family tree starts in 2004 with Boneh, Boyen, and Shacham's Short Group Signatures, the construction now universally called BBS[@bbs-2004-chapter]. BBS uses bilinear pairings on a pairing-friendly elliptic curve -- BLS12-381 in the modern IETF draft -- to produce signatures that are roughly eighty bytes, two orders of magnitude smaller than the CL-RSA equivalent. Au, Susilo, and Mu extended BBS to a multi-message form in 2006 (originally titled Constant-Size Dynamic k-TAA), which is the scheme the W3C Verifiable Credentials community now calls BBS+[@bbs-plus-2006-chapter].

A pairing-based multi-message signature scheme (Au, Susilo, and Mu, 2006) over a pairing-friendly curve, BLS12-381 in the current IETF draft. BBS+ supports zero-knowledge proofs of possession with selective disclosure, achieves multi-show unlinkability, and produces signatures of roughly 80 bytes and proofs of roughly 256 bytes -- the smallest known for any scheme with these properties.

BBS is, by 2026, the cleanest cryptography in the credentials portfolio. The IETF CFRG draft-irtf-cfrg-bbs-signatures-10, dated 8 January 2026 with authors Looker, Kalos, Whitehead, and Lodder, gives an interoperable specification[@bbs-draft-10]. The MATTR and Trinsic stacks ship BBS implementations[@mattr-bbs][@trinsic-id]. The W3C Verifiable Credentials Data Model 2.0 (Recommendation, 15 May 2025) accommodates BBS as a securing mechanism[@w3c-vcdm-2]. None of that translates to mainstream issuer adoption, because no driver's-licence-issuing DMV, no national-ID authority, no banking customer-identification scheme has switched to signing credentials with a pairing on BLS12-381. The infrastructure asks for ECDSA-P-256, what every existing PKI emits.

Every theoretically pure proposal in this twenty-year era assumed the verifier wanted multi-attribute selective disclosure. Every verifier in 2010 just wanted to verify a cookie. The cryptography sat in libraries. The deployment substrate to call it did not exist.

4. Eight Generations, One Pattern

Pull back from the individual papers and the four-decade arc has a clean shape. Each generation produces correct cryptography. Each generation fails to ship at consumer scale, for one of two reasons: the construction needs hardware that does not exist yet, or the construction needs a relying-party-side protocol that does not exist yet. The single generation that broke the pattern in 2017 did so by giving up the multi-attribute ambition entirely.

gantt dateFormat YYYY-MM axisFormat %Y section Foundational primitives Blind signatures (Chaum) :done, ch1, 1982-01, 1985-12 Security without ID (Chaum CACM) :done, ch2, 1985-10, 1990-01 section Multi-attribute (academic) Brands wallets + observers :done, br, 1993-08, 2001-01 CL signatures (Camenisch-Lysyanskaya) :done, cl, 2001-05, 2010-01 BBS short group signatures :done, bbs, 2004-08, 2014-01 BBS+ (Au-Susilo-Mu) :done, bbsp, 2006-08, 2016-01 Microsoft acquires Credentica :done, ms, 2008-03, 2011-01 section Hardware root DAA paper (Brickell-Camenisch-Chen) :done, daa, 2004-10, 2014-10 TPM 2.0 spec with optional ECDAA :done, tpm, 2014-10, 2020-01 section Deployment era Cloudflare ships Privacy Pass extension :done, cf, 2017-11, 2018-06 PoPETs Privacy Pass paper :done, popets, 2018-06, 2020-01 Apple PAT in iOS 16 :done, apat, 2022-06, 2023-01 RFC 9474 RSA Blind Signatures :done, r74, 2023-10, 2024-01 RFC 9497 OPRF :done, r97, 2023-12, 2024-06 eIDAS 2 enters into force :done, eidas, 2024-05, 2024-12 Privacy Pass RFCs 9576-9578 :done, ppppp, 2024-06, 2025-01 section Multi-attribute resurgence Frigo-shelat Longfellow paper :done, lf1, 2024-12, 2025-06 W3C VCDM 2.0 Recommendation :done, vcdm, 2025-05, 2025-11 Google open-sources Longfellow-zk :done, lf2, 2025-07, 2026-04 SD-JWT becomes RFC 9901 :done, sd, 2025-11, 2026-04 Green primer Part 1 :done, g1, 2026-03, 2026-04 EU age app technically ready :done, eu, 2026-04, 2026-12 Green primer Part 2 :done, g2, 2026-04, 2026-05 EUDI Wallet Member-State deadline :crit, mdl, 2026-12, 2027-12

Generation 1 (1982-1985): blind signatures. Chaum's single primitive. Signs one opaque message. No multi-attribute support. DigiCash bankruptcy 1998. The substrate was a merchant network that did not exist.

Generation 2 (1993): Brands' wallet-with-observer. The correct architecture for a tamper-resistant chip plus host computer. Hardware that could play the observer role did not exist; consumer smartphones with secure elements would not arrive until the 2010s. U-Prove acquired by Microsoft 2008; never shipped[@wiki-brands][@microsoft-uprove].

Generation 3 (2001-2010): CL signatures + Idemix. First multi-show unlinkable, selectively-disclosing credentials with provable security. Multi-kilobyte presentation proofs. No browser parsed them. The Davidson et al. PoPETs 2018 paper later wrote that prior CL-based approaches "require an order of magnitude more computational resources than our protocol"[@popets-2018].

Generation 4 (2004-2006): BBS, BBS+. Eighty-byte pairing signatures and 256-byte proofs. Still undeployed at issuer scale in 2026 because no national identity authority has switched its PKI to BLS12-381[@bbs-draft-10].

Generation 5 (2004-2014): DAA / TPM 2.0 ECDAA. Shipped into the spec; mostly not into consumer hardware; never into a browser-side challenge.

Note: The TPM 2.0 Library Specification (TCG, October 2014) defines ECDAA but makes it an optional algorithm. Consumer-TPM vendors mostly do not enable it, and no major operating system or browser issues DAA challenges. The often-repeated claim "DAA shipped on every TPM 2.0 chip" is wrong on two counts -- the algorithm is optional in the spec, and the relying-party-side consumption path was never built[@tpm-2-spec].

Generation 6 (2017-2018): Privacy Pass. Alex Davidson, Ian Goldberg, Nick Sullivan, George Tankersley, and Filippo Valsorda looked at the Cloudflare CAPTCHA crisis -- Tor users especially were being challenged on every Cloudflare-fronted site -- and asked the question the field had refused to ask for fifteen years: what if we just need one bit?[@popets-2018]

Drop selective disclosure. Drop multi-attribute. The credential becomes "this client solved a CAPTCHA." For one bit, you do not need CL or BBS+. You need a verifiable oblivious pseudorandom function, or a blind RSA signature, both of which fit in two group operations. Cloudflare shipped the original browser extension on 9 November 2017[@cloudflare-2017-pp].The 2017 launch date is sometimes given as 24 October, but the surviving canonical post slug is cloudflare-supports-privacy-pass and is dated 2017-11-09. The earlier introducing-privacy-pass URL returns 404 today; Cloudflare's current documentation page links the November date[@cloudflare-pp-docs].

An Oblivious Pseudorandom Function: a two-party protocol that computes $F(k, x)$ where one party knows the key $k$ but learns nothing about the input $x$, and the other party knows $x$ but learns nothing about $k$. The Verifiable variant additionally proves that the same $k$ was used as in a published public key. RFC 9497 standardises OPRF, VOPRF, and POPRF (a partially-oblivious variant) over prime-order groups[@rfc9497]. An IETF Standards-Track protocol family (RFCs 9576, 9577, and 9578, all June 2024) for issuing and redeeming unlinkable one-bit anonymous tokens at internet scale. Deployed in production by Cloudflare, by Apple as Private Access Tokens, by Google Chrome as Private State Tokens, and -- per Matthew Green's April 2026 primer -- by Microsoft Edge[@rfc9576][@rfc9577][@rfc9578][@green-2026-part2].

The IETF threat model that the RFCs eventually codified splits the world into four parties. The client wants a token. The attester decides whether the client deserves one (CAPTCHA solved, device attested, account in good standing). The issuer cryptographically issues the token without learning what the attester learned. The origin -- the website the client wants to access -- redeems the token without learning who the client is. The separation between attester and issuer is what gives Privacy Pass its formal anonymity property; an attacker would need both parties to collude to link a token to the human who earned it.

Generation 7 (2023-2024): IETF standardisation. Privacy Pass moved from a Cloudflare experiment to a Standards-Track protocol in a tight eight-month window. RFC 9474 (RSA Blind Signatures, CFRG, Informational) appeared in October 2023[@rfc9474]. RFC 9497 (OPRF/VOPRF/POPRF, CFRG, Informational) appeared in December 2023[@rfc9497]. The three Privacy Pass RFCs followed in June 2024 -- RFC 9576 (Architecture, Informational)[@rfc9576], RFC 9577 (HTTP Authentication Scheme, Standards Track)[@rfc9577], and RFC 9578 (Issuance Protocols, Standards Track), which defines token type 0x0001 (VOPRF) and token type 0x0002 (Blind RSA) in a public registry[@rfc9578].

Generation 8 (2022-2026): the multi-attribute resurgence. Once Privacy Pass made the issuer-attester-origin abstraction a standardised wire format, the field went back to the multi-attribute problem with a clearer head. By 2026 there is a three-way race for the EUDI Wallet and mobile-driving-licence slot:

SD-JWT VC, the JSON Web Signature plus salted-hash selective-disclosure scheme by Daniel Fett, Kristina Yasuda, and Brian Campbell. Promoted from a long-running IETF draft to RFC 9901 (Standards Track) in November 2025, and the EUDI Wallet Architecture and Reference Framework's mandatory baseline[@rfc9901].
ISO/IEC 18013-5 mdoc baseline, the CBOR-plus-ECDSA mobile driving licence format, published 2021, deployed by US state DMVs in Arizona, Colorado, Georgia, Maryland and others, and adopted as the EUDI Wallet PID co-baseline[@iso-18013-5].
Longfellow-zk, the MPC-in-the-head SNARK by Matteo Frigo and abhi shelat that wraps an existing ECDSA-signed mdoc, posted as IACR ePrint 2024/2010 in December 2024 and open-sourced by Google under Apache-2.0 on 3 July 2025[@google-2025-zkp-blog][@longfellow-repo][@libzk-draft].The Google announcement is dated 3 July 2025, not April 2026. The April 2026 date occasionally seen in press coverage conflates Google's open-sourcing with Matthew Green's April 2026 primer that brought broader engineering attention to it.

The cryptography community had spent fifteen years on selective-disclosure schemes, predicate proofs, and pairing-based protocols meant to fold every credential anyone might want into a single cryptographically clean structure. Cloudflare's deployment team in 2017 said, in effect, *we do not need any of that, we need one bit, and we need it now*. The bit is "did this client solve a CAPTCHA in the last day or so." A VOPRF-issued token is the bit; nothing else has to ship. That constraint relaxation is what crossed the deployment chasm -- and the multi-attribute resurgence of 2022-2026 is happening on top of the wire-format substrate that Privacy Pass established.

The cultural reset matters as much as the cryptography. Before Privacy Pass, the field's working assumption was that an anonymous credential needed to be a general-purpose identity certificate. After Privacy Pass, an anonymous credential can be as narrow as a single bit -- and the multi-attribute schemes return as one more option in a portfolio rather than the only thing that can ship.

In eighteen months -- between June 2024 and April 2026 -- anonymous credentials went from "Cloudflare's anti-abuse experiment" to "shipped in every browser, standardised at IETF, mandated by the EU." How did the field finally crack a problem that had been open for four decades? The answer is not "better cryptography." It is one insight, repeated twice in different decades.

5. The Two Insights That Finally Shipped It

Two breakthroughs, twenty years apart, neither of which was a new cryptographic primitive.

Breakthrough 1: One Bit (2017)

In 2017, the academic problem statement for an anonymous credential read roughly prove a predicate over a multi-attribute signed bundle without revealing any unrelated attribute. That problem, in full generality, demands selective disclosure, predicate proofs, and multi-show unlinkability -- the entire CL and BBS+ machinery. For fifteen years the field had been trying to make that machinery fast enough and small enough to ship inside a browser.

Cloudflare's anti-abuse team was looking at a different problem. The dominant real-world need for anonymous authentication on the web was: prove that a client is human, prove nothing else. Tor users solving a CAPTCHA on every Cloudflare-fronted page wanted that bit redeemable across many subsequent page loads. Privacy-preserving advertising fraud signals wanted that bit. The protocol did not need to express "I am over 18 and a licensed driver in California" -- it needed to express "this client is not a bot." One bit.

For one bit, all of the multi-attribute machinery falls away. A blind RSA signature is exactly one bit of authentication (the signature either verifies or it does not), and the holder gets unlinkability because the issuer cannot match the unblinded token to its signing act. A VOPRF token is the same shape, with the issuer learning nothing about the token's content and only the holder of the input knowing what was authenticated.

Key idea: Two decades of failed anonymous-credential deployment ended not because the cryptography got better, but because the field accepted constraints (one bit per token; multi-kilobyte SNARK proofs) that the elegant multi-attribute schemes had refused. The constraint relaxation was the breakthrough, not the math.

The PoPETs 2018 paper by Davidson, Goldberg, Sullivan, Tankersley, and Valsorda made this explicit[@popets-2018]. Privacy Pass advertises "1-RTT" issuance, sub-millisecond per token, 64-96 bytes on the wire. The construction is so light that Cloudflare's edge could run an issuer in the same datacentre as a CAPTCHA solver and bill the whole flow as latency-equivalent to a single HTTP redirect[@popets-2018][@cloudflare-2017-pp].

Breakthrough 2: Keep the Issuer's ECDSA Key (2024)

The same move happened again, in the same shape, in December 2024.

For multi-attribute credentials, the obvious cryptographic answer was BBS. Eighty-byte signatures, 256-byte proofs, multi-show unlinkability, predicate proofs in progress. Cryptographically clean. The barrier was issuer adoption: every credential issuer in the world signs with ECDSA-P-256 today. Persuading the European Member State driving-licence authorities to switch their PKI to pairings on BLS12-381 is a twenty-seven-jurisdiction infrastructure project, not a software upgrade.

Matteo Frigo and abhi shelat (then both at Northeastern, with Frigo later at Google) accepted a different constraint. Their idea: build a SNARK that proves "I know an ECDSA-P-256 signature, by the DMV's public key, on an mdoc whose age_over_18 element is true," and let the holder hand over only the SNARK proof. The issuer never changes anything. The DMV keeps signing ECDSA mdocs the way it already does. The holder's device runs the SNARK at presentation time[@google-2025-zkp-blog][@libzk-draft].

A proof-system construction (Ishai, Kushilevitz, Ostrovsky, and Sahai, 2007) in which the prover simulates a multi-party computation "in their head" and commits to each party's view; the verifier opens a random subset of views to check consistency. The Ligero variant plus a sumcheck protocol is the proof system that underlies Longfellow-zk and lets it verify an ECDSA signature inside a SNARK at acceptable cost on a 2024 mobile CPU.

The proof system Frigo and shelat picked -- MPC-in-the-head plus sumcheck -- had been sitting in the literature since 2007 (Ishai-Kushilevitz-Ostrovsky-Sahai, STOC[@ikos-2007-dblp][@ikos-doi]) and 2017 (Ligero, Ames-Hazay-Ishai-Venkitasubramaniam, CCS[@ligero-2017-dblp][@ligero-doi]), largely dormant because mobile CPUs were too slow to make it practical for a real signature verification circuit. By 2024, an iPhone 14 or a 2024-era Pixel could produce a Longfellow proof on an mdoc in roughly 1.2 seconds, with a proof size of roughly 30 KB on the wire[@google-2025-zkp-blog][@longfellow-docs]. Not pretty. Two orders of magnitude bigger than a BBS proof. But the issuer's PKI does not move an inch.

The protocol step is worth unpacking. The prover wants to convince a verifier that they know a witness $w$ such that a circuit $C(x, w) = 1$ for public input $x$. The prover imagines an $n$-party MPC that evaluates $C$ on a random secret-sharing of $w$ across the $n$ parties; runs the entire MPC in their head; and *commits* to each party's complete view (its share, its randomness, every message it received). The verifier picks a random subset of $t < n$ views to open, and the prover reveals those views. The verifier then re-runs each opened party's MPC locally, checks that each opened view is internally consistent with the protocol it claims to run, and checks that every pair of opened views agrees on the messages they exchanged. If any opened view cheats -- if the prover faked a share or a message -- two opened parties will disagree, and the verifier rejects.

The per-check soundness error is $\binom{n-c}{t}/\binom{n}{t}$, where $c$ is the number of views the prover would need to cheat in to forge. For the standard $(n,t)=(3,2)$ IKOS parameters this is $1/3$ per check, so $O(\lambda)$ independent column-openings drive the total error below $2^{-\lambda}$.

Ligero swaps the view-commitment for a Reed-Solomon-encoded matrix of secret values and adds a sumcheck-style verification step, letting the verifier check large arithmetic constraints with logarithmic interaction. The composite proof size scales as $O(\sqrt{|C|}\cdot\lambda)$ in the verified circuit. For ECDSA-P-256 verification (a few thousand gates), that lands at the ~30 KB Longfellow reports.

Both breakthroughs accept constraints the cryptography community had refused to accept -- and the elegant alternatives (CL signatures, BBS+) sat unshipped for two decades each. The deployment picture in May 2026 is therefore no longer hypothetical.

6. What's Actually on the Wire in May 2026

The deployment picture partitions into three layers: hardware root, network layer, application layer. Each has shipped, each has a story, and the story differs sharply by layer.

flowchart TD subgraph L1["Hardware root: shipped on paper"] Daa["TPM 2.0 ECDAA (optional in spec)"] end subgraph L2["Network layer: ubiquitous"] Apl["Apple Private Access Tokens"] Cf["Cloudflare Privacy Pass"] Ch["Chrome Private State Tokens"] Edg["Microsoft Edge Privacy Pass"] Apl --> RFCs["RFC 9576 / 9577 / 9578"] Cf --> RFCs Ch --> RFCs Edg --> RFCs end subgraph L3["Application layer: four-way race"] Bbs["BBS (draft-irtf-cfrg-bbs-signatures-10)"] Sd["SD-JWT (RFC 9901)"] Mdoc["mdoc (ISO/IEC 18013-5)"] Lf["Longfellow-zk over ECDSA mdoc"] Bbs --> Vcdm["W3C VC Data Model 2.0"] Sd --> Vcdm Mdoc --> Vcdm Lf --> Vcdm end

Layer 1: The Hardware Root That Almost Was

ECDAA is the longest-standing "shipped on paper, not in consumer hardware" case in this story; §3 gives the full vendor-by-vendor diagnosis (Intel fTPM, AMD fTPM, Infineon, STMicroelectronics, Nuvoton). The hardware root is a layer in the diagram because the spec says so[@tpm-2-spec], not because anything depends on it day to day.

Layer 2: Privacy Pass, Ubiquitous

The network layer is where Privacy Pass actually lives at scale. RFC 9576 specifies the four-party architecture[@rfc9576]. RFC 9577 specifies the PrivateToken HTTP authentication scheme that gives a browser a uniform way to receive a 401 challenge and present an unblinded token in response[@rfc9577]. RFC 9578 defines two interchangeable token types in a public registry: token type 0x0001 (VOPRF on P-384, RFC 9497 cryptography) and token type 0x0002 (Blind RSA on RFC 9474 cryptography)[@rfc9578][@rfc9497][@rfc9474].

Privacy Pass token type	Cryptography	Publicly verifiable?	Typical deployment
0x0001 (VOPRF)	VOPRF on P-384 (RFC 9497)	No -- verifier needs issuer secret	Single-tenant: issuer == verifier (Cloudflare anti-abuse, Chrome Private State Tokens)
0x0002 (Blind RSA)	RSA-PSS with blinding (RFC 9474)	Yes -- verifier needs only the issuer public key	Federated: issuer != verifier (Apple Private Access Tokens)

The two-token-type design is the IETF's recognition that the deployment models are genuinely different.

If the issuer and verifier are the same party -- say, Cloudflare issues a token to a client that solved its CAPTCHA, then verifies that token on a Cloudflare-fronted origin -- the VOPRF saves bytes on the wire (~96 bytes per token) and keeps the issuer secret unexposed. If issuer and verifier are separate -- say, a Cloudflare or Fastly issuer attests a device for an Apple-served website that has never seen the issuer secret -- the publicly-verifiable blind-RSA token is the right choice; any party with the issuer public key can verify.

The deployers, with verified-source attribution:

Apple Private Access Tokens shipped in iOS 16, iPadOS 16, and macOS Ventura, announced at WWDC 2022 and demonstrated by Tommy Pauly in session 10077, Replace CAPTCHAs with Private Access Tokens. Cloudflare and Fastly are the launch issuers. The token type is 0x0002 (Blind-RSA), publicly verifiable[@apple-pat-news][@apple-wwdc-pat-2022].The Apple PAT WWDC22 session number is 10077. Session 10092 is "Meet passkeys" -- a different session by a different speaker. The two sessions are easy to confuse because both shipped in iOS 16; the Apple Developer News article that introduces PAT links directly to wwdc2022/10077.
Cloudflare ran the original 2017 browser-extension deployment, deprecated that v1 protocol in March 2024 (now Turnstile), and continues to operate RFC-compliant Privacy Pass issuers for the Apple PAT model[@cloudflare-2017-pp][@cloudflare-pp-docs][@cloudflare-2022-pat].
Google Chrome ships Private State Tokens -- the renamed successor to Trust Tokens -- as the VOPRF token-type implementation, currently used for anti-fraud signalling[@google-private-state-tokens].
Microsoft Edge is named by Matthew Green's April 2026 primer ("Privacy Pass is so ubiquitous that even Microsoft uses it in their Edge browser")[@green-2026-part2]. No primary Microsoft documentation for an "Edge Private Access Tokens" product name appears in public; the claim is reported with Green-attribution.

Privacy Pass deployer	Token type	Role	Source
Apple (Private Access Tokens)	0x0002 (Blind RSA)	Origin and verifier; uses Cloudflare and Fastly as issuers	Apple WWDC22 session 10077[@apple-wwdc-pat-2022]
Cloudflare	0x0002 issuer for Apple PAT; runs Turnstile in parallel	Issuer plus anti-abuse origin	Cloudflare documentation[@cloudflare-pp-docs]
Google Chrome (Private State Tokens)	0x0001 (VOPRF)	Anti-fraud signalling	Google Privacy Sandbox[@google-private-state-tokens]
Microsoft Edge (Privacy Pass)	Not published	Per Green: "uses it in their Edge browser"	Matthew Green, April 2026[@green-2026-part2]

Cloudflare's redemption throughput is the metric every press release wants. Green's April 2026 primer estimates "hundreds of thousands of transactions per second" across the broader Cloudflare anti-abuse surface, of which Privacy Pass is a fraction[@green-2026-part2]. No primary Cloudflare-side figure for tokens-per-second exists in public, so we report Green's estimate as Green's estimate and do not promote it to a Cloudflare-side fact.

Layer 3: The Multi-Attribute Four-Way Race

The application layer holds the four contenders the EU age-verification app's eventual design will pick among (and the parallel-path Hyperledger AnonCreds community). The envelope is the W3C Verifiable Credentials Data Model 2.0, a Recommendation since 15 May 2025 that defines a credential format and supports multiple securing mechanisms[@w3c-vcdm-2]. The cryptography lives inside the envelope.

BBS, with draft-irtf-cfrg-bbs-signatures-10 dated 8 January 2026[@bbs-draft-10]. Pairing on BLS12-381. 80-byte signature, 256-byte proof. Multi-show unlinkable by construction. Best cryptographic privacy of the four; issuer adoption blocked on pairing-PKI migration.
SD-JWT -- selective-disclosure JSON Web Tokens -- promoted to RFC 9901 (Standards Track) in November 2025 by Daniel Fett, Kristina Yasuda, and Brian Campbell[@rfc9901]. The mechanism is JSON Web Signatures plus salted hashes of individual claims, no zero-knowledge. Lowest deployment cost; the EUDI Wallet ARF's mandatory baseline.
ISO/IEC 18013-5 mdoc baseline -- published in 2021, deployed by US state DMVs in Arizona, Colorado, Georgia, Maryland and others, and the EUDI Wallet PID's mandatory co-baseline. CBOR-encoded mdoc plus ECDSA-signed mobile security object (MSO); same "no ZK" trade-off as SD-JWT[@iso-18013-5].
Longfellow-zk -- ~1.2 s prover time, ~30 KB proof, open-sourced by Google under Apache-2.0 on 3 July 2025. Google partnered with Sparkasse for the German banking pilot[@google-2025-zkp-blog][@longfellow-repo][@longfellow-docs][@libzk-draft].
The EU age-verification app -- "technically ready" 15 April 2026, with the technical portal at ageverification.dev describing zero-knowledge proof cryptography as the unlinkability mechanism[@ec-2026-age-app][@ageverification-dev]. The wire format remains a public consultation question; Longfellow-zk over an mdoc is the strongest candidate among the four schemes above.
Hyperledger AnonCreds -- the CL-RSA production stack used in self-sovereign-identity deployments (BC.GOV in Canada, the Ontario Digital Trust pilot)[@anoncreds-spec]. Parallel-path; not a contender for the EUDI Wallet slot, but actively shipping in the SSI community.

Regulation (EU) 2024/1183 -- the eIDAS 2 regulation that mandates the EUDI Wallet -- entered into force on 20 May 2024. The provisioning deadline for Member States to make at least one EUDI Wallet available is **24 December 2026**. Mandatory private-sector acceptance of an EUDI Wallet for relying parties subject to the regulation begins **6 December 2027**[@eidas2][@eu-cir-2024-2977]. Relying parties planning age-verification or attribute-disclosure deployments should treat these dates as binding regulatory deadlines, not as aspirational targets.

Four schemes, four different optimisation targets, none of them strictly dominant. The choice depends on what you are willing to give up.

7. Choosing Among Four Multi-Attribute Schemes

There is no single best multi-attribute anonymous credential as of May 2026. There are four, each optimised for a different axis, and the EU's choice (mandate SD-JWT and mdoc; allow a ZKP overlay later) is the single most important deployment decision the field has made in a generation.

The head-to-head comparison runs across seven dimensions that matter for any relying party choosing a scheme:

Dimension	BBS	SD-JWT	mdoc baseline	Longfellow-zk
Issuer cryptography	Pairing on BLS12-381	ECDSA-P-256 / EdDSA	ECDSA-P-256 (COSE_Sign1)	ECDSA-P-256 (unchanged from mdoc)
Holder cryptography	Pairing-based ZK proof	Hash + JWS verify	Hash + ECDSA verify	MPC-in-the-head SNARK + sumcheck
Selective disclosure	Native (any subset)	Native (any disclosed claim)	Native (any disclosed element)	Native (any subset of mdoc elements)
Multi-show unlinkability	Yes (each ProofGen is fresh)	No (JWS signature is a stable linker)	No (MSO signature is a stable linker)	Yes (each SNARK is fresh)
Native predicate proofs	Yes (range proofs over committed messages -- draft in progress)	No (issuer must pre-encode `age_over_18` claim)	No (issuer must pre-encode `age_over_18` element)	Yes (predicate enforced inside SNARK circuit)
Per-presentation size	~256 B (BBS proof)	~KB-scale	~KB-scale (full mdoc)	~30 KB (SNARK proof)
Per-presentation prover wall-clock	~30 ms	~1 ms	~1 ms (ECDSA verify on disclosure)	~1.2 s on mobile (per Google blog)
Issuer-side adoption cost	High (new BLS12-381 PKI; not in any DMV or national ID today)	Low (stock JWS / OIDC stack)	Low (stock ECDSA + COSE)	Zero (reuses existing mdoc issuance)
Standards maturity	IETF CFRG Draft 10 (Jan 2026); not yet RFC	RFC 9901 (Standards Track, Nov 2025)	ISO/IEC 18013-5:2021 published	IETF CFRG individual draft (libzk); proof system named; credential profile not yet standardised
EUDI Wallet ARF status	Optional / future	Mandatory baseline	Mandatory co-baseline (PID)	Targeted backend for age verification
Quantum resistance	No (pairing DLP broken by Shor)	No (ECDSA broken by Shor)	No (ECDSA broken by Shor)	Conditional: SHA-256 circuit is Grover-only but the issuer ECDSA is still Shor-broken

Read the table top to bottom and a single tension dominates: cryptographic privacy versus issuer adoption cost.

Best cryptographic privacy: BBS. A BBS presentation is a single fresh 256-byte proof per show, structurally unlinkable across presentations, supports any selective disclosure subset, and the in-progress range-proof extension will support predicate proofs natively. The price is that every issuer has to operate a pairing-friendly PKI on BLS12-381, which no national-identity authority does today.

Lowest deployment cost: SD-JWT or mdoc baseline. Stock ECDSA, stock JWS or COSE_Sign1, drop-in to any existing OAuth or COSE pipeline. The price is that every presentation reveals the issuer's deterministic signature on the credential, which is a stable identifier across presentations -- so SD-JWT and mdoc baseline have selective disclosure but not multi-show unlinkability. Two presentations of the same SD-JWT VC to colluding verifiers are trivially linkable.

Cryptographic privacy without issuer migration: Longfellow-zk. The trick is to wrap the existing ECDSA-signed mdoc in a SNARK that proves "I know an ECDSA signature on a credential whose disclosed elements satisfy the predicate." The issuer changes nothing. The price is 30 KB of proof on the wire and 1.2 seconds of prover time on a 2024-era mobile phone, both two orders of magnitude above what BBS achieves.

Key idea: There is no single best multi-attribute anonymous credential as of May 2026. The choice is between cryptographic privacy (BBS), deployment cost (SD-JWT or mdoc), or no issuer migration (Longfellow-zk) -- and the EU has decided the third axis matters most.

The political dynamic behind the EUDI Wallet ARF is worth naming. Version 1.4 of the architecture document mandates SD-JWT VC and mdoc as the credential format baselines -- privacy-suboptimal but deployable in 2026 -- and lists BBS as "optional, future"[@eudi-arf]. Google's open-sourcing of Longfellow-zk on 3 July 2025 was the strategic move to ensure a zero-knowledge overlay was shipping in a real library before SD-JWT entrenched as the only credential format anyone actually implemented[@google-2025-zkp-blog]. The German banking pilot with Sparkasse is the first test of that strategy at issuer scale. The EU age-verification app is the first test at population scale.

The cryptography community had spent two decades trying to build a one-credential-for-everything scheme. Privacy Pass shipped because it gave up that ambition and signed one bit. Longfellow ships because it gives up cryptographic minimality so the issuer never moves.

Every shipping scheme is correct cryptography for the constraints it was given. Each scheme makes a different concession -- to deployment, to throughput, to standardisation -- and the concessions reveal what the field still cannot do.

8. What the Cryptography Cannot Do

Three things the cryptography genuinely cannot do, and one we do not know how to do efficiently.

Revocation Under Unlinkability Is Structurally Impossible Without State

Revoking a specific credential -- the holder's wallet was stolen, the holder's status changed, the credential expired -- means a verifier must be able to recognise "this credential has been revoked." Recognising a specific credential means keeping some state that maps it to its revocation status. Multi-show unlinkability means no two presentations of the same credential should be linkable. The two requirements are in direct tension.

The literature has produced three escape hatches, each trading privacy or scale for revocation.

Accumulator-based revocation -- the BBS+ approach -- stores all valid credentials in a cryptographic accumulator and gives each holder a witness of membership; revocation updates the accumulator and the holder must update their witness, which scales badly at nation-state membership counts. Epoch-based credential rotation -- the Hyperledger AnonCreds approach -- has each credential expire at a fixed epoch (a week, a month) and re-issues; the cost is bandwidth and online-issuer dependence. Verifier-local linkability with revocation tokens -- the EPID approach -- gives each verifier a pseudonym derived from the credential plus a verifier-specific tag, sacrificing unlinkability across that verifier in exchange for revocation-list checking[@daa-2004-doi].

The deployed status-list approaches (used by SD-JWT VC and mdoc baseline today) take an even simpler route: assign each credential an index into a published bitmap. The verifier downloads the bitmap and checks the bit. The trade is brutal: the credential's index is a stable identifier across presentations, so status lists give revocation by giving up unlinkability[@oauth-status-list-draft].The Token Status List specification is the IETF draft draft-ietf-oauth-status-list-20 (April 2026, intended Standards Track but not yet an RFC), by Looker, Bastian, and Bormann. An older summary of this stack sometimes cited it as "RFC 9863"; that is a different document about a PCEP Color extension and is unrelated. The Token Status List is still a draft.

Selective Disclosure Without ZK and With Multi-Show Unlinkability Is Impossible

If the issuer signs the credential with a deterministic signature -- any standard JWS, COSE_Sign1, or mdoc MSO -- the signature itself is a stable bit-string. Two presentations of the same credential expose the same signature, and colluding verifiers can link them by comparing signatures alone.

The only way to break that link is to randomise the signature per presentation, which mathematically requires a zero-knowledge proof: instead of revealing the signature, the holder proves they know one. SD-JWT and the mdoc baseline are explicit about being on the "no ZK, presentations linkable" side of the dichotomy; BBS and Longfellow-zk are explicit about being on the ZK-required side[@rfc9901][@iso-18013-5]. You can have selective disclosure without ZK, or selective disclosure with multi-show unlinkability via ZK, but you cannot have selective disclosure with multi-show unlinkability and without ZK.

Holder Unlinkability Under Issuer-Verifier Collusion Is Structurally Limited

If issuer and verifier share state -- a per-credential nonce, a serial number burned into the credential at issuance -- unlinkability against a colluding pair is broken. Privacy Pass mitigates this with the four-party Attester-Issuer-Origin split in RFC 9576, where the issuer learns nothing about the user's attestation and the origin learns nothing about the issuance event[@rfc9576]. BBS relies on the pairing-based discrete-log assumption and the random-oracle model to ensure that issuer and verifier together cannot link presentations without breaking pairing crypto. Both mitigations work, but both require operational separation between the parties; collapse them into a single trust domain and the unlinkability guarantee weakens.

Post-Quantum Migration Is Unsolved for Credentials

Every deployed scheme at every layer breaks against a cryptographically relevant quantum computer.

BBS depends on pairings on BLS12-381; Shor's algorithm breaks the underlying discrete-log problem.
ECDSA in SD-JWT, mdoc baseline, and Longfellow-zk's issuer signature: broken by Shor.
RSA in blind-RSA Privacy Pass: broken by Shor.
TPM 2.0 ECDAA: broken by Shor.
SHA-256 inside Longfellow-zk's MPC-in-the-head circuit: Grover-only, which halves the effective security level but does not break the construction outright. The issuer's ECDSA signature inside the SNARK, however, is still Shor-broken.

Lattice-based anonymous-credential constructions exist in the research literature -- the headline blind-signature primitive is BLOOM (Lyubashevsky and Nguyen, IACR ePrint 2022/1307, ASIACRYPT 2022[@bloom-eprint][@bloom-dblp]), and the headline 2023 anonymous-credentials framework built on top is BLNS (Bootle-Lyubashevsky-Nguyen-Sorniotti, ePrint 2023/560[@blns-eprint]). BLNS reports proofs "as small as a few dozen kilobytes" for arbitrarily large user populations[@blns-eprint] -- none are deployed, none are within an order of magnitude of BBS's eighty-byte signature, and none are inside NIST's post-quantum standardisation rounds. Credentials issued in 2026 with multi-decade validity (a national ID expected to be honoured through 2046, say) face the structural risk that they may be forgeable by a quantum adversary inside their nominal lifetime.

Note: A cryptographically relevant quantum computer breaks every currently deployed scheme in Layers 1, 2, and 3 of this stack. CRQC timelines are uncertain. Credentials issued in 2026 with multi-decade validity periods need a post-quantum migration plan that does not yet exist for anonymous credentials, and that gap is the most consequential open problem in the field.

Key idea: Revocation under anonymity, multi-show unlinkability without ZK, and post-quantum credentials are not engineering problems waiting on better libraries. They are structural impossibilities or open research questions that require the field to either change assumptions or accept new primitives. The next decade is not "ship better libraries"; it is either "invent new primitives" or "accept that 2046 will see forgeable credentials issued in 2026."

The framing the field tends to avoid is sharper than "this scheme is small." Two formal results pin where each construction sits. Pointcheval and Stern's Journal of Cryptology 2000 paper -- the canonical security proof for blind signatures under the one-more-unforgeability game in the random-oracle model -- gives a reduction whose loss factor scales as the number of random-oracle queries $q_h$ the adversary makes; asymptotically this forces signature size to be $\Omega(\lambda)$ bits at security parameter $\lambda$, or about 16 bytes at $\lambda = 128$[@pointcheval-stern-2000-joc]. Bitansky, Canetti, Chiesa, and Tromer's ITCS 2012 paper on extractable SNARKs ("...and back again") proves that any extractable succinct argument of knowledge cannot be shorter than $\Omega(\lambda)$ bits either[@bcct-2012-itcs][@bcct-dblp]. BBS at 80 bytes is therefore within a small constant factor of the SNARK-class floor; that is not "the" information-theoretic minimum, but it sits in the right asymptotic neighbourhood.

Applying the Pointcheval-Stern[@pointcheval-stern-2000-joc] and BCCT[@bcct-2012-itcs][@bcct-dblp] $\Omega(\lambda)$ bounds from the preceding paragraph to the Longfellow numbers from §5: Longfellow's ~30 KB proof is roughly $3$ to $4\times$ above the construction-class floor $O(\sqrt{|C|}\cdot\lambda)$ for MPC-in-the-head plus sumcheck on an ECDSA-verification circuit of a few thousand gates[@ligero-2017-dblp][@ligero-doi]. Against the Groth16-class floor of ~128 bytes that a trusted-setup-permitted SNARK reaches[@bcct-2012-itcs], Longfellow is roughly $200$ to $300\times$ larger. That gap is the cost of avoiding trusted setup, not a cryptographic shortcoming.

9. Open Problems

Five problems the field knows it has and cannot yet solve at the scale shipping demands. For each, the question is not just "what is missing?" but "what is the structural obstacle that the engineering has been bumping into?"

1. Practical revocation under anonymity at nation-state scale. The EUDI Wallet rollout will need revocation across roughly 450 million wallets and tens of thousands of relying parties, preserving multi-show unlinkability.

The canonical academic answer is the Camenisch-Kohlweiss-Soriente accumulator-based revocation scheme from PKC 2009 -- a dynamic accumulator on bilinear maps with efficient witness updates[@cks-2009-edinburgh][@cks-2009-dblp]. Cryptographically, the accumulator value $V \in G_1$ is a single BLS12-381 group element (48 bytes compressed) that commits to the set of currently-valid credential identifiers. Each holder carries a witness $W_i \in G_1$ of membership (48 more bytes). When the issuer revokes credential $j$, every non-revoked holder must update their witness using a per-revocation broadcast update value $U_j$ (48 bytes per revocation) and one scalar multiplication in $G_1$. CKS prove that the update is correct without re-issuance and can be delegated to untrusted helpers, which is the property that makes the scheme attractive in the first place[@cks-2009-edinburgh].

Plug nation-state numbers into that arithmetic and the scaling shows up. Assume 10,000 revocations per day across a 50M-wallet population (a single mid-sized member state). Every non-revoked holder must download $10{,}000 \times 48 = 480$ KB per day of update values and perform 10,000 scalar multiplications on BLS12-381 -- on the order of ten seconds of mobile CPU per day.

Batching the updates helps, but it does not change the asymptotics: the per-holder cost is linear in the number of revocations in the relevant time window. At full-EU scale (450M wallets, the same revocation rate per capita), the per-holder bandwidth stays the same; the issuer-side aggregation cost grows linearly.

Status-list revocation -- the Token Status List approach that SD-JWT VC and the mdoc baseline currently use[@oauth-status-list-draft] -- gets around the bandwidth problem by giving each credential an index into a published bitmap. But the index is a stable identifier across presentations, so the trade is brutal: revocation by giving up unlinkability. No deployed solution today gives both unlinkability and sublinear-per-holder revocation at nation-state scale.

2. Post-quantum BBS and post-quantum Privacy Pass. Lattice-based attempts are multi-kilobyte at best and an active research area; pairing-based schemes remain at ~80-byte signatures.

The structural obstacle is the geometry of lattice commitments. The BLNS framework (Bootle-Lyubashevsky-Nguyen-Sorniotti, 2023[@blns-eprint]) reports proofs "as small as a few dozen kilobytes" for arbitrarily-large user populations -- concretely on the order of 20-40 KB per credential and 30-50 KB per show.

Three layers of unavoidable cost stack up. First, a module-LWE-based commitment needs a dimension of roughly 10 ring elements of degree 256, so the commitment object alone is around $10 \times 256 \times 32$ bits $= 10$ KB at the smallest plausible parameters. Second, the modulus must grow to $\ge 2^{32}$ for 128-bit security against current lattice attacks. Third, rejection sampling in the zero-knowledge step adds roughly a $2\times$ blow-up to the resulting proof, mitigated to roughly $1.3\times$ by BLOOM's bimodal-Gaussian trick[@bloom-kcl].

The 25-fold-or-better signature-size improvements BLOOM reports over prior lattice one-out-of-many proofs are real, but they take you from "very large" to "still large" -- not to byte-scale. Constructing a post-quantum anonymous credential within an order of magnitude of BBS's wire size is a conjectured open problem. It is not currently in NIST's PQ standardisation rounds; FIPS 204 ML-DSA, FIPS 205 SLH-DSA, and FIPS 206 FN-DSA all target plain signatures, not anonymous-credential primitives.

3. Cross-platform interop. A Bavarian EUDI mdoc presented at a Florida bar that uses AAMVA mDL verification, then the same flow on Apple Wallet, Google Wallet, and Samsung Wallet.

The W3C Digital Credentials API is the browser-side connective tissue, currently a Working Draft from the Federated Identity Working Group rather than a Recommendation[@w3c-digital-creds]. OpenID for Verifiable Presentations (OID4VP) handles the online-presentation case[@openid4vp-spec]; ISO/IEC 18013-7 handles the offline case[@iso-18013-7].

The deeper obstacle is in the trust layer, not the presentation layer. The AAMVA and EUDI worlds publish their issuer trust anchors in structurally different forms. AAMVA's Digital Trust Service distributes a VICAL -- a Verified Issuer Certificate Authority List -- defined under ISO/IEC 18013-5 §9, where each entry is a self-contained CA root with metadata[@aamva-dts][@iso-18013-5]. The EUDI Wallet's trust model, defined in the ARF chapter 6 and the implementing acts CIR 2024/2977 (PID and EAA) and CIR 2024/2979 (interop)[@eudi-arf][@eu-cir-2024-2977], runs on Member-State Trust Lists -- national trust-service-provider registries that the European Commission cross-recognises.

A VICAL entry and a Member-State Trust List entry both express "this CA root is authorised to issue an mDL or a PID," but no published cross-recognition protocol maps one to the other today. Cross-implementation conformance testing is underway in 2026 but no end-to-end interop story is shipping. The most likely path is an ISO/IEC 18013-7 profile for VICAL plus Member-State Trust List cross-anchoring in the 2027-2030 window.

4. Quantitative deployment metrics for Privacy Pass. No primary Cloudflare or Apple figure for tokens-per-second exists in public. Matthew Green's April 2026 primer reports "hundreds of thousands of transactions per second" across the broader Cloudflare anti-abuse surface, of which Privacy Pass is a fraction[@green-2026-part2]. The most-deployed anonymous credential in the world lacks an actual deployment metric, which is a striking gap in a field that is otherwise generous with engineering disclosure. The structural reason is the protocol's own design: the privacy properties depend on the size of the anonymity set per issuer key, and operators have no incentive to publish per-key issuance counts that would let a third party estimate the set size.

Matthew Green's April 2026 primer says Privacy Pass is "so ubiquitous that even Microsoft uses it in their Edge browser." We could not find primary Microsoft documentation naming a specific "Edge Private Access Tokens" product. The Privacy Pass deployment in Edge is real -- Green is a careful source -- but we do not invent a product name that Microsoft itself does not use. That is the honest limit of the available evidence.

5. Holder binding without identification. Prevent credential transfer (Alice's age credential used by 17-year-old Bob) while preserving unlinkability. Binding to a hardware key works at the cost of secure-element identifiability across presentations. The cleanest formal answer at the protocol level is Brands' wallet-with-observer architecture from 1993[@brands-1993-doi]; the cleanest modern one is the IETF draft draft-irtf-cfrg-bbs-per-verifier-linkability-01 by Kalos (MATTR) and Bernstein (Grotto Networking), published March 2025[@bbs-pseudonym-draft].

The construction in the draft is worth a paragraph. The holder picks a long-term nym_secret $\in \mathbb{Z}_q$ at the BBS credential's issuance, committed inside the BBS message vector. For each verifier $V$, the holder derives a per-verifier pseudonym $\text{pseudonym}_V = \text{nym_secret} \cdot \text{HashToCurveG1}(\text{verifier_id}_V) \in G_1$.

The same holder presenting the same credential to the same verifier twice always yields the same pseudonym_V -- so the verifier can recognise returning users, which is intentional. Two different verifiers $V_1$ and $V_2$ see two different pseudonyms that they cannot link to a common holder unless they break the Decisional Diffie-Hellman assumption in $G_1$ on BLS12-381 -- a pairing-curve assumption closely related to (though not identical with) the q-Strong Diffie-Hellman assumption that underpins BBS unforgeability.

Hardware binding is not in the current draft. The spec leaves it as an out-of-band concern handled by the qualified signature creation device layer: Secure Enclave on iPhone, StrongBox on Android, Pluton or a discrete TPM on PCs. Tying a hardware-attested key to nym_secret with provable unforgeability across the device boundary is the open profile work the EUDI and ISO/IEC committees are pushing on in 2026. Nothing yet ships at consumer scale that completely solves the problem.

These open problems are the next-decade research and engineering agenda. The deployed answers are good enough to ship today. So: what should a relying party actually do?

10. A Practical Guide for Relying Parties

Seven concrete recommendations for choosing a credential scheme in May 2026, organised by use case.

1. Anti-Abuse and Human Attestation

Pick the RFC 9578 Privacy Pass token type that matches your operator model.

Single-tenant (issuer == verifier): VOPRF, token type 0x0001. ~96 bytes per token, sub-millisecond on both sides, but the verifier must hold the issuer secret. Best for in-house anti-abuse where the issuer and verifier are the same trust domain (Cloudflare's own surface, Chrome's Private State Tokens).
Federated (issuer != verifier): Blind RSA, token type 0x0002. 256 bytes per token (RSA-2048), publicly verifiable -- any party with the issuer public key can verify. Best for Apple's Private Access Tokens model, where Cloudflare or Fastly is the issuer and an arbitrary website is the verifier.

The redemption-side check for a publicly-verifiable token is a single RSA-PSS verification against the published issuer key. The pseudocode below shows the verifier's check in JavaScript -- the point is to make the wire format and the publicly-verifiable property concrete, not to be a drop-in implementation.

{` // Pseudocode for redemption-side verification of a Privacy Pass token // of type 0x0002 (Blind RSA) per RFC 9578 with RFC 9474 cryptography. // Real implementations should use a vetted crypto library.

async function verifyPrivacyPassToken(token, issuerPublicKey, origin) { // RFC 9578 token layout (token type 0x0002): // token_type (2 bytes) || nonce (32 bytes) || challenge_digest (32 bytes) // || token_key_id (32 bytes) || authenticator (Nk bytes, RSA-PSS sig) const view = new DataView(token); const tokenType = view.getUint16(0); if (tokenType !== 0x0002) return { ok: false, reason: 'wrong type' };

const nonce = token.slice(2, 34); const challengeDigest = token.slice(34, 66); const tokenKeyId = token.slice(66, 98); const authenticator = token.slice(98);

// The signed input is everything except the authenticator itself. const signedInput = token.slice(0, 98);

// Bind the token to the origin's challenge (per RFC 9577). const expectedDigest = await sha256(buildOriginChallenge(origin)); if (!constantTimeEquals(challengeDigest, expectedDigest)) { return { ok: false, reason: 'challenge mismatch' }; }

// The token is a stock RSA-PSS signature over the signed input, // under the issuer's published public key. No issuer secret needed. const ok = await crypto.subtle.verify( { name: 'RSA-PSS', saltLength: 48 }, issuerPublicKey, authenticator, signedInput, ); return { ok, reason: ok ? 'valid' : 'bad signature' }; } `}

The IETF working group considered shipping only one token type. The split survived because the two operator models genuinely want different things. A single-tenant deployment (Cloudflare issues and Cloudflare verifies) saves bytes and keeps the issuer secret in-house with VOPRF, and Cloudflare can afford the operational cost of holding the secret. A federated deployment (Cloudflare issues, Apple verifies) cannot share an issuer secret across organisational trust boundaries, so the verifier needs a publicly-verifiable signature like RSA-PSS. RFC 9578 ships both and lets the deployment pick.

2. Age Verification in the EU

Wait for the EUDI Wallet age-attestation interface. The Member-State provisioning deadline is 24 December 2026, and mandatory private-sector acceptance for relying parties subject to eIDAS 2 begins 6 December 2027[@eidas2][@eu-cir-2024-2977]. The wire format will be SD-JWT VC over OpenID4VP, with Longfellow-zk available as the optional ZKP overlay for stronger privacy. The EU's technical portal at ageverification.dev is the canonical reference for pilot integrators in 2026[@ageverification-dev].

3. Age Verification Globally With Strong Privacy

Evaluate Google's Longfellow-zk over an ISO mdoc. The reference implementation is Apache-2.0 at github.com/google/longfellow-zk; the project documentation site includes security review reports[@longfellow-repo][@longfellow-docs]. The issuer requirements are "do what every mDL issuer already does" -- sign ECDSA-P-256 over the CBOR mdoc. The holder requirements are a phone that can run a ~1.2 s SNARK prover.

4. Full Multi-Attribute Privacy With Maximum Cryptographic Cleanliness

For a privacy-preserving employee badge, professional credential, or membership card where you control both the issuer and the consumer (an enterprise context), use BBS via draft-irtf-cfrg-bbs-signatures-10[@bbs-draft-10]. Expect to operate your own pairing-based PKI on BLS12-381. Native predicate proofs and ~256-byte presentations are the reward.

5. Quick Deployment Without Multi-Show Unlinkability

If selective disclosure is required and multi-show unlinkability is not, SD-JWT VC (RFC 9901) on stock ECDSA or EdDSA is the lowest-friction integration into existing OAuth and OpenID Connect stacks[@rfc9901]. Two presentations of the same credential to colluding verifiers will be linkable; for many enterprise scenarios that is acceptable.

6. TPM or Hardware Vendor

ECDAA is in the TPM 2.0 spec; consumer-market demand is near zero[@tpm-2-spec]. The pragmatic recommendation is to wait for an operating-system-layer consumption story to mature before allocating silicon area or firmware to ECDAA in a discrete or firmware TPM.

7. Self-Sovereign Identity (SSI)

Hyperledger AnonCreds 2.0 (BBS-based) is the road forward in the SSI community; AnonCreds 1.0 (CL-RSA) is the production stack actually running in deployments like BC.GOV and Ontario Digital Trust[@anoncreds-spec]. The SSI community has run its own parallel path for years and is unlikely to converge with the EUDI Wallet stack any time soon.

Note: Three lines to memorise. Anti-abuse: Privacy Pass (RFC 9578) -- VOPRF if you are both issuer and verifier, blind-RSA if you are federated. Age verification in the EU: wait for the EUDI Wallet age attestation (Member-State deadline 24 December 2026). Age verification globally with privacy: Longfellow-zk over an ISO mdoc.

That covers the deployment matrix. An entire layer of privacy-preserving identity infrastructure now exists, in production, at internet scale. The next question is not whether the cryptography ships -- it has shipped -- but what we choose to use it for.

11. Frequently Asked Questions

Privacy Pass is anonymous against the verifier under RFC 9576's Attester / Issuer / Origin non-collusion threat model -- the attester learns which user solved which CAPTCHA, the issuer learns nothing about the user, the origin learns only that a valid token redeemed. It is *not* anonymous against an issuer-verifier colluder who shares state across the trust boundary. It is also subject to residual per-issuer linkability of the kind that comes from seeing thousands of tokens signed by the same issuer key; the formal anonymity set is "all users whose tokens are signed by the same issuer key in the same epoch." Passkeys prove WHO -- they bind an authentication event to a specific public key pair associated with a specific account. Anonymous credentials prove WHAT IS TRUE about you -- an attribute (over 18, licensed to drive) -- without identifying the holder. Different primitive, different threat model. WebAuthn and passkeys assume the verifier wants to know who you are; Privacy Pass and BBS assume the verifier specifically does not. ECDAA is *optional* in TPM 2.0 -- the algorithm is in the spec but the TCG did not require vendors to ship it[@tpm-2-spec], no major browser or operating system ever built a challenge path, and the cryptography sits dormant on the chip. §4's "DAA is OPTIONAL in TPM 2.0" callout and §3's DAA subsection give the full diagnosis; the short answer is that [WebAuthn](/blog/webauthn-and-passkeys-on-windows-from-ctap-to-the-credential/) won the device-attestation slot because it has a relying-party-side consumption protocol and gives up anonymity in exchange for a usable enrolment flow. Matthew Green's April 2026 primer says Privacy Pass is "so ubiquitous that even Microsoft uses it in their Edge browser"[@green-2026-part2]. We could not find primary Microsoft documentation naming a specific "Edge Private Access Tokens" product. The §9 Aside on this point gives the full diagnosis: the deployment is real (Green is a careful source) but we do not invent a product name that Microsoft itself does not use. That is the honest limit of the available evidence. Technically yes -- a zero-knowledge proof on a device against a signed mdoc that contains an `age_over_18` element is a constructible and tested protocol[@ec-2026-age-app][@ageverification-dev]. Operationally, the answer depends on the EUDI Wallet rollout (the 24 December 2026 Member-State deadline is binding under eIDAS 2). Politically, the answer depends on enforcement -- whether large platforms accept anonymous proofs or insist on identifying flows that the regulation would treat as non-compliant. The Commission's "technically ready" claim of 15 April 2026 is verifiable against the cryptography; the deployment timeline is the open question. Different primitive. Anonymous credentials are designed to allow N unlinkable presentations per user. Proof-of-personhood schemes are explicitly sybil-resistance mechanisms that limit one user to one presentation against a particular service. They are complementary but answer different questions, and we do not cover them here. Orthogonal. Passkeys and anonymous credentials answer different questions and will continue to coexist. Anonymous credentials do not authenticate you to an account; passkeys do not let you prove a fact about yourself without revealing your account binding. Most production identity flows in 2027 and beyond will combine both -- a passkey for account access, an anonymous credential for attribute disclosure where identification is unnecessary.

Forty-one years after a Berkeley graduate student described an anonymous credential in Communications of the ACM, every major browser ships one, the IETF has standardised the wire format, and the European Commission has bet the regulation of online age verification on the primitive working at population scale. The cryptography did its work in the 1980s and 1990s. The protocol stack, the standards bodies, the device wallets, and the regulatory deadline came forty years later. What is left to do is the part the cryptography never claimed to do: choose what to use it for.

Direct Anonymous Attestation: The Zero-Knowledge Proof Already in Every TPM

noreply@paragmali.com (Parag Mali) — Tue, 12 May 2026 00:00:00 GMT

**Direct Anonymous Attestation is the zero-knowledge proof your laptop already has -- and never uses.** Every TPM 2.0 specification since 2014 names a group-signature primitive called `TPM_ALG_ECDAA`, with a normative command pair (`TPM2_Commit`, `TPM2_Sign`) and a mandatory curve (`TPM_ECC_BN_P256`). A TPM with ECDAA enabled can prove "I am a genuine TPM whose endorsement key was certified by a known issuer" without revealing *which* TPM and without an online third party in the verification path. ISO/IEC 20008-2:2013 Mechanism 4 standardizes it. FIDO Alliance bound it to authenticator attestation in 2018. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the `packed` and `tpm` attestation statement formats in March 2019. Three years later, WebAuthn Level 2 removed it entirely. The TCG PC Client Platform TPM Profile made `TPM_ALG_ECDAA` optional in February 2020. Microsoft Azure Attestation, Windows Health Attestation, AWS Nitro, Apple App Attest, and Google Play Integrity all use Privacy-CA-shaped broker flows instead. This article walks the thirty-year cryptographic lineage, the TPM 2.0 normative surface, the FIDO ECDAA failure, and the structural reasons Microsoft chose brokers over math.

1. A Billion Chips, Zero Verifiers

Every TPM 2.0 Library Specification published since 2014 names a zero-knowledge proof of knowledge. The algorithm identifier TPM_ALG_ECDAA (value 0x001A) appears in Part 2 (Structures). The command pair TPM2_Commit and TPM2_Sign appears in Part 3 (Commands). The mathematical construction appears in Part 1 Annex C.5. The mandatory curve is TPM_ECC_BN_P256 (0x0010), a 256-bit Barreto-Naehrig curve picked specifically because it admits the asymmetric pairings the protocol needs [@tpm-library-spec]. A conforming TPM 2.0 chip with ECDAA enabled can produce a signature that proves the chip is a genuine TPM whose endorsement key was certified by a known issuer -- without revealing which TPM, and without an online certificate authority sitting in the verification path. The cryptography is called Direct Anonymous Attestation, and the Wikipedia article notes that the construction is "implemented by both EPID 2.0 and the TPM 2.0 standard" [@wiki-daa].

Almost nobody uses it.

Microsoft Azure Attestation does not. Its public architecture document describes a certificate authority that ingests endorsement-key certificates and issues per-key JWTs with a special issuance policy [@azure-attestation]. The Windows Health Attestation Service does not. AWS Nitro Enclaves does not [@aws-nitro-attestation]. Apple App Attest does not [@apple-app-attest]. Google Play Integrity does not [@google-play-integrity]. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the packed and tpm formats in March 2019; WebAuthn Level 2 in April 2021 removed it entirely [@webauthn-2]. The TCG PC Client Platform TPM Profile, the document that governs which TPM 2.0 algorithms an OEM must support to ship a Windows-class platform, made TPM_ALG_ECDAA and TPM_ALG_ECSCHNORR optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025) [@tcg-ptp]. Microsoft Pluton's published surface, which enumerates the algorithms the security processor exposes through its TPM 2.0 personality, does not advertise ECDAA at all [@pluton].

The most thoroughly standardized hardware-anchored group-signature primitive in the history of platform security sits in firmware on a billion-plus machines and runs on almost none.

Why?

Key idea: Direct Anonymous Attestation solves the same problem as a Privacy-CA -- prove the TPM is genuine without disclosing which TPM -- by moving the trust assumption from operational (the broker promises not to log) to cryptographic (the math forbids the issuer from learning). The interesting question is not whether the cryptography works. It is why an industry that spent thirty years building the math chose, in production, the architecture the math was meant to replace.

This article walks the answer in four moves. Sections 2 through 5 reconstruct the cryptographic lineage: the Privacy-CA architecture DAA was invented against (TPM 1.1, 2003), the group-signature pre-history that made the construction possible (Chaum-van Heyst 1991 through Camenisch-Lysyanskaya 2004), the Brickell-Camenisch-Chen breakthrough at ACM CCS 2004, and the seven-year evolution to the elliptic-curve scheme TPM 2.0 actually ships (Chen-Page-Smart, CARDIS 2010). Sections 6 and 7 walk the normative surfaces: the TPM 2.0 ECDAA command surface and the ISO/IEC 20008-2 / 20009-2 standards. Sections 8 and 9 are case studies in non-deployment: FIDO's three-year experiment with ECDAA-in-WebAuthn, and Microsoft's two-decade commitment to broker-mediated attestation. Section 10 names the open problems -- post-quantum DAA, confidential computing, the One-TPM-to-Bind-Them-All fix that has not made it into TCG text. Section 11 closes with a role-keyed practical guide and an FAQ.

timeline title Direct Anonymous Attestation, 1991-2024 1991 : Chaum-van Heyst (EUROCRYPT) : Group signature defined 1997 : Camenisch-Stadler (CRYPTO) : Constant-size signatures 2000 : ACJT (CRYPTO) : Coalition resistance 2004 : Brickell-Camenisch-Chen (CCS) : Boneh-Boyen-Shacham short groupsigs 2005 : DAA-RSA added to TPM 1.2 rev 94 2007 : Brickell-Li EPID (WPES) : Signature-based revocation 2008 : Brickell-Chen-Li (TRUST) : First pairing DAA : CMS asymmetric DAA proposed 2010 : Chen-Li (IPL) : CMS proof flaw : Chen-Page-Smart (CARDIS) : The scheme TPM 2.0 ships 2013 : BFGSW (IJIS) : User-controlled linkability model : ISO/IEC 20008-2 / 20009-2 2014 : TPM 2.0 Library Spec : ECDAA in firmware 2015 : Smyth-Ryan-Chen : Retroactive BCC privacy bug 2018 : FIDO ECDAA v2.0 2019 : WebAuthn Level 1 : ecdaa attestation format 2020 : TCG PTP v1.04 : ECDAA made optional 2021 : WebAuthn Level 2 : ecdaa format removed 2024 : CoSNIZK : Lattice DAA at 38 kB

To answer the question of why, we have to start where every TPM attestation story does -- with the architecture DAA was invented to replace.

2. The Privacy-CA Trap (1999-2003)

TPM 1.1, originally published by the Trusted Computing Platform Alliance in 2002 and taken over in April 2003 by the Trusted Computing Group that replaced it [@wiki-tcg], had a privacy story. The story was a broker called the Privacy Certificate Authority. The story had a single load-bearing flaw, and the field spent the next two decades writing papers about it.

The mechanism, paraphrased from the Wikipedia summary that itself paraphrases the TCG spec, is five steps [@wiki-daa]:

A TPM manufacturer embeds a 2048-bit RSA Endorsement Key (EK) at the time the chip is provisioned, along with a certificate EKCert signed by the manufacturer [@wiki-tpm].
The platform generates a fresh Attestation Identity Key (AIK) inside the TPM.
The platform sends (EKCert, AIKpub, proof-of-binding) to a Privacy-CA.
The Privacy-CA validates the EK certificate, confirms the binding proof, and issues Cert(AIKpub) signed by the CA.
The platform uses the AIK to sign actual attestations -- platform configuration register quotes, boot logs, key-attestation certificates -- and presents Cert(AIKpub) to relying parties as proof that the AIK is TPM-resident.

The Endorsement Key is the long-lived, manufacturer-certified asymmetric key burned into the TPM at provisioning. Its public half is the chip's permanent cryptographic identity; its certificate, signed by the manufacturer, is the platform's proof that the chip is a real TPM. The Attestation Identity Key is a short-lived TPM-resident key generated for signing attestation outputs. Because the EK is uniquely identifying, the AIK exists to absorb attestation traffic on the EK's behalf: the EK certifies the AIK once (or once per Privacy-CA), and the AIK does the signing thereafter [@azure-attestation]. The broker introduced by the TCG in TPM 1.1 to separate the unique-by-design Endorsement Key from the per-attestation Attestation Identity Key. The Privacy-CA verifies the EK certificate, attests that the AIK is bound to a real TPM, and issues a certificate on the AIK that the platform then uses to sign quotes. The privacy property is operational, not cryptographic: the CA promises not to log the linkage between EK and AIK [@wiki-daa].

The architecture has three structural problems, and the Wikipedia summary of the original TPM 1.1 design makes the most uncomfortable one explicit: "privacy requirements may be violated if the privacy CA and verifier collude" [@wiki-daa]. The Privacy-CA can link AIKs to EKs. It promises not to. That promise is enforceable by audit, by legal contract, by reputation, and by the threat of a regulator finding out. It is not enforceable by mathematics.

The other two problems are availability and concentration. Wikipedia again, on the TPM 1.1 design: "the privacy CA must take part in every transaction" [@wiki-daa]. Every AIK certification is a synchronous network round-trip to a single CA. The CA is therefore a high-availability target, a high-value attack target, and a high-throughput service obligation for whoever decides to operate one. The FIDO Alliance, fifteen years later, wrote down the operational consequences of that obligation with surprising frankness in its ECDAA Algorithm v2.0 specification [@fido-ecdaa-v2]:

An alternative approach to 'group' keys is the use of individual keys combined with a Privacy-CA [TPMv1-2-Part1]. Translated to FIDO, this approach would require one Privacy-CA interaction for each Uauth key. This means relatively high load and high availability requirements for the Privacy-CA. Additionally the Privacy-CA aggregates sensitive information (i.e. knowing the relying parties the user interacts with). This might make the Privacy-CA an interesting attack target. -- FIDO ECDAA Algorithm v2.0 Implementation Draft, 2018

The FIDO document was written in 2018, but it is operating on a problem that was current in 2003. The Privacy-CA model concentrates the very identifiers it is supposed to anonymize. A regulator with a subpoena, an insider with a database query, or a successful attacker with persistent access can recover the linkage the CA promised to forget. In 2003 the TCG named the missing primitive -- a direct attestation scheme whose anonymity was guaranteed by math rather than a CA's promise -- and the cryptographic literature went to work on it.The privacy-advocate criticism of the TPM in the 2003-2005 window came from a small but well-placed group. Ross Anderson at Cambridge had been writing critical surveys of trusted computing since 2002, both in a continuously updated TCPA FAQ [@anderson-tcpa-faq] and in a PODC 2003 paper "Cryptography and Competition Policy -- Issues with Trusted Computing" [@anderson-tcpa-paper]. Seth Schoen and the Electronic Frontier Foundation published a 2003 white paper, "Trusted Computing: Promise and Risk," on the privacy implications of trusted-computing-class identifiers [@eff-schoen-2003]. European data-protection authorities had begun studying TCPA in the same window [@anderson-tcpa-faq]. The DAA construction was, by 2004, a research community answer to these criticisms more than it was a TCG product requirement.

The Privacy-CA architecture is still production architecture in 2026. Microsoft Azure Attestation runs a Privacy-CA in everything but name. Its public documentation describes a CA-mediated flow whose five-step shape mirrors the TPM 1.1 Privacy-CA almost line for line: "A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM" [@azure-attestation]. The full verbatim Microsoft Learn quote is reproduced in §9, where it anchors the Windows case study.

The same pattern repeats across every hyperscaler. AWS Nitro Enclaves issues PKIX certificates rooted in AWS-operated CAs that bind enclave measurements to instance identifiers [@aws-nitro-attestation]. Apple App Attest issues per-app device identifiers from Apple-operated infrastructure [@apple-app-attest]. Google Play Integrity ships integrity verdicts signed by Google-operated infrastructure [@google-play-integrity]. In 2026 the operational descendants of TPM 1.1's Privacy-CA broker run the production attestation surface of every consumer-grade cloud platform.

By 2003 the field had a name for the missing primitive: a direct attestation scheme that delivered the Privacy-CA's anonymity property cryptographically rather than operationally. What followed was an academic lineage that had been quietly building, for a decade and a half, the primitives that lineage required.

3. The Pre-History: Group Signatures Before DAA (1991-2003)

Direct Anonymous Attestation was invented in 2004. The primitive it was built from was invented in 1991, in a paper that had nothing to do with TPMs.

David Chaum and Eugene van Heyst presented "Group Signatures" at EUROCRYPT 1991 [@chaum-vh-1991]. The construction was a curiosity: a digital signature scheme in which any one of n group members could sign on behalf of the group, the verifier could check that some member of the group signed, and a designated group manager could, given a signature, recover the identity of the signer. The use case Chaum and van Heyst had in mind was organizational: a company spokesperson signs press releases on behalf of the company; the CEO can, if necessary, recover which spokesperson signed which release.

A digital signature scheme in which any one of `n` group members can sign on behalf of the group such that (i) verifiers can confirm "some member of the group signed this message" using a single group public key, (ii) verifiers cannot determine which member signed, and (iii) a designated group manager, holding a trapdoor, can *open* any signature to recover the original signer. Chaum and van Heyst introduced the primitive in 1991; the next decade was about making the construction efficient enough to deploy [@wiki-group].

The 1991 construction had a fatal practical property: signature size was linear in the size of the group. A 10,000-member group meant a 10,000-component signature. For a primitive intended to handle organizational use cases at organizational scale, this was a non-starter. The next decade is a sequence of papers, each adding one property to the previous, each addressing the issue that made the previous unfit for deployment.

Jan Camenisch and Markus Stadler, at CRYPTO 1997, gave the field its first constant-size group signature -- signature length independent of the number of group members, suitable for groups of arbitrary size [@camenisch-stadler-1997]. Their construction relied on a particular kind of zero-knowledge proof of knowledge of a discrete logarithm whose form would, six years later, become the structural template for DAA's Sign protocol. The CS97 scheme had its own problems -- the security proof made strong assumptions, and the construction was vulnerable to "framing" attacks where a malicious group manager could forge signatures attributable to other members -- but the size barrier was broken.

Three years later, at CRYPTO 2000, Giuseppe Ateniese, Jan Camenisch, Marc Joye, and Gene Tsudik introduced what the field now calls the ACJT scheme [@acjt-2000]. The Springer abstract is unusually direct about what ACJT contributed: the paper "introduces a new provably secure group signature... proven secure and coalition-resistant under the strong RSA and the decisional Diffie-Hellman assumptions." The property that made ACJT important was coalition resistance -- a formal guarantee that no subset of k group members, no matter how large, could collude to produce a valid signature that did not open to one of them. ACJT's security proofs were the first in the group-signature literature to treat coalitions as a first-class threat model.Coalition resistance as a property predated ACJT, but coalition resistance as a formal property -- something proven against an adversary defined in a complexity-theoretic model -- did not. Camenisch and Michels in 1998, and several authors in between, had given coalition-resistance arguments that depended on heuristic assumptions about the underlying hash function or signature scheme [@camenisch-michels-1998]. ACJT 2000 gave the proof under the strong RSA assumption, which by 2000 was a well-understood number-theoretic conjecture that the cryptographic community treated as a load-bearing security primitive.

ACJT was the construction the DAA designers built on. The reason is in its protocol structure. The ACJT signer holds a signed credential on a secret membership value f. Signing a message means producing a non-interactive zero-knowledge proof of knowledge of (f, signature) satisfying the group manager's verification equation, bound to the message. The proof is constant-size; the verifier checks it against the group public key and learns only that some member signed.

Jan Camenisch and Anna Lysyanskaya, working in parallel, were building the other primitive DAA would need. Their EUROCRYPT 2001 paper introduced what the field now calls CL credentials -- a digital signature scheme with two unusual properties [@cl-2001]. First, a signer can issue a signature on a committed value Commit(f) without seeing f itself, so the holder of f ends up with a signature on something the signer never learned. Second, a holder of (f, signature) can prove possession of that pair in zero knowledge, revealing neither f nor the signature itself.

A digital signature scheme with two algorithmic protocols on top of the standard sign-and-verify pair. A *blind issuance* protocol lets a signer issue a signature on a value the signer cannot see (the holder commits to a value `f` and proves the commitment well-formed; the signer signs the commitment without learning `f`). A *proof-of-possession* protocol lets a holder of `(f, signature)` prove "I have a CL signature from this signer on some value" without revealing either the value or the signature. CL signatures are the primitive a DAA Issuer uses to issue the long-lived attestation credential the TPM keeps after the Join protocol [@cl-2001] [@cl-2004].

CL signatures gave the field a clean way to issue a member credential without the issuer ever learning the member's secret -- exactly the property a TPM needs when receiving a long-lived DAA credential from an issuer who, by design, must remain unable to recognize the TPM later. Camenisch and Lysyanskaya's CRYPTO 2004 paper extended the construction to bilinear pairings [@cl-2004], a generalization that would matter for the elliptic-curve DAA schemes of the next decade.

flowchart LR A["Chaum-van Heyst 1991
Primitive defined
Linear-size signatures"] --> B["Camenisch-Stadler 1997
Constant-size signatures"] B --> C["ACJT 2000
Coalition resistance
Strong RSA + DDH"] C --> D["Brickell-Camenisch-Chen 2004
DAA-RSA"] A --> E["Camenisch-Lysyanskaya 2001
Blind issuance
Proof of possession"] E --> D E --> F["Camenisch-Lysyanskaya 2004
CL on bilinear pairings"] F --> G["Chen-Page-Smart 2010
EC-DAA"]

A sibling lineage was building in parallel. Dan Boneh, Xavier Boyen, and Hovav Shacham presented "Short Group Signatures" at CRYPTO 2004 [@bbs-2004]. The BBS scheme used bilinear pairings to compress group signatures to a few hundred bytes -- signatures, in the abstract's words, "approximately the size of a standard RSA signature with the same security." BBS gave the W3C Verifiable Credentials community a primitive that descendants like BBS+ would later use for selective-disclosure credentials. BBS itself did not become the TPM construction. The DAA designers, working from ACJT and CL, took a different path.

By 2003 the primitives existed. The TPM community had the use case. The two communities had not yet met. In 2004, three authors at three different industrial labs made the introduction.

4. The Breakthrough: DAA-RSA (Brickell-Camenisch-Chen, CCS 2004)

The introduction happened at ACM CCS 2004. Ernie Brickell at Intel, Jan Camenisch at IBM Zurich, and Liqun Chen at HP Labs Bristol published "Direct Anonymous Attestation" [@bcc-2004]. The IACR ePrint abstract makes the structural contribution explicit:

Direct anonymous attestation can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable. Moreover, DAA allows for pseudonyms, i.e., for each signature a user (in agreement with the recipient of the signature) can decide whether or not the signature should be linkable to another signature. DAA furthermore allows for detection of 'known' keys: if the DAA secret keys are extracted from a TPM and published, a verifier can detect that a signature was produced using these secret keys. -- BCC 2004 (IACR ePrint 2004/205)

Two design moves did the work, and naming them clearly is the first step in understanding why DAA solved the Privacy-CA problem.

The first move is a subtraction. Every prior group-signature scheme -- Chaum-van Heyst, Camenisch-Stadler, ACJT, BBS -- gave a designated group manager the power to open a signature and recover its signer. For a TPM attestation primitive, the opening capability is undesirable. An issuer who can open is morally a Privacy-CA: it has the linkage information the architecture is supposed to forget. BCC 2004 removes the opening capability entirely. No party can de-anonymize a signature -- not the issuer, not the verifier, not a coalition of either. The IACR ePrint 2004/205 abstract captures the consequence: DAA "can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable" [@bcc-2004]. Once the credential is issued, the issuer has no cryptographic handle left to break the user's privacy.

A zero-knowledge attestation primitive in which a TPM holds a long-lived membership credential (the output of a one-time Join protocol with an Issuer) and can subsequently produce signatures that prove "the signing TPM holds a credential certified by this Issuer" without revealing which TPM signed and without an online third party in the verification path. No party -- not the Issuer, not the Verifier, not a coalition of either -- can de-anonymize a DAA signature. The construction first appeared in Brickell-Camenisch-Chen 2004 [@bcc-2004].

The second move is a substitution. Where prior schemes traced misbehaving signers by manager-controlled opening, DAA introduces a user-controlled linkability mechanism through what the BCC paper calls a basename-keyed pseudonym. The signing TPM holds a secret membership value f. The verifier supplies a basename bsn (a string the verifier picks per session, per relying party, or per global epoch). The TPM derives a pseudonym

$$N_V = \zeta^f \pmod \Gamma, \qquad \zeta = H_\Gamma(\text{bsn})$$

where H_Γ hashes the basename into a generator of a multiplicative group Γ. The pseudonym N_V has two structural properties. If the same verifier reuses the same bsn across sessions, signatures from the same TPM produce the same N_V, so the verifier can link them (and blacklist them if needed). If the verifier randomizes bsn per session, or sets bsn to the special value ⊥ indicating "no linkability," signatures from the same TPM produce different N_V values that are indistinguishable from random.

A DAA property in which the *verifier* chooses a basename `bsn` per session or per relying party. Signatures from the same TPM under the same basename produce the same pseudonym; signatures under different basenames produce pseudonyms indistinguishable from random. The TPM, not a group manager, controls which signatures are linkable to which others. The Bernhard-Fuchsbauer-Ghadafi-Smart-Warinschi 2013 paper gives the canonical formal model [@bfgsw-2013].

Together the subtraction and the substitution define the DAA contract. The Issuer issues a CL signature on the TPM's secret f during a one-time Join. The TPM thereafter holds the credential (f, A, e, v) -- the secret membership value plus the CL signature components. To sign a message m against a verifier-supplied basename bsn, the TPM:

Computes the pseudonym N_V = ζ^f mod Γ where ζ = H_Γ(bsn).
Randomizes the CL signature: picks a fresh w, computes T_1 = A · S^w mod n and T_2 = g^e · h^w mod n.
Produces a Fiat-Shamir non-interactive zero-knowledge proof of knowledge of (f, A, e, v, w) satisfying the CL verification equation

$$A^e \equiv Z / (R^f \cdot S^{v' + v''}) \pmod n,$$

binding the proof to the tuple (m, T_1, T_2, N_V).

A verifier checks the proof against the Issuer's public key. The verifier learns nothing about f, nothing about the TPM's identity, nothing about which CL signature was randomized -- and either gains a linkable pseudonym (if bsn was reused) or no linkability at all (if bsn was fresh).

The architectural picture, set against §2's Privacy-CA flow, makes the contrast vivid.

flowchart TD I["Issuer
(holds CL signing key)"] T["TPM
(holds secret f)"] V["Verifier
(holds Issuer pub key)"] I -.->|"one-time Join
CL signature on f
(blind, issuer never sees f)"| T T -->|"credential (f, A, e, v)
stored in TPM forever"| T T -->|"DAA-Sign(m, bsn)
= randomized credential + NIZK + N_V"| V V -->|"Verify against Issuer pub key
(no online interaction)"| V

This is the first aha. The reader entered §3 thinking "anonymity with manager-controlled traceability" was the goal of group signatures. They exit §4 understanding that for TPM attestation the goal is anonymity without any opener plus user-controlled, per-verifier linkability. The breakthrough is structurally a subtraction (remove the opener) plus a substitution (per-verifier basename pseudonyms in place of manager-controlled opening). It is not an addition.Eleven years after BCC 2004, Ben Smyth, Mark Ryan, and Liqun Chen ran a formal analysis of the original BCC construction and found a retroactive privacy bug [@smyth-ryan-chen-2015]. The bug allowed certain Issuer-coalition adversaries to link signatures across basenames in ways the original security argument had not anticipated. The bug was fixed in the 2008-2010 redesigns (specifically the BCL 2009 simplified-security-notions paper [@bcl-2009] and the CDL 2016 strong-Diffie-Hellman revisitation). The reader interested in why "we proved this in 2004" is not the same as "this is provably secure in 2026" should read SRC 2015 alongside the original BCC abstract.

On paper, the BCC 2004 construction solved the Privacy-CA trap. In practice, DAA-RSA was hard to ship. The CL signature in the original scheme used strong RSA moduli at 2048 bits. A single Sign operation took several seconds on the TPM 1.2 hardware of the time. The signature itself was approximately 2.5 kilobytes -- larger than the entire AIK signature output a Privacy-CA-mediated attestation produced. TPM 1.2 shipped DAA-RSA as an optional capability when revision 94 of the spec added it in 2005 [@tpm-library-spec]. Almost no platform integrator turned it on. The cryptography worked. The implementation budget did not.

The next decade was about making the construction small enough to deploy. The path was anything but straight.

5. The Evolution: From RSA-DAA to EC-DAA (2007-2013)

Six papers in seven years, two industrial branches, one dead end, one production scheme. Why was the EC-DAA story so much harder than it should have been?

The honest answer: the entire toolkit of pairing-based cryptography arrived at the same time the TPM industry needed it, and the field discovered in real time that not every choice of pairing was safe. The path from BCC 2004 to the construction the TPM 2.0 spec actually shipped runs through five waypoints, each addressing the problem the previous one created.

5.1 Brickell-Li 2007: EPID and signature-based revocation

In 2007 Ernie Brickell, now leading Intel's trusted-computing work, and Jiangtao Li published "Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities" at WPES 2007 [@brickell-li-epid-2007]. The journal version appeared at IEEE TDSC in 2012 [@brickell-li-tdsc-2012]. The single feature EPID added was a revocation list called Sig-RL: a list of signatures the issuer wished to disavow. A verifier, given a signature σ and a Sig-RL containing entries σ_1, ..., σ_k, could prove that σ was not produced by the same TPM as any σ_i -- without learning the linking information itself.

EPID became Intel's production attestation primitive. Wikipedia records the deployment scale: "It has been incorporated in several Intel chipsets since 2008," and "at RSAC 2016 Intel disclosed that it has shipped over 2.4B EPID keys since 2008" [@wiki-epid]. EPID is what Intel SGX enclaves used to attest, before SGX attestation migrated to the vendor-CA DCAP architecture. EPID is what certain Intel-platform Widevine L1 implementations use to attest content-decryption modules. The Intel EPID SDK (the reference implementation) was eventually marked public-archive on GitHub [@epid-sdk]. The Wikipedia entry notes that the original EPID 2.0 specification was contributed by Intel into ISO/IEC 20008 and 20009 under royalty-free terms [@wiki-epid].

EPID is not exactly DAA. EPID is a DAA variant with the Sig-RL revocation layer added. The Chen-Page-Smart construction that TPM 2.0 actually ships is closer to BCC 2004 plus an elliptic-curve substrate; EPID 2.0 is closer to BCC 2004 plus EC plus Sig-RL plus Intel's specific basename and key-management conventions. The two converge at the cryptographic core and diverge at the deployment surface.

5.2 Brickell-Chen-Li 2008: the first pairing-based DAA

At the TRUST 2008 conference, Ernie Brickell, Liqun Chen, and Jiangtao Li published "A New Direct Anonymous Attestation Scheme from Bilinear Maps" -- the first DAA scheme constructed over bilinear pairings instead of strong RSA [@bcl-2008]. Signature size dropped by an order of magnitude relative to BCC 2004, from roughly 2.5 kilobytes to a few hundred bytes [@bcl-2008]. TPM-side sign time, on hardware that supported elliptic-curve arithmetic, came down from seconds to fractions of a second [@bcl-2008]. The construction used symmetric (Type-1) pairings -- pairings where the two input groups G_1 and G_2 are the same -- which the implementation community would, two or three years later, decide were too inefficient for production TPM hardware.

A function `e : G_1 × G_2 -> G_T` on three elliptic-curve subgroups satisfying *bilinearity* (for all integers `a, b` and points `P ∈ G_1, Q ∈ G_2`, `e(aP, bQ) = e(P, Q)^(ab)`) and *non-degeneracy*. Type-3 (asymmetric) pairings, in which `G_1 ≠ G_2` and no efficient homomorphism is known between them, are the production pairing for TPM 2.0 ECDAA because they admit faster implementations and tighter security reductions than Type-1 (symmetric) pairings. The Chen-Page-Smart 2010 construction is built on Type-3 pairings over Barreto-Naehrig curves [@cps-2010].

5.3 Chen-Morrissey-Smart 2008: the asymmetric proposal and its proof flaw

Pairing 2008 hosted the next move. Liqun Chen, Paul Morrissey, and Nigel Smart published "Pairings in Trusted Computing" [@cms-pairing-2008], proposing a DAA scheme on asymmetric Type-3 pairings -- the kind that admit Barreto-Naehrig curves and the speed-ups TPM hardware needed. The same authors published a companion ProvSec 2008 paper "On Proofs of Security for DAA Schemes" providing the security argument [@cms-provsec-2008].

Two years later, in Information Processing Letters, Liqun Chen and Jiangtao Li published "A note on the Chen-Morrissey-Smart Direct Anonymous Attestation scheme" [@chen-li-2010] showing that the CMS asymmetric-pairing construction had a flawed proof. The cryptographic intuition was correct; the proof technique used an assumption that did not hold in the asymmetric-pairing setting the construction relied on.The Chen-Morrissey-Smart episode is, in 2026, one of the most cited proof-flaw stories in pairing-based cryptography precisely because the construction was simple and the flaw was subtle. The mathematical content of the scheme was salvageable. The security argument was not. The lesson the field took away -- a proof in the symmetric-pairing model does not transfer to the asymmetric-pairing model without a separate argument -- has been a load-bearing convention in cryptographic publishing since.

5.4 Chen-Page-Smart 2010: the scheme TPM 2.0 actually ships

The fix arrived at CARDIS 2010 in Passau in April 2010 [@cardis-book]. Liqun Chen, Dan Page, and Nigel Smart published "On the Design and Implementation of an Efficient DAA Scheme" [@cps-2010] [@cps-2010-eprint], proposing an asymmetric-pairing DAA over Barreto-Naehrig curves with a Sign protocol split between the TPM and the host. The TPM, in the new design, performed only the cryptographic operations that absolutely required custody of the secret f: it produced commitment points and computed a Schnorr-style response over those commitments. The host -- a comparatively powerful general-purpose CPU sitting in front of the TPM -- composed the Fiat-Shamir challenge, performed the pairing computations, and assembled the final signature.

The Chen-Page-Smart construction is the scheme TPM 2.0 actually ships. The Wikipedia DAA article makes the attribution direct, in a sentence that is itself the most-cited single primary-source extract in this article:

Chen, Page, and Smart proposed a new elliptic curve cryptography scheme using Barreto-Naehrig curves. This scheme is implemented by both EPID 2.0 and the TPM 2.0 standard. -- Wikipedia, *Direct Anonymous Attestation* [@wiki-daa] A family of pairing-friendly elliptic curves with embedding degree 12, parameterized by an integer `u` to admit Type-3 pairings whose arithmetic is fast enough for resource-constrained devices [@bn-2006]. The curve identifier `TPM_ECC_BN_P256` (`0x0010`) is the specific 256-bit instance the TPM 2.0 Library Specification mandates for ECDAA, picked because of its pairing-friendly structure rather than as a NIST P-256 equivalent.

Six years after CPS 2010, Taechan Kim and Razvan Barbulescu (CRYPTO 2016) published "Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case," giving an improved sieve attack against pairing-friendly elliptic curves at the 256-bit BN level. The improvement dropped the practical security of BN-256 from roughly 128 bits to roughly 100 bits [@kim-barbulescu-2016]. The TCG normative text for TPM 2.0 ECDAA did not, as of late 2025, change the mandatory curve in response. This is the kind of cryptographic technical debt that lives quietly in deployed systems for a decade -- specs do not migrate on the same calendar as research moves.

5.5 BFGSW 2013 and SRC 2015: the formal closure

The cryptographic engineering of EC-DAA was done by 2010. What the field still owed itself was a clean security model: one definition of "secure DAA" that captured the user-controlled-linkability property and the TPM/host split, against which any candidate scheme could be evaluated.

In 2013 David Bernhard, Georg Fuchsbauer, Essam Ghadafi, Nigel Smart, and Bogdan Warinschi published "Anonymous attestation with user-controlled linkability" in the International Journal of Information Security [@bfgsw-2013] [@bfgsw-2013-eprint]. The BFGSW paper formalized the user-controlled-linkability property the BCC 2004 abstract had described in prose, introduced a clean separation of "pre-DAA signing" (TPM-side operations) from "DAA signing" (TPM + host composition), and proved the security of a representative construction in the resulting model.

In 2015, Ben Smyth, Mark Ryan, and Liqun Chen published the retroactive analysis that closed the BCC 2004 privacy bug [@smyth-ryan-chen-2015]. By 2015 the cryptography was, formally, settled.

In 2016 Jan Camenisch, Manu Drijvers, and Anja Lehmann revisited the construction at TRUST 2016 in "Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited" [@cdl-2016] [@cdl-2016-eprint], giving a tighter security argument under the q-SDH assumption and providing a fix for a Diffie-Hellman-oracle issue in the TPM 2.0 ECDAA interface that "One TPM to Bind Them All" would document in 2017 [@one-tpm-2017]. The CDL16 scheme is what most modern DAA library code references as the canonical construction.

flowchart LR BCC["BCC 2004
RSA-DAA
TPM 1.2"] --> BL["Brickell-Li 2007
EPID + Sig-RL
Intel SGX / Widevine"] BCC --> BCL["BCL 2008
Type-1 pairing DAA"] BCL --> CMS["CMS 2008
Asymmetric pairing
(broken by CL 2010)"] BCL --> CPS["CPS 2010
Type-3 BN-curve DAA
TPM 2.0 ECDAA"] CPS --> BFGSW["BFGSW 2013
Formal user-controlled
linkability model"] BFGSW --> CDL["CDL 2016
q-SDH revisitation
Canonical modern DAA"] BCC --> SRC["SRC 2015
Retroactive BCC
privacy bug"]

By 2013 the cryptography was complete. The standards organizations took the construction and made it official -- in two different specifications, on two parallel tracks.

6. The TPM 2.0 ECDAA Surface (2014-Present)

If you own a Windows laptop with a TPM 2.0, this section is the part of the chip you have never used. What does the spec actually say?

The TPM 2.0 Library Specification, the canonical document published by the Trusted Computing Group, is a four-part normative reference [@tpm-library-spec]. Part 1 (Architecture) describes the threat model and the mathematical primitives. Part 2 (Structures) defines the data types every TPM command accepts and returns. Part 3 (Commands) defines the commands themselves. Part 4 (Supporting Routines) gives a reference C implementation. The ECDAA surface lives across all four parts.

An algorithm identifier defined in TPM 2.0 Library Specification Part 2 and selectable from any `TPMT_SIG_SCHEME` field. A signing key tagged with `TPM_ALG_ECDAA` produces signatures using the Chen-Page-Smart 2010 elliptic-curve DAA construction. The same algorithm identifier appears in any signature-scheme negotiation point in the TPM 2.0 command surface [@tpm-library-spec]. The 256-bit Barreto-Naehrig curve identifier the TPM 2.0 Library Specification mandates for any ECDAA-capable signing key. BN-P256 is *not* NIST P-256: it is a pairing-friendly curve with embedding degree 12 whose group structure admits the Type-3 pairings the DAA verification equation requires. Implementations that confuse the two will produce signatures that verify against the wrong group. The command pair defined in TPM 2.0 Library Specification Part 3 that implements the Chen-Page-Smart 2010 split-protocol structure. `TPM2_Commit(keyHandle, P1, s2, y2)` returns commitment points `(K, L, E)` plus a `counter`. The host then computes the Fiat-Shamir challenge `c` over the message and the commitment points. `TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation)` returns the Schnorr-style response `s = r + c·f mod p`. The host assembles the final signature from the commitment points, the challenge, and the response [@tpm-library-spec].

The protocol split matters. The TPM, in the CPS 2010 construction, holds the secret f and must perform exactly two cryptographic operations on it: produce a freshly randomized commitment to f (via TPM2_Commit), and produce a Schnorr response that proves knowledge of f modulo the verifier's challenge (via TPM2_Sign). Everything else -- the pairing computations, the curve arithmetic in G_T, the Fiat-Shamir hash, the final signature assembly -- happens on the host CPU. This is the only reason the construction is practical on a TPM. A monolithic Sign that did pairing arithmetic inside the chip would be unshippable; the split offloads the expensive operations onto silicon that has them for free.

Note: The most common implementer mistake when working with TPM 2.0 ECDAA for the first time is to reuse the NIST P-256 ECDSA code path with the curve identifier swapped. The two curves share a bit length and a hash function and otherwise nothing. BN-P256 has a pairing-friendly group structure with embedding degree 12; NIST P-256 does not admit efficient pairings at all. Signatures produced by ECDSA over NIST P-256 will not verify against an ECDAA verifier expecting BN-P256, and the converse is true. The pairing requirement is what forces the BN curve choice; treat BN-P256 as a separate primitive with a separate code path.

The Join protocol -- the one-time exchange between the Issuer and the TPM that produces the long-lived credential -- piggybacks on a TPM 2.0 command pair already present in every Windows attestation flow: TPM2_MakeCredential and TPM2_ActivateCredential [@tpm-library-spec]. The Issuer wraps the DAA credential under an encryption key derived from the TPM's Endorsement Key, ensuring that only the legitimate TPM (the one that holds the EK private key) can decrypt the credential and bind it to its internal f.The choice of TPM2_ActivateCredential as the Join anchor is convenient. The same primitive that TPM 2.0 attestation-key certification flows use for AIK-binding gets reused for DAA-credential binding. An OEM that supports TPM2_ActivateCredential for ordinary AIK enrollment already has 80% of the firmware path the Join protocol needs. The difference is in what the Issuer ships back -- a per-TPM AIK certificate in the AIK case, an Issuer-randomized CL credential in the DAA case.

Part 1 Annex C.5 contains the informative mathematical description -- the actual ECDAA verification equation, the basename-pseudonym derivation, the proof-of-knowledge template. Part 3 contains the normative command definitions. An implementer who reads only the Part 3 command definitions without reading Annex C.5 will have correct byte-buffer-level semantics and no idea what the protocol is computing; an implementer who reads only Annex C.5 without the normative command definitions will have correct math and the wrong API.

The implementation surface, gathered into one place:

Artifact	Identifier / location	Source
Algorithm selector	`TPM_ALG_ECDAA = 0x001A`	TPM 2.0 Library Specification Part 2 [@tpm-library-spec]
Mandatory curve	`TPM_ECC_BN_P256 = 0x0010`	Part 2 [@tpm-library-spec]
First-round command	`TPM2_Commit(keyHandle, P1, s2, y2) -> (K, L, E, counter)`	Part 3 [@tpm-library-spec]
Second-round command	`TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation) -> signature`	Part 3 [@tpm-library-spec]
Join anchor	`TPM2_MakeCredential` / `TPM2_ActivateCredential`	Part 3 [@tpm-library-spec]
Math description	Part 1 Annex C.5 (informative)	Part 1 [@tpm-library-spec]
Optionality status	Optional since PTP v1.04 (Feb 2020); carried through v1.07 RC1 (Dec 2025)	TCG PC Client Platform TPM Profile changelog [@tcg-ptp]

sequenceDiagram participant V as Verifier participant H as Host (CPU) participant T as TPM V->>H: send basename bsn H->>T: TPM2_Commit(keyHandle, P1, s2, y2) T-->>H: (K, L, E, counter) H->>H: compute c = H(K, L, E, message, bsn) H->>T: TPM2_Sign(keyHandle, digest=c, scheme=ECDAA) T-->>H: response s = r + c*f mod p H->>H: assemble signature (K, L, E, c, s) H->>V: ECDAA signature V->>V: verify pairing equation

The TCG published the TPM 2.0 Library Specification in 2014. From 2014 through early 2020, the PC Client Platform TPM Profile -- the document that says "to ship a TPM 2.0 in a PC-class device, these algorithms must be present" -- listed TPM_ALG_ECDAA as mandatory-if-the-platform-supports-elliptic-curve-cryptography. In v1.04 (released February 2020) the TCG PTP working group made a quiet but consequential change. The changelog records the line verbatim: "Made TPM_ALG_ECDAA and TPM_ALG_ECSCHNORR optional." The same designation has carried through v1.06 RC1 (January 2025) and v1.07 RC1 (December 2025) [@tcg-ptp]. After February 2020, an OEM can ship a Windows-class TPM 2.0 platform that does not implement ECDAA at all and remain conformant.

Note: The Trusted Computing Group's resource pages (trustedcomputinggroup.org/resource/tpm-library-specification/ and trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/) reject non-browser User-Agents at the HTTP layer. This is a long-standing anti-bot policy. Citations in this article to the TPM 2.0 Library Specification and to the PC Client Platform TPM Profile point to the canonical URLs but are flagged in the verified-source registry as UNVERIFIED_FETCH; the verbatim changelog text was extracted under primary-source rules during the Stage 0a focus-premise audit and is the audit-of-record for the optionality claim. The downstream accuracy and fact-check stages of this pipeline carry the same caveat forward.

The Pluton question is the second hedge. Microsoft Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms since AMD's Ryzen 6000 in 2022, in AMD Ryzen 7040 (Phoenix) in 2023, in Qualcomm Snapdragon X Elite in 2024, and in Intel Core Ultra (Meteor Lake, December 2023; Lunar Lake, September 2024) and successive Intel Core Ultra generations. Pluton exposes a TPM 2.0 personality. The Microsoft Learn documentation page enumerates the cryptographic algorithms the processor exposes and the platform-security primitives it implements [@pluton].

The page contains zero occurrences of ECDAA or TPM_ALG_ECDAA. The honest framing here is not "Pluton does not implement ECDAA" -- the documentation neither confirms nor denies it -- but "Pluton's published surface does not advertise ECDAA." That is the hedged statement this article carries from its opening to its FAQ.

The runnable demonstration below is educational -- Microsoft ships no BCryptDirectAnonymousAttestation, no NCryptDaaSign, no Windows API at all that exposes ECDAA from a user-mode application. The code shows the logic an admin or platform engineer would follow when probing a TPM's reported algorithm set, not a working call against any shipping Windows API.

{` // Logic only. Microsoft ships no Windows API that surfaces TPM_ALG_ECDAA. // In practice an admin would parse the output of Get-TpmEndorsementKeyInfo // or use a vendor-specific tool to inspect the TPM's algorithm capability table. const TPM_ALG_ECDAA = 0x001A; const TPM_ECC_BN_P256 = 0x0010;

function probeECDAA(tpmAlgList, tpmEccCurveList) { const hasECDAA = tpmAlgList.includes(TPM_ALG_ECDAA); const hasBN256 = tpmEccCurveList.includes(TPM_ECC_BN_P256); if (!hasECDAA) return 'no ECDAA: chip omits algorithm 0x001A'; if (!hasBN256) return 'ECDAA without BN-P256: nominally compliant, practically unusable'; return 'ECDAA + BN-P256 present (Join still requires Issuer infrastructure)'; }

// Example: a Pluton-class chip whose published surface does not advertise ECDAA. const plutonLike = [0x0001 /* RSA /, 0x0008 / SHA-256 /, 0x0023 / ECDSA /]; console.log(probeECDAA(plutonLike, [0x0003 / NIST P-256 */])); // -> "no ECDAA: chip omits algorithm 0x001A"

// Example: a discrete Infineon SLB9670 TPM 2.0 (vendor docs list ECDAA + BN-P256). const discreteTpm = [0x0001, 0x0008, 0x0023, TPM_ALG_ECDAA]; console.log(probeECDAA(discreteTpm, [0x0003, TPM_ECC_BN_P256])); // -> "ECDAA + BN-P256 present (Join still requires Issuer infrastructure)" `}

The spec was written. The chips shipped. The TCG was satisfied. So why does no one verify ECDAA signatures?

7. The Standards Bridge: ISO/IEC 20008 and 20009

There is a difference between a TCG specification section number and an ISO/IEC mechanism identifier. The difference is the price of admission to a Common Criteria protection profile and to most government procurement contracts.

ISO/IEC 20008 is the international-standards anchor for anonymous digital signatures. It comes in three parts. Part 1 ("General") sets the framework and terminology [@iso-20008-1]. Part 2 ("Mechanisms using a group public key") catalogues the specific anonymous-signature schemes the international community has standardized -- and Mechanism 4 is the EPID-derived elliptic-curve DAA construction that aligns with the TPM 2.0 ECDAA surface [@iso-20008-2]. Part 3 ("Mechanisms using multiple public keys") catalogues a different family of schemes that is not the focus of this article.

The international-standards series titled "Information technology -- Security techniques -- Anonymous digital signatures." Part 1 (general framework) and Part 2 (mechanisms using a group public key) were both published in 2013. Mechanism 4 in Part 2 standardizes EPID-derived elliptic-curve DAA. ISO/IEC 20008 is the bibliographic anchor cited by Common Criteria protection profiles, FIPS 140-3 module-validation evidence, and government procurement specifications that need to reference a *named, internationally agreed* anonymous-signature mechanism rather than a vendor-specific construction [@iso-20008-2].

A note on the title. Earlier drafts of this article carried the title of ISO/IEC 20008-2 as "anonymous signatures with message recovery." That phrasing belongs to a different standard, ISO/IEC 9796. The verified ISO catalogue title for 20008-2 is, verbatim, "Information technology -- Security techniques -- Anonymous digital signatures -- Part 2: Mechanisms using a group public key" [@iso-20008-2].

ISO/IEC 20009 is the companion standard for authentication. Where 20008 standardizes signatures, 20009 standardizes the challenge-response protocols that wrap signatures into entity-authentication exchanges. Part 2 ("Mechanisms based on signatures using a group public key") is where TPM-style attestation lives in ISO terminology [@iso-20009-2]. A FIDO authenticator or a TPM-backed Kerberos client that performs an attested authentication is, in ISO-speak, executing a 20009-2 mechanism that wraps a 20008-2 signature.

Intel held patents on the EPID construction. In contributing the EPID 2.0 algorithm to ISO/IEC 20008 and 20009, Intel made the underlying intellectual property available under royalty-free (RAND-Z) terms. The Wikipedia EPID article records the contribution and notes that EPID "complies with international standards ISO/IEC 20008 / 20009" [@wiki-epid]. The licensing structure mattered: it is what made the construction acceptable to the FIDO Alliance, to the TCG for the TPM 2.0 ECDAA surface, and to the European procurement community whose conformance regimes treat royalty-bearing cryptographic primitives differently from royalty-free ones. Exact licensing-event dates are not directly indexed in publicly fetchable Intel materials; this paragraph is inference-grade reconstruction from the Wikipedia citation chain.

The procurement reason ISO standardization mattered is structural. A Common Criteria Protection Profile cannot, in the general case, reference a TCG specification section number. It can reference an ISO mechanism identifier. The Federal Information Processing Standards 140-3 evidence package for a cryptographic module must, in many cases, demonstrate that the cryptographic primitives the module implements are members of an internationally recognized standard family. The European Cyber Resilience Act, drafted in 2024 and applicable in stages from 2027 onward, treats compliance with a recognized international standard as one of the routes to a presumption of conformity. ISO/IEC 20008-2 Mechanism 4 is the door TPM 2.0 ECDAA walks through to be admissible in those regimes.

Standardization was complete by 2014. Cryptographic primitive: CPS 2010. Security model: BFGSW 2013. ISO mechanism: 20008-2 Mechanism 4. TPM normative surface: TPM_ALG_ECDAA, TPM_ECC_BN_P256, TPM2_Commit, TPM2_Sign. Every box was checked. The next question -- the one the standardization community could not answer on its own -- was whether anyone would write a verifier.

8. The FIDO Bet That Failed (2017-2021)

In 2018, the FIDO Alliance bet that ECDAA was the missing privacy story for WebAuthn. Three years later, W3C took the bet off the table.

The bet was not casual. FIDO had a real problem. WebAuthn authenticators -- the YubiKey hardware tokens, the Microsoft Hello platform authenticators, the Touch ID and Face ID modules -- need to attest that they are genuine hardware. The attestation surface FIDO Alliance had inherited from U2F was Basic Attestation: every authenticator in a manufacturing batch of 100,000 or more units shared one attestation key [@fido-cert-levels], so a relying party that checked the attestation learned only "this is one of 100,000-plus YubiKey 5 NFCs," not which device specifically. The cohort-size rule gave Basic Attestation a workable operational privacy property. But there was an architectural fork in the road for an organization that wanted cryptographic attestation privacy without the cohort-key fan-out problem.

FIDO Alliance picked the cryptographic fork. The FIDO ECDAA Algorithm v2.0 specification was published as an Implementation Draft on February 27, 2018 [@fido-ecdaa-v2]. The document is the most carefully written specification of the DAA contract from a deployment perspective; the editor was Rolf Lindemann at Nok Nok Labs. The motivation section we have already quoted in §2 names the Privacy-CA failure mode in unusually direct terms.

WebAuthn Level 1 reached W3C Recommendation status on March 4, 2019 [@webauthn-1]. Section 8 defined six attestation statement formats by fmt identifier: packed, tpm, android-key, android-safetynet, fido-u2f, and none. ECDAA was not a separate format; the WebAuthn-1 §6.4.4 attestation-type list (Basic, Self, AttCA, ECDAA, None) carried ECDAA as an attestation type supported within the packed and tpm formats. An independent verification of the live HTML returns 63 occurrences of the string "ecdaa" in the Level 1 Recommendation -- ECDAA had its own type identifier, its own signing logic, and its own verification procedure embedded inside the two formats that mattered [@webauthn-1].

WebAuthn Level 2 reached W3C Recommendation status on April 8, 2021 [@webauthn-2] [@wiki-webauthn]. The same independent verification against the live Level 2 HTML returns zero occurrences of "ecdaa." Every reference -- the type identifier, the signing rules, the verifier procedure that the packed and tpm formats invoked -- was removed in a single editorial pass. The Yubico migration guide for its Java WebAuthn server library makes the vendor view explicit: "This attestation type was removed from WebAuthn Level 2. ECDAA support has not been implemented in this library, so this value could in practice never be returned" [@yubico-migration].

Why did the bet fail? Four reasons, each visible from the public record.

First, no major browser ever shipped an ECDAA verifier inside the packed or tpm statement format paths. Chromium, Firefox, and Safari implemented WebAuthn with packed, tpm, fido-u2f, and android-safetynet attestation, but the ECDAA branch within packed and tpm stayed unimplemented. The Yubico migration guide quoted above is the vendor-side confirmation of an industry-wide outcome [@yubico-migration].

Second, the largest authenticator vendors picked the Basic and AttCA attestation types instead of ECDAA. YubiKey 5 series ships with the packed format using a Basic Attestation key shared across a 100,000+-unit cohort [@yubico-yk5-attestation] [@fido-cert-levels]. Feitian, Google Titan, and other major FIDO2 authenticator vendors ship Basic Attestation under the same FIDO certification-policy cohort rule [@fido-cert-levels]. Microsoft Hello platform authenticators on Windows TPM-backed devices use the tpm attestation statement format with an AIK that a Microsoft-operated CA certifies -- the AttCA type, functionally a Privacy-CA [@ms-hello-doc] [@azure-attestation]. The vendor base from which a WebAuthn relying party would actually see an attestation statement, in practice, never produced an ECDAA one.

Third, FIDO ECDAA v2.0 never advanced beyond Implementation Draft. The URL slug for the document literally encodes its status: fido-v2.0-id-20180227 -- the id-20180227 segment names the format <status>-<date>, and "id" is "Implementation Draft." It never reached "Proposed Standard" or "Approved Specification" in FIDO's process [@fido-ecdaa-v2]. A relying party making a long-term technology bet on an attestation statement format that has never advanced past Implementation Draft has no reason to invest in a verifier library.

Fourth, FIDO Basic Attestation's cohort-size rule (100,000+ authenticators per attestation group key, enforced contractually on the certified-authenticator side) gave the underlying privacy concern an operational answer [@fido-cert-levels]. A WebAuthn relying party that sees a Basic Attestation signature learns "this is one of at least 100,000 identical authenticators" -- a cohort large enough that the relying party cannot, in practice, recover individual identifying information from the attestation alone. The cohort rule does not require pairing arithmetic, does not need a verifier library, and works with the same packed and tpm attestation formats every relying party already implements.

The FIDO Basic Attestation cohort minimum is a particularly clean example of how operational rules can compete directly with cryptographic primitives. The privacy property a relying party wants -- "I cannot single out this device from its peers" -- can be obtained by (a) hardware-anchored zero-knowledge proofs that mathematically forbid linkage (cryptographic DAA), or (b) a contractual obligation that every batch of attestation keys covers at least 100,000 devices (FIDO Basic Attestation) [@fido-cert-levels]. The cryptographic answer is mathematically stronger. The operational answer is dramatically easier to debug, audit, and revoke. Production has consistently chosen the latter.

Key idea: ECDAA shipped chips. It never shipped verifiers. Standardization is necessary but not sufficient for production deployment: production cryptography needs verifier libraries, and verifier libraries are social phenomena -- they emerge from relying-party demand, SDK presence, incident-response tooling, and library-maintainer attention, none of which the cryptography itself produces. Cryptographic excellence does not predict deployment; library availability does.

This is the second aha. The reader entered §8 believing that a standardized cryptographic primitive backed by FIDO, three browser vendors, and a publicly authored attestation format would deploy. They exit understanding that ECDAA standardized everything except the social machinery -- and the social machinery is where production attestation actually lives.

If a consortium with FIDO's privacy mandate, browser-vendor coalition, and authenticator-vendor base could not generate enough relying-party momentum to keep ECDAA in WebAuthn, what chance did the silent option in TPM 2.0 ever have? The answer requires walking the Microsoft attestation stack.

9. Windows: A Billion Chips, Zero Production Use (2014-Present)

Microsoft has shipped over a billion Windows TPM 2.0 platforms [@ms-pluton-blog] [@wiki-windows-11]. Microsoft has not shipped a Windows DAA API. The two facts are not in tension. They are the story.

The shipping Windows attestation stack is documented and unambiguous. Microsoft Azure Attestation is the production-grade attestation service. Its public architecture document describes the protocol in five paragraphs that read, line for line, like TPM 1.1 from 2003 [@azure-attestation]:

"Every TPM ships with a unique asymmetric key called the endorsement key (EK)... A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... A device proves to the CA that the key for which the certificate is being requested is cryptographically bound to the EKPub and that the TPM owns the EKPriv. The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM."

The architecture is the Privacy-CA architecture. The Microsoft-operated CA inputs an EK certificate and outputs a JWT that downstream Microsoft services (Defender for Endpoint device-compliance, Intune Conditional Access policies, Entra ID conditional access, customer-defined Azure Attestation policies) consume. The Windows Health Attestation Service, the older Microsoft surface that predated Azure Attestation, used the same broker model with different deployment shape. The Defender for Endpoint device-compliance flow that gates Conditional Access on attested TPM boot state consumes WHAS or Azure Attestation JWTs, not raw DAA quotes.

Microsoft Pluton's published surface tells the same story from the silicon side. Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms. Its Microsoft Learn page enumerates the cryptographic algorithms and platform-security primitives the processor exposes [@pluton]. The page is exhaustive about TPM 2.0 baseline algorithms (RSA-2048, ECDSA over NIST P-256, SHA-2 family). It contains zero occurrences of ECDAA, of TPM_ALG_ECDAA, or of any phrase like "anonymous attestation." Insufficient public evidence to assert that Pluton implements ECDAA; sufficient evidence to assert that Pluton's published surface does not advertise it.

The Windows API surface gap is the third piece of evidence. The TPM Base Services (Tbsi_* functions in Tbs.dll) expose TPM2_Commit and TPM2_Sign to user-mode applications -- but only as raw command-buffer submissions. There is no BCryptDirectAnonymousAttestation. There is no NCryptDaaSign. There is no Web Authentication API wrapper that surfaces ECDAA.

The TPM Platform Crypto Provider (PCP) that Windows ships as part of the Cryptography Next Generation (CNG) framework supports RSA and ECDSA TPM-backed keys but does not surface ECDAA. The TSS.MSR open-source TPM stack from Microsoft Research does not ship a DAA wrapper. An application developer who wants ECDAA on Windows today writes raw TBS_SUBMIT_COMMAND byte buffers against the documented TPM 2.0 command numbering, manages the Join protocol against an Issuer of their own provisioning, and verifies the resulting signatures with a library they wrote themselves or pulled from a research-grade implementation.

The interesting question is why. Microsoft has never published a "we considered DAA and chose the broker model because..." statement. Treating that absence honestly, the four reasons below are inferences from observable architecture decisions, not Microsoft-engineer-published rationales. The article labels them as such.

First, operational simplicity. A hosted CA with audit logs is more debuggable than a per-relying-party DAA verifier with no central audit point. When a device fails attestation in production, the on-call engineer reading the Azure Attestation logs can answer "why did this device fail?" in seconds; the same question against a DAA verifier requires reasoning about pairing arithmetic, basename derivation, and Issuer-credential validity. Engineering organizations choose architectures whose failure modes they can debug.

Second, revocation economics. A Privacy-CA can revoke an AIK by removing one certificate from its issued-certificate store. Revoking a DAA credential, in the construction TPM 2.0 ships, requires either EPID-style signature-based revocation -- which the TPM 2.0 ECDAA scheme does not provide -- or a private-key list distributed to every relying party (extracting the private key from the misbehaving TPM is presumed possible after compromise, and verifiers then check that the signing key is not on the list). The CA's revocation primitive is a database delete. The DAA revocation primitive is an SDK rollout to every consumer of the verification library.

Third, the relying-party stack. DAA verifier libraries are not present in any mainstream cloud platform's SDK. The .NET CryptoNG surface, the Java JCA, the Python cryptography library, the Go crypto standard library, the Rust ring and dalek ecosystems -- none ship an ECDAA verifier. X.509 / PKI verifier libraries, by contrast, are everywhere. A relying party building on top of mainstream SDKs gets PKI verification for free; gets DAA verification for nothing close to free.

Fourth, the Windows API surface gap is itself the obstacle. Adding a BCrypt / NCrypt / WebAuthn DAA wrapper to Windows requires designing a new key-storage provider contract, defining the JOIN-protocol service interface, writing the conformance test suite, drafting the security documentation, and rolling it out on the Windows release calendar. That is a project the size of Windows Hello's. Microsoft has not, to public knowledge, prioritized it.

flowchart TD HW["TPM 2.0 hardware
(discrete or Pluton)
TPM_ALG_ECDAA may be present"] TBS["TPM Base Services
(Tbs.dll, kernel)"] PCP["TPM Platform Crypto Provider
(BCrypt / NCrypt)
RSA and ECDSA only"] AZ["Microsoft Azure Attestation
(Privacy-CA architecture)"] WHAS["Windows Health Attestation Service
(Privacy-CA architecture)"] RP["Intune / Defender / Entra
Conditional Access enforcement"] HW --> TBS TBS --> PCP PCP --> AZ PCP --> WHAS AZ --> RP WHAS --> RP HW -.->|"ECDAA path exists
no Windows API"| HW

The deeper reading -- the one that makes Microsoft's choice look structural rather than accidental -- starts from a comparison the four inferences above already pointed toward.

Key idea: Privacy-CA brokers and DAA solve the same problem -- prove the TPM is genuine without disclosing which TPM. They differ only in where the trust assumption lives. The broker treats privacy as an operational policy (the CA promises not to log, audit logs prove it kept the promise, regulators enforce the promise). DAA treats privacy as a mathematical property (the issuer cannot link, period, no audit needed). The architecture that wins in production is the one with the smaller operational surface, not the one with the better cryptographic guarantee.

This is the third aha. The reader entered §9 believing that cryptographic superiority should eventually win in production, and that Microsoft's non-adoption of DAA must be an oversight or a missed product opportunity. They exit understanding that the deployment-economics asymmetry is structural: a broker-mediated attestation flow reduces, end-to-end, to standard X.509 plumbing every cloud SDK already ships, while a DAA-mediated flow requires bespoke verifier libraries, bespoke revocation infrastructure, bespoke debugging tooling, and bespoke incident-response runbooks. Cloud-platform organizations have spent the last ten years building world-class operational machinery for X.509 attestation. They will not throw it away for a cryptographic property no compliance regime currently demands.

Note: The four reasons compound. The broker model gives a single audit point, a database-delete revocation primitive, an SDK that ships in every major language, and a debugging story the on-call engineer can walk through at 3 a.m. DAA gives mathematical privacy and requires every one of those operational properties to be rebuilt from scratch. Cloud platforms have, repeatedly and consistently, picked the architecture whose operational properties are easier to ship -- not because they do not understand the cryptographic alternative, but because the cryptographic alternative would require them to discard the operational machinery they already have. This is the structural reason DAA has stayed in firmware on a billion chips and out of production attestation flows on all of them.

If the broker calculus is this durable, is there any future world in which DAA wins? Two, and both are research-stage with decade-long horizons.

10. Theoretical Limits and Open Problems

What can DAA never do? Where does the next decade of research go? Three open problems organize the active research community in 2026.

10.1 What DAA cannot do

The first honest statement is the negative one. A correctly implemented DAA scheme does not prevent a compromised TPM from signing for the cohort it belongs to. The EK certificate attestation must be honest at manufacture time; if a TPM's secret membership value f leaks to an attacker (through fault injection, through side-channel extraction, through a firmware backdoor), the attacker can produce ECDAA signatures indistinguishable from legitimate ones until the TPM's f is added to a revocation list. The same constraint applies to every group-signature scheme.

A second hard limit is per-basename linkability. The user-controlled-linkability property gives a TPM the choice of linkable or unlinkable signing -- but once a verifier has seen the pseudonym N_V = ζ^f mod Γ for a particular (TPM, bsn) pair, the linkage for that basename is permanent. A misbehaving TPM that wants its history with a particular relying party forgotten cannot, by signing under a different basename, retroactively unlink past sessions.

A third limit is rogue-key scalability. The TPM 2.0 ECDAA scheme detects rogue keys by checking each signature against a list of compromised-f values the verifier maintains. For small lists this is cheap. For very large lists -- imagine a deployment where 1% of the chip population leaks f to attackers and the verifier must check every signature against ten million revoked values -- the constant factor matters. EPID's Sig-RL mechanism uses signature-based revocation that scales better; the TPM 2.0 ECDAA scheme does not include it.

10.2 The One-TPM-to-Bind-Them-All fix

In 2017 a team consisting of Jan Camenisch, Liqun Chen, Manu Drijvers, Anja Lehmann, David Novick, and Rainer Urian published "One TPM to Bind Them All: Fixing TPM 2.0 for Provably Secure Anonymous Attestation" at IEEE S&P 2017 [@one-tpm-2017]. The paper demonstrated a Diffie-Hellman-oracle attack against the TPM 2.0 ECDAA interface as shipped: a malicious host could query the TPM in a way that gave the host a DH-oracle relative to the TPM's secret f, effectively breaking the unlinkability property. The proposed fix had been published the previous year by Camenisch, Drijvers, and Lehmann at TRUST 2016 [@cdl-2016] [@cdl-2016-eprint]; library implementations of DAA published from 2017 onward incorporate the fix.The CDL16 fix is library-level, not silicon-level. The TPM 2.0 ECDAA command surface in the chip remains as shipped; the software that drives it must use the corrected protocol sequence to avoid presenting the host-controlled DH oracle. As of late 2025, the TCG normative TPM 2.0 Library Specification text has not been amended to require the corrected sequence. Implementations of DAA on top of TPM 2.0 -- the FIDO ECDAA v2.0 library, the Camenisch-Drijvers-Lehmann reference code, modern academic ECDAA implementations -- follow CDL16. Implementations written against the bare TPM 2.0 Library Specification without reading CDL16 are vulnerable.

10.3 Post-quantum DAA

Shor's algorithm is fatal to DAA. Every classical DAA construction -- BCC 2004, BCL 2008, CPS 2010, CDL 2016 -- relies on the hardness of discrete logarithms in elliptic-curve groups, the hardness of strong-RSA factoring, or both. A cryptographically relevant quantum computer breaks all of them. Post-quantum DAA is therefore active research, with no production deployment as of 2026. Three candidate families are being actively explored:

Symmetric-primitive DAA. Dan Boneh, Saba Eskandarian, and Ben Fisch presented "Post-quantum EPID Signatures from Symmetric Primitives" at CT-RSA 2019 [@bef-2019], building a post-quantum group signature from one-way functions and Merkle trees. The construction has classical post-quantum security guarantees but pays a steep size cost.
Lattice-based DAA. Rachid El Bansarkhani and Ali El Kaafarani published "Direct Anonymous Attestation from Lattices" as IACR ePrint 2017/1022 [@bk-2017-eprint], the earliest such proposal in the literature. The state-of-the-art lattice DAA construction is the 2024 Collaborative Segregated NIZK ("CoSNIZK") work by Liqun Chen, Patrick Hough, and Nada El Kassem [@cosnizk-2024], achieving signatures of approximately 38 kilobytes -- an order of magnitude smaller than the earliest lattice proposals but still two orders of magnitude larger than CPS 2010 ECDAA.
Hash-based DAA. Liqun Chen, Changyu Dong, Nada El Kassem, Christopher Newton, and Yalan Wang published "Hash-Based Direct Anonymous Attestation" at PQCrypto 2023 [@hashdaa-2023], building DAA from SPHINCS+-style stateless hash-based signatures. Size and speed remain unfavorable for TPM 2.0 firmware budgets.

The blocker for any of these reaching production TPM firmware is not academic. The TPM 2.0 normative algorithm set does not include lattice primitives. A post-quantum DAA in TPM 2.0 would require introducing TPM_ALG_DILITHIUM, TPM_ALG_FALCON, TPM_ALG_KYBER, or some equivalent into the spec, mandating support in the PC Client Platform TPM Profile, and rolling out across the OEM TPM-vendor base. That is, at minimum, a three-to-five-year standards effort that the TCG has not, as of late 2025, publicly committed to. CoSNIZK at 38 kilobytes is also two to three times larger than the largest signature any deployed TPM 2.0 firmware budgets for; the TPM-side compute time at quantum-safe parameter sets is currently measured in seconds rather than tens of milliseconds.

10.4 DAA for confidential computing

The other future-world thread is confidential computing -- the family of CPU-anchored isolated-execution primitives (Intel SGX, Intel TDX, AMD SEV-SNP, ARM CCA) that need their own attestation surfaces. Intel SGX attestation initially used EPID and has since migrated to DCAP, a vendor-CA broker similar in shape to Microsoft Azure Attestation. AMD SEV-SNP and Intel TDX use vendor-rooted PKI from the start.

Whether DAA-style group-signature schemes are appropriate for VM-level attestation -- where cohorts are small (per-region TDX hosts in a given hyperscaler datacenter), where the verifier is often a small set of well-known cloud-platform endpoints, and where traffic-analysis leakage between confidential VMs and Privacy-CA-like services is itself a threat -- is an open architectural question. The 2026 default is "vendor-CA broker"; the academic community continues to argue that cryptographic DAA would be a better match for the threat model. Production has not, so far, agreed.

A note on Java Card DAA prototypes. A small number of academic implementations of DAA on Java Card secure elements appeared between 2014 and 2017 -- Camenisch and others published smartcard-class implementations as proofs of concept. None reached production deployment. The reasons appear to be the same operational-economics asymmetry that limits TPM 2.0 ECDAA adoption: Java Card environments lack the relying-party verifier libraries that would consume the output. This is inference; no Java Card vendor has, to public knowledge, published a "we evaluated DAA and chose not to ship it" statement.

These are the open problems for researchers. What about the rest of us, on Monday morning?

11. Practical Guide and Frequently Asked Questions

Five roles, one Monday morning. Where does this leave you?

For a Windows platform engineer. The minimum viable Windows DAA API surface is approximately a BCryptCreateDaaContext, BCryptDaaJoin, BCryptDaaSign, and BCryptDaaVerify set, plus an NCryptDaaKeyHandle for key-storage-provider lifecycle, plus a Web Authentication API surface that consumes ECDAA attestation. Shipping all of that costs a Hello-sized engineering investment. If Pluton's published surface ever advertises ECDAA, an OEM-side integration becomes possible. Today the answer is that DAA is not available through any supported Windows API.

For an attestation-provider product engineer. Pick a Privacy-CA broker architecture for production. The comparison table below makes the trade-offs explicit. Cryptographic DAA does not pay for the architectural switch unless the relying-party privacy threat is specifically the broker itself -- a threat model that, in 2026, no shipping production attestation product publicly assumes.

For a FIDO authenticator vendor. ECDAA attestation is not a viable production choice in 2026. The path to it becoming viable runs through verifier libraries in Chromium, Firefox, and Safari; relying-party SDK support across Auth0, Okta, Microsoft Entra, and Google Identity Platform; and a non-deprecated WebAuthn Level N specification that re-adds the format. None of those preconditions are visibly in progress.

For an academic zero-knowledge-proof researcher. Four open problems map onto production needs: post-quantum DAA at TPM-firmware-shippable signature sizes (the current state-of-the-art at 38 kilobytes is too large), threshold-issuer DAA (no single party can issue a credential), confidential-computing DAA (for small-cohort VM attestation), and IoT DAA (for milliwatt-class energy budgets). Each is publishable; none yet has a deployment path.

For a privacy-tech advocate or policymaker. The framing that helps Microsoft, Google, and AWS engineering teams hear the request is "the broker can be compelled by a subpoena; the math cannot." The framing that does not help is "your cryptography is worse than the academic alternative." The first is a threat-model conversation that engineering organizations can engage with; the second is a technology conversation they have already had and decided.

Comparison: four production architectures for attested privacy

Property	Privacy-CA broker	TPM 2.0 ECDAA	EPID 2.0	Vendor-CA (Apple, AWS Nitro, Google)
Trust assumption	Operational (CA promises not to log)	Cryptographic (issuer cannot link)	Cryptographic (issuer cannot link)	Operational (vendor CA promises not to log)
Anonymity from verifier?	If CA does not log	Yes (per-basename)	Yes (per-basename)	If vendor does not log
TPM-side sign time	Milliseconds (AIK signing)	Tens of milliseconds	Tens of milliseconds	N/A (signing on vendor silicon)
Signature size	Hundreds of bytes (AIK)	Hundreds of bytes	Hundreds of bytes	Hundreds of bytes (X.509 over signed JWT)
Revocation	CA database delete	Private-key list (TPM 2.0)	Sig-RL (signature-based)	Vendor revocation list
Implementer complexity	Low (X.509 PKI everywhere)	High (BN-P256 pairing libraries)	High (vendor SDK required)	Low (vendor SDK ships it)
Standardization	TCG (2003)	TPM 2.0 + ISO 20008-2 Mech 4	ISO 20008-2 Mech 4	Vendor-proprietary
Best suited for	Cloud attestation at hyperscaler scale	Hardware-anchored attestation where broker is the threat	Intel-deployed enclave attestation	Vendor-platform attestation
2026 deployment scale	Billions of attestations per day	Essentially zero production verifiers	2.4B+ EPID keys per RSAC 2016	Billions of attestations per day

The "essentially zero production verifiers" entry for TPM 2.0 ECDAA is the deployment story this article exists to explain. The cryptography is in firmware on hundreds of millions of devices; the verifier side, in 2026, is research-grade libraries and the FIDO ECDAA-Verify reference code. No production cloud-platform SDK ships an ECDAA verifier.

Four things, in order. First, Pluton's published surface advertises `TPM_ALG_ECDAA` and an Issuer key-management story (a Microsoft-operated DAA Issuer for Windows devices, with documented enrollment and revocation flows). Second, a Cryptography Next Generation API surface (`BCryptDaaSign`, `NCryptDaaKey*`) that exposes the TPM2_Commit / TPM2_Sign sequence behind a single managed-language call. Third, a Web Authentication API extension that surfaces ECDAA attestation as a first-class statement format the same way the `tpm` format is today. Fourth, an Azure Attestation policy mode that consumes ECDAA signatures and produces JWT outputs downstream Microsoft services already understand. None of these are technically blocking; all four require a multi-year roadmap commitment that, as of late 2025, Microsoft has not publicly made. This is a thought experiment about technical feasibility, not a forecast about Microsoft strategy.

The companion piece to this article is the TPM in Windows article, which walks the broader TPM 2.0 command surface ECDAA sits inside.

It depends on what the laptop ships. The TPM 2.0 Library Specification names `TPM_ALG_ECDAA`. The TCG PC Client Platform TPM Profile made the algorithm optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025), so a conformant Windows-class platform is allowed to omit it. Many discrete TPM 2.0 modules (Infineon, STMicroelectronics, Nuvoton) do implement the algorithm; Microsoft Pluton's published documentation does not advertise it. The honest answer is "look at your specific TPM vendor's algorithm capability table" -- and that even if your TPM does support the algorithm, Windows ships no API to use it [@tpm-library-spec] [@tcg-ptp] [@pluton] [@wiki-daa]. Microsoft has not published an explicit rationale. Four inferable reasons are visible from the architecture: (1) operational simplicity -- a hosted CA is easier to debug than a per-relying-party DAA verifier; (2) revocation economics -- a CA can revoke an AIK by deleting a certificate, while DAA revocation requires a private-key list distributed to every verifier; (3) a missing relying-party verifier-library stack; (4) no Windows API surface for ECDAA. All four are inferences. The shipped architecture is the Privacy-CA-shaped flow documented at the Microsoft Learn attestation page [@azure-attestation]. WebAuthn Level 1 (March 2019) registered ECDAA as an attestation *type* (Basic, Self, AttCA, ECDAA, None) carried inside the `packed` and `tpm` attestation statement formats. The Level 1 specification text contains 63 references to "ecdaa." WebAuthn Level 2 (April 2021) removed the type entirely; an independent grep of the Level 2 Recommendation HTML returns zero occurrences of "ecdaa." The Yubico migration guide for its WebAuthn server library states verbatim that "this attestation type was removed from WebAuthn Level 2" and that "ECDAA support has not been implemented in this library." The format has not been resurrected as of 2026 [@webauthn-1] [@webauthn-2] [@yubico-migration]. EPID is a DAA variant with one cryptographic addition: signature-based revocation (Sig-RL), which lets a verifier prove that a candidate signature was not produced by the same signer as any signature on a revocation list. The TPM 2.0 ECDAA scheme is the Chen-Page-Smart 2010 construction; EPID 2.0 is essentially the same construction with Sig-RL added. Intel positions EPID separately because of its production deployment (2.4 billion-plus keys shipped per Intel's RSAC 2016 disclosure, used for SGX attestation, Widevine, and several Intel chipsets), its specific licensing structure (royalty-free under Intel's contribution to ISO/IEC 20008 / 20009), and its open-source SDK that Intel maintained until archiving in 2023 [@brickell-li-epid-2007] [@brickell-li-tdsc-2012] [@wiki-epid] [@epid-sdk]. Active research, no production deployment as of 2026. The leading constructions are lattice-based (CoSNIZK 2024 at approximately 38 kilobytes per signature [@cosnizk-2024]), hash-based (the 2023 PQCrypto paper from SPHINCS+ [@hashdaa-2023]), and symmetric-primitive-based (Boneh-Eskandarian-Fisch CT-RSA 2019 [@bef-2019]). The barriers to shipping any of them in a TPM are fundamental: TPM 2.0 firmware does not implement lattice primitives, signature sizes at 30+ kilobytes are incompatible with current attestation-latency budgets, and no relying-party verifier library exists. A post-quantum DAA TPM is a 2030s project at the earliest. No. The Stage 0a focus-premise audit of this article demoted that framing as not supported by evidence. The accurate claim is "standardized in the TPM 2.0 Library Specification (2014); optional in the TCG PC Client Platform TPM Profile since February 2020; present on many discrete TPMs (vendor documentation confirms); absent from Microsoft Pluton's published algorithm surface; supported by no Windows API." That hedged statement is the one the article carries from its first 200 words through to this FAQ [@tpm-library-spec] [@tcg-ptp] [@pluton].

The cryptography is finished. The standardization is finished. The hardware is in the field. What is missing is the social machinery -- the verifier libraries, the SDK presence, the operational tooling, the incident-response runbooks, the regulator demand -- that turns cryptography into deployment. Direct Anonymous Attestation is the cleanest example in platform security of a primitive that won every standardization fight and lost every deployment one. The lesson is not that the cryptography is wrong. The lesson is that cryptography is necessary but never sufficient. Production systems are social systems whose mathematical components, however elegant, must compete with operational alternatives whose properties are easier to ship.

The companion pieces in this series are The TPM in Windows (the cryptographic primitive plumbing TPM 2.0 ECDAA sits inside) and the Microsoft Pluton continuation article (Pluton's published capability surface and the negative claim this article rests its §9 hedge on). The Measured Boot piece -- forthcoming -- walks the data that a hypothetical DAA quote would attest. If those three articles arrive together, the picture of Windows attestation as a system rather than a primitive becomes complete.