DC API, OpenID4VP, ZKP: Die Laufzeit-Fallback-Matrix, die jeder Altersverifikations-Verifier implementieren muss

Es gibt eine einzige Designentscheidung, die einen Altersverifikations-Verifier, der für alle funktioniert, von einem trennt, der für die meisten funktioniert: wie er zurückfällt. Die EU-Verifier-Leitlinie zur Altersverifikation überlässt das nicht dem Geschmack. Sie besagt klar, dass ein Verifier mehr als einen Präsentationsmechanismus unterstützen und zur Laufzeit die beste verfügbare Option auswählen muss. Implementieren Sie nur den Happy Path, sperren Sie stillschweigend jeden Nutzer aus, dessen Browser oder Gerät ihn nicht unterstützt.

Dieser Beitrag legt die Fallback-Matrix dar, warum sie existiert und wie man über sie nachdenkt, ohne die Datenschutzeigenschaften an der Spitze des Stacks zu überzeichnen.

Zwei Mechanismen, zwei Nachweistypen

Die Matrix hat zwei Achsen.

Präsentationsmechanismus – wie die Anfrage das Wallet erreicht und die Antwort zurückkommt:

• DC API (Digital Credentials API) – eine browserintegrierte API. Der Browser vermittelt die Credential-Anfrage direkt und bietet das reibungsloseste Nutzererlebnis. Dies ist die primäre Methode, und sie ist in modernen Betriebssystemen und Browsern zunehmend verfügbar.
• OpenID4VP (OpenID for Verifiable Presentations) – das OpenID-basierte Protokoll zum Anfordern und Empfangen überprüfbarer Präsentationen. Dies ist der Fallback, der verwendet wird, wenn der Browser des Nutzers die DC API nicht unterstützt. Wenn Sie zunächst die Protokollgrundlagen möchten, beginnen Sie mit Das OpenID4VP-Protokoll verstehen.

Nachweistyp – welche kryptografische Form der Nachweis annimmt:

• Standard-mdoc-Bescheinigung – das signierte mso_mdoc Proof-of-Age, einmal verwendbar gemacht und in Batches ausgestellt, um Verkettbarkeit zu begrenzen.
• ZKP (Zero-Knowledge Proof) – ein erweiterter Nachweistyp, der stärkere Datenschutzeigenschaften bietet und dort, wo verfügbar, als die bevorzugte Option behandelt wird.

Die Leitlinie fasst dies als Laufzeit-Präferenzreihenfolge auf – stärkster Datenschutz + bestes UX zuerst, mit kontrolliertem Abfallen auf schwächere Optionen:

Ihr Verifier muss die Kombinationen unterstützen, nicht nur seine Lieblingsoption, und die höchstpriorisierte Option auswählen, die jedes Gerät tatsächlich erfüllen kann.

Warum der Fallback nicht optional ist

Es ist verlockend, nur DC API auszuliefern und dem langen Schwanz zu sagen, er solle seinen Browser aktualisieren. Drei Gründe, das nicht zu tun:

1. Abdeckung. Die DC API ist zunehmend verfügbar – was genau die Formulierung ist, die noch nicht universell verfügbar bedeutet. Jeder Nutzer auf einem Browser oder Betriebssystem ohne sie ist eine gescheiterte Altersprüfung, wenn Sie keinen Fallback haben. Für eine Altersschranke ist eine gescheiterte Prüfung kein verschlechtertes Erlebnis; es ist eine blockierte Transaktion.
2. Die Leitlinie verlangt es. „Ihr Verifier muss alle Kombinationen unterstützen" ist nicht beratend. Ein konformer EU-Altersverifikations-Verifier implementiert den Fallback.
3. Kontrolliertes Degradieren ist eine Zuverlässigkeitseigenschaft. Dieselbe Disziplin, die wir auf jede robuste Integration anwenden – davon ausgehen, dass der beste Pfad nicht verfügbar sein könnte, und einen getesteten zweiten Pfad haben –, gilt hier. Der OpenID4VP-Fallback ist Ihr zweiter Pfad.

Die Datenschutz-Reihenfolge, ehrlich formuliert

ZKP auf Priorität 1 zu setzen ist korrekt, aber wie Sie es gegenüber Stakeholdern beschreiben, ist der Punkt, an dem Teams in Schwierigkeiten geraten. Seien Sie präzise dabei, was ausgeliefert ist gegenüber bevorzugt:

• Ausgeliefert und real: Der Standard-mdoc-Nachweis ist einmal verwendbar und batch-ausgestellt und offenbart nur den Über-Schwellen-Status – nicht das Geburtsdatum, nicht die Identität. Das allein vereitelt den naiven Korrelationsangriff „dasselbe Credential zweimal präsentiert".
• Bevorzugt, nicht universell: ZKP ist als ein unterstützter, bevorzugter Nachweistyp gelistet. Dokumentieren Sie Ihr System nicht als „Zero-Knowledge, daher konstruktionsbedingt nicht-korrelierbar", es sei denn, der konkrete Einsatz, den Sie integrieren, liefert ZKP für die betreffende Transaktion tatsächlich. Der korrekte Satz lautet: „Wo ZKP verfügbar ist, bevorzugen wir es; andernfalls beruht die Verkettungsfreiheit auf einmal verwendbaren, batch-ausgestellten mdoc-Nachweisen."

Wir treffen dieselbe sorgfältige Unterscheidung in unserem Entwicklerleitfaden zur Altersnachweis-Bescheinigung und in Datenschutzorientierte Altersverifikation. Es ist wichtig, weil ein Datenschutzversprechen ein Compliance-Versprechen ist und ein überzeichnetes eine Haftung.

Die Laufzeit-Auswahl implementieren

Die Logik, die Ihr Verifier konzeptionell bei jeder Transaktion ausführt:

1. Die DC API per Feature-Detection prüfen. Stellt dieser Browser sie bereit? Wenn ja, sie bevorzugen.
2. Den Nachweistyp aushandeln. Innerhalb der DC API einen ZKP-Nachweis anfordern; einen Standard-mdoc akzeptieren, wenn ZKP nicht verfügbar ist.
3. Auf OpenID4VP zurückfallen, wenn die DC API fehlt, mit einem Standard-mdoc-Nachweis.
4. Vor der Zugriffsgewährung validieren. Unabhängig vom Pfad muss der präsentierte Nachweis gegen die EU Age Verification Trusted List validiert werden, bevor Sie den Nutzer durchlassen. Dieser Validierungsschritt ist ein eigenes Thema – siehe unseren Begleitbeitrag zur Validierung des Altersnachweises gegen die Trusted List.
5. Den Nachweis als einmalig behandeln. Nicht speichern, nicht erneut abspielen, keinen stabilen Identifikator daraus ableiten. Andernfalls würden Sie genau die Verkettbarkeit wieder einführen, die das Batch-Design verhindern soll.

Beachten Sie, dass die Schritte 1–3 das Erreichen des Wallets betreffen und die Schritte 4–5 das Vertrauen und Behandeln der Antwort. Ein korrekter Verifier tut beides. Ein häufiger Fehlermodus sind Teams, die den Anfragepfad meistern und dann den Nachweis falsch behandeln – ihn „für die Audit-Aufzeichnung" speichern, was eine datenschutzwahrende Prüfung stillschweigend in einen Tracking-Datensatz verwandelt.

Wie das ins große Bild passt

Die Fallback-Matrix ist die verifierseitige Mechanik desselben Ablaufs, der auf der Relying-Party-Identitätsseite von der WRPAC-Registrierung abhängt: Ihr Verifier authentifiziert sich als registrierte Relying Party, stellt die Anfrage über DC API oder OpenID4VP, empfängt einen Nachweis, validiert ihn gegen die Trusted List und gewährt oder verweigert den Zugriff. Für einen ausführlicheren Vergleich, wie sich dieses Verifier-Modell von herkömmlichen Identitätsprüfungen unterscheidet, stellt unser Entwicklervergleich EUDI Wallet vs. KYC die beiden nebeneinander.

Das Fazit

Die Verifier-Leitlinie gibt Ihnen eine Präferenzreihenfolge – DC API + ZKP, dann DC API + mdoc, dann OpenID4VP + mdoc – und eine Anweisung: die Kombinationen unterstützen und zur Laufzeit die beste auswählen. Die DC API gibt Ihnen das Erlebnis; OpenID4VP gibt Ihnen die Abdeckung; die Nachweistyp-Reihenfolge gibt Ihnen den Datenschutz. Liefern Sie nur die Spitze der Matrix aus, liefern Sie eine Altersschranke aus, die für die Nutzer scheitert, die am wenigsten wahrscheinlich auf einem topaktuellen Browser sind. Liefern Sie die ganze Matrix aus, beschreiben Sie die ZKP-Eigenschaft ehrlich und behandeln Sie jeden Nachweis als einmalig – und Sie haben einen Verifier, der korrekt, inklusiv und verteidigbar ist.

Dieser Beitrag spiegelt die EU-Verifier-Leitlinie zur Altersverifikation von Juni 2026 wider. Der Laufzeit-Fallback und die Nachweistyp-Reihenfolge beruhen auf der offiziellen Verifier-Leitlinie; prüfen Sie gegen die aktuelle Spezifikation, bevor Sie implementieren.