# The Age Gate That Doesn't Know Your Age: How Anonymous Credentials Finally Crossed the Deployment Chasm > Forty years after David Chaum's manifesto, anonymous credentials -- Privacy Pass, BBS, SD-JWT, Longfellow-zk -- have shipped into every major browser. *Published: 2026-05-20* *Canonical: https://paragmali.com/blog/the-age-gate-that-doesnt-know-your-age-how-anonymous-credent* *License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/* --- 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](/blog/direct-anonymous-attestation-the-zero-knowledge-proof-alread/) in the [TPM 1.2 Main Specification](/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) 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](/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) 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](/blog/webauthn-and-passkeys-on-windows-from-ctap-to-the-credential/), 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. flowchart LR Client[Client browser or app] Attester[Attester: checks device or CAPTCHA] Issuer[Issuer: blind-signs token] Origin[Origin: target website] Client -->|1. request attestation| Attester Attester -->|2. forward blinded token| Issuer Issuer -->|3. return blinded signature| Client Client -->|4. redeem unblinded token| Origin **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. 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. flowchart LR DMV[mDL issuer: state DMV] Mdoc[ECDSA-P-256 signed mdoc] Wallet[Holder wallet on phone] Proof[Longfellow SNARK proof: age_over_18 is true] Verifier[Age-gate verifier] DMV -->|sign with existing ECDSA key| Mdoc Mdoc -->|stored in| Wallet Wallet -->|MPC-in-the-head + sumcheck SNARK| Proof Proof -->|verify against issuer pubkey| Verifier Verifier -->|accept or reject| Wallet 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. 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](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati/). 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. **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](/blog/apple-secure-enclave-vs-microsoft-pluton-two-roads-to-hardwa/) 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.