---

title: "Integration des EU-Altersnachweises: Ein Entwicklerleitfaden zum Namespace eu.europa.ec.av.1" excerpt: "Der EU-Aussteller für Altersverifikation stellt eine „Proof of Age"-Bescheinigung im mso_mdoc-Format unter dem Namespace eu.europa.ec.av.1 über OpenID4VCI aus. Hier erfahren Sie, was dieser Namespace tatsächlich enthält, wie die Ausstellung funktioniert und wie Sie Ihre Integration auf den Live-Referenz-Aussteller richten – mit dem Vorbehalt, dass es sich um eine Referenz handelt, nicht um einen Produktions-Endpunkt." date: "2026-06-26" readTime: "11 Min. Lesezeit" author: "eIDAS Pro Team" category: "Technik" tags: ["Altersverifikation", "mdoc", "OpenID4VCI", "Proof of Age", "Entwicklerleitfaden", "EUDI Wallet"] coverImage: "/images/integrating-eu-proof-of-age-attestation-developer-guide.jpg"

Wenn Sie Altersverifikation gegen die EU-Lösung integrieren, wird eine Zeichenkette in Ihrem Code häufiger auftauchen als jede andere: eu.europa.ec.av.1. Es ist der Namespace der „Proof of Age"-Bescheinigung, und zu verstehen, was er ist – und was er bewusst nicht ist –, ist das Fundament einer korrekten Integration.

Dieser Leitfaden ist das praktische Gegenstück zu unserer konzeptionellen Aufschlüsselung der EU-Altersverifikations-App. Hier bleiben wir auf der Protokoll- und Datenmodell-Ebene: das Credential-Format, der Ausstellungsablauf und wie Sie Ihren Code mit dem Live-Referenz-Aussteller verdrahten.

Die Bescheinigung, genau

Der offizielle Age Verification Issuer der EU ist ein (Q)EAA-Anbieter – ein Anbieter (qualifizierter) elektronischer Attributbescheinigungen im Sinne von eIDAS 2.0. Er implementiert die Age Verification Specification und stellt eine „Proof of Age"-Bescheinigung mit diesen definierenden Eigenschaften aus:

• Format: mso_mdoc – das ISO/IEC-18013-5-Mobile-Document-Format, dieselbe Familie, die von mobilen Führerscheinen und der PID des EUDI-Wallets verwendet wird. Wenn Sie Wie eIDAS-Verifikation funktioniert gelesen haben, ist das das Credential-Format darunter.
• Namespace: eu.europa.ec.av.1. Jeder Claim in der Bescheinigung ist durch diesen Namespace qualifiziert. Die Version ist im Namespace selbst eingebacken – das nachgestellte .1 –, sodass eine künftige Breaking Change zu eu.europa.ec.av.2 wird und Ihr Code darauf verzweigen kann.
• Semantik: Sie bestätigt, dass der Inhaber über einer bestimmten Altersschwelle liegt, ohne das Geburtsdatum offenzulegen. Das ist der ganze Sinn. Die Bescheinigung beantwortet „Ist diese Person über N?" und nichts weiter.

In eIDAS-Begriffen ist dies eine elektronische Attributbescheinigung nach Artikel 3(44) der Verordnung. Diese rechtliche Einordnung ist keine Dekoration – sie ist das, was einer Altersnachweis-Präsentation grenzüberschreitende Rechtswirkung verleiht, genauso wie eine grenzüberschreitende Verifikation einer Identität.

Warum ein Namespace statt nur „Alter ≥ 18"

Neueinsteiger fragen oft, warum die EU etwas so Einfaches wie einen Über-18-Boolean in einen formalen mdoc-Namespace verpackt hat. Drei Gründe, von denen jeder Ihnen später Arbeit erspart:

1. Mehrere Schwellen, ein Modell. Altersschranken sind nicht alle 18. Alkohol, Glücksspiel, bestimmte Inhalte und Regeln für „an Kinder gerichtete Dienste" verwenden 16, 18, 21 und andere. Eine namespaced Bescheinigung kann Schwellen-Claims einheitlich ausdrücken, statt jede Relying Party zu zwingen, ihre eigene Kodierung zu erfinden.
2. Überprüfbare Herkunft. Weil der Claim innerhalb eines signierten mdoc liegt, prüft Ihr Verifier eine Signatur und eine Vertrauenskette – nicht einen selbstbehaupteten Wert. Die Signatur ist das, was dies grundlegend von der Alters-Checkbox unterscheidet, die sie ersetzt.
3. Verkettungsfreiheit durch Konstruktion. Die Standard-Bescheinigung ist einmal verwendbar und wird in Batches ausgestellt, gerade damit wiederholte Präsentationen nicht zu einem Profil korreliert werden können. Darauf kommen wir weiter unten zurück, denn es ist die am häufigsten überbehauptete Eigenschaft des Systems.

Ausstellung: OpenID4VCI

Der Aussteller folgt OpenID for Verifiable Credential Issuance (OpenID4VCI). Wenn Ihr Team mit OpenID4VP für die Präsentation gearbeitet hat, ist VCI dessen ausstellungsseitiges Geschwister: Wo VP der Weg ist, wie ein Credential Ihnen präsentiert wird, ist VCI der Weg, wie es überhaupt erst ins Wallet gelangt.

Der Ablauf, auf der Ebene, auf der Sie ihn durchdenken müssen:

1. Ein Nutzer onboardet sich in der Altersverifikations-App oder im Wallet und weist sein Alter einmalig über eine vertrauenswürdige Quelle nach (eine eID oder – seit Blueprint v2 – einen Reisepass oder nationalen Personalausweis).
2. Das Wallet führt einen OpenID4VCI-Austausch mit dem Aussteller durch, um einen Batch von Proof-of-Age-Bescheinigungen zu erhalten.
3. Jede Bescheinigung im Batch ist einmal verwendbar. Während der Nutzer im Lauf der Zeit Nachweise präsentiert, zieht das Wallet vom Batch ab und füllt nach Bedarf auf.

Als integrierende Relying Party betreiben Sie die Ausstellungsseite in der Regel nicht – das ist die Aufgabe des (Q)EAA-Anbieters. Aber das Verständnis erklärt die Eigenschaften, die Sie zur Präsentationszeit beobachten werden: kurzlebige, einmalige Nachweise, ohne stabilen Identifikator, an dem man sich festmachen könnte.

Der Live-Referenz-Aussteller – und der entscheidende Vorbehalt

Die EU veröffentlicht eine funktionierende Referenzimplementierung. Das Aussteller-Backend (av-srv-web-issuing-avw-py) ist Open Source unter der offiziellen GitHub-Organisation EU Digital Identity Wallet, urheberrechtlich bei der Europäischen Kommission, und es gibt einen live, öffentlich gehosteten Referenz-Aussteller, den Sie während der Entwicklung ausüben können.

Lesen Sie das sorgfältig: Es ist eine Referenz- und Testimplementierung. Es ist ausdrücklich kein produktionsvollständiger, bürgertauglicher Aussteller. Nutzen Sie ihn, um Ihre Integration, Ihr Credential-Parsing und Ihren Präsentationsablauf zu validieren. Bauen Sie keinen Launch-Plan, der davon ausgeht, dass es der Produktions-Endpunkt ist, den Ihre echten Nutzer ansteuern – dieser Endpunkt werden die nationalen Altersverifikations-Apps und Wallets sein, die die Vorreiter-Mitgliedstaaten ausrollen. Behandeln Sie den Referenz-Aussteller so, wie Sie jede Sandbox behandeln würden: unschätzbar wertvoll für das Bauen, keine Produktionsabhängigkeit.

Das Datenschutzversprechen, korrekt formuliert

Hier trennen sich sorgfältige Ingenieure von Marketing-Texten. Sie werden lesen, dass die EU-Altersverifikationslösung Zero-Knowledge Proofs (ZKP) verwendet, sodass eine Relying Party nur eine Ja/Nein-Antwort erfährt, ohne jede Möglichkeit der Korrelation. Seien Sie präzise:

• Was solide ist: Die Standard-mdoc-Bescheinigung ist einmal verwendbar und batch-ausgestellt, gerade um Verkettbarkeit zu vereiteln. Der Nachweis offenbart den Über-Schwellen-Status, nicht das Geburtsdatum oder die Identität. Das ist eine echte, ausgelieferte Datenschutzeigenschaft.
• Womit Sie vorsichtig sein müssen: ZKP wird in der Verifier-Leitlinie als ein unterstützter, bevorzugter Nachweistyp beschrieben – nicht als eine universell ausgelieferte, vollständig nicht-korrelierbare Garantie, die in irgendeinem Anhang spezifiziert wäre. Schreiben Sie keine Dokumentation, die behauptet „das System ist Zero-Knowledge, daher ist Korrelation unmöglich." Schreiben Sie: „Verkettungsfreiheit wird durch einmal verwendbare, batch-ausgestellte Nachweise erreicht; ZKP wird als erweiterter Nachweistyp unterstützt."

Das ist keine Wortklauberei. Wenn Ihre Compliance-Story eine kryptografische Garantie behauptet, die das eingesetzte System noch nicht einheitlich bietet, ist das genau die Behauptung, an der ein Prüfer zieht. Die ehrliche Version ist immer noch eine hervorragende Datenschutz-Story – siehe Datenschutzorientierte Altersverifikation, wie wir sie einordnen.

Eine minimale Integrations-Checkliste

Schritt 6 verbindet diese Entwickleraufgabe zurück mit den Pflichten zur Relying-Party-Registrierung und zu WRPAC. Eine Relying Party, die sich nur für den Altersnachweis registriert, ist strukturell außerstande, zu viel zu fragen – die sauberste mögliche Antwort an einen Datenschutzregulierer.

Das Fazit

Der Namespace eu.europa.ec.av.1 ist klein im Umfang und groß in seiner Konsequenz. Er ist eine mso_mdoc-, Artikel-3(44)-Bescheinigung, ausgestellt über OpenID4VCI, die eine Altersschwelle nachweist und nichts weiter. Bauen Sie gegen den Live-Referenz-Aussteller, um Ihr Parsing und Ihren Präsentationsablauf richtig hinzubekommen – aber behandeln Sie ihn als Sandbox, nicht als Produktion. Und wenn Sie die Datenschutzeigenschaften dokumentieren, beschreiben Sie, was ausgeliefert ist (einmalig, batch-ausgestellt, nur Schwelle), statt was angestrebt wird (universelles ZKP). Bekommen Sie diese beiden Dinge richtig hin, und Ihre Integration übersteht den Kontakt mit echten Wallets ebenso wie mit echten Prüfern.

Dieser Beitrag spiegelt die EU Age Verification Specification und Referenzimplementierung von Juni 2026 wider. Der Referenz-Aussteller ist eine Testimplementierung, keine Produktion. Prüfen Sie das Credential-Schema gegen das offizielle Aussteller-Repository, bevor Sie bauen.