eu.europa.ec.av.1 erklärt: Wie ein Verifier einen EU-Altersnachweis gegen die Trusted List validiert

Wenn Sie begonnen haben, die EU-Altersverifikations-App zu integrieren, sind Ihnen mit hoher Wahrscheinlichkeit zwei Formulierungen begegnet, die selten in einfacher Sprache erklärt werden: der Namespace eu.europa.ec.av.1 und die Anweisung, die Proof-of-Age-Bescheinigung gegen die Trusted List zu validieren.

Beides ist entscheidend, denn zusammen trennen sie eine echte Altersprüfung von einer fälschbaren. Ein kryptografisch signiertes „ja, diese Person ist über 18“ ist wertlos, wenn Sie die nächste Frage nicht beantworten können: Wer hat es signiert, und durfte diese Stelle das überhaupt? Dieser Beitrag erklärt, was in eu.europa.ec.av.1 steckt, und welche Schritte ein Verifier genau ausführt, um die Echtheit einer Bescheinigung mithilfe der EU Age Verification Trusted List nachzuweisen.

Was eu.europa.ec.av.1 tatsächlich ist

Die EU Age Verification Solution – die White-Label-App, die die Kommission am 15. April 2026 funktional bereitgestellt hat, einschließlich einer Open-Source-Referenzimplementierung (ageverification.dev) – stellt ein bestimmtes Credential aus: eine Proof-of-Age-Bescheinigung. In der ISO/IEC-18013-5-Codierung mso_mdoc sind sowohl der Dokumenttyp dieser Bescheinigung als auch ihr einziger Namespace eu.europa.ec.av.1.

Der Namespace ist bewusst sehr klein. Er enthält nur diese Attribute:

Dazu kommt eine harte Regel aus der Spezifikation: Eine Proof-of-Age-Bescheinigung DARF KEINE anderen Attribute enthalten. Kein Name, keine Dokumentnummer, kein Geburtsdatum – eine Proof-of-Age-Bescheinigung ist eine elektronische Attributsbescheinigung im Sinne von Artikel 3(44) der EUDI-Verordnung. Sie bestätigt einen Schwellenwert und nichts weiter. Genau das ist die Datenminimierung, die im Format selbst verankert ist: Selbst wenn sie wollte, kann die Bescheinigung keine Identität preisgeben.

Das Vertrauensproblem: Ein Boolean braucht einen nachweisbaren Aussteller

Hier liegt der Punkt, auf den jeder Integrator früher oder später stößt. Ihr Verifier erhält ein signiertes Objekt mit age_over_18: true. Die Signatur beweist, dass das Objekt nicht manipuliert wurde – aber sie beweist nicht für sich allein, dass der Signierende ein legitimer Aussteller von Altersbescheinigungen ist. Jeder kann ein Schlüsselpaar erzeugen und {age_over_18: true} signieren.

Die eigentliche Vertrauensentscheidung lautet also nicht „ist die Signatur gültig?“. Sie lautet: Steht das Zertifikat, das diese Signatur erzeugt hat, auf der Liste der Stellen, die die EU zur Ausstellung von Proof-of-Age-Bescheinigungen autorisiert hat? Diese Liste ist die Age Verification Trusted List.

Die Age Verification Trusted List

Die EU Age Verification Trusted List ist eine Trusted List im ETSI-Stil, gehostet von der Europäischen Kommission im eIDAS Dashboard. Sie dient als zentrale Vertrauensanker-Infrastruktur für Altersverifikation in allen Mitgliedstaaten. Jeder Mitgliedstaat meldet der Kommission die in seinem Hoheitsgebiet niedergelassenen Proof of Age Attestation Provider, deren Signaturzertifikate anschließend in der Liste veröffentlicht werden.

Sie wird durch einen eigenen Listentyp identifiziert, die Altersaussteller durch einen eigenen Diensttyp:

<TSLType>http://ec.europa.eu/tools/lotl/av/TrstSvc/TrustedList/TSLType/AVTL</TSLType>
...
<TSPService>
  <ServiceInformation>
    <ServiceTypeIdentifier>http://ec.europa.eu/tools/lotl/av/TrstSvc/Svctype/PAA</ServiceTypeIdentifier>
    <ServiceName><Name xml:lang="en">Age Verification Issuer</Name></ServiceName>
    <ServiceDigitalIdentity>
      <DigitalId><X509Certificate>...</X509Certificate></DigitalId>
    </ServiceDigitalIdentity>
  </ServiceInformation>
</TSPService>

PAA steht für Proof of Age Attestation Provider. Das X509Certificate unter jedem Dienst ist der Vertrauensanker, gegen den Ihr Verifier prüft. Die Kommission hostet außerdem eine Acceptance-Test-Trusted-List in der ACC-Umgebung, damit Sie vor dem Go-live gegen mehrere nationale Testaussteller integrieren können.

Wie ein Verifier eine Bescheinigung validiert, Schritt für Schritt

Wenn eine Proof-of-Age-Bescheinigung eingeht, führt ein korrekt gebauter Verifier alle folgenden Schritte aus und verweigert den Zugriff, wenn einer davon fehlschlägt:

1. Parsen und Scope prüfen. Decodieren Sie das mso_mdoc, bestätigen Sie, dass der Dokumenttyp eu.europa.ec.av.1 ist, und lesen Sie nur das angefragte Attribut, zum Beispiel age_over_18. Alles andere wird ignoriert.
2. Aussteller-Signatur verifizieren. Prüfen Sie die Signatur des Mobile Security Object (MSO), damit klar ist, dass der Inhalt der Bescheinigung authentisch und unverändert ist.
3. Signierenden gegen die Trusted List validieren. Nehmen Sie das Document-Signer-Zertifikat, das diese Signatur erzeugt hat, und bestätigen Sie, dass es zu einem Zertifikat kettet, das in der AV Trusted List unter dem Diensttyp PAA veröffentlicht ist. Dies ist der Schritt, der eine Signatur in Vertrauen verwandelt. Kein Treffer → ablehnen.
4. Gültigkeit prüfen. Erzwingen Sie expiry_date und das ValidityInfo-Fenster des mdoc.
5. Holder Binding bestätigen. Verifizieren Sie, dass die Bescheinigung an das präsentierende Gerät gebunden ist: Das Wallet weist nach, dass es die Kontrolle über den privaten Schlüssel hat, der zum öffentlichen Schlüssel in der Bescheinigung gehört. So kann eine kopierte Bescheinigung nicht wiederverwendet werden.
6. Fail closed. Wenn der Aussteller nicht in der Liste steht, die Signatur nicht verifiziert, der Nachweis abgelaufen oder nicht gebunden ist: verweigern. Niemals „bei Fehler erlauben“.

Die Schritte 2 und 3 sind der Kern. Sie spiegeln das Passive-Authentication-Modell von elektronischen Reisepässen wider: Signatur prüfen, dann das Signaturzertifikat gegen eine autoritative Liste legitimer Aussteller validieren. Die Trusted List ist genau diese autoritative Liste.

Präsentation und Datenschutz: DC API, OID4VP, ZKP und Einmal-mdocs

Zwei Dinge sind wichtig, weil sie bestimmen, wie Sie den Verifier bauen:

Zwei Transportmechanismen. Die Digital Credentials API (DC API) ist der primäre, in den Browser integrierte Weg; OpenID for Verifiable Presentations (OID4VP) ist der Fallback, wenn DC API nicht verfügbar ist. Ein Produktions-Verifier unterstützt beides und wählt zur Laufzeit den besten Pfad.

Zwei Nachweistypen, beide gegen Tracking designt. Eine Präsentation per Zero-Knowledge Proof liefert dasselbe Ja/Nein, ohne eine verknüpfbare Kennung offenzulegen. Die standardmäßige mdoc-Bescheinigung erreicht Unverknüpfbarkeit anders: Nachweise sind einmalig verwendbar und werden in Batches ausgestellt (die Spezifikation empfiehlt 30 pro Batch), und Aussteller vergröbern bewusst die ValidityInfo-Zeitstempel (gleiche hh:mm:ss innerhalb eines Batches, entsprechend der ISO-18013-5-Empfehlung), damit die Bescheinigung selbst keinen Fingerabdruck enthält, mit dem Dienste eine Person über mehrere Besuche hinweg korrelieren könnten.

Die Konsequenz für alle, die eine Altersrichtlinie durchsetzen: Sie erhalten eine Schwellenwert-Antwort, und das Design verhindert, dass Sie daraus eine Tracking-Kennung machen.

Warum genau diese Infrastruktur unsere Aufgabe ist

All das lässt sich erstaunlich leicht falsch machen. Überspringen Sie Schritt 3, und Sie haben eine Altersprüfung, die jeder Angreifer fälschen kann. Codieren Sie ein einzelnes Ausstellerzertifikat fest ein, und Ihre Integration bricht in dem Moment, in dem ein weiterer Mitgliedstaat einen Anbieter meldet. Parsen Sie das ETSI-XML von Hand, übernehmen Sie dauerhaft Trusted-List-Refresh, Zertifikatskettenvalidierung und Revocation.

Genau diese Schicht betreibt eIDAS Pro für Sie: Unser Verifier spricht eu.europa.ec.av.1, validiert jede Bescheinigung gegen die Live-AV-Trusted-List (mit der Test-/ACC-Liste für die Integration), unterstützt DC API und OID4VP und liefert Ihrer Anwendung einen sauberen Boolean zurück – ohne personenbezogene Daten zu speichern. Wenn die eigenständige AV-Bescheinigung und die breiteren EUDI-Wallet-Pfade zusammenlaufen, deckt derselbe Verifikationsaufruf beides ab.

Wenn Ihre Compliance-Anforderung lautet „Alter gegen eine vertrauenswürdige, staatlich autorisierte Quelle prüfen“, dann ist die Trusted List diese Quelle – und ihre Validierung korrekt umzusetzen ist die eigentliche Arbeit.

eIDAS Pro bietet datenschutzorientierte, EUDI-bereite Alters- und Identitätsverifikation für europäische Plattformen – Trusted-List-Validierung, mehrschichtige eID und eine Boolean-out-API, ohne Speicherung personenbezogener Daten. Beratung buchen →

Dieser Artikel ist allgemeine technische Information und keine Rechtsberatung. Arbeiten Sie immer mit den aktuellen EU-Spezifikationen zur Altersverifikation und Ihrer eigenen Compliance-Beratung.