Zum Hauptinhalt springen
Der Bericht zur biometrischen Authentifizierung zeigt, wie Didit die erneute Verifizierung eines wiederkehrenden Benutzers zurückmeldet. Der Workflow führt eine neue Liveness-Prüfung durch und, wenn der Gesichtsabgleich im Workflow aktiviert ist, auch einen 1:1-Gesichtsabgleich mit dem bei der Sitzungserstellung ermittelten Referenzgesicht (das von Ihnen bereitgestellte portrait_image oder das über vendor_data abgefragte gespeicherte Gesicht des Benutzers). Beide Prüfungen erscheinen als standardmäßige Funktionselemente in der V3-Sitzungsentscheidungsantwort.
Didit-Bericht zur biometrischen Authentifizierung, der Liveness-Prüfung und Gesichtsabgleich mit einem gespeicherten Porträt kombiniert

Übersicht

Biometrische Authentifizierung ist ein Workflow-Typ (workflow_type: "biometric_authentication"), kein separates Antwortobjekt. Wenn der Workflow ausgeführt wird, erzeugt er:
  • Eine Liveness-Prüfung, die ein Live-Selfie erfasst und auf Spoofing bewertet.
  • Einen Gesichtsabgleich, der das erfasste Gesicht mit dem bei der Sitzungserstellung ermittelten Referenzgesicht vergleicht (nur wenn der Gesichtsabgleich im Workflow aktiviert ist).
Wann immer der Workflow den Gesichtsabgleich umfasst, erfordert die Sitzungserstellung ein Referenzgesicht. Senden Sie portrait_image (Base64-codiertes Bild, max. 2MB), oder lassen Sie es weg, sodass Didit das für den vendor_data-Benutzer bereits gespeicherte Gesicht wiederverwendet: zuerst ein genehmigtes Liveness-Gesicht, dann das ePass-Chipfoto, dann das Porträt aus dem Ausweisdokument, dann ein manuell registriertes Profilgesicht. Wenn weder portrait_image noch ein gespeichertes Gesicht verfügbar sind, gibt die Sitzungserstellung 400 mit {"portrait_image": "No stored face image was found for this user. Send a portrait_image, or complete an approved verification with face liveness or an ID document for this vendor_data first."} zurück. In beiden Fällen wird die ermittelte Referenz unter der neuen Sitzung erfasst, sodass source_image_session_id des Gesichtsabgleich-Elements auf die eigene session_id dieser Sitzung gesetzt wird (dies zeigt Ihnen an, dass die Referenz aus dem gespeicherten Porträt der Sitzung stammt und nicht aus einem in derselben Sitzung erfassten Dokumentenporträt, was das Feld auf null belassen würde).

Wo es erscheint

Beide Arrays werden von GET /v3/session/{sessionId}/decision/ für Sitzungen zurückgegeben, deren Workflow-Typ biometric_authentication ist. Sie sind immer Arrays – niemals einzelne Objekte – und jedes ist null, bis der jeweilige Schritt Daten erzeugt hat. Jedes Element enthält eine node_id, damit Workflows mit mehreren Instanzen Schritte eindeutig unterscheiden können.

Schema-Referenz

Die vollständige Feldliste wird einmal auf der Datenmodell-Seite definiert, damit jeder Bericht, der diese Funktionen enthält, dieselbe zentrale Referenz nutzt:

Statuswerte

Sowohl liveness_checks[].status als auch face_matches[].status verwenden den gemeinsamen Funktionslebenszyklus (Statuswerte auf Funktionsebene): Der übergeordnete status der Sitzung fasst beide Elemente zusammen: Jede Funktion im Status Declined führt zur Ablehnung der Sitzung, jede im Status In Review setzt die Sitzung auf In Review, andernfalls Approved (nachdem jede Funktion abgeschlossen ist). Informationen zum Schwellenwertverhalten und die vollständige Liste der Warnungscodes finden Sie unter Warnungen zur biometrischen Authentifizierung.

Beispiel – Liveness + Gesichtsabgleich (genehmigt)

Die Beispiele sind gekürzt: Die vollständige Entscheidungsantwort enthält auch session_url, metadata, callback, reviews, contact_details, expected_details, environment, created_at und expires_at.

Beispiel – Nur Liveness (Gesichtsabgleich im Workflow deaktiviert)

Der reine Liveness-Modus ist eine Workflow-Konfiguration: Wenn der Gesichtsabgleich deaktiviert ist, wird bei der Sitzungserstellung kein Referenzgesicht benötigt und face_matches bleibt null. Wenn der Gesichtsabgleich aktiviert ist, fällt das Weglassen von portrait_image nicht auf den reinen Liveness-Modus zurück: Didit verwendet das für den vendor_data-Benutzer gespeicherte Gesicht wieder, und wenn kein gespeichertes Gesicht existiert, schlägt die Sitzungserstellung mit 400 fehl.

Beispiel – Gesichtsabgleich wegen geringer Ähnlichkeit abgelehnt

Sicherheitshinweis

reference_image, video_url, source_image und target_image sind signierte URLs, die nach einem begrenzten Gültigkeitsfenster (standardmäßig 4 Stunden) ablaufen. Sie verweisen auf biometrische Daten – speichern Sie sie nicht im Cache und machen Sie sie nicht öffentlich zugänglich. Speichern Sie das Verifizierungsergebnis (Status, Score, source_image_session_id) auf Ihrer Seite; rufen Sie den Entscheidungs-Endpoint erneut ab, wenn Sie neue URLs benötigen.

Verwandte Themen

Warnungen zur biometrischen Authentifizierung

Warnungscodes, Schwellenwerte und Bedingungen für automatische Ablehnungen.

Liveness-Bericht

Vollständige Feldreferenz für liveness_checks[]-Elemente.

Gesichtsabgleich-Bericht

Vollständige Feldreferenz für face_matches[]-Elemente.
Zuletzt geändert am 7. November 2026