Panoramica
Gli avvisi nel report di verifica dell’identità segnalano ogni condizione rilevata da Didit durante la lettura e la validazione del documento. Vengono inseriti nell’arraywarnings[] di ciascun elemento di id_verifications[] (consulta Report di verifica dell’identità), con la struttura descritta in Modelli di dati — Oggetto dell’avviso: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Ogni avviso ha tre livelli:
- Il codice
risk— un identificativo stabile da usare per il confronto nel codice. - Il
log_type— derivato dall’azione assegnata dalla tua configurazione al rischio in fase di valutazione: Rifiuta →error, Revisione →warning, qualsiasi altra cosa →information. - L’impatto sulla decisione — definito dai gruppi di rischio configurabili del workflow. Lo stesso codice
riskpuò essere indirizzato verso Approva, Revisione o Rifiuta a seconda di come è configurata la tua applicazione.
Condizioni di rifiuto automatico
Nei workflow, i seguenti rischi forzano sempre il report di verifica dell’identità (e la sessione) allo statoDeclined. Non sono configurabili:
Per l’API OCR autonoma, il set di rifiuto incondizionato comprende
DOCUMENT_EXPIRED, MINIMUM_AGE_NOT_MET, PORTRAIT_IMAGE_NOT_DETECTED, SCREEN_CAPTURE_DETECTED, PRINTED_COPY_DETECTED, PORTRAIT_MANIPULATION_DETECTED e PUBLIC_DOCUMENT_IMAGE_DETECTED. Nei workflow, l’età minima è configurabile (Rifiuta per impostazione predefinita) e i tre rischi di vitalità del documento sono gestiti tramite soglie (vedi sotto).
I parametri di richiesta per i rischi configurabili di tale API accettano DECLINE o NO_ACTION anziché un verdetto di Revisione. L’unico esito di Revisione che può restituire non è configurabile: quando un controllo di vitalità del documento richiesto non produce un punteggio utilizzabile, la risposta è In Review con un avviso DOCUMENT_LIVENESS_NOT_COMPUTED (consulta Vitalità del documento).
Impostazioni di verifica configurabili
Nella console Didit, i restanti rischi relativi ai documenti d’identità sono raggruppati in impostazioni che puoi instradare verso Approva, Revisione o Rifiuta (per workflow e per nodo nei workflow a grafo):
I rischi di duplicato e blocklist dell’acquisizione silenziosa provengono dalla Ricerca facciale sul selfie scattato durante l’acquisizione del documento. La ricerca viene eseguita quando Ricerca facciale con acquisizione silenziosa (
document_selfie_face_search_enabled) è attiva, impostazione predefinita, e la Ricerca facciale non è disattivata nel passaggio di Rilevamento della vitalità; altrimenti nessuno di questi sei rischi viene generato.
Due famiglie di rischi relativi ai documenti d’identità sono basate su soglie anziché su selettori Approva/Revisione/Rifiuta:
- Rilevamento della vitalità del documento —
SCREEN_CAPTURE_DETECTED,PRINTED_COPY_DETECTED,PORTRAIT_MANIPULATION_DETECTED. Ciascun tipo di frode ha le proprie soglie di rifiuto e revisione: punteggio inferiore alla soglia di rifiuto →error+ Rifiutata; inferiore alla soglia di revisione →warning+ In revisione; altrimentiinformation. - Confronto facciale tra fotocamere —
LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY, regolato dadocument_selfie_portrait_match_decline_threshold/document_selfie_portrait_match_review_threshold.
Configurazione delle soglie di rilevamento della vitalità del documento
Nell’editor dei workflow queste soglie si trovano nella scheda Falsificazione del passaggio di Verifica dell’identità, con una scheda per ciascun tipo di frode: Sostituzione del ritratto, Copia stampata e Cattura schermo. Ciascun controllo assegna al documento un punteggio da0 a 100 che ne indica l’autenticità apparente. Un punteggio più alto indica che il documento è più probabilmente autentico. I due valori su ciascuna scheda dividono tale scala in tre fasce:
Aumentando uno dei due valori il controllo diventa più rigoroso: un numero maggiore di sessioni finisce nella fascia superiore. Abbassando un valore si lascia passare un numero maggiore di sessioni. Nell’editor il valore Rifiuta non può superare il valore Revisione. Tramite API, un valore Rifiuta superiore al valore Revisione rimuove la fascia In revisione.
Valori predefiniti della piattaforma, utilizzati quando un workflow non imposta un valore:
Inizia dai valori predefiniti e modifica un valore alla volta. Ciascuna scheda mostra il valore predefinito e un pulsante Ripristina valori predefiniti, così puoi sempre tornarvi. L’editor ti avvisa inoltre in merito a queste configurazioni:
- Revisione a
100. Solo un punteggio perfetto supera il controllo, quindi quasi ogni sessione passa a In revisione o viene rifiutata. - Rifiuta a
100. Solo un punteggio perfetto evita il rifiuto, quindi quasi ogni sessione viene rifiutata. - Entrambi i valori a
0. Nessun punteggio viene mai segnalato, quindi il controllo è di fatto disattivato.
SCREEN_CAPTURE_DETECTED.
Il confronto facciale tra fotocamere utilizza lo stesso principio con una differenza sul limite: un punteggio pari alla relativa soglia di revisione passa comunque a In revisione.
Quattro rischi relativi all’ID non sono né configurabili né basati su soglie. POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST reindirizza sempre a Revisione: un selfie che si avvicina a un volto presente nella blocklist, senza essere una corrispondenza confermata, deve essere valutato da una persona; non dà mai luogo a un rifiuto automatico e non viene mai ignorato. BARCODE_SIGNATURE_INVALID reindirizza sempre a Revisione. Si attiva solo quando un codice a barre riporta una firma dell’autorità di emissione che non supera la verifica crittografica, quindi non esiste alcuna configurazione in cui una contraffazione accertata venga ignorata. DOCUMENT_BACK_SIDE_NOT_AVAILABLE è sempre di tipo informativo e non influisce mai sulla decisione: segnala una limitazione del catalogo dei documenti di Didit, non una caratteristica del documento presentato, quindi non esiste alcuna configurazione in cui possa rifiutare o inviare in revisione un titolare autentico.
FRONT_CAMERA_CAPTURED_DOCUMENT reindirizza sempre a Revisione.
Si attiva solo quando il fotogramma della fotocamera frontale acquisito durante la scansione del documento mostra un documento d’identità e nessuna persona, così che un’acquisizione che non dice nulla su chi reggesse il documento raggiunga sempre una persona.
Viene controllato ogni volta che il confronto tra selfie e acquisizione del documento (is_document_selfie_portrait_match_enabled) è attivo.
Avvisi generati
Verificato rispetto acollect_ocr_logs, al flusso di acquisizione del documento e a process_ocr_logs_and_get_status. Le descrizioni brevi di seguito rappresentano le stringhe esatte di short_description restituite dall’API.
Riconoscimento e qualità del documento
Il flusso di acquisizione può anche rifiutare un caricamento con i codici di feedback
IMAGE_RESOLUTION_TOO_LOW, DOCUMENT_NOT_FULLY_VISIBLE, IMAGE_QUALITY_TOO_LOW e DOCUMENT_OCCLUSION_DETECTED (un dito o un oggetto viene ritenuto fisicamente sovrapposto al testo stampato). Ciascuno di essi richiede un nuovo tentativo nell’SDK e viene registrato nel report come rischio a sé stante, instradato dalle impostazioni di Image Quality; DOCUMENT_OCCLUSION_DETECTED e IMAGE_QUALITY_TOO_LOW condividono la stessa azione. Questi codici descrivono l’acquisizione: un nuovo tentativo riuscito cancella l’avviso. La questione se un campo coperto debba influire sulla decisione viene gestita separatamente dal controllo di integrità CRITICAL_FIELD_OCCLUSION_DETECTED riportato sotto, che viene generato al momento della decisione e ha come valore predefinito Revisione.Estrazione dei campi
MRZ, QR, codice a barre
Tutti e tre i rischi MRZ vengono saltati per i tipi di documenti con MRZ notoriamente inaffidabili.La verifica della firma del codice a barre copre attualmente le carte d’identità nazionali francesi, il cui codice a barre ANTS 2D-Doc è firmato dall’autorità di emissione.
BARCODE_SIGNATURE_INVALID viene generato solo quando lo stesso controllo della firma rifiuta il payload. Un codice a barre senza firma, uno firmato da un’autorità non ancora presente nell’archivio delle autorità attendibili di Didit o uno la cui firma non può essere decodificata viene trattato come dato non autenticato e convalidato rispetto alla MRZ e al testo stampato come in precedenza, senza generare questo rischio.I codici a barre delle patenti di guida statunitensi e canadesi (AAMVA) non sono verificati crittograficamente: la firma digitale in tali contesti è opzionale e specifica per giurisdizione, e nessuna giurisdizione pubblica le chiavi di verifica, quindi Didit rileva e registra solo se un payload presenta una firma; la firma in sé non viene mai controllata. Gli errori di firma AAMVA non costituiscono oggi un segnale di rischio. Un payload AAMVA manomesso emerge solo come BARCODE_VALIDATION_FAILED, e solo se la manomissione fa sì che il codice a barre sia in disaccordo con la MRZ o i dati stampati/OCR: una firma falsificata su un payload altrimenti internamente coerente passa senza alcun segnale.All’utente non viene mai richiesto di ripetere l’acquisizione in caso di BARCODE_SIGNATURE_INVALID: una firma che non corrisponde al payload non può essere corretta scattando una foto migliore.Corrispondenza dell’identità
Vitalità del documento (manomissione)
Basato su soglie per tipo di frode nei workflow. Sull’API OCR autonoma questi tre rischi comportano il rifiuto incondizionato, e un controllo richiesto che non produce alcun punteggio utilizzabile restituisceIn Review invece di approvare.
I punteggi stessi sono presenti su ogni report V3 come document_liveness, anche quando non è scattato alcun avviso, consentendo comunque l’audit di un documento approvato.
Integrità del canale di acquisizione
Il
log_type riflette l’azione configurata: error per Rifiuta, warning per Revisione, information per Nessuna azione.
Azione consigliata: tratta una sessione rifiutata come un’acquisizione iniettata e chiedi alla persona di effettuare un nuovo tentativo su un dispositivo fisico con la sua fotocamera integrata.
I segnali che una persona reale può produrre non generano mai INJECTION_ATTACK_DETECTED e rimangono informativi.
Le app che trasmettono una fotocamera reale, come un telefono usato come webcam o una sovrapposizione di effetti su una webcam reale, non vengono segnalate come attacchi di iniezione.
Questo è il rilevamento degli attacchi di iniezione, che è distinto dal rilevamento degli attacchi di presentazione (un falso mostrato a una fotocamera reale).
Immagini di documenti pubblici noti
Mancate corrispondenze con i dettagli previsti
Quando passiexpected_details a una sessione, Didit genera un avviso di mancata corrispondenza per ogni campo non corrispondente. Un unico raggruppamento (expected_details_mismatch_action, predefinito Revisione) controlla l’instradamento per tutti questi casi:
Ogni avviso di mancata corrispondenza include i valori previsti ed estratti in
additional_data.
Età
Indirizzo
Corrispondenze di documenti tra sessioni
Oltre agli avvisi sopra indicati, il report V3 di verifica dell’identità include un arraymatches[] — fino a 5 altri documenti nella tua applicazione con la stessa data di nascita, lo stesso paese di emissione e un nome completo altamente simile (i documenti nella blocklist richiedono inoltre una corrispondenza esatta del numero di documento), escluse le sessioni che appartengono allo stesso utente. I documenti aggiunti alla tua blocklist compaiono con is_blocklisted: true. I documenti nella tua lista consentita compaiono comunque tra le corrispondenze, ma l’azione associata all’utente duplicato viene ignorata.
Ogni corrispondenza include session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted, api_service e un front_image_url firmato.
Esempi
Avviso configurabile con instradamento predefinito (informazione)
Rifiuto automatico per documento scaduto
Mancata corrispondenza dei dettagli previsti con payload
Tipi di avviso
A ciascun rischio viene assegnata una gravità in base alla configurazione della tua applicazione. Le tre gravità sono:Correlati
- Report di verifica dell’identità — schema completo del report e stati.
- Monitoraggio dei documenti — come Didit rileva le manomissioni e i duplicati tra sessioni.
- Webhook —
session.status.updatedinclude gli avvisi non appena il passaggio ID termina. - Modelli di dati — Verifica dell’identità — schema canonico campo per campo.
- Modelli di dati — Oggetto avviso — la struttura di ogni voce in
warnings[].