From State Credentials to Civic Proofs

Allen Lab Fellowship Meeting · 2026.04.17

From State Credentials
to Civic Proofs

Digital Identity in Digital Civic Infrastructure (DCI)

mashbean (Taipei)

01 Why identity matters in DCI

06 Age assurance as a stress test

02 From digital identity to civic proof

07 Full identity vs. minimal proof

03 2-layer trust model & 4 types of civic proof

08 Civic & subnational experiments

04 Global comparison

09 Public blockchain as trust layer

05 Taiwan deep dive

10 Policy agenda & next questions

CC BY-NC 4.0 · mashbean 2026

中文版 Chinese version

At our last meeting, Jeremy gave everyone a way into DPI through the lens of payment. Today I want to add another piece of the puzzle, which is identity. If we use the common three-part framing of DPI, the conversation usually lands on Data, Payment, and Identity. Allen Lab has already built up a lot of material on Data, so today I want to focus on the last piece: digital identity. I've spent about half of the past year working on this topic. For the last two and a half years, I worked at Taiwan's Ministry of Digital Affairs on digital wallet planning and rollout. After leaving government in the middle of last year, I kept doing policy research on digital identity, and I also joined some experiments in civic settings. That included pilot work around ZKP, helping open community platforms think through identity integration, and exploring how to build verifiable qualifications without revealing full identity. At the same time, because of another line of my work, I've also been paying close attention to how dispersed communities and exile communities adopt emerging technologies. I originally thought this would be a digital democracy topic. What I found, though, was that the same issue kept coming up over and over again: digital identity. In Eastern Europe, in Catalonia, and in city-level democratic experiments, people keep running into the same question: how do you prove that you have enough standing in digital space without handing yourself over to the state, a platform, or any single intermediary? What really helped me connect all these materials was getting exposed to the idea of Digital Civic Infrastructure after coming to Allen Lab. I started realizing that what I actually care about is bigger than whether large state projects can be institutionalized, and bigger than whether commercial services can integrate identity in a stable way. The deeper question is whether digital identity can become a piece of infrastructure that supports civic action. Can it help people connect, understand, and act, while still avoiding over-disclosure, over-tracking, and over-exclusion? Ash Center frames DCI as the institutional and technical conditions that let people Connect, Learn, and Act. The question I care about today is: how does digital identity determine whether someone can move from connection to action? I've long felt that digital tools already have a lot of success stories at the stage of what we might call digital assembly. In some countries, digital assembly has even played an important role in regime change. But digital association still doesn't have many strong examples. My hypothesis is that a big reason for that is the weak foundation underneath it, which is digital identity. This is still a hypothesis. I haven't proven it empirically. But my inference is that digital identity still is not private enough. Because of that, forms of secret association built on digital identity have never really become workable, and that limits digital activism too. So today I want to focus on a narrower and more political question: what kind of digital identity architecture would let citizens act in digital space with low friction, low exposure, and real avenues for redress? For me, simply moving credentials onto a phone is just the surface-level product story. The deeper issues are about state power, platform responsibility, civil liberty, cross-border interoperability, and the conditions for entering public space. That is why I want to put identity back into the DCI frame. I think this is one place where I can bring something useful to Allen Lab.

Why DCI Needs Digital Identity

Connect

Community, persistence

→

Learn

Understanding, information, discussion

→

Act

Petition, vote, join, collaborate

→

Does the system
require qualification?

No → Low identity need
Yes → Identity enters core governance

Identity matters most when systems gate action.

Digital identity matters most in DCI when systems begin to require qualification, uniqueness, accountability, and procedural legitimacy.

If we think of DCI as a stack of institutions that lets people connect, learn, and act, then the most sensitive moment for digital identity comes when the system starts to gate action. At the Connect layer, identity mostly handles persistence, community governance, role allocation, and basic trust. It answers questions like: who is who in the community, who gets to be a moderator, and who can build up a long-term record of contribution? My experience in g0v, which is Taiwan's largest civic tech community, is that open source collaboration communities usually do not have a gate-action problem. Trust between people is built through long-term contribution. In that world, we use terms like "do-ocracy," "trust through contribution," and, from the IETF tradition, "rough consensus and running code." In civic action communities like that, even major contributors can stay anonymous. So digital identity becomes only a symbolic trust anchor. It does not really function as a digital service layer. There have also been many projects that tried to record open source contribution, including web3 projects like hypercerts, but most of them failed. My guess is that no quantitative metric can really replace the social capital a community builds up naturally over time. At the Learn layer, a lot of information access and discussion does not require strong identity either. Anonymous reading, low-threshold discussion, and weak-identity participation often still work just fine. The real political pressure lands on Act. The moment a system asks whether you are qualified, whether you are duplicating, whether you belong to a certain geography, whether you meet an age threshold, whether you comply with procedure, or whether you are accountable for an outcome, digital identity moves into the center of public decision-making. From that point on, identity is no longer just a login detail. It starts directly shaping the distribution of public resources, the conditions for entering public space, and the legitimacy structure of digital public life. Ash Center's DCI framework treats Connect, Learn, and Act as linked entry points for civic participation. My observation is that identity intervenes most strongly in Act, because Act often touches public services, including whistleblowing, voting, seconding proposals, running for office, and long-term association governance. So today I want to put forward three working propositions. First, mainstream digital identity systems are already quite successful, especially in service delivery, authentication, signatures, compliance, and fraud reduction. Second, once identity infrastructure moves into age verification, platform governance, and access to public space, it starts deciding who can enter which spaces and under what conditions. Third, the maturation of wallets, selective disclosure, unlinkability, ZK, and browser APIs means that more democratic digital identity design has, for the first time, become feasible at the policy and product level. But institutional governance is still clearly lagging behind what the technology now makes possible. The next few slides unpack those three propositions.

Two-Layer Trust Model

flowchart TD A1["State / legal authorization"] --> A["Upper layer: Issuance Legitimacy"] A2["Trusted institution / community rules"] --> A A --> C["Civic Proof"] B1["Credential / Wallet"] --> B["Lower layer: Exchange Architecture"] B2["Browser / OS / App"] --> B B3["Trust List / Registry / Verifier"] --> B B --> C C --> D["Public action
Vote · Petition · Credential verification · Membership governance · Whistleblowing"]

VC 2.0 Recommendation (2025) · Chrome Digital Credentials API · NIST SP 800-63 Rev. 4 subscriber-controlled wallets · w3.org

I think it helps to split digital identity into two layers. The first layer is issuer legitimacy: who has the authority to issue a qualification that carries civic consequences? This layer is about legal effect, sovereignty, institutional accountability, revocation authority, and why a credential deserves to be trusted in the first place. The second layer is exchange architecture: how credentials are held, how they are presented, who verifies them, how they are revoked, how they get reused across systems, and whether the whole process leaves a trackable trail. Once you separate these two layers, a lot of debates that usually get mixed together become much clearer. PKI, VC, wallets, browsers, trust lists, and trust registries all operate at different layers. I want to add one more term here: civic proof. The point of this term is to move the focus away from the credential itself and toward the form of proof that can actually support public action. In many cases, civic action does not require full legal identity. What it may need is only an attribute proof, like proving that you are over 18, or that you live in a certain jurisdiction. In some cases, it only needs a uniqueness proof, such as one person, one vote, or one person, one account, without needing your real name. In more politically sensitive settings, we also run into pseudonymous participation. That means you need to be able to participate, speak, contribute, and be audited afterward, without exposing your real identity in ordinary conditions. If we do not separate these four needs first, then every later debate about whether digital identity requires strong identity just gets muddy. Normatively, I use four conditions to evaluate the system, and then I test whether different needs, institutional designs, and technical architectures satisfy them. First, anonymity. Second, unlinkability. Third, verifiability. Fourth, accountability. All four need to hold at the same time. One cannot stand in for another. In the different kinds of next-generation digital identity projects I've worked on, I've found one point that feels counterintuitive at first, but is actually coherent from a cryptographic, and maybe political-philosophical, perspective: accountability does not require real-name identity. That sentence runs through everything that follows. Once you accept it, a lot of problems that used to be treated as solvable only through total personal data disclosure suddenly open up new institutional possibilities.

Four Types of Civic Proof

Requirement Type	Typical Scenario	Upper Layer: What Legitimacy Is Needed	Lower Layer: What Exchange Architecture Is Needed	Minimum Freedom & Privacy Requirement
🏛️ Legal Identity	Tax filing, legally binding signatures, statutory benefits	State or legally authorized root identity	High assurance, revocable, prosecutable	Verifiable, with redress
🎯 Attribute Proof	Age, residency, student status, membership	Verifiable attribute source	Selective disclosure, minimal disclosure	Unlinkable, no-phone-home
🧬 Uniqueness Proof	One person one account, one person one vote, forum blue checkmark	Uniqueness source can be trusted	Deduplication, Sybil-resistant, low disclosure	Pseudonymous, unlinkable
🎭 Pseudonymous Participation	Whistleblowing, sensitive consultation, political discussion	Procedural legitimacy and post-hoc accountability mechanisms	Preserve anonymity, preserve audit possibility	Anonymous, accountable, supervised

Accountability does not require real names.

Taxonomy based on mashbean's synthesis

Global Comparison: Main Cases

	Upper: Issuance Legitimacy	Lower: Exchange Architecture	Current Strengths	DCI Gap
Taiwan	MOICA has legal effect; TW DIW multi-issuer ecosystem	PKI + wallet / VC dual track	Clear legal effect, rising policy experimentation flexibility	Ecosystem integration friction and civic burden coexist
EU	eIDAS trust services, national trusted lists	EUDI Wallet, attestation, selective disclosure	Complete legal framework, formal cross-border interoperability	Complex rules; wallet / browser = new gatekeeper
Sweden	Commercial BankID as de facto infrastructure; government supplementing	High daily adoption, mature platformization	High usage frequency, deep social penetration	Single commercial operator dependency, inclusion risk
United States	State-level mDL, state law, state-level wallets	Mature standards, fragmented deployment	Strong OS and market influence	Nationally fragmented system, large interstate variation

State-granted root identity remains the mainstream. The real divergence lies in the lower-layer exchange architecture and ecosystem governance.

MOICA · eIDAS = electronic IDentification, Authentication and trust Services · EUDI = European Union Digital Identity · TW DIW = Taiwan Digital Identity Wallet

If we start from the upper layer, issuer legitimacy, then today high-assurance digital identity still mostly comes from the state, or from institutions formally recognized by the state. That has not really changed. Self-issued identity, such as an Ethereum address, civil-society-issued identity, such as union membership, clubs, or associations, and company-issued identity, such as Gmail, generally still do not satisfy the needs of legal proof or attribute proof. In the areas of uniqueness proof and pseudonymous participation, there have been a number of experimental projects, like Gitcoin Passport in web3, although that project has already been sold and passed on. But in the end, most of these efforts still rely mainly on state-issued credentials, as in zkPassport. I think the main reason is still very simple: people, including people from other countries, trust sovereign states to issue identity. Where things have really started to diverge over the last decade is the lower layer, the exchange architecture. That means how credentials are held, how they are presented, who gets to verify them, who can join the ecosystem, who controls the trust list, and who bears the onboarding cost. Differences at this layer directly shape whether digital identity can actually enter the Act layer of DCI. The historical trigger here was really COVID-19. Vaccine passports carried highly sensitive personal data, and that pushed different standards bodies to start proposing the idea of decentralized identity as a response to the risks of centralized government identity databases and the possibility of government surveillance. That line of development later expanded into fields like Verifiable Credentials, Decentralized Identifiers, and even Zero-knowledge proofs. But today I'm less interested in the tech lineage itself. I want to look at how countries differ across these two layers. I'll start with three main comparison sets. The first is Taiwan. Taiwan has both MOICA, which is a high-assurance, strong-legal-effect, issuer-centric path, and TW DIW, which is a wallet path moving toward multiple issuers, scenario-based presentation, and selective disclosure. The second is the European Union. At the upper layer, the EU still relies on eIDAS trust services and national trusted lists. At the lower layer, the EUDI Wallet integrates attestations, wallet holding, user consent, and cross-border presentation. The third is Sweden. Sweden is interesting because society relies heavily on the commercial BankID system, to the point where monopoly risk becomes a real concern. That is why the central bank has publicly argued that government e-identification should serve as an important complement. It shows that commercial identity systems can penetrate everyday life very deeply, but the public governance problem does not disappear just because the operator is private. Beyond those, there are a few useful reference points. The United States is not one coherent path. It is more like a cluster where state-level initiatives and market platforms overlap. California's OpenCred and wallet ecosystem, and Utah's digital identity rights language, are both worth watching. MOSIP offers a modular, open source model of infrastructure that a state can own itself. Aadhaar reminds us that massive scale and broad coverage do not automatically produce a civic-freedom-first system. As for Bhutan, its importance is that the state-backed NDI path has already put a trusted wallet and VC into a national-level direction, which makes it a high-signal case to keep watching. The main point of this slide is this: around the world, the competitive focus has expanded from "who issues identity" to "who controls the trust list, who controls the presentation interface, and who bears verifier onboarding and ecosystem cost." The key to digital identity entering DCI is not whether a root identity exists. The key question is what kind of exchange architecture that root identity gets placed into.

Global Comparison: Supplementary Cases

	Upper: Issuance Legitimacy	Lower: Exchange Architecture	Current Strengths	DCI Gap
MOSIP	Modular identity infrastructure self-built by each country	Open source, modular, locally deployable	Cost and sovereignty appeal for multiple countries	Whether it supports civic rights depends on each country's governance
Aadhaar	National-scale root identity	Authentication / eKYC oriented	Extremely high scale and coverage	High scale ≠ high freedom guarantees
Bhutan NDI	Sovereignty-backed National Digital Identity	Trusted wallet, VC oriented	National-level innovation direction	International interoperability and governance maturity still forming

mDL = Mobile Driver's License · MOSIP = Modular Open Source Identity Platform · NDI = National Digital Identity · mosip.io · California DMV Wallet

Taiwan: MOICA vs TW DIW

Dimension	MOICA (Citizen Digital Certificate)	TW DIW (Digital Identity Wallet)
Design center	Issuer-centric, legal effect, identification, digital signature	Holder-centric, credential reuse across scenarios
Typical tasks	Identification, digital signature, encryption/decryption	Attribute presentation, cross-scenario credentials, selective disclosure
Third-party integration	Requires formal application, review, and approval to access	More open sandbox; wider entry for issuers / verifiers
Disclosure logic	Tends toward high-assurance confirmation, even full identity verification	Scenario-based authorization and minimal disclosure
Main friction	In-person counter service, eligibility, API review, integration cost	User comprehension, verifier integration, trust list governance
DCI implication	Strong credentials sufficiently support government processes, but not necessarily civic action	Application space expands, but civic burden also distributes to citizens and verifiers

MOICA = Ministry of the Interior Certification Authority · moica.nat.gov.tw · TW DIW GitHub

Taiwan deserves its own slide because it contains both a warning case and a testbed. MOICA is Taiwan's natural person certificate, the traditional PKI smart card, and later it also got a mobile app service. It offers high assurance, strong legal effect, and relatively clear integration into government process. For many government use cases, that matters a lot. In 2020, the Taiwanese government even tried to merge MOICA with the paper national ID card under a project called New e-ID. That triggered major public backlash. The broad public view was that New e-ID lacked a clear legal basis and carried cybersecurity risks, so the plan was eventually put on hold. As of now, New e-ID is still not moving forward, and inside government it has basically become a frozen project. The core problem with MOICA is not the term PKI, and it is not the existence of a strong credential. The real issue is the integration friction in an open ecosystem: who is eligible to apply, what the in-person process looks like, how much third-party integration costs, and how strongly the whole system remains issuer-centric. MOICA's official identity verification service explicitly requires application systems to apply in advance and get approved before they can access the relevant functions. That design works very well for high-control, high-legal-effect, high-responsibility-chain environments. But for third-party civic services, the friction becomes very high. TW DIW takes a different path. The official direction is not to issue another centralized national digital identity. Instead, it turns existing government and private-sector credentials into digital credential cards that the holder can manage. TW DIW has already open-sourced the Mobile App code, which is a very important milestone. Right now it includes a telecom card that supports picking up online shopping parcels at convenience stores. In the future, it should also support business credentials and driver's licenses. At the policy level, TW DIW emphasizes selective disclosure, interoperability, open ecosystem design, and the possibility of multiple issuers and multiple verifiers. From a DCI perspective, that gives it a lot of potential, because what civic action often needs is not a stronger central login. It needs proof that is more portable, more composable, and less revealing. But the democratic issue with TW DIW is larger than simple adoption friction. A more precise way to describe it is this: it redistributes civic burden. Because DIW can hold "digital identities" issued by many different institutions, multiple trust roots, multiple trust lists, and multiple issuers expand the ecosystem, but they also shift the burden of understanding, consent, verification, dispute handling, and responsibility assignment onto citizens and verifiers. MOICA concentrates friction before entry: application, review, and integration. TW DIW concentrates friction inside ecosystem operation: how you understand the credential you hold, whether you trust that issuer, how the verifier should verify it, and who becomes responsible when something goes wrong. That matters a lot for DCI, because civic infrastructure is about much more than whether the technology runs. It is also about how costs of use and accountability are distributed.

Taiwan Civic Cases

Case A: PTT × MOICA × ZK Blue Checkmark

PTT, Taiwan's largest BBS system, uses citizen digital certificates to generate ZK proofs, allowing users to obtain a "blue checkmark" without revealing their real identity, reducing coordinated information attacks during elections.

Proof: State root credential serves as the trust root, but full identity need not be handed to the platform.

Path: State credential → civic proof

Case B: g0v Summit × TW DIW

g0v Summit 2026, the biennial conference of Taiwan's largest civic tech community, uses the digital identity wallet to issue entry credentials, with non-governmental third parties serving as issuer and verifier.

Proof: A holder-centric ecosystem can be operated not only by government, but also by civic communities.

Path: Wallet → civic ecosystem

g0v Summit 2026 · g0v Summit 2026 Digital Wallet Work Items · ZK = Zero-Knowledge Proof

mashbean et al. — Bond for the Future: Interoperable Yet Unlinkable Digital Identity

Case A: PTT x MOICA x ZK Blue Check PTT is Taiwan's largest BBS and still has hundreds of thousands of users. For a long time, the platform has struggled with coordinated behavior and influence operations before elections, and the volunteer team has had a hard time solving that through conventional moderation. This year is Taiwan's mid-term election year, so the engineering team used MOICA to generate a ZK proof that lets users get a "blue check" without revealing their real identity. The proof value of this case is extremely strong. It demonstrates something very important: a state-rooted credential can provide the trust root without handing full identity over to the platform, and without telling the platform exactly who the user is. That is a concrete path from a state credential to a civic proof. Case B: g0v Summit 2026 x TW DIW x Civil-Society Issuer / Verifier There is another direction that matters just as much: g0v Summit 2026. g0v is Taiwan's largest civic tech community, and it holds its summit every two years. This year, the g0v volunteer team will use a digital wallet to issue credentials and entry passes, and non-government third parties will act as issuer and verifier. That directly proves that a holder-centric ecosystem does not have to be run by government alone. Civic communities, event organizers, and unofficial verifiers can also operate inside a trust framework. This forms a useful contrast with the PTT case. The PTT case uses a strong state credential to generate a low-disclosure proof. The g0v Summit case uses a wallet architecture to expand practical space for non-government issuing and verification.

Age Assurance: The Best Stress Test

Child safety policy × identity infrastructure × public-space entry

	Regulatory Development	Key Timeline	Core Tension
UK	Ofcom requires highly effective age assurance; allows multiple technology paths	From 2025-07, adult content sites must implement strong age checks	High regulatory intensity; privacy standards not necessarily consistent
Australia	Social media minimum age restriction; platforms required to take reasonable steps	Effective 2025-12; compliance update 2026-03	Platform responsibility, effectiveness, false blocks
EU	Age verification app / blueprint aligned with EUDI roadmap	2025 blueprint; deployable 2026-04	Whether minimal disclosure can be institutionalized
United States	From state-level content gates toward device / OS / app-store age signals	2025-06 Paxton case; 2025-10 CA AB1043	Sliding from "adult content gate" toward "infrastructure-layer age signal"

Ofcom · CA AB1043 = California Assembly Bill 1043 (Digital Age Assurance Act)

mashbean — Prove You're Old Enough (research report)

I see age verification as the clearest stress test in this whole discussion. It pushes identity infrastructure, which used to sit in the back end, right up to the front door of public space. Users no longer encounter content first and get governed later. They have to prove themselves first just to enter. The pace of legislation in this area has actually moved faster than technical standards and human rights assessment. Before ISO/IEC 27566-1 was released at the end of 2025, the UK had already required strong age checks, Australia's law had already taken effect, and the EU had already announced that an age verification app could be deployed. These four jurisdictions represent four different paths. The UK is high-regulation and technology-neutral. Australia is a platform-liability model. The EU is trying to institutionalize a system that proves only one thing: that you are over 18. The United States is especially important because the turn is very clear. In the Paxton case, the Supreme Court accepted age verification for adult content, and California's AB1043 goes even further by requiring operating systems to generate an age-bracket signal at account setup and provide it to apps through an API. That means age checking is moving down the stack, from content websites to devices, operating systems, and app distribution infrastructure.

Age Assurance: Four Rights at Stake

Rights Dimension	Risk Type
Privacy	ID documents, age, biometrics centrally processed
Anonymity	Conflict with lawful browsing and the right to anonymity
Free speech	Adults forced into self-censorship (chilling effect)
Digital divide	Those without ID / bank accounts are excluded

flowchart TD A["Child safety pressure"] --> B["Rapid legislative push"] B --> C{"Proof flow?"} C --> D["Per-site verification"] C --> E["OS / App Store
age signal"] C --> F["Privacy-preserving
proof"] D --> G["Tracking · Leaks
Chilling effect · Exclusion"] E --> G F --> H["Risk reduced
but not eliminated"] G --> I["Expand into
general-purpose
identity gate?"] H --> I

Will age assurance expand from specific content controls into a general-purpose digital identity gate?

Discord 2025-10: third-party vendor 5CA incident; government ID photos of approximately 70,000 users potentially exposed

mashbean — Prove You're Old Enough: How Age-Verification Laws Are Quietly Building a Global Identity Infrastructure

From Full Identity to Minimal Proof

Selective Disclosure Unlinkability No-Phone-Home Browser Politics

Question	Full Identity	Minimal Proof
Are you over 18?	Present date of birth, full ID	Prove only "over 18"
Do you live here?	Present full address or household registration	Prove only residency eligibility
Are you the same person?	Hand over real name, ID number	Uniqueness proof or pseudonymous credential
Do you have a certain qualification?	Hand over entire credential	Present only specific attribute

flowchart TD A["Use case"] --> B{"Single-service
login?"} B -->|Yes| C["Federation /
passkey is sufficient"] B -->|No| D{"Multi-issuer /
cross-scenario /
minimal disclosure?"} D -->|Yes| E["Wallet system
value is clear"] D -->|No| F["Simple proof flow"]

VC 2.0 = Verifiable Credentials · Chrome Digital Credentials API: over 18 without revealing DOB · Google Wallet 2025 open-sourced ZKP libraries ·

PSE client-side proving · EUDI ARF restricts browser/OS from using presentation requests for market analysis · W3C

Age verification is a very good example of what happens when policy moves before technology. It is a classic case of attribute proof, and there are two broad digital identity approaches here: full identity and minimal proof. At this point, the issue is no longer whether the technology can do it. It can. The real question is which situations should treat minimal proof as the default. Very often, all we need to know is whether one condition holds: over 18, resident in a certain jurisdiction, student status, membership in a certain group. If a system demands full identity every time, then it is effectively institutionalizing over-disclosure. If instead the proof flow is designed around selective disclosure, unlinkability, and no-phone-home, then digital identity starts to become compatible with a more democratic model of governing public space. This slide also needs to answer a more direct question: is a wallet necessary? My answer is conditional. If the need is just login for a single service, then federation, such as Sign in with Google, passkeys, or an existing high-assurance login tool, is often enough. But when the need becomes multi-issuer, cross-context reuse, minimal disclosure, user consent, and cross-border interoperability, then the institutional value of the wallet goes up sharply. At that point, the wallet is no longer just a container. It is taking on presentation, consent, credential management, and the logic for combining credentials from different issuers. The fact that NIST has brought subscriber-controlled wallets into its model is basically an acknowledgment of that shift. I also want to stress that the presentation layer is being platformized very quickly. Once wallets, operating systems, and browsers become the default front door for digital credentials, the real competition expands from "who issues identity" to "who controls identity presentation and the consent interface." Google Wallet, Chrome, Apple Wallet, and EUDI's browser-mediated presentation are all moving in that direction. That means the platform layer is no longer neutral. It may become the next gatekeeper, or it may become the place where rights protection actually gets built in. EUDI's restrictions on browsers and operating systems, and Google's language around no server tracking, both show that this layer is already being institutionalized. I also want to bring in Ethereum Foundation PSE here. Minimal proof and ZKP are closely linked. If minimal proof is going to enter real civic use, standards alone are not enough. We also need performance breakthroughs in client-side proving, usable revocation design, and engineering work that lets phones and ordinary consumer devices handle proving in practice. PSE has put client-side proving and zkID on its roadmap, and in 2026 it has kept pushing discussions around GPU acceleration and revocation. That means ZK is becoming less of a research language and more of a technical base that products and civic experiments can actually rely on.

Civic & Subnational Experiments

The more likely future: a combination of state-rooted credentials and civic-layer participation tools, rather than wholesale replacement.

Case	Trust Root	What Need It Reveals	Where It Remains Weak
Vocdoni Catalonia	Local government, organizational membership boundaries, passport	Need for verifiable, auditable, privacy-first digital voting	Legal effect, adoption rate, cross-jurisdictional scalability
Rarimo Freedom Tool	Passport-rooted, ZK proof	Need for anonymous credential proof in exile communities and authoritarian contexts	High dependency on passports and specific technology stacks
QuarkID Buenos Aires	City-level government, public-sector trust framework	Need for city-level public digital trust frameworks	Extrapolation from city-level to national level requires caution

vocdoni.io · Rarimo Freedom Tool: decentralized privacy-preserving online voting · QuarkID: Buenos Aires digital trust framework

mashbean.net — Extended reading on civic and subnational experiments

When mainstream systems do not fully support low-exposure, portable, verifiable civic proof, civic and subnational experiments start to emerge. The main value of these projects is not that they have already proven a mature alternative identity regime. Their value is that they expose needs that the mainstream system still does not serve very well. Vocdoni is a technical nonprofit based in Catalonia. Since the failure of the 2017 Catalan independence referendum, political activity in Catalonia has faced major constraints, so a number of emerging organizations have started trying new forms of civic participation. In the Vocdoni project, a Spanish passport is used to verify that a holder qualifies as Catalan for mock voting. The Vocdoni case tells us that local governments and civil-society organizations really do need verifiable, auditable, privacy-first digital voting tools. Rarimo is similar in that it also transforms passports from different places into anonymous digital identity for mock voting. Rarimo has run small-scale mock voting in Romania, Russia, and Iran. In exile communities and authoritarian contexts, passport-rooted, ZK-based anonymous qualification proof clearly serves a real need. QuarkID shows that city-level governments are also trying to bring digital trust frameworks and citizen-controlled credentials into public governance. But I want to be careful here. These cases work better as evidence of demand than as evidence of a complete substitute. Most of them still depend on existing passports, membership boundaries, local government documents, or some other institutional trust root. In other words, root identity still needs public legitimacy and democratic accountability. What happens after the branch point is that flexibility increases, but the trust base also becomes weaker. From that angle, the more plausible future is not the full replacement of state-rooted credentials. It is a combination of state-rooted credentials and civic-layer participation tools. This slide also raises a deeper political issue: how do you make citizens believe that a government-issued credential will not become a tool for government tracking? That is actually one of the most important hidden questions behind many civic experiments. If citizens believe that the credential serves only as a trust root, and that the verification flow itself does not report transactions back to the state, acceptance changes completely. That is why no-phone-home and unlinkability matter so much.

Public Blockchain: Trust Layer & Status Anchoring

Component	Recommended Position	Reason
Personal data	Off-chain, local wallet	Protect privacy, avoid irreversible linkage
Issuer DID / public key	Public registry or on-chain anchoring	Enable cross-organization independent verification
Trust list anchor	Publicly verifiable infrastructure	Auditable, commonly visible, resistant to single-point failure
Individual verification event	Avoid per-transaction callback to issuer	Reduce phone-home risk

Federated trust-list alliance:
Trust lists from different jurisdictions, cities, and communities bridged to one another

flowchart LR A["Issuer"] --> B["Trust List /
Registry"] B --> C["Public Chain
Anchoring"] C --> D["Verifier"] A --> E["Credential
→ Holder"] E --> D D -. "Avoid per-transaction
callback to issuer" .-> A

Currently, only Bhutan and Taiwan have actually deployed public blockchain at the national digital identity level.

DID = Decentralized Identifier · EBSI = European Blockchain Services Infrastructure

In next-generation digital identity services, there is one idea that keeps appearing in standards discussions, but has barely been adopted by states in practice: public blockchain. I think this is one of the most important parts of the conversation, and also one that needs the most restraint. Public blockchain carries a lot of institutional imagination in digital identity, but there are still not many national cases of large-scale deployment. Right now, only Bhutan and Taiwan have really implemented it. My view is that the institutional value of public blockchain here is not legitimacy in itself, and it is definitely not about putting personal data on-chain. Its best role is at the trust layer: status anchoring, cross-organizational shared visibility, and auditable status publication. This is not about putting personal data on-chain. From the standpoint of GDPR, privacy, unlinkability, and practical data governance, that is not a good direction. What makes more sense to anchor on-chain is the issuer's DID, a public key, a trust-list anchor, a status-list commitment, or some other publicly verifiable data that does not directly expose personal information. That way, a holder or verifier can confirm whether an issuer is trustworthy without contacting the issuer one record at a time. That matters a lot for civic proof because it helps reduce central lookups, which means reducing the chance of phone-home behavior. Why am I specifically emphasizing public blockchain, instead of using the broader term DLT? Because among the infrastructure we actually have today, public blockchain is one of the few tools that can provide permissionless publication, cross-organizational shared visibility, independent verification, and relatively strong resistance to single-point failure at the same time. That is especially attractive in cross-jurisdiction settings, civic communities, subnational governance, and city-level trust frameworks. By contrast, the value of permissioned consortium infrastructure usually lies in coordination efficiency within a specific jurisdiction or alliance, but its node governance model and its logic of global verifiability are completely different. In the case of the EU's trusted lists, their core value comes from law and regulation. If you insert public chain into that position, the most reasonable role for it is closer to a trust layer and registry interface. It is not there to replace legal legitimacy itself. That is also why I suggest thinking about interoperability through the idea of a federated trust-list alliance. The most workable future is probably not one single global trust root. It is more likely a network where trust lists from different jurisdictions, cities, institutions, and communities bridge to one another, creating something that can be connected, audited, and governed in layers. To think this through, I spent a full year in an ICANN-related fellowship trying to understand how the trust root of DNS was built. But my conclusion is that DNS came out of a historical path that is completely different from state power, and even today its 12 trust roots are still, to a large extent, not managed by nation-states. Because the historical conditions are so different, I think that model will be very hard to reproduce in digital identity.

Policy Agenda: From Rights to Deployment

Layer	Specific Policy Action	Corresponding Cases	Why It Matters
Rights baseline	Minimal disclosure, unlinkability, no-phone-home, voluntariness, alternative paths, redress	ACLU, EFF, CDT No Phone Home, EU browser restrictions	Without a baseline, new use cases all start from maximum visibility
Platforms & standards	Open wallets, standardized provisioning, avoid single-platform lock-in	Chrome DC API, TW DIW OID4VC/OID4VP, CA OpenCred	The presentation layer will become the new gatekeeper
Procurement & rollout	Procurement sandbox, third-party testing, exit clauses, incident response	Verifier onboarding, module replacement testing	If rights are not translated into procurement language, they vanish at rollout
Public-interest pilots	Small-scale trials with specific civic use cases	Forum blue checkmark, event credentials, local consultation	First prove civic proof is useful, then discuss full rollout
AI delegation	Scope limitation, revocable, auditable, human override	OpenID agent identity, NIST AI agent concept	The identity question shifts from "who logs in" to "who can act on whose behalf"

A system can be excellent at digital government yet still inadequate for digital civic action.
The difference lies in whether rights baselines, open ecosystems, and procurement governance are affirmatively addressed.

ACLU = American Civil Liberties Union ·

EFF = Electronic Frontier Foundation · CDT = Center for Democracy & Technology ·

OID4VC/VP = OpenID for Verifiable Credentials / Presentations · ACLU

mashbean — Who Gets to Govern the Identity of AI Agents?

From my own work experience, I've found that trying to build DCI from the government side is extremely hard. A few years ago I did not even know the term DCI yet, but the implementation path I was working on was very similar. The hardest part is not the technology itself. The hardest part is translating technical architecture and the ideals of political philosophy into action language that civil servants and civic groups can actually use, like procurement requirements, milestone checks, or even policy vocabulary that the current government can adopt. And I've found that this is a highly specialized area where experts from different domains rarely overlap. Political workers, technical bureaucrats, engineers, and even System Integrators are all speaking very different languages. Technically they are all speaking Chinese, but I often feel like I'm moving between different cultures. So I've tried to reduce this into a few key principles that can help DPI turn into DCI successfully in the area of digital identity. I would rewrite the policy agenda into five operational moves. First, fix a privacy-first baseline. At a minimum, that should include minimal disclosure, unlinkability, no-phone-home, voluntariness, a paper path or non-smartphone fallback, and clear complaint and redress channels. This set of principles is very much in line with digital rights advocacy from groups like ACLU, EFF, Access Now, and No Phone Home. The reason is simple. If you do not lock in these floors first, nearly every new use case will default toward the most visible, easiest-to-manage, and most data-extractive design. Second, require open wallets / standardized provisioning. The presentation layer is going to become the next gatekeeper. If the wallet, operating system, or browser layer is dominated by a single platform, then digital identity simply shifts from state monopoly to platform monopoly. The TW DIW official app is built around OID4VC / OID4VP, Chrome is bringing the Digital Credentials API into implementation, and California is using OpenCred to think through the verifier ecosystem. These are all useful materials to learn from. What policy needs to do is standardize provisioning, presentation, and verifier onboarding as much as possible, so we do not end up building the next closed ecosystem. Third, create a procurement sandbox. This point is easy to miss, but I think it is crucial. A lot of rights claims look great in policy white papers and then disappear the moment rollout begins. The reason is that they were never translated into procurement language. What really needs testing is total lifecycle cost, third-party testing, incident response, module replaceability, exit clauses, and the real friction of verifier onboarding. In other words, rollout is not the last step. Rollout is itself part of institutional design. Procurement is so process-heavy that it often gets ignored, and that is exactly why it matters. Fourth, build a testbed network. I would not recommend starting by chasing a universal digital identity. A more stable approach is to pick a few civic use cases and run small-scale, comparable experiments. Uniqueness proof in forums or public discussion spaces is one example. Minimal disclosure proof for age or residency is another. Membership proof for community self-governance or civic groups is another. If these pilots can produce material that is comparable, evaluable, and portable, that would be very useful for a DCI-oriented environment like Allen Lab. Fifth, AI delegated authority needs to be brought into the main line of the conversation. AI agents are already moving very quickly into human work and everyday life. The next big question will shift from "who logs in" to "who is allowed to act on whose behalf." Can an AI agent query, purchase, sign, vote, submit materials, or operate some civic workflow for me? All of that requires scope limitation, revocation, auditability, and human override. Both the OpenID Foundation and NIST have already written this into formal documents, so I think this slide should reserve space for agentic identity and delegated authority as part of the core topic.

Conclusion

A democratic digital identity system should determine
when I can act without exposing more than necessary.

Which civic acts require legal identity, and which need only an attribute proof or uniqueness proof?
Have browsers, operating systems, and wallets already become new public infrastructure? How will they shape civic life?
If state-rooted credentials remain the mainstream, what exchange architecture is sufficient to support privacy, portability, redress, and inclusion?
How should this research converge to avoid becoming overly dispersed?
What are the next steps for practitioners, policy advocates, and researchers respectively?

mashbean · mashbean.net · Allen Lab Policy Fellow

The one sentence I want to leave behind is this: The digital identity system a democratic society needs must do more than prove who I am. It also has to decide when I should be able to participate lawfully in public life without exposing more information than necessary. From a DCI perspective, the core problem of digital identity is not just how to make people easier to identify. The deeper issue is how to turn legitimate sources of qualification into civic proof that is low-friction, low-exposure, and redressable. That conversion runs through two trust models. The upper layer is issuer legitimacy. The lower layer is exchange architecture. The world today already shows that mainstream state identity systems are very good at supporting government service, signatures, compliance, and platform onboarding. Where they are often much weaker is pseudonymous participation, unlinkability, redress, and low-threshold civic reuse. Connect, Learn, and Act helped me see that identity really moves to the center when a system starts to gate action. I also want to leave three questions openly with everyone here. First, which civic acts really require legal identity, and which ones only require attribute proof, uniqueness proof, or pseudonymous participation? Second, if wallets, operating systems, and browsers gradually become the default presentation layer, have they already become a new kind of public infrastructure? Third, if state-rooted credentials remain the mainstream for the foreseeable future, what kind of exchange architecture would actually be enough to support the privacy, portability, redress, and inclusion that a democratic society needs? Finally, this is also my own research question. Right now I'm struggling most with two things. First, this research area touches digital policy, standards, cryptography, civic participation, platform governance, and cross-jurisdiction institutions. The scope is very large. I would really like to know what axis I should use to narrow it next: use case, actor, trust layer, or a specific jurisdiction. Second, if we look at this from the position of practitioner, policy advocate, and academic researcher, what is the next step in each role? There are so many things to do right in front of us that what I need most now is a clearer order of research and action.