Gambaran umum
Peringatan pada laporan liveness menandai setiap kondisi yang diamati Didit saat menjalankan pemeriksaan liveness. Peringatan tersebut masuk ke dalam arraywarnings[] pada setiap item di liveness_checks[] (lihat Laporan liveness), dengan feature yang diatur ke "LIVENESS". Setiap entri mengikuti struktur umum objek peringatan: feature, risk, additional_data, log_type, short_description, long_description, node_id.
Setiap peringatan memiliki tiga lapisan:
- Kode
risk— pengidentifikasi stabil yang dapat Anda cocokkan di kode Anda (kode yang tercantum di bawah). log_type— salah satu dariinformation,warning, atauerror. Risiko penolakan otomatis selalu membawaerror. Untuk risiko yang dapat dikonfigurasi, nilainya diturunkan dari tindakan yang dikonfigurasi: Tidak ada tindakan →information, Tinjauan →warning, Tolak →error. Untuk risiko berbasis ambang batas (LOW_LIVENESS_SCORE,LOW_FACE_QUALITY), nilainya adalaherrorsaat nilai berada pada atau di bawah ambang batas penolakan danwarningsaat nilai hanya berada pada atau di bawah ambang batas peninjauan.- Dampak keputusan — perutean yang sama mendorong
statuslaporan liveness: tindakan Tinjauan memindahkannya keIn Review, tindakan Tolak (atau risiko penolakan otomatis apa pun) keDeclined, dan Tidak ada tindakan membiarkannya tidak berubah.
PASSIVE (pemeriksaan beberapa wajah, kualitas, dan luminans). Tabel di bawah mencantumkan kumpulan lengkap kode risiko liveness beserta tingkat keparahannya — tidak ada kode risiko liveness lainnya.
Kondisi tolak otomatis
Risiko-risiko berikut selalu memaksa laporan liveness (dan sesi) menjadiDeclined, dengan log_type: "error":
Saat
NO_FACE_DETECTED terpicu, LOW_LIVENESS_SCORE diredam (tidak ada wajah yang dapat dinilai).
Pengaturan verifikasi yang dapat dikonfigurasi
Di konsol Didit, risiko liveness dikelompokkan di bawah pengaturan alur kerja berikut:Peringatan yang dihasilkan
Liveness inti
Integritas saluran pengambilan
Sinyal serangan injeksi yang dilaporkan oleh klien pada saat pengambilan. Berbeda dari serangan presentasi (artefak yang ditempatkan di depan kamera asli), sinyal-sinyal ini menjelaskan umpan kamera itu sendiri yang diganti atau disadap. Masing-masing dapat dikonfigurasi per alur kerja dan secara default adalah tanpa tindakan, sehingga mengaktifkan fitur ini tidak mengubah keputusan apa pun sampai Anda memilihnya.Browser tidak mengekspos atestasi sumber kamera tingkat OS ke vendor mana pun, sehingga di web sinyal-sinyal ini berfungsi sebagai bukti penguat dan bukan bukti mutlak. Di web, vonis
null berarti tidak ditentukan (label perangkat tidak tersedia hingga izin kamera diberikan) dan tidak pernah memicu risiko.FRAME_INJECTION_SUSPECTED: kasus ini dideteksi dari lingkungan perangkat - tumpukan rendering dan model perangkat yang dilaporkan dalam user agent - bukan dari nama kamera. Temuan yang dipicu dari lingkungan perangkat memuat additional_data.reason: "emulated_capture_device", membedakannya dari analisis frame oleh model liveness itu sendiri.
Mendeteksi mesin dari browser merupakan bukti, bukan atestasi, dan penyerang yang gigih dapat memanipulasinya. SDK mobile native melaporkan sinyal integritas tingkat sistem operasi yang lebih kuat yang tidak dapat dilihat oleh browser (emulator, perangkat yang di-root atau di-jailbreak, pengaitan runtime, debugger yang terpasang), masing-masing dengan tindakannya sendiri yang dapat dikonfigurasi di bawah Integritas perangkat dan runtime. Sinyal-sinyal ini meningkatkan biaya penyerang secara signifikan, tetapi secara mandiri tidak membuktikan bahwa pengambilan berasal dari perangkat asli. Sinyal integritas perangkat independen dari metode liveness, sehingga dapat digabungkan dengan metode Passive, 3D Flash, atau 3D Action & Flash mana pun.
Forensik kewajaran rekaman
LIVENESS_VIDEO_ANOMALY dihitung di sisi server pada rekaman liveness yang disimpan, terpisah dari model liveness. Pemeriksaan ini mendeteksi urutan bergerak yang berulang di beberapa siklus, konsisten dengan umpan yang berulang.
Atur tindakan pada node Liveness atau Estimasi Usia Anda:
NO_ACTION mencatat temuan informasional, REVIEW dapat meningkatkan verifikasi yang sudah diputuskan menjadi Dalam Peninjauan, dan DECLINE dapat meningkatkannya menjadi Ditolak. Pemeriksaan ini berjalan secara asinkron, sehingga eskalasi dapat terjadi setelah hasil awal keluar. Keputusan yang sudah ada dan lebih berat tidak akan diturunkan tingkatnya, dan keputusan peninjauan manual tetap dipertahankan.
Temuan versi 2 mencakup forensics_version: 2, bukti repeated_sequence, dan repeated_moving_sequence di dalam anomaly_reasons. Metrik pengiriman seperti unique_frame_ratio, static_pair_ratio, decoded_fps_ratio, dan max_frame_gap_seconds tetap menjadi diagnostik; metrik tersebut tidak dapat membuktikan adanya pemutaran ulang (replay) secara mandiri. Temuan yang lebih lama menjelaskan versi detektor yang digunakan pada saat itu dan tidak diklasifikasikan ulang secara retroaktif.
Ini adalah sinyal tambahan yang konservatif, bukan deteksi lengkap atas media sintetis atau video yang diinjeksikan. Rekaman tanpa anomali bukan merupakan bukti liveness. Pengambilan gambar yang singkat atau ambigu serta pengambilan tanpa bukti pemutaran ulang yang dapat digunakan tetap tidak ditandai oleh pemeriksaan ini. Rekaman yang hilang atau tidak dapat dibaca tidak menghasilkan temuan dari pemeriksaan ini; pemeriksaan verifikasi lainnya tetap berlaku.
Pencocokan wajah lintas sesi
Untuk kecocokan terhadap wajah yang diimpor atau wajah dari entri daftar (yang tidak memiliki sesi), nilai
*_session_id, *_session_number, dan api_service dalam additional_data bernilai null.
Wajah milik pengguna yang sama (vendor_data yang sama, atau pengguna vendor yang sama jika tersedia) dikecualikan dari seluruh pencarian indeks — baik deteksi duplikat maupun skrining daftar blokir. Prioritas kecocokan adalah: kecocokan persis dengan daftar blokir → kecocokan persis dengan daftar izin → kecocokan duplikat persis → kemungkinan kecocokan dengan daftar blokir → kemungkinan kecocokan dengan daftar izin → kemungkinan kecocokan duplikat — hanya satu dari enam kode yang saling eksklusif ini yang muncul per laporan. DUPLICATED_FACE_NAME_MISMATCH bukan bagian dari kelompok prioritas tersebut: ini adalah kode tambahan yang dihasilkan selain DUPLICATED_FACE ketika pemeriksaan identitas juga gagal, tidak pernah menggantikannya. additional_data.name_match_score tidak pernah memuat nama yang dibandingkan — hanya id dan skor, sehingga tidak ada PII yang masuk ke dalam payload peringatan.
Nama yang ditulis dalam aksara berbeda pada masing-masing dokumen (misalnya Ibrani di satu dokumen dan Latin di dokumen lainnya) dapat menghasilkan skor di bawah ambang batas meskipun kedua sesi tersebut milik orang yang sama. Dalam satu kasus tersebut, DUPLICATED_FACE_NAME_MISMATCH tidak dihasilkan ketika dokumen identitas dari kedua sesi saling menguatkan dalam semua hal berikut:
- Kedua dokumen memuat negara penerbit yang sama.
- Pengenal cocok secara persis di antara kedua dokumen.
document_numberdanpersonal_numberdianggap setara atau dapat saling dipertukarkan, karena nomor nasional yang sama dapat berada di salah satu kolom tergantung pada jenis dokumen. - Jika kedua dokumen memuat tanggal lahir, tanggalnya harus sama.
Kualitas liveness pasif (hanya saat method = "PASSIVE")
LOW_FACE_LUMINANCE dan HIGH_FACE_LUMINANCE saling eksklusif — luminansi berada di bawah minimum atau di atas maksimum, tidak pernah keduanya.
Estimasi usia (alur kerja adaptif dan node AGE_ESTIMATION)
String deskripsi persis
API mengembalikan stringshort_description dan long_description persis berikut untuk setiap risiko:
API deteksi liveness pasif mandiri
API Deteksi Liveness mandiri menggunakan kembali kode risiko yang sama dengan beberapa perbedaan perilaku:NO_FACE_DETECTEDdanLOW_LIVENESS_SCOREsaling eksklusif — pemeriksaan skor hanya berjalan jika wajah ditemukan.LOW_LIVENESS_SCOREterpicu berdasarkanface_liveness_score_decline_thresholdpermintaan (default 30) dan selalu membawalog_type: "error".POSSIBLE_FACE_IN_BLOCKLISTdiperlakukan sebagai penolakan (log_type: "error"), bukan peninjauan.MULTIPLE_FACES_DETECTEDmembawalog_type: "warning", sedangkan risiko wajah duplikat tetap bersifat informasional. Hanya peringatan tingkaterroryang mengubahstatusrespons mandiri menjadiDeclined.- Entri peringatan mandiri mencakup
featuretetapi tidak menyertakannode_id.
Contoh
Penolakan otomatis pada serangan yang terdeteksi
Peringatan yang dapat dikonfigurasi pada pengambilan pasif
Wajah duplikat dengan payload
log_type: "warning" dan status laporan liveness adalah In Review. Dengan pengaturan default (No action), peringatan ini akan memuat log_type: "information". api_service bernilai null karena wajah yang cocok berasal dari sesi alur kerja, bukan panggilan API mandiri.
Wajah duplikat dengan nama berbeda
DUPLICATED_FACE tetap pada tindakan terkonfigurasinya sendiri (di sini, No action — log_type: "information"), sementara DUPLICATED_FACE_NAME_MISMATCH membawa tindakannya sendiri, dengan default Review (log_type: "warning"). Status laporan liveness mengikuti yang paling parah dari keduanya: In Review di sini, meskipun pengaturan wajah duplikat standar saja tidak akan menandainya.
Anomali pada pemeriksaan kewajaran rekaman beserta hasil pengukurannya
log_type bernilai information karena tindakan yang dikonfigurasi adalah NO_ACTION. Diagnostik pengiriman frame, yang dihilangkan dari contoh ini demi ringkasnya penjelasan, tidak memicu temuan tersebut.
Jenis peringatan
Setiap risiko diberikan tingkat keparahan berdasarkan konfigurasi aplikasi Anda. Tiga tingkat keparahan tersebut adalah:Terkait
- Laporan liveness — skema laporan lengkap dan status.
- Peringatan pencocokan wajah — peringatan terkait pencocokan wajah 1:1.
- Webhook —
session.status.updatedmembawa peringatan segera setelah langkah liveness selesai. - Model data — Pemeriksaan liveness — skema kanonis dengan setiap kolom.
- Model data — Objek peringatan — bentuk setiap entri dalam
warnings[].