portrait_image oder das über vendor_data abgefragte gespeicherte Gesicht des Benutzers). Beide Prüfungen erscheinen als standardmäßige Funktionselemente in der V3-Sitzungsentscheidungsantwort.

Ü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).
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:- Liveness-Element-Schema –
status,method,score,reference_image,video_url,age_estimation,matches[],face_quality,face_luminance,warnings[],node_id. - Gesichtsabgleich-Element-Schema –
status,score,source_image_session_id,source_image,target_image,warnings[],node_id. - Struktur eines Warnungseintrags –
feature,risk,additional_data,log_type,short_description,long_description,node_id.
Statuswerte
Sowohlliveness_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 auchsession_url, metadata, callback, reviews, contact_details, expected_details, environment, created_at und expires_at.
Beispiel – Nur Liveness (Gesichtsabgleich im Workflow deaktiviert)
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.