Wenn Ihre App Nutzer heute um ein Foto ihres Reisepasses oder Personalausweises bittet, haben Sie wahrscheinlich gehört, dass die EU Digital Identity Wallets (EUDI-Wallets, amtlich „europäische Brieftaschen für die Digitale Identität“) „Ende 2026“ kommen. Das Datum stimmt, und es ist exakt: der 24. Dezember 2026. Aber es ist eine Frist für die Mitgliedstaaten, nicht für Sie, und es schaltet Dokumentenscans nicht ab.

Dieser Beitrag leistet drei Dinge. Er zeigt, woher das Datum kommt, samt Rechnung. Er listet auf, was eine Wallet tatsächlich übergibt, anhand der Attributtabellen in den Vorschriften. Und er skizziert ein Design, das eine Wallet akzeptiert, wenn der Nutzer eine hat, und auf einen Dokumentenscan zurückfällt, wenn nicht. Geschrieben hat ihn doc.cheap, eine OCR-API für Reisepässe und Ausweise. Lesen Sie die Produktteile also mit diesem Wissen. doc.cheap liest Dokumentbilder; Wallets liest es nicht.

Woher der 24. Dezember 2026 kommt

Die Pflicht steht in Art. 5a Abs. 1 der Verordnung (EU) Nr. 910/2014, eingefügt durch die Verordnung (EU) 2024/1183, die eIDAS-Änderung. Danach „stellt“ jeder Mitgliedstaat „innerhalb von 24 Monaten nach dem Tag des Inkrafttretens der in Absatz 23 dieses Artikels und in Artikel 5c Absatz 6 genannten Durchführungsrechtsakte mindestens eine europäische Brieftasche für die Digitale Identität bereit“.

Die Uhr beginnt also nicht mit der eIDAS-Änderung selbst zu laufen. Sie beginnt mit den Durchführungsrechtsakten der Kommission. Die Rechtsakte nach Art. 5a Abs. 23 sind vier Durchführungsrechtsakte der Kommission vom 28. November 2024, darunter die Durchführungsverordnung (EU) 2024/2979 über die Integrität und die Kernfunktionen der Wallets. Sie wurde am 4. Dezember 2024 im Amtsblatt veröffentlicht (ABl. L, 2024/2979). Ihr Art. 15 besagt, dass sie „am zwanzigsten Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union in Kraft“ tritt.

Die Rechnung:

Schritt Datum
Veröffentlichung im Amtsblatt 4. Dezember 2024
Tag 1 nach der Veröffentlichung 5. Dezember 2024
Tag 20 nach der Veröffentlichung: Inkrafttreten 24. Dezember 2024
Plus 24 Monate (Art. 5a Abs. 1): Wallets fällig 24. Dezember 2026
Plus 36 Monate (Art. 5f Abs. 2): bestimmte private vertrauende Beteiligte müssen Wallets akzeptieren 24. Dezember 2027

Der „zwanzigste Tag nach“ wird ab dem Tag nach der Veröffentlichung gezählt, also landet der 4. Dezember plus 20 Tage auf dem 24., nicht auf dem 23. Dasselbe Inkrafttreten bestimmt auch das zweite Datum in der Tabelle, und das ist das Datum, das die meisten Produktteams tatsächlich betrifft (mehr dazu unten).

Was eine Wallet übergibt

Eine Wallet schickt kein Bild eines Reisepasses. Sie präsentiert signierte Daten. Der Datensatz für eine natürliche Person ist im Anhang der Durchführungsverordnung (EU) 2024/2977 festgelegt: die „Personenidentifizierungsdaten“ (PID, person identification data). Laut Anhang werden PID in zwei Formaten ausgestellt: ISO/IEC 18013-5:2021 und das „Verifiable Credentials Data Model 1.1“ des W3C.

Hier sind die Attribute, jeweils mit dem Status, den der Text ihnen gibt (Tabellen 1, 2 und 5 des Anhangs, in der am 4. Dezember 2024 veröffentlichten Fassung). Die letzte Spalte nennt das nächstliegende Feld in einer Scan-Antwort von doc.cheap, damit Sie sehen, wo beide Welten zusammenpassen und wo nicht.

PID-Attribut Status Nächstliegendes Feld in einem Dokumentenscan
family_name verpflichtend holder.surname
given_name verpflichtend holder.given_names
birth_date verpflichtend holder.birth_date (ISO 8601)
birth_place verpflichtend ein birth_place-Eintrag in fields[], wenn das Dokument ihn aufdruckt
nationality verpflichtend (Alpha-2, einer oder mehrere) holder.nationality (Alpha-3, einer)
resident_address, resident_country, resident_state, resident_city, resident_postal_code, resident_street, resident_house_number optional keines auf der Datenseite eines Reisepasses
personal_administrative_number optional nicht dasselbe; fields[] kann eine vom Dokument aufgedruckte personal_number enthalten
portrait optional images.main_photo
family_name_birth, given_name_birth optional kein kuratiertes Feld
sex optional (Codes 0, 1, 2, 3, 4, 5, 6, 9) holder.sex (M, F, X)
email_address, mobile_phone_number optional nicht auf einem Dokument
expiry_date (Metadaten) verpflichtend document.expiry_date, aber für das Dokument, nicht für die PID
issuing_authority (Metadaten) verpflichtend ein authority-Eintrag in fields[], wenn aufgedruckt
issuing_country (Metadaten) verpflichtend (Alpha-2) document.issuing_state (Alpha-3)
document_number (Metadaten) optional nicht dasselbe: Die Nummer der PID vergibt der PID-Anbieter, document.number ist die des Reisepasses
issuing_jurisdiction, location_status (Metadaten) optional keines

Drei Dinge in dieser Tabelle zählen, wenn Sie den Mapping-Code schreiben.

  • Die Ländercodes unterscheiden sich. PID verwenden ISO 3166-1 Alpha-2 (DE). Reisepässe und die maschinenlesbare Zone verwenden Alpha-3 (DEU). Führen Sie intern eine einzige Form und konvertieren Sie an der Grenze.
  • „Verpflichtend“ heißt nicht „immer bekannt“. Unter Tabelle 1 fügt der Text hinzu: „Ist ein Attributwert für die Person nicht bekannt oder kann er nicht anderweitig als Teil des Personenidentifizierungsdatensatzes ausgestellt werden, so verwenden die Mitgliedstaaten stattdessen einen der Situation angemessenen Attributwert.“ Rechnen Sie mit Platzhalterwerten, nicht mit fehlenden Schlüsseln.
  • Nur fünf Attribute zur Person sind verpflichtend. Adresse, Lichtbild, Geschlecht und Geburtsnamen sind alle optional. Braucht Ihr Ablauf eines davon, kann es sein, dass die Wallet es für einen bestimmten Nutzer schlicht nicht enthält.

Wer weiterhin mit einem Dokument kommt

Die Frist verpflichtet jeden Mitgliedstaat, eine Wallet bereitzustellen. Sie verpflichtet niemanden, eine zu nutzen. Art. 5a Abs. 15 ist unmissverständlich: „Die Nutzung der europäischen Brieftaschen für die Digitale Identität ist freiwillig.“ Und weiter: „Der Zugang zu öffentlichen und privaten Diensten muss weiterhin mit anderen bestehenden Identifizierungs- und Authentifizierungsmitteln möglich sein.“

Nach dem 24. Dezember 2026 werden Sie also weiterhin sehen:

  • Reisende und Kunden von außerhalb der EU. Die Erwägungsgründe knüpfen die Wallet an „die rechtliche Identität von Unionsbürgern, in der Union Ansässigen oder juristischen Personen“. Ein Besucher mit einem Reisepass von anderswo hat keine EU-Wallet, die er vorzeigen könnte.
  • Menschen, die keine installiert haben, es nicht können oder es lieber lassen. Der Text schützt diese Wahl.
  • Abläufe, die das Dokument selbst brauchen. Manche Prozesse wollen das Dokumentbild, die Dokumentnummer oder die maschinenlesbare Zone des physischen Dokuments, keine Bescheinigung über die Person. Die PID einer Wallet tragen ihre eigene document_number, vergeben vom PID-Anbieter, und das ist nicht die Nummer des Reisepasses.
  • Die Zeit, bevor die Wallet eines bestimmten Landes live ist. Der 24. Dezember 2026 ist die gesetzliche Frist. Wann jede nationale Wallet tatsächlich bei den Nutzern ankommt, ist eine andere Frage, und die einzige verlässliche Antwort für ein Land ist die Ankündigung dieses Landes selbst oder die der Kommission.

Ein Design, das beides annimmt

Die Form, die all das übersteht, ist einfach: Fordern Sie eine Wallet-Präsentation an, wenn der Nutzer eine Wallet hat, und fallen Sie auf einen Dokumentenscan zurück, wenn nicht. Beide Wege enden im selben internen Datensatz.

user starts verification
        |
        v
  offers a wallet? --yes--> wallet presentation --> verify signature --> map PID
        |                                                               |
        no                                                              v
        |                                                      internal identity
        v                                                          record
  document photo --> POST /v1/scans --> map scan fields ----------------^

Ein paar Grundsätze machen die beiden Wege austauschbar:

  1. Mappen Sie beide auf einen Datensatz mit Ihren eigenen Feldnamen. Nutzen Sie die Tabelle oben als Mapping.
  2. Halten Sie die Quelle fest. Speichern Sie, ob ein Datensatz aus einer Wallet oder aus einem Scan stammt. Sie liefern unterschiedliche Nachweise, und wer prüft, wird wissen wollen, welchen.
  3. Nehmen Sie Nullwerte als ehrlich. In einer Antwort von doc.cheap ist jeder Schlüssel immer vorhanden, und ein unbekannter Wert ist null. Eine Wallet schickt stattdessen womöglich einen Platzhalter. Normalisieren Sie beides auf eine Konvention.
  4. Speichern Sie nur so viel, wie der Ablauf braucht. Ein Scan lässt sich so ausführen, dass auf der API-Seite nichts gespeichert wird (siehe unten).

Hier ist der Fallback-Aufruf mit reinem fetch. Der öffentliche Sandbox-Schlüssel sk_sandbox_public steht in der Dokumentation und erfordert keine Registrierung; er ist pro Client-Adresse ratenbegrenzt.

import { readFileSync } from "node:fs";
import { randomUUID } from "node:crypto";

async function scanDocument(path, apiKey = "sk_sandbox_public") {
  const response = await fetch("https://api.doc.cheap/v1/scans", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      "Idempotency-Key": randomUUID(), // ein Retry liefert das erste Ergebnis
    },
    body: JSON.stringify({
      image: readFileSync(path).toString("base64"),
      options: { retain_hours: 0, return_portrait: false }, // nichts wird gespeichert
    }),
  });
  if (!response.ok) throw new Error(`scan failed: HTTP ${response.status}`);
  return response.json();
}

// Einen Scan auf denselben Datensatz mappen, den eine Wallet-Präsentation füllen würde.
function fromScan(scan) {
  if (scan.meta.status !== "recognized") return null;
  const field = (name) => scan.fields.find((f) => f.id === `${name}@0`)?.value ?? null;
  return {
    source: "document_scan",
    family_name: scan.holder?.surname ?? null,
    given_name: scan.holder?.given_names ?? null,
    birth_date: scan.holder?.birth_date ?? null,
    birth_place: field("birth_place"),
    nationality_alpha3: scan.holder?.nationality ?? null,
    issuing_country_alpha3: scan.document?.issuing_state ?? null,
    document_number: scan.document?.number ?? null,
    mrz_status: scan.mrz.status, // "passed", "failed" oder "absent"
  };
}

meta.status ist einer von fünf Strings: recognized, no_document_found, unreadable, unsupported_document oder rejected. Nur der erste sollte einen Datensatz füllen; die anderen sollten den Nutzer das Foto neu aufnehmen lassen. Bei einem kostenpflichtigen Schlüssel wird das Guthaben nur belastet, wenn der Scan abrechenbar ist.

Wir haben einen solchen Aufruf am 24. September 2026 um 21:17 UTC gegen sk_sandbox_public ausgeführt, mit dem produkteigenen Testdokument, einem Reisepass. Die Antwort kam mit HTTP 200 zurück. Alle Dokumentwerte unten sind maskiert, und fields, images und mrz.lines sind gekürzt:

{
  "meta": {
    "schema_version": "1.0",
    "id": "<SCAN_ID>",
    "status": "recognized",
    "billed": true,
    "confidence": "medium",
    "timing": { "upload_ms": 255, "processing_ms": 409, "total_ms": 678 },
    "created_at": "<RUN_TIMESTAMP>",
    "reference": null
  },
  "document": {
    "kind": "passport", "country": "<ISO3>", "country_name": "<COUNTRY>",
    "issuing_state": "<ISO3>", "number": "<DOCUMENT_NUMBER>", "series": null,
    "issue_date": "<DATE>", "expiry_date": "<DATE>", "is_expired": false, "days_remaining": "<N>"
  },
  "holder": {
    "given_names": "<GIVEN_NAMES>", "surname": "<SURNAME>", "full_name": "<FULL_NAME>",
    "birth_date": "<DATE>", "sex": "<SEX>", "nationality": "<ISO3>"
  },
  "mrz": { "status": "passed", "reason": null, "lines": ["<LINE_1>", "<LINE_2>"], "text": "<MRZ>" },
  "quality": { "overall": "pass" },
  "authenticity": { "overall": "not_checked", "checks": [] }
}

billed: true bedeutet hier, dass der Scan abrechenbar war und auf das Gratiskontingent der Sandbox angerechnet wurde; der Sandbox-Schlüssel selbst wird nie belastet. Das Array fields dieses Laufs enthielt Einträge für birth_place, authority und personal_number – genau dorthin verweist die Tabelle oben für diese PID-Attribute. Die Datenseite eines Reisepasses trägt ihre MRZ als zwei Zeilen im Layout TD3; die Seite zu den Formaten TD1, TD2 und TD3 zeigt die Layouts nebeneinander.

Beachten Sie authenticity.overall: "not_checked". Ein solcher Scan ist Erkennung: Er liest, was aufgedruckt ist, und prüft die Prüfziffern der MRZ. Er ist keine Fälschungserkennung und bietet nicht dieselbe Sicherheit wie eine signierte Wallet-Präsentation. Braucht Ihr Prozess auf dem Scan-Weg ein höheres Vertrauensniveau, muss das aus einem anderen Teil Ihres Ablaufs kommen. Wenn Sie einen Anbieter für den Fallback auswählen, stellt unser Vergleich von Reisepass-OCR-APIs die Optionen dar, auch solche, die mehr als Erkennung leisten.

Worauf Sie als Nächstes achten sollten

  • 24. Dezember 2026 – Wallets fällig. Art. 5a Abs. 1, Verordnung (EU) 2024/1183, gerechnet ab dem Inkrafttreten der Durchführungsrechtsakte wie oben gezeigt.
  • 24. Dezember 2027 – private vertrauende Beteiligte. Nach Art. 5f Abs. 2 „akzeptieren“ private vertrauende Beteiligte, die für die Online-Identifizierung per Gesetz oder Vertrag eine starke Nutzerauthentifizierung verwenden müssen, „spätestens 36 Monate nach dem Tag des Inkrafttretens der in Artikel 5a Absatz 23 und Artikel 5c Absatz 6 genannten Durchführungsrechtsakte und nur auf freiwilliges Verlangen des Nutzers auch europäische Brieftaschen für die Digitale Identität“. Der Text nennt Verkehr, Energie, Bankwesen, Finanzdienstleistungen, soziale Sicherheit, Gesundheit, Trinkwasser, Postdienste, digitale Infrastruktur, Bildung und Telekommunikation und nimmt Kleinst- und Kleinunternehmen aus.
  • Sehr große Online-Plattformen. Art. 5f Abs. 3 verpflichtet sie, Wallets zur Nutzerauthentifizierung zu akzeptieren, wiederum nur auf freiwilliges Verlangen des Nutzers und für die mindestens erforderlichen Daten.
  • Änderungen an den Durchführungsrechtsakten. Erwägungsgrund 4 der Durchführungsverordnung (EU) 2024/2979 sagt, die Kommission „sollte“ sie bei Bedarf „überprüfen und aktualisieren“. Prüfen Sie die Attributtabellen in 2024/2977, bevor Sie ein Mapping festschreiben.

Die praktische Konsequenz: Bauen Sie den Wallet-Weg, wenn die Länder Ihrer Nutzer ihre Wallets ausrollen, behalten Sie den Dokumentenweg und mappen Sie beide vom ersten Tag an auf einen Datensatz. Die Dokumentation der OCR-API für Reisepässe und Ausweise deckt die Scan-Seite vollständig ab.

Dies ist eine technische Zusammenfassung, keine Rechtsberatung.