Zum Hauptinhalt springen
Die biometrische Authentifizierung kombiniert eine Liveness-Prüfung mit einem optionalen 1:1-Gesichtsabgleich mit dem bei der Sitzungserstellung ermittelten Referenzgesicht (das bereitgestellte portrait_image oder das über vendor_data nachgeschlagene, gespeicherte Gesicht des Benutzers). Jeder Schritt gibt in der V3-Entscheidungs-Payload eigene Warnungen aus. Diese Seite listet jeden Code auf, zeigt, wo er erscheint und wie Schwellenwerte in einen endgültigen Sitzungsstatus überführt werden.

Übersicht

Wenn eine Sitzung zur biometrischen Authentifizierung ausgeführt wird, führt Didit folgende Schritte aus:
  • Erfasst ein Live-Selfie mithilfe von 3D Action, Flash oder passiver Liveness (method: ACTIVE_3D, FLASHING oder PASSIVE).
  • Extrahiert das größte Gesicht aus der Aufnahme und bewertet dessen Liveness.
  • Vergleicht das erfasste Gesicht mit dem Referenzgesicht der Sitzung (bereitgestelltes portrait_image oder gespeichertes Gesicht des Benutzers), sofern der Workflow Gesichtsabgleich beinhaltet.
  • Schreibt das Ergebnis jedes Schritts sowie etwaige Warnungen in die Sitzungsentscheidung.
Warnungen folgen der plattformweit einheitlichen Struktur des Warnungsobjekts: feature, risk, additional_data, log_type, short_description, long_description und node_id.

Wo Warnungen angezeigt werden

In einer typischen Sitzung zur biometrischen Authentifizierung enthält jedes Array ein Element. Bei Workflows mit mehreren Instanzen gibt die node_id bei jeder Warnung eindeutig an, welcher Schritt sie erzeugt hat.

Bedingungen für eine automatische Ablehnung

Die folgenden Warnungen führen unabhängig von Ihrer Workflow-Konfiguration stets zur Ablehnung des jeweiligen Schritts (log_type: "error"): Wenn NO_FACE_DETECTED ausgelöst wird, wird LOW_LIVENESS_SCORE unterdrückt (da kein Gesicht zur Bewertung vorhanden ist).

Konfigurierbare Schwellenwerte und Aktionen

Diese Warnungen werden bewertet und anschließend anhand der von Ihnen pro Workflow festgelegten Schwellenwerte und Aktionen einem Status zugeordnet: POSSIBLE_FACE_IN_BLOCKLIST (LIVENESS) ist nicht konfigurierbar – ein Treffer in der Sperrliste mit geringerer Konfidenz wird immer zur Prüfung (log_type: "warning") weitergeleitet.

Wiederholungsversuche bei der Erfassung

Fehler, die ausschließlich auf behebbare Qualitätsrisiken bei der Erfassung zurückzuführen sind (niedriger Score, kein Gesicht, Qualität, Helligkeit, mehrere Gesichter – und geringe Ähnlichkeit beim Gesichtsabgleich), durchlaufen eine Wiederholungsschleife, bevor der Status endgültig feststeht: Der Benutzer erhält insgesamt bis zu face_liveness_max_attempts / face_match_max_attempts Versuche (Standard: 3, konfigurierbar von 2 bis 5 pro Workflow-Knoten). Wenn das Kontingent erschöpft ist, gilt der berechnete Status des letzten Versuchs, und LIVENESS_MAX_ATTEMPTS_EXCEEDED oder FACE_MATCH_MAX_ATTEMPTS_EXCEEDED wird als information protokolliert, um dies festzuhalten.

Liveness-Warnungen

Die API gibt exakt diese short_description- und long_description-Zeichenfolgen zurück: Übereinstimmungen mit Sperrlisten, Positivlisten und Duplikaten enthalten additional_data mit der übereinstimmenden Sitzung (blocklisted_session_id / allowlisted_session_id / duplicated_session_id, der entsprechenden *_session_number und api_service). Nur einer dieser sechs Codes erscheint pro Bericht. DUPLICATED_FACE_NAME_MISMATCH ist die Ausnahme: Er wird zusätzlich zu DUPLICATED_FACE ausgegeben, niemals stattdessen, wenn die Identität der übereinstimmenden Sitzung nicht mit dem aufgelösten Namen dieser Sitzung übereinstimmt. Seine additional_data ergänzen dieselben Felder der Duplikatsitzung um name_match_score. Ein Name, der auf beiden Seiten in einem unterschiedlichen Schriftsystem geschrieben ist, wird nicht als Abweichung gewertet, wenn die Ausweisdokumente beider Sitzungen denselben ausstellenden Staat, eine exakt übereinstimmende Dokumenten- oder persönliche Nummer und ein nicht widersprüchliches Geburtsdatum aufweisen. Siehe Liveness-Warnungen.

Warnungen zum Gesichtsabgleich

Beispiel – abgelehnt wegen Gesichtsangriff

Beispiel – in Prüfung wegen geringer Ähnlichkeit

Der Wert (58.70) liegt zwischen dem Schwellenwert für eine Ablehnung (Standard: 50) und dem Schwellenwert für eine Prüfung (Standard: 70), weshalb die Warnung log_type: "warning" enthält und der Status des Gesichtsabgleichs In Review lautet. In diesem Beispiel wurde die Warnung bei einer Sitzung ausgelöst, deren session_id 11111111-2222-3333-4444-555555555555 lautet – source_image_session_id enthält die ID der Sitzung selbst, da die Referenz aus dem bei der Sitzungserstellung gespeicherten Porträt stammte.

Warnungstypen

Jedem Risiko wird basierend auf der Konfiguration Ihrer Anwendung ein Warnungstyp zugewiesen. Warnungen unterteilen sich in drei Schweregradkategorien:

Verwandte Themen

Bericht zur biometrischen Authentifizierung

Wo liveness_checks[] und face_matches[] in der V3-Entscheidung erscheinen.

Liveness-Warnungen

Vollständige Referenz zu Liveness-Warnungen einschließlich des Abgleichs doppelter Gesichter.

Warnungen zum Gesichtsabgleich

Vollständige Warnungsreferenz zum Gesichtsabgleich für 1:1-Vergleiche.
Zuletzt geändert am 7. November 2026