Wie die EU-Altersverifikation freie Infrastruktur vereinnahmt

Die Aufregung um die neue EU-Altersverifikations-App ist verständlich, aber sie zielt grösstenteils auf die falsche Ebene. Ein Sicherheitsforscher zeigte innert kürzester Zeit, dass sich Schutzmechanismen der App lokal umgehen lassen. PIN, Rate Limits und Biometrie waren in der veröffentlichten Form schwach oder schlecht gebunden.1 Hadmut Danisch hat mit seiner Kritik an dieser oberflächlichen Berichterstattung einen brauchbaren Ausgangspunkt geliefert. Sein definitorischer Einwand ist zutreffend und sein weiterer Instinkt ist richtig: Das eigentliche Problem liegt nicht in einzelnen App-Bugs, sondern tiefer, nämlich im Protokolldesign, im Vertrauensmodell, in der Rollenarchitektur, in der White-Label-Logik und in der politischen Einbettung des Ganzen.2

Medial behauptet wurde ein Hack. Tatsächlich gezeigt wurden zunächst lokale Implementierungsfehler und Umgehungen behaupteter Sicherheitseigenschaften. Das ist nicht dasselbe. Wenn eine App dem Nutzer nahelegt, PIN und Biometrie schützten einen Altersnachweis auf dem Gerät, und sich diese Sicherungen durch Manipulation lokaler Zustände oder Konfigurationsdaten aushebeln lassen, dann liegt eine Umgehung einer beworbenen Sicherheitseigenschaft vor. Man muss das Wort Hack nicht mögen, um den Befund ernst zu nehmen. Danisch hat recht, wenn er sagt, dass der grössere Fall erst dort beginnt, wo sich Nachweise kopieren, übertragen, massenhaft missbrauchen oder über Infrastrukturpfade protokollieren lassen.

Die Kommission und das technische Portal beschreiben eine Referenzarchitektur mit definierten Rollen, Schnittstellen und Protokollen. Beteiligt sind der Nutzer, die konkrete Age Verification App Instance3 auf dem Gerät, der Attestation Provider4 als Aussteller des Altersnachweises, die zugrunde liegenden authentic sources5 wie Register oder andere vertrauenswürdige Datenquellen, die Relying Party6 als nachfragender Dienst und die Trust-Infrastruktur über zentrale Trusted Lists7. Die Architektur benennt sogar ausdrücklich die jeweiligen Interfaces zwischen Authentic Source und Attestation Provider, zwischen Attestation Provider und App Instance sowie zwischen App Instance und Relying Party.8

Der Austauschpfad bei der Ausstellung des Nachweises ist standardisiert. Das veröffentlichte Profil setzt für die Ausgabe der Attestation auf OpenID9 for Verifiable Credential Issuance. App und Attestation Provider müssen den authorization_code-Flow und den pre-authorized_code-Flow unterstützen. Für den klassischen Autorisierungsweg verlangt das Profil RFC 763610 mit code_challenge und code_verifier, also PKCE11. Die Attestation selbst wird als ISO-mDoc12 im Typ eu.europa.ec.av.1 profiliert. Inhaltlich geht es nicht um eine volle Identität, sondern um boolesche Altersattribute wie age_over_18. Das wirkt datensparsam. Es schafft aber gleichzeitig eine formalisierte Nachweisökonomie, in der Aussteller, Präsentation und Verifikation sauber getrennt und technisch anschlussfähig gemacht werden. Das System ist damit nicht improvisiert, sondern bewusst in bestehende Wallet- und VC-Standards eingehängt.13

Für die Präsentation an einen Online-Dienst ist standardmässig die W3C Digital Credentials API14 vorgesehen. Die Relying Party stellt dabei eine Anfrage mit deviceRequest und encryptionInfo. Die Antwort des Geräts kommt nicht als Klartextobjekt, sondern als verschlüsselter DeviceResponse; das Profil nennt dafür HPKE15 nach RFC 918016. Als Fallback ist OpenID for Verifiable Presentations vorgesehen. Dann läuft die Anfrage mit vp_token, direct_post, nonce und DCQL17. Bis hierher klingt das sauber und modern. Nur folgt unmittelbar der Haken: Reader Authentication18 ist im Profil nicht verpflichtend, Client Authentication ebenfalls nicht. Der Fallback verzichtet sogar bewusst auf zusätzliche Absicherungen wie JAR19 oder direct_post.jwt und vertraut stattdessen auf TLS20 und Web PKI21. Das ist keine Randbemerkung, sondern ein bewusster Zuschnitt des Threat Models zugunsten schneller Einführbarkeit und geringerer Komplexität.

Die Basiskryptographie ist ebenso klar dokumentiert. Alle beteiligten Entitäten müssen P-25622 secp256r1 unterstützen, ES25623 für Signatur und Signaturprüfung und SHA-256 für die Digests im mDoc-VC. Eine veröffentlichte PQC-Baseline24 existiert im normativen Profil gerade nicht. Das neue europäische Altersverifikationsregime startet also kryptographisch nicht mit postquantenresistenter Grundlage, sondern mit klassischer elliptischer Kurvenkryptographie. Das ist heute praktisch, breit implementiert und in mobilen Plattformen verfügbar. Es ist aber auch eine klassische Entscheidung zugunsten von Kompatibilität und gegen Zukunftsrobustheit. Wer ein neues Regime aufbaut, schafft damit Pfadabhängigkeiten. Je weiter Rollout, Zertifikatsinfrastruktur, Trusted Lists, Verifier und Wallet-Anbindungen vorangetrieben werden, desto teurer und politisch schwieriger wird eine spätere PQC-Migration.25

Noch heikler ist, was das System nicht oder nur abgeschwächt bereitstellt. Die Architektur sagt ausdrücklich, dass Revocation in der aktuellen Form nicht unterstützt wird. Später heisst es noch schärfer, Revocation sei für Altersverifikationszwecke nicht erforderlich; empfohlen wird stattdessen ein maximal dreimonatiges Gültigkeitsfenster und eine Einmalnutzung. Die Registrierung von Relying Parties, die Altersnachweise anfordern, ist ebenfalls nicht erforderlich. Dasselbe gilt für die Registrierung von App-Providern. Zugleich wird der eigentliche Aussteller, also der Attestation Provider, zentral über eine von der Kommission verwaltete Trusted List verankert. Die Relying Party soll anhand dieser Liste prüfen, ob ein vorgelegter Nachweis überhaupt von einer autorisierten Stelle stammt. Das heisst übersetzt: zentrale Vertrauensanker auf Ausstellerseite, ausgedünnte Gegenstellen-Authentisierung auf Anfragerseite, keine initiale Revocation-Baseline, keine universelle Pflichtregistrierung der Dienste.

Die Kommission verkauft das System öffentlich wesentlich glatter, als es das normative Profil in seiner ersten Fassung garantiert. Auf der Politikseite heisst es, die Lösung sei technisch einsatzbereit, Nutzer könnten ihr Alter beweisen, ohne andere personenbezogene Daten preiszugeben, und ihre Aktivität könne nicht getrackt werden. Auf dem technischen Portal wird sogar formuliert, Unlinkability werde „by design“ durch Zero-Knowledge-Proof-Kryptographie26 erreicht. Diese Rhetorik kollidiert mit den Details des veröffentlichten Profils. Dort heisst es nur, die App Instance solle ZKP unterstützen, nicht dass ohne Ausnahme jeder produktive Pfad zwingend auf durchgängigen ZKPs beruhen müsse. Annex B wiederum bezeichnet das bereitgestellte ZKP-Schema ausdrücklich als experimentelles Feature. Die politische Sprache reist also voraus. Die normative Verbindlichkeit kommt deutlich nüchterner daher.27 28

Genau deshalb muss ZKP hier gesondert behandelt werden. Zero-Knowledge Proofs erlauben in diesem Kontext, der Relying Party nur den Sachverhalt „über 18“ oder „über N“ zu beweisen, ohne Geburtsdatum, Identität oder andere Credential-Metadaten offenzulegen. Annex B beschreibt das recht konkret. Der Witness ist die eigentliche Proof-of-Age-Attestation29. Öffentliche Parameter sind etwa der öffentliche Schlüssel des Attestation Providers, das nachzuweisende Attribut und ein Nonce. Der Circuit prüft dann, ob die Attestation gültig signiert ist, ob das geforderte Attribut auf true steht, ob die App über den passenden Geräteschlüssel verfügt und ob die Attestation innerhalb ihrer Gültigkeit liegt. Erst wenn all das zusammenkommt, wird ein knapper Beweis an die Relying Party ausgegeben. Der Dienst braucht keinen vollständigen Nachweis mehr zu sehen, sondern nur einen verifizierbaren Ja-Nein-Beleg.

Ohne durchgängige ZKP-Nutzung bleiben erhebliche Korrelations- und Tracking-Risiken bestehen. Das folgt nicht aus Alarmismus, sondern aus der Spezifikation selbst. Annex B nennt als Anforderung ausdrücklich, dass ein ZKP-Schema die Validitätsdauer verbergen können soll, weil ein fein granuliertes Gültigkeitsfenster als Tracking-Vektor dienen kann. Die Architektur verlangt vom Attestation Provider sogar, den Zeitstempel in ValidityInfo mit einer Präzision zu setzen, die Linkability begrenzt. Wer so formuliert, räumt bereits ein, dass Metadaten des Nachweises korrelationsfähig sein können. Solange also nicht überall der knappe Nullwissen-Beweis an die Stelle des normalen präsentierten Credentials tritt, bleibt ein Teil der Privacy-Garantie organisatorisch und nicht streng kryptographisch abgesichert. Deshalb ist die offizielle Formel „cannot be tracked“ stärker als das, was das normative Profil in seiner ersten Fassung tatsächlich garantiert.

Die Frage, weshalb man bei einem neuen System nicht von Beginn an eine PQC-Basis wählt, lässt sich aus dem veröffentlichten Material indirekt gut beantworten. Annex B formuliert mehrere Anforderungen an das ZKP-Schema. Verlangt wird Kompatibilität mit ECDSA-Schlüsseln, weil mobile Plattformen gerade dafür nutzbare kryptographische Module bereitstellen. Verlangt wird ferner minimale Störung bestehender Infrastruktur. Wörtlich priorisiert die Lösung eine „rapid time-to-market strategy“ unter Nutzung vorhandener Systeme und Standards. Unter den geprüften Ansätzen erscheint ECDSA Anonymous Credentials deshalb „most promising„, gerade wegen der Kompatibilität mit bestehenden Credential-Formaten und Issuance-Flows.30

Politisch besonders aufschlussreich ist die White-Label-Logik. Die Architektur hält fest, dass Mitgliedstaaten oder Drittparteien für Deployment in ihrer Jurisdiktion verantwortlich sind. Die Lösung werde als White-Label-Open-Source-Implementierung bereitgestellt, operative Verantwortung verbleibe nicht beim Konsortium. An anderer Stelle heisst es, die Projektseite sei der Entwickler- und Integratoren-Hub für Mitgliedstaaten, Anbieter und Online-Dienste. Die High-Level-Requirements nennen sogar, was die Implementierer zu tun haben: integrieren, absichern, schützen, deployen, hosten, warten. Die Kommission liefert also Referenzarchitektur, Toolbox, Beispiel-Services, Muster-App und politische Rahmung. Produktiver Betrieb, Härtung, nationale Anbindung und laufender Unterhalt wandern nach unten. Daraus folgte eine belastbare Beobachtung: Implementierungs- und Betriebslast werden funktional externalisiert.31

Dasselbe Muster zeigt sich im zeitlichen und rechtlichen Rollout. Die Kommission erklärt die Lösung seit dem 15. April 2026 für technisch einsatzbereit. Sie beschreibt sie zugleich als Brückenlösung und „mini-wallet„, also als Vorstufe beziehungsweise funktionskompatiblen Baustein der breiteren EUDI-Wallet-Welt, deren Rollout bis Ende 2026 vorgesehen ist. Mitgliedstaaten wie Dänemark, Frankreich, Griechenland, Italien und Spanien wurden bereits als Pilotstaaten genannt; andere sollen folgen. Gleichzeitig ist festzuhalten, dass es nach Reuters derzeit noch keine unionsweit verbindliche Rechtsnorm gibt, die sämtlichen sozialen Netzwerken exakt diese Lösung zwingend vorschreibt. Es gibt politischen Druck, Leitlinien, Pilotierung, Anwendungsdruck aus dem DSA-Umfeld und parallel wachsende nationale Vorstösse. Wer behauptet, es handle sich bloss um eine harmlose App-Idee ohne regulatorische Zukunft, ignoriert die offenkundige Bewegungsrichtung.32 33

Hadmut Danisch liegt richtig, wo er die Presseberichterstattung über den angeblichen „Hack“ als begrifflich unsauber kritisiert und den Blick auf Protokoll, Trust-Modell und Governance lenkt. Richtig liegt er auch mit seiner Skepsis gegenüber der Vorstellung, man könne durch ein paar lokale UI- und Datei-Tricks bereits das eigentliche politische Problem verstanden haben. Was die Quellen zusätzlich zeigen: externer Gesetzesdruck, offene Referenzimplementierungen, regulatorische Anpassung und der Versuch, Alters- und Identitätslogik über gemeinsame Middleware salonfähig und technisch anschlussfähig zu machen.34 35 36 37

Gerade die Linux-Seite ist dafür ein instruktiver Beleg. Das kalifornische AB 1043 verpflichtet Betriebssystemanbieter ab dem 01. Januar 2027 dazu, bei der Kontoeinrichtung Alter oder Geburtsdatum zu erheben und Entwicklern über eine möglichst konsistente Echtzeit-API ein Alterssignal in Altersklassen bereitzustellen. Auf der Ubuntu-Developer-Liste wurde genau deshalb die Einführung einer Schnittstelle org.freedesktop.AgeVerification1 diskutiert, mit Methoden wie SetAge, SetDateOfBirth und GetAgeBracket. Der Thread ist bemerkenswert offen: Man wolle nicht alle Nutzer in Kalifornien und Colorado aussperren, suche also nach einer API, die den Gesetzen genügt, ohne in ein Privacy-Desaster umzuschlagen.

Noch deutlicher wird der infrastrukturelle Sog in den Upstream-Komponenten. Im systemd-Projekt wurde birthDate als Feld in JSON-User-Records tatsächlich gemergt. Der Begründungstext nennt ausdrücklich Kalifornien, Colorado und Brasilien und verweist zugleich auf das xdg-desktop-portal als Abnehmer, der eine Datenquelle für das Alter brauche. Dort wiederum wurde im Portal-Kontext nicht nur über „parental controls“ gesprochen, sondern präzise darüber, dass man aus rechtlichen Gründen ein separates „Age Verification„-Feature brauche. In der Diskussion wird sogar hypothetisch beschrieben, dass eine künftige EU-Lösung ein anonymes staatliches System mit einmalig signierten Tokens bereitstellen könnte, an das ein Age-Verification-Portal andocken müsste.38 39 40

Warum arbeiten Teile der Linux-Gemeinde dabei überhaupt mit? Nicht jede unheilvolle Entwicklung braucht Verrat, manchmal genügt Implementierungwut, wie Hadmut Danisch schreibt. Wer zentrale Alters-APIs, Geburtsdatumsfelder und Portal-Schnittstellen in Basiskomponenten einzieht, normalisiert eine Infrastruktur, die später weit über ihre ursprüngliche Rechtfertigung hinaus genutzt werden kann und wird.

Belegt ist somit eine offene regulatorische Kolonisierung gemeinsamer Infrastruktur. Externe Regulierung schafft Zwangspunkte an Betriebssystemen, App Stores, Portal-APIs und Nutzerverwaltungsdaten. Die EU liefert dafür eine offene Referenzarchitektur samt Trust-Modell, White-Label-App und Integrationspfaden. Teile freier Ökosysteme reagieren mit Implementierungswut. Das Resultat ist eine schleichende Vereinnahmung: freie Infrastruktur dient als billige, flexible und reputationsstarke Integrationsschicht für Alters- und Identitätslogik, die politisch anderswo beschlossen und technisch nach unten durchgereicht wird.

Die eigentliche Gefahr liegt deshalb nicht im einzelnen Bug. Gefährlich ist die Kombination aus einem normierenden Alters- und Identitätsregime, White-Label-Rollout, zentralen Trust-Listen, ausgedünnter Gegenstellen-Authentisierung, fehlender Revocation-Baseline, experimenteller statt zwingender ZKP-Schicht, klassischer statt postquantenresistenter Basiskryptographie und wachsendem regulatorischem Druck auf freie Basisschichten. Eine PIN-Datei, die man lokal manipulieren kann, ist unerfreulich. Ein europaweit ausrollbares Referenzsystem, das sich in Wallets, Portale, Betriebssysteme und Plattform-Compliance einhängt, ist politisch und freiheitsrechtlich die grössere Nachricht.

Genau darum geht es. Nicht um die eine missratene App, sondern um den Aufbau einer ausrollbaren Ordnung, in der offene Systeme die Schienen für ein neues Kontrollregime liefern.

In eigener Sache

Diese Arbeit entsteht nicht im luftleeren Raum. Sie kostet Zeit, Geld, Infrastruktur und sie läuft seit langem unter den Bedingungen eines dokumentierten Rechtsstreits, den ich öffentlich offengelegt habe. Wer dazu beitragen will, dass meine publizistischen Texte, meine technischen Projekte und diese Form unabhängiger Arbeit fortbestehen, kann meine Spendenseite teilen oder mich direkt unterstützen.

Unterstützungsmöglichkeiten:

https://www.gofundme.com/f/rechtsverteidigung-existenzsicherung-arbeitsgericht-lisbon

Oder direkt hier:

Spenden

Mille fois an alle Spender.

Quellen

  1. Heise online, „EU age verification app: ‘Worry-free package’ with security vulnerabilities“, April 2026. Zusammenfassung der publizierten Implementierungsbefunde zu PIN-Schutz, Rate-Limits und lokaler Gerätesicherheit. https://www.heise.de/en/news/EU-age-verification-app-Worry-free-package-with-security-vulnerabilities-11262921.html ↩︎
  2. Hadmut Danisch, „Warum die Kritik an der EU-Altersnachweis-App töricht ist“, 19.04.2026. Analysiert den öffentlichen „Hack“-Diskurs und verschiebt den Fokus auf spezifizierte Sicherheitseigenschaften, Missbrauchsfälle, Revocation und Protokollfragen. https://www.danisch.de/blog/2026/04/19/warum-die-kritik-an-der-eu-altersnachweis-app-toericht-ist/ ↩︎
  3. Age Verification App Instance, kurz AVI. Die Architektur-Spezifikation definiert die AVI als die auf dem Gerät des Nutzers installierte und konfigurierte Age Verification App; sie ist damit die konkrete Instanz, die Nachweise empfängt, verwaltet und präsentiert. https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/ ↩︎
  4. Attestation Provider. Die Architektur-Spezifikation definiert den Attestation Provider als natürliche oder juristische Person, die dem Nutzer einer Age Verification App Instance eine Proof-of-Age-Attestation bereitstellt; er muss konforme Altersattestierungen ausstellen, die Linkability durch geeignete Zeitpräzision begrenzen und in der Trusted List registriert sein. https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/ ↩︎
  5. Authentic Source. Die Architektur-Spezifikation definiert eine Authentic Source als Register, Repository oder sonstiges System unter Verantwortung einer öffentlichen Stelle oder privaten Entität, das Attribute über natürliche oder juristische Personen enthält und als Primärquelle oder rechtlich als authentische Quelle anerkannt ist; zwischen Authentic Source und Attestation Provider ist eine eigene Schnittstelle vorgesehen. https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/ ↩︎
  6. Relying Party. Die Architektur-Spezifikation definiert die Relying Party als natürliche oder juristische Person, die sich auf die Age Verification App stützt, um zu prüfen, ob der Nutzer ein bestimmtes Mindestalter überschritten hat; sie muss die präsentierte Attestation auf Authentizität und Integrität prüfen und dabei auf die Trusted List Bezug nehmen. https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/ ↩︎
  7. Trusted List, hier im Sinn der zentral gepflegten Liste autorisierter Attestation Provider innerhalb der EU-Altersverifikationsarchitektur. Die Architektur-Spezifikation verlangt, dass alle Attestation Provider bei der EU registriert und in eine zentral gepflegte Trusted List aufgenommen werden; die Relying Party kann diese Liste per HTTP GET abrufen, um die Autorisierung des Ausstellers zu prüfen. https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/ ↩︎
  8. European Commission, EU Age Verification Blueprint, „Overall architecture“, technisches Portal, 2026. Enthält Rollenmodell, Interfaces, Trusted-List-Modell, Verzicht auf RP-Registrierung, Revocation-Entscheidung und Anforderungen an Attestation Provider, App und Relying Party. https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/ ↩︎
  9. OpenID Foundation, „OpenID for Verifiable Presentations“, Draft 25, veröffentlicht am 03.04.2025. Die Spezifikation definiert ein Protokoll zum Anfordern und Präsentieren verifizierbarer Credentials; im EU-AV-Profil wird OID4VP als Fallback-Pfad für die Präsentation des Altersnachweises verwendet. https://openid.net/specs/openid-4-verifiable-presentations-1_0-25.html ↩︎
  10. IETF, RFC 7636, „Proof Key for Code Exchange by OAuth Public Clients“, September 2015. https://www.rfc-editor.org/rfc/rfc7636 ↩︎
  11. PKCE, Abkürzung für „Proof Key for Code Exchange“. Bezeichnet das in RFC 7636 standardisierte Schutzverfahren für OAuth-Authorization-Code-Flows, bei dem ein Client pro Anfrage einen kryptographisch zufälligen code_verifier erzeugt und nur dessen abgeleiteten code_challenge vorab übermittelt. ↩︎
  12. mDoc, hier im Sinn des in der EU-Altersverifikation verwendeten ISO-mDoc-Formats. Das AV-Profil beschreibt die Lösung ausdrücklich als Profil für die Ausstellung und Präsentation einer ISO-mDoc-basierten Proof-of-Age-Attestation und verwendet dafür im Anfragebeispiel das Format mso_mdoc mit dem Dokumenttyp eu.europa.ec.av.1. https://ageverification.dev/Technical%20Specification/annexes/annex-A/annex-A-av-profile ↩︎
  13. European Commission, EU Age Verification Blueprint, „Annex A: Age Verification Profile“, Fassung vom 05.02.2026. Legt OID4VCI für Ausstellung, W3C Digital Credentials API für Standardpräsentation, OID4VP als Fallback sowie HPKE, P-256, ES256 und SHA-256 fest; Reader Authentication und Client Authentication sind nicht verpflichtend. https://ageverification.dev/Technical%20Specification/annexes/annex-A/annex-A-av-profile ↩︎
  14. W3C, „Digital Credentials“. Die Spezifikation beschreibt die Digital Credentials API als browserseitige Vermittlungsschicht für Anfragen nach digitalen Credentials von Websites; sie ist format- und protokollagnostisch gedacht und soll einen sichereren und privateren Credential-Austausch zwischen Verifier und Holder ermöglichen als frühere Ad-hoc-Verfahren. https://www.w3.org/TR/digital-credentials/ ↩︎
  15. HPKE, Abkürzung für „Hybrid Public Key Encryption“. Im hier einschlägigen Sinn bezeichnet HPKE das in RFC 9180 standardisierte Verfahren, das Public-Key-Kryptographie zur Kapselung eines Sitzungsschlüssels mit symmetrischer Verschlüsselung für den eigentlichen Nachrichteninhalt kombiniert. ↩︎
  16. IRTF, RFC 9180, „Hybrid Public Key Encryption“, Februar 2022. Beschreibt HPKE als Schema für hybride Public-Key-Verschlüsselung von beliebig grossen Klartexten für einen Empfänger-Schlüssel; einschlägig für die verschlüsselte Übermittlung des DeviceResponse im AV-Profil. https://www.rfc-editor.org/rfc/rfc9180 ↩︎
  17. DCQL, Abkürzung für „Digital Credentials Query Language“. Die OpenID-Spezifikation zu OID4VP beschreibt DCQL als JSON-kodierte Abfragesprache, mit der ein Verifier Präsentationen anfordern kann, die zur formulierten Query passen; das AV-Profil zeigt dafür beispielhaft eine Anfrage nach age_over_18 im Format mso_mdoc. https://openid.net/specs/openid-4-verifiable-presentations-1_0.html ↩︎
  18. Reader Authentication. Das AV-Profil verwendet diesen Begriff für die kryptographische Authentisierung der anfragenden Gegenstelle bei der Präsentation eines Altersnachweises. Für den Standardpfad über die W3C Digital Credentials API erklärt das Profil ausdrücklich: „Reader authentication is not required and therefore is out of scope of this profile“. Im OID4VP-Fallback begründet das Profil die vereinfachte Ausgestaltung zusätzlich mit der Abstützung auf TLS und Web PKI sowie mit dem Fehlen einer Trust List für Relying Parties. https://ageverification.dev/Technical%20Specification/annexes/annex-A/annex-A-av-profile ↩︎
  19. JAR, Abkürzung für „JWT-Secured Authorization Request“. RFC 9101 definiert JAR als OAuth-Erweiterung, bei der Autorisierungsparameter in einem JWT als Request Object übertragen werden, um Integritätsschutz, Quellenauthentisierung und gegebenenfalls Vertraulichkeit der Anfrage zu erreichen. Das AV-Profil nennt JAR ausdrücklich, verlangt es für den OID4VP-Fallback aber gerade nicht; als Begründung führt es an, dass die Schutzwirkung von JAR aus seiner Sicht vom Vorhandensein einer Trust List für Relying Parties abhänge, die in der Age-Verification-Lösung nicht vorgesehen sei. https://www.rfc-editor.org/rfc/rfc9101 ↩︎
  20. IETF, RFC 8446, „The Transport Layer Security (TLS) Protocol Version 1.3“, August 2018. TLS 1.3 ist das einschlägige Internet-Transportprotokoll zur Absicherung von Client-Server-Kommunikation gegen Mithören, Manipulation und Nachrichtenfälschung. https://www.rfc-editor.org/rfc/rfc8446 ↩︎
  21. Web PKI, hier in der üblichen Bedeutung des webbasierten X.509-Zertifikats- und Vertrauensmodells. Technische Grundlage sind insbesondere X.509-Zertifikate und die dazugehörige Zertifikats- und Sperrlisteninfrastruktur, wie sie im Internet-PKI-Profil von RFC 5280 beschrieben ist. https://www.rfc-editor.org/rfc/rfc5280 ↩︎
  22. P-256, auch secp256r1. Bezeichnet die elliptische Kurve, die im JOSE/JWA-Kontext für ES256 verwendet wird; RFC 7518 ordnet ES256 ausdrücklich „ECDSA using P-256 and SHA-256“ zu. https://www.rfc-editor.org/rfc/rfc7518 ↩︎
  23. ES256, JOSE-Algorithmusbezeichnung für ECDSA mit P-256 und SHA-256. RFC 7518 führt ES256 explizit als Signaturalgorithmus „ECDSA using P-256 and SHA-256“. https://www.rfc-editor.org/rfc/rfc7518 ↩︎
  24. NIST, „Post-Quantum Cryptography“, fortlaufendes Standardisierungsprojekt. Bezeichnet kryptographische Verfahren, die gegen Angriffe hinreichend leistungsfähiger Quantencomputer resistent sein sollen; NIST beschreibt PQC ausdrücklich als Antwort auf die künftige Bedrohung heutiger, weit verbreiteter Kryptosysteme durch Quantencomputer. https://csrc.nist.gov/projects/post-quantum-cryptography ↩︎
  25. European Commission, EU Age Verification Blueprint, „Annex B: Zero Knowledge Proofs for the Age Verification Solution“, 2026. Definiert ZKP im AV-Kontext, bezeichnet die ZKP-Lösung als experimentelles Feature, nennt Tracking-Risiken über Validitätsfenster und priorisiert ECDSA-kompatible Ansätze mit minimaler Störung bestehender Infrastruktur. https://ageverification.dev/av-doc-technical-specification/docs/annexes/annex-B/annex-B-zkp/ ↩︎
  26. Zero-Knowledge-Proof-Kryptographie, kurz ZKP. Im Kontext der EU-Altersverifikation bezeichnet dies kryptographische Verfahren, mit denen ein Nutzer einer Relying Party die Wahrheit einer Aussage wie „über 18“ beweisen kann, ohne über die Gültigkeit dieser Aussage hinaus zusätzliche Informationen offenzulegen; Annex B der EU-Spezifikation beschreibt dies ausdrücklich so und ordnet die ZKP-Lösung zugleich als experimentelles Feature ein. https://ageverification.dev/av-doc-technical-specification/docs/annexes/annex-B/annex-B-zkp/ ↩︎
  27. Ebd. ↩︎
  28. European Commission, „The EU approach to age verification“ sowie Startseite des technischen Portals, April 2026. Enthält die politische Privacy-Rhetorik „cannot be tracked“ sowie die technisch-marketinghafte Aussage, Unlinkability werde durch ZKP „by design“ erreicht. https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification ↩︎
  29. Proof of Age attestation. Die Architektur-Spezifikation definiert dies als Attestierung, die Informationen über das Alter des Nutzers unter Verwendung des in der Spezifikation festgelegten Datenmodells enthält; das AV-Profil konkretisiert dies als mDoc-basierten Nachweis mit dem Dokumenttyp eu.europa.ec.av.1. https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/ ↩︎
  30. European Commission, „Call for tenders: Development, consultancy and support for an age verification solution“, 16.10.2024. Zeigt, dass von Anfang an eine generische White-Label-App mit ZKP-Unterstützung erwogen wurde, aber noch im Modus „could be developed“. https://digital-strategy.ec.europa.eu/en/funding/call-tenders-development-consultancy-and-support-age-verification-solution ↩︎
  31. European Commission, „Commission releases enhanced second version of the age-verification blueprint“, 10.10.2025. Dokumentiert Digital Credentials API, Open-Source- und White-Label-Ansatz, freie Weiterentwicklung durch Marktakteure, Pilotstaaten und die damals noch zukünftige ZKP-Integration. https://digital-strategy.ec.europa.eu/en/news/commission-releases-enhanced-second-version-age-verification-blueprint ↩︎
  32. Reuters, „EU age verification app ready as Europe moves to curb children’s social media access“, 15.04.2026. Belegt die politische Dynamik, die Bereitschaft der App und zugleich, dass eine einheitliche unionsweite bindende Gesetzgebung für soziale Medien noch nicht beschlossen ist. https://www.reuters.com/world/eu-age-verification-app-ready-europe-moves-curb-childrens-social-media-access-2026-04-15/ ↩︎
  33. European Commission, „European Digital Identity Regulation“ sowie age verification policy pages, 2025 bis 2026. Ordnet die Lösung als Brückenlogik zur breiteren EUDI-Wallet-Infrastruktur ein. https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation ↩︎
  34. Siehe Fn. 2. ↩︎
  35. Aaron Rainbolt, Ubuntu Developer Mailing List, „On the unfortunate need for an ‘age verification’ API for legal compliance reasons in some U.S. states“, 01.03.2026. Enthält die vorgeschlagene D-Bus-Schnittstelle org.freedesktop.AgeVerification1 samt Methoden und die explizite Suche nach einer gesetzeskonformen Lösung, die kein Privacy-Desaster wird. https://lists.ubuntu.com/archives/ubuntu-devel/2026-March/043510.html ↩︎
  36. systemd Pull Request #40954, „userdb: add birthDate field to JSON user records“, gemergt am 18.03.2026. Nennt Kalifornien, Colorado und Brasilien als Regulierungsanlass und verweist direkt auf xdg-desktop-portal als Abnehmer der Altersdaten. https://github.com/systemd/systemd/pull/40954 ↩︎
  37. xdg-desktop-portal Pull Request #1922, Diskussion um „Age Verification“ versus „parental controls“, März 2026. Dokumentiert die Verschiebung von allgemeiner Kindersicherung hin zu einem eigenen, gesetzesgetriebenen Altersverifikationsportal und den gedanklichen Anschluss an eine mögliche EU-Lösung mit anonymen Tokens. https://github.com/flatpak/xdg-desktop-portal/pull/1922 ↩︎
  38. Ebd. ↩︎
  39. Siehe Fn. 36. ↩︎
  40. Siehe Fn. 35. ↩︎

Categories: Deutschland, Digitalisierung, EU, IT-Security, Kryptographie, Linux, Regulierung, Zensur
Tags: , , , , , , ,

You may also like

Search: