Vai al contenuto principale
Il report di Autenticazione biometrica è il modo in cui Didit restituisce i risultati di una nuova verifica di un utente già registrato. Il workflow esegue un nuovo rilevamento della vitalità e, quando il Confronto facciale è abilitato nel workflow, un confronto facciale 1:1 rispetto al volto di riferimento determinato durante la creazione della sessione (il portrait_image da te fornito, oppure il volto memorizzato dell’utente cercato tramite vendor_data). Entrambi i controlli appaiono come elementi standard delle funzionalità nella risposta decisionale della sessione V3.
Report di autenticazione biometrica Didit che combina il rilevamento della vitalità e il confronto facciale rispetto a un ritratto memorizzato

Panoramica

L’Autenticazione biometrica è un tipo di workflow (workflow_type: "biometric_authentication"), non un oggetto di risposta separato. Quando il workflow viene eseguito genera:
  • Un rilevamento della vitalità che acquisisce un selfie dal vivo e gli assegna un punteggio in base alla presenza di spoofing.
  • Un confronto facciale che confronta il volto acquisito con il volto di riferimento determinato durante la creazione della sessione (solo quando il Confronto facciale è abilitato nel workflow).
Ogni volta che il workflow include il Confronto facciale, la creazione della sessione necessita di un volto di riferimento. Invia portrait_image (immagine codificata in base64, max 2MB), oppure omettilo e Didit riutilizzerà il volto già memorizzato per l’utente identificato da vendor_data: prima un volto approvato da un rilevamento della vitalità, poi la foto dal chip del passaporto elettronico, poi il ritratto del documento d’identità, quindi un volto del profilo registrato manualmente. Se né portrait_image né un volto memorizzato sono disponibili, la creazione della sessione restituisce 400 con {"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."}. In entrambi i casi, il riferimento determinato viene registrato nella nuova sessione, quindi il campo source_image_session_id dell’elemento di confronto facciale viene impostato sul session_id della sessione stessa (questo indica che il riferimento proviene dal ritratto memorizzato della sessione anziché da un ritratto del documento acquisito nella stessa sessione, il che lascerebbe il campo null).

Dove compare

Entrambi gli array vengono restituiti da GET /v3/session/{sessionId}/decision/ per le sessioni il cui tipo di workflow è biometric_authentication. Sono sempre array — mai singoli oggetti — e ciascuno è null finché il relativo passaggio non ha prodotto dati. Ogni elemento include un node_id in modo che i workflow con più istanze possano distinguere i passaggi.

Riferimento dello schema

L’elenco completo dei campi è definito una sola volta nella pagina dei modelli dati, in modo che ogni report che mostra queste funzionalità condivida un’unica fonte di riferimento:

Valori di stato

Sia liveness_checks[].status sia face_matches[].status utilizzano il ciclo di vita condiviso delle funzionalità (stati a livello di funzionalità): Lo status complessivo della sessione aggrega entrambi gli elementi: qualsiasi funzionalità con esito Declined comporta il rifiuto della sessione, qualsiasi in In Review imposta la sessione in In Review, altrimenti Approved (dopo che tutte le funzionalità sono state completate). Per il comportamento delle soglie e l’elenco completo dei codici di avviso, consulta gli avvisi di Autenticazione biometrica.

Esempio — rilevamento della vitalità + confronto facciale (approvato)

Gli esempi sono abbreviati: la risposta decisionale completa include anche session_url, metadata, callback, reviews, contact_details, expected_details, environment, created_at ed expires_at.

Esempio — solo rilevamento della vitalità (Confronto facciale disabilitato nel workflow)

La modalità con solo rilevamento della vitalità è una configurazione del workflow: quando il Confronto facciale è disabilitato, non è necessario alcun volto di riferimento durante la creazione della sessione e face_matches rimane null. Quando il Confronto facciale è abilitato, l’omissione di portrait_image non esegue un fallback al solo rilevamento della vitalità: Didit riutilizza il volto memorizzato per l’utente identificato da vendor_data, e se non esiste alcun volto memorizzato la creazione della sessione fallisce con 400.

Esempio — confronto facciale rifiutato per bassa somiglianza

Nota sulla sicurezza

reference_image, video_url, source_image e target_image sono URL firmati che scadono dopo una finestra di validità limitata (4 ore per impostazione predefinita). Puntano a dati biometrici: non memorizzarli nella cache né esporli pubblicamente. Conserva il risultato della verifica (stato, punteggio, source_image_session_id) dal tuo lato; chiama nuovamente l’endpoint decisionale se hai bisogno di URL aggiornati.

Correlati

Avvisi di Autenticazione biometrica

Codici di avviso, soglie e condizioni di rifiuto automatico.

Report sul rilevamento della vitalità

Riferimento completo dei campi per gli elementi di liveness_checks[].

Report sul Confronto facciale

Riferimento completo dei campi per gli elementi di face_matches[].
Ultima modifica il 7 novembre 2026