European Age Verification App Sparks Backlash Over Google and Apple Lock-In

A European age verification app being developed under the EU Digital Identity framework has ignited a significant technical and political controversy: the specification requires both Google Play Integrity API and Apple App Attestation to function — a design choice that would, in practice, restrict the entire solution to devices running Google-certified Android or Apple iOS. Critics argue the specification is effectively forcing everyone who wants to access age-restricted services in the EU to own a device controlled by one of two American corporations. A GitHub discussion thread opened on 16 July 2025 rapidly attracted thousands of upvotes and hundreds of comments, making it one of the most visible public objections to an EU digital infrastructure decision in recent memory.

The core tension is simple but consequential: the EU's own technical specification for the European age verification solution explicitly names interoperability as a foundational design principle, yet the implementation as documented would exclude users of Linux desktops, de-Googled Android phones, F-Droid-only distributions, and any future operating systems that lack either Google Mobile Services or Apple's proprietary attestation stack. For a continent that has spent years asserting digital sovereignty against American platform dominance, the irony has not been lost on the developer community.

---

What the European Age Verification App Is and Why It Exists

The Regulatory Mandate

The European age verification solution is not a standalone product conceived by a single vendor. It sits within the broader ecosystem of the EU Digital Identity (EUDI) Wallet, the pan-European identity framework being rolled out under the revised eIDAS 2.0 regulation. According to the official technical specification hosted at ageverification.dev, the age verification app is explicitly described as a bridge solution — designed to function until full EUDI Wallets become available by the end of 2026. The push for a workable European age verification law framework stems from several converging legislative forces, most prominently the EU Digital Services Act (DSA), which places obligations on large online platforms to prevent minors from accessing age-restricted content.

Architecture and Roles

The architecture is built around well-defined roles:

• Age Verification App (AV App): The end-user application for requesting, receiving, managing, and presenting a "Proof of Age" attestation.
• Attestation Provider (AP): The entity that issues the Proof of Age credential after verifying the user's identity through an authoritative source.
• Relying Party (RP): A website or service that checks the user's age credential before granting access to age-restricted content.
• AV Trusted List: A whitelist of authorised Attestation Providers, maintained by a Trust Provider, allowing relying parties to validate credential legitimacy.
• Authentic Source: The primary repository of identity attributes — typically a national identity database or equivalent government record.

Technical Standards Referenced

The specification draws on serious technical standards. It is structured per IEEE 830-1998 (software requirements) and ISO/IEC/IEEE 42010:2022 (architecture description), and normatively references ISO/IEC 18013-5:2021 (the mobile driving licence standard), OpenID for Verifiable Presentations (OpenID4VP), and the W3C Digital Credentials API. Annex B references Zero Knowledge Proofs (ZKP) for privacy-preserving age attestation — meaning the underlying cryptographic design is genuinely sophisticated. The controversy is not about the cryptography or the protocol stack. It is specifically about the proprietary platform attestation layer sitting on top of it.

---

The Problem: Google and Apple as Mandatory Infrastructure

The Requirement That Started the Backlash

The README of the age verification app repository, hosted under the eu-digital-identity-wallet GitHub organisation, listed one requirement that triggered the community backlash — described in the documentation as app and device verification based on Google Play Integrity API and Apple App Attestation.

These two proprietary attestation mechanisms verify that an app running on a device is the genuine, unmodified binary published by the developer, and that the device itself has not been rooted or tampered with. Google Play Integrity is only available on Android devices running Google Mobile Services (GMS) — meaning it explicitly does not work on AOSP-based Android forks, GrapheneOS, LineageOS without GMS, or any device that ships without a Google licence. Apple App Attestation is an iOS-only API tied to Apple's hardware security architecture and entirely unavailable on any non-Apple platform.

Who Gets Locked Out

The combined effect is a hard platform wall. To use the European age verification app as currently designed, a user must own either a Google-certified Android device or an Apple iPhone. There is no pathway for:

• Desktop and laptop users — Windows, macOS, or Linux — none of whom can access either attestation API.
• De-Googled Android users running GrapheneOS, CalyxOS, or LineageOS without GMS — a demographic that includes privacy-conscious individuals and security researchers.
• F-Droid users who rely on Google-free app distribution as a matter of principle or necessity.
• Citizens using cheaper unbranded devices that ship without GMS certification, which are more common in some EU markets.
• Future OS ecosystems that may emerge without Apple or Google's proprietary attestation stack.

In short: the specification would push everyone who cannot or will not use a Google- or Apple-certified device toward non-compliance with an EU-mandated identity requirement — a direct contradiction of the regulation's stated universal access goals.

A Recurring Pattern in EU Digital Identity

Discussion participants pointed to parallel objections already filed in the main EUDI wallet repositories — specifically issues eudi-app-android-wallet-ui#287 ("Please remove the requirement for Google Play Integrity") and eudi-app-android-wallet-ui#390 ("use the standard Android hardware attestation API to verify the device, OS and app instead of enforcing licensing Google Mobile Services") — indicating this is not a new concern but a recurring architectural pattern in the EU's digital identity stack. Other participants noted that the Italian government's wallet implementation, tracked under pagopa/io-app, has generated a mega-thread and multiple duplicate issues related to Play Integrity failures, suggesting the problem has already surfaced in production in one of the EU's largest member states.

---

The Sovereignty Argument: Outsourcing EU Infrastructure to American Platforms

The Political Framing

The technical objection quickly escalated into a broader political one, and on this point community sentiment was overwhelmingly critical. The original discussion framed the issue in terms that resonate with ongoing EU debates about strategic autonomy: that requiring a dependency on US technology giants for age verification deepens the EU's dependence on American control of internet infrastructure — an outcome participants argued is especially undesirable given the current geopolitical climate.

That observation lands differently in mid-2025 than it would have five years ago. With EU-US relations under renewed strain and European policymakers actively seeking to reduce dependence on US cloud and platform infrastructure, mandating that every EU citizen route an identity verification flow through Google's or Apple's proprietary attestation servers is a conspicuous policy contradiction. Commenters in the thread characterised the prospect of gaining access to a website as an EU citizen by accepting the terms of service of a US megacorp — one the EU itself has penalised in antitrust and data cases — as a striking illustration of the contradiction.

Security and Data Processing Risks

Participants also articulated the security dimension: digital sovereignty is presented as a necessary step to reduce data-processing risk, on the argument that every external third-party dependency adds a whole ecosystem of potential security issues. Contributors who identified themselves as cybersecurity practitioners described the design as a privacy and security concern, and proposed that a solution built around EU-controlled infrastructure — such as a web application using national credentials — would be both more secure and more constitutionally appropriate.

The South Korea Analogy

Another recurring reference was the cautionary tale of South Korea's long entrapment in older Internet Explorer versions due to government-mandated ActiveX dependencies — a case study in how government technology choices can create vendor lock-in that takes years, sometimes the better part of a decade, to unwind. The parallel is apt: once European age verification infrastructure is deployed at scale with Google and Apple attestation baked into the trust model, replacing those dependencies mid-lifecycle would require renegotiating trust chains across all member states simultaneously.

---

How the Design Contradicts the Specification's Own Principles

The Interoperability Clause

Perhaps the most pointed criticism is also the simplest: the app appears to conflict with its own stated design principles. The technical specification explicitly declares:

"Interoperability: The solution ensures seamless integration across diverse device operating systems, wallet applications, and online services."

Discussion participants noted that tying the app to specific OS vendor attestation mechanisms undercuts not only this interoperability principle, but also two additional organisational principles visible in the specification: that the solution should be made available to anyone who wants to use it and should be controlled by users. Requiring a Google or Apple device as a precondition of access is in tension with both clauses at once.

The Desktop and Laptop Exclusion

The technical specification itself, in its device compatibility section, explicitly lists mobile phones, tablets, laptops, and desktop computers as target devices. Mandating Google Play Integrity API and Apple App Attestation — neither of which functions on any laptop or desktop platform — is irreconcilable with this stated scope. The specification's own device list includes hardware classes that the chosen attestation mechanism categorically cannot serve.

The Open-Source Contradiction

Participants also argued that the entire native app requirement is questionable: the W3C Digital Credentials API, which the specification itself normatively references, could potentially enable a browser-based verification flow that avoids proprietary platform attestation entirely. Others reinforced the open-source contradiction: requiring a mandatory Google account is difficult to reconcile with what is intended to be an open-source project. Google Play Integrity fundamentally cannot function in a fully open-source, GMS-free context — making the FOSS designation and the Play Integrity requirement mutually exclusive in practice.

---

What a Better Architecture Looks Like: The Yivi Precedent

The discussion is not purely critical. Several participants pointed to working alternatives that demonstrate the dependency on Google and Apple attestation is a design choice, not a technical necessity imposed by the security threat model.

Yivi: A Live European Counterexample

The thread specifically cited Yivi (formerly known as IRMA — I Reveal My Attributes), a Dutch digital identity app originally developed under the Privacy by Design Foundation and now managed by Caesar Groep, a Dutch company. Yivi is fully open source, dual-licensed under Apache 2.0 and GPL 3, distributed through open app channels including F-Droid, and already performs age verification in the Netherlands — without requiring Google Mobile Services or Apple App Attestation. Yivi's maintainers have publicly emphasised a sovereignty-oriented governance model for the project; readers evaluating any specific corporate-ownership safeguard should confirm the current details directly with Caesar Groep, as such arrangements can change.

Side-by-Side Comparison

Attribute	EU Age Verification App (current spec)	Yivi (Dutch alternative)
Platform attestation	Google Play Integrity / Apple App Attestation (mandatory)	No GMS dependency; no Apple attestation required
Open source	Intended FOSS, but GMS dependency is incompatible with full open-source distribution	Fully open source (Apache 2.0 / GPL 3)
F-Droid availability	Not possible with Play Integrity requirement	Available on F-Droid
Desktop / browser support	Excluded — Play Integrity and App Attestation are mobile-only	Supports browser-based flows
Ownership	EU Digital Identity Wallet GitHub org (EC-linked)	Managed by Caesar Groep (Dutch company); Privacy by Design Foundation origins
Privacy model	ZKP referenced in spec (Annex B) — aspirational	Selective disclosure operational: only minimum data shared (e.g., "over 18: yes/no")
Government-grade deployment	Proposed bridge solution (2025–2026)	Operational in the Netherlands

Why Yivi's Privacy Model Matters

Yivi's selective disclosure architecture is worth examining closely. Rather than transmitting a raw date of birth, a user proving eligibility for an age-restricted service can simply confirm they are "18 or older" — the underlying credential is verified cryptographically without exposing the precise attribute value. This is exactly the kind of minimal-disclosure design the EU specification's own ZKP annex aspires to, and it is already running in a real national deployment today. The existence of Yivi substantially weakens any argument that Google Play Integrity and Apple App Attestation are strictly necessary for the security properties the EU is trying to achieve.

---

The European Age Verification Law Context

eIDAS 2.0 and the EUDI Wallet Timeline

The European age verification law context is inseparable from the eIDAS 2.0 regulation, which mandates that all EU member states make a compliant digital identity wallet available to citizens by the end of 2026. The age verification app is the explicitly defined interim mechanism for the period between now and that deadline. The specification's architecture is directly derived from the EU Digital Identity Architecture and Reference Framework (ARF) and leverages existing eIDAS infrastructure including eIDAS nodes. The Age Verification Profile defined in Annex A is designed for forward compatibility — attestations issued under the current bridge system are intended to remain valid once the full EUDI Wallet infrastructure is operational.

The DSA Connection

The Digital Services Act is the primary driver of demand for a functioning age verification mechanism. Under the DSA, very large online platforms are obliged to take measures to protect minors from accessing age-restricted content, creating regulatory pressure for a standardised, cross-border verification method. Without a working European age verification solution, each member state risks developing incompatible national implementations — precisely the fragmentation the EUDI Wallet is designed to prevent.

Age Thresholds Across Member States

It is worth noting that the European age of consent varies significantly across member states — from 14 years in some jurisdictions to 18 in others — and the age verification solution under discussion is not directly tied to sexual consent legislation. The system is primarily aimed at enforcing age gates for online platforms under the DSA framework, where the relevant threshold is typically 16 or 18 depending on the content category. However, any European age verification law that mandates a specific app-based mechanism as the primary or sole verification method will inherently inherit whatever platform exclusions that app carries. If the current design is adopted without revision, citizens using de-Googled Android devices or Linux desktops will face structural exclusion from age-gated services as a matter of law — a civil access problem that extends well beyond a GitHub debate.

---

Where to Find the Source Code and Follow the Discussion

For developers and researchers tracking this issue, the key primary sources are:

• European age verification app source code and specification: The official technical specification is hosted at ageverification.dev. The European age verification app GitHub repository is maintained under the eu-digital-identity-wallet organisation on GitHub, where the full public git history of specification and implementation decisions is visible and auditable.
• The primary GitHub discussion thread: Opened 16 July 2025, this thread is the central location for the technical community's objections and, with thousands of upvotes and hundreds of comments, represents one of the largest public comment events on EU digital infrastructure policy conducted in the open.
• EUDI Wallet Android repository issues: eudi-app-android-wallet-ui#287 and eudi-app-android-wallet-ui#390 contain the earlier, parallel objections to Play Integrity in the main wallet implementation.
• Italian government wallet: pagopa/io-app on GitHub contains the mega-thread and duplicate issues documenting Play Integrity failures in production.
• Reddit discussions: The European age verification app Reddit discussion has spread across communities including r/privacy, r/europe, r/degoogle, and r/opensource, where the sovereignty and access arguments have drawn additional commentary from users outside the developer community.
• Yivi source code: Available under Apache 2.0 and GPL 3 on GitHub under the Privacy by Design Foundation and Caesar Groep organisations, with F-Droid distribution confirming GMS-free operation.

---

Key Takeaways

• The European age verification app's technical specification requires Google Play Integrity API (Android) and Apple App Attestation (iOS), effectively restricting use to Google-certified Android and Apple devices — excluding everyone else.
• This directly contradicts the specification's own stated interoperability principle, which explicitly covers "diverse device operating systems" including laptops and desktops — hardware classes that neither attestation API can serve.
• A GitHub discussion thread criticising this decision drew thousands of upvotes and hundreds of comments within days of opening on 16 July 2025, reflecting broad developer opposition to the design.
• The Play Integrity dependency makes the app incompatible with fully open-source distribution via F-Droid, contradicting its intended FOSS status.
• The design raises acute EU digital sovereignty concerns by routing a government-mandated identity function through two US-owned proprietary APIs that can be modified, restricted, or withdrawn at any time.
• Working alternatives — notably Yivi, the Dutch open-source identity app — demonstrate that age verification is operationally achievable without Google or Apple platform dependencies.
• Parallel issues have already been filed against the main EUDI wallet Android repository and the Italian government wallet (pagopa/io-app), suggesting this is a systemic architectural pattern rather than an isolated oversight.
• The underlying cryptographic design (ZKP, OpenID4VP, ISO/IEC 18013-5:2021) is sound; the controversy is specifically about the platform attestation layer, not the protocol stack.
• The European age verification app source code and specification are fully public, meaning whatever architectural decision is ultimately made will be completely auditable via the public git history.

---

What Happens Next

The volume and technical quality of the GitHub discussion make it hard for maintainers to dismiss. The EUDI Wallet GitHub organisation is publicly accountable, and with the bridge solution intended to serve EU citizens until end of 2026, there is still a meaningful window to revise the attestation architecture before the system reaches wide deployment. The most technically coherent path forward — substituting the standard Android hardware attestation API for Google Play Integrity, and exploring W3C Digital Credentials API support for browser-based flows — has already been articulated in the open issues and discussion threads. These changes would restore interoperability with de-Googled Android, desktop browsers, and F-Droid distribution in one move.

Whether the European Commission's digital identity programme has the institutional agility to adopt those recommendations before the bridge solution hardens into production infrastructure is the central question. If the Google and Apple dependency is quietly normalised, European age verification risks trading the continent's stated digital sovereignty goals for the operational convenience of outsourcing trust to two private American corporations — a choice that, once embedded in cross-border infrastructure, would be far harder to undo than the South Korean ActiveX experience that participants warned against. Because the full public git history of the specification repository is open, whatever decision is taken will be entirely transparent — and the developer community has made abundantly clear it is watching closely.