Altersnachweis gegen die EU Trusted List validieren: Der Schritt, den alle überspringen

Ein Verifier, der eine Altersnachweis-Bescheinigung akzeptiert, weil ihre Signatur wohlgeformt ist, hat die halbe Arbeit getan und die wichtige Hälfte übersprungen. Eine gültige Signatur beweist nur, dass das Credential von irgendeinem Schlüssel signiert wurde. Sie sagt nichts darüber aus, ob dieser Schlüssel zu einem Aussteller gehört, dem die EU tatsächlich die Bescheinigung des Alters anvertraut. Diese Lücke zu schließen ist die Aufgabe der Age Verification Trusted List, und die Verifier-Leitlinie ist explizit: Sie müssen jede Altersbescheinigung vor der Zugriffsgewährung gegen sie validieren.

Dies ist der Schritt, den Teams am häufigsten überspringen – und der, nach dem ein Prüfer am zuverlässigsten fragt.

Vertrauen ist eine Liste, keine Signatur

Im EUDI-Ökosystem ist Vertrauen in veröffentlichten Trusted Lists verankert: maschinenlesbaren Registern der Stellen, die zur Wahrnehmung einer bestimmten Rolle berechtigt sind. Für die Altersverifikation ist das relevante Register die Age Verification Trusted List – die Menge der Aussteller, deren Altersnachweis-Bescheinigungen ein konformer Verifier akzeptieren darf.

Die Validierungskette, die Ihr Verifier durchlaufen muss:

1. Parsen Sie das präsentierte mso_mdoc Proof-of-Age (die eu.europa.ec.av.1-Bescheinigung – siehe unseren Entwicklerleitfaden zum Namespace).
2. Verifizieren Sie die Signatur gegen das Zertifikat des Ausstellers.
3. Verankern Sie dieses Zertifikat in der Age Verification Trusted List – bestätigen Sie, dass der Aussteller tatsächlich gelistet ist.
4. Gewähren Sie erst dann Zugriff.

Überspringen Sie Schritt 3, akzeptieren Sie bereitwillig eine perfekt signierte Bescheinigung von einem Aussteller, den niemand autorisiert hat. Das ist der Unterschied zwischen kryptografischer Gültigkeit und Vertrauen, und genau dafür existieren Trusted Lists. Wir gehen die allgemeine Version dieser Kette in Wie eIDAS-Verifikation funktioniert durch; dieser Beitrag ist die altersverifikationsspezifische Ausprägung davon.

Es gibt bereits eine Testliste – in der ACC-Umgebung

Sie müssen nicht auf die Produktion warten, um dies zu bauen. Die Kommission hostet bereits eine Test-Age-Verification-Trusted-List in der ACC-(Acceptance-)Umgebung des eIDAS Dashboards. Ein bemerkenswertes Detail für jeden, der sie erkundet: Der Referenz-Testaussteller erscheint in dieser Umgebung unter Island – eine Testplatzierung, keine Aussage über einen isländischen Einsatz. Nutzen Sie die ACC-Liste, um Ihre Trust-Anchoring-Logik schon jetzt gegen die echte Listenstruktur zu entwickeln und auszuüben, im Vorlauf zur Live-Schaltung der Produktionsliste.

Das eIDAS Dashboard ist dieselbe Infrastruktur, die die Produktions-Trusted-List-Endpunkte hosten wird. Wenn Sie Ihre Validierung gegen die ACC-Liste bauen, ändern Sie bei der Veröffentlichung der Produktionsliste einen Endpunkt und einen Trust Anchor – statt eine Fähigkeit von Grund auf zu architekturieren.

Die Unterscheidung, die Menschen stolpern lässt: AV-Liste ≠ WRPAC-Liste

Dies ist die mit Abstand wichtigste Klarstellung in diesem Beitrag. Das eIDAS Dashboard wird mehrere Trusted Lists für verschiedene Rollen hosten, und sie zu verwechseln führt zu wirklich falschen Integrationen:

Sie laufen in entgegengesetzte Richtungen. Die AV Trusted List schützt Sie, den Verifier, davor, Nachweise von betrügerischen Ausstellern zu akzeptieren. Die WRPAC-Anbieterliste schützt das Wallet des Nutzers davor, Attribute an nicht registrierte Relying Parties offenzulegen. Wie wir dokumentiert haben, ist die WRPAC-Anbieterliste noch nicht veröffentlicht – ihre Pflichten gelten ab dem 24. Dezember 2026. Die AV-Testliste hingegen ist in ACC bereits verfügbar. Dasselbe Dashboard, verschiedene Listen, verschiedene Zeitpläne, verschiedene Richtungen des Vertrauens. Behandeln Sie sie als eine Sache, und Sie verdrahten Ihren Verifier so, dass er das falsche Register prüft.

Operative Realitäten der Trusted-List-Validierung

Ein paar technische Punkte, die eine robuste Implementierung von einer brüchigen trennen:

• Cachen, aber aktualisieren. Trusted Lists ändern sich – Aussteller werden hinzugefügt, Zertifikate rotieren. Holen Sie die Liste, cachen Sie sie aus Performance-Gründen, aber aktualisieren Sie nach einem Zeitplan und behandeln Sie den Fall, dass ein zuvor vertrauenswürdiger Anchor verschwindet.
• Fail closed. Wenn Sie die Trusted List nicht erreichen oder validieren können, ist die korrekte Voreinstellung für eine Altersschranke, zu verweigern – nicht, den Nutzer durchzuwinken. Eine Vertrauensprüfung, die offen scheitert, ist keine Vertrauensprüfung.
• „Noch nicht veröffentlicht" von „leer" unterscheiden. Während dieser Übergangsphase kann ein Endpunkt legitim zurückmelden, dass eine Liste nicht veröffentlicht ist. Das ist ein definierter Zustand, kein zu verschluckender Fehler – genau wie wir es beim WRPAC-Status der EU-27 von Ende Mai 2026 festgestellt haben, wo der WRPAC-Endpunkt bewusst „nicht veröffentlicht" meldet. Ihr Code sollte den Unterschied zwischen „die Liste sagt: keine Aussteller" und „es gibt noch keine Liste" erkennen.
• Test- und Produktions-Anchors sauber trennen. Die ACC-Liste (mit ihrem isländischen Testaussteller) darf in Ihrem Produktions-Verifier niemals ein Trust Anchor sein. Halten Sie die Umgebungskonfiguration explizit, damit ein Test-Anchor niemals in das Produktionsvertrauen durchsickern kann.

Warum dies ein Wettbewerbsvorteil ist, nicht nur ein Häkchen

Die meisten Altersverifikationsanbieter validieren heute eine Signatur und erklären die Sache für erledigt. Ein Verifier, der korrekt an der EU Age Verification Trusted List verankert, tut etwas materiell Stärkeres: Er setzt die Governance der EU darüber durch, wer das Alter bescheinigen darf, nicht nur die Kryptografie einer einzelnen Signatur. Wenn eine regulierte Relying Party – ein Glücksspielbetreiber, ein altersbeschränkter Marktplatz, eine Plattform unter DSA-Artikel 28 – nachweisen muss, wie sie weiß, dass ein Altersnachweis echt ist, ist „wir verankern an der EU Age Verification Trusted List" eine weitaus stärkere Antwort als „die Signatur hat gestimmt". Dieselbe Logik liegt unseren Integrationen für WooCommerce und Online-Gaming zugrunde.

Das Fazit

Die Validierung gegen die Age Verification Trusted List ist der Schritt, der ein signiertes Credential in ein vertrauenswürdiges verwandelt. Die Testliste existiert heute in der ACC-Umgebung des eIDAS Dashboards, es gibt also keinen Grund, ihren Aufbau aufzuschieben. Verankern Sie jeden Nachweis an der Liste, verweigern Sie im Fehlerfall den Zugriff („fail closed"), aktualisieren Sie Ihren Cache, halten Sie Test- und Produktions-Anchors strikt getrennt – und verwechseln Sie niemals die AV-Aussteller-Liste mit der WRPAC-Anbieterliste. Bekommen Sie das richtig hin, und Ihr Verifier setzt EU-Vertrauens-Governance durch, nicht bloß Rechenoperationen.

Dieser Beitrag spiegelt die EU-Vertrauensinfrastruktur zur Altersverifikation von Juni 2026 wider. Die Produktions-Age-Verification-Trusted-List war zum Zeitpunkt der Erstellung noch nicht live; die ACC-Testliste und ihre Platzierungen dienen ausschließlich der Entwicklung. Prüfen Sie gegen das eIDAS Dashboard und die aktuelle Verifier-Leitlinie, bevor Sie sich auf Einzelheiten verlassen.