Langsung ke konten utama

Gambaran umum

Peringatan pada laporan liveness menandai setiap kondisi yang diamati Didit saat menjalankan pemeriksaan liveness. Peringatan tersebut masuk ke dalam array warnings[] 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:
  1. Kode risk — pengidentifikasi stabil yang dapat Anda cocokkan di kode Anda (kode yang tercantum di bawah).
  2. log_type — salah satu dari information, warning, atau error. Risiko penolakan otomatis selalu membawa error. 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 adalah error saat nilai berada pada atau di bawah ambang batas penolakan dan warning saat nilai hanya berada pada atau di bawah ambang batas peninjauan.
  3. Dampak keputusan — perutean yang sama mendorong status laporan liveness: tindakan Tinjauan memindahkannya ke In Review, tindakan Tolak (atau risiko penolakan otomatis apa pun) ke Declined, dan Tidak ada tindakan membiarkannya tidak berubah.
Beberapa risiko hanya dimunculkan jika metode liveness adalah 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) menjadi Declined, 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.
Kamera virtual diidentifikasi berdasarkan nama perangkatnya, sehingga kamera yang disajikan sistem operasi dengan nama biasa tidak dikenali dengan cara tersebut. Di dalam emulator Android, kamera yang dipetakan ulang diberi label seperti halnya kamera bawaan, itulah sebabnya kasus perangkat keras yang diemulasikan dilaporkan melalui 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_number dan personal_number dianggap 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.
Jika nama menggunakan aksara yang sama; pengenal atau negara penerbit berbeda atau tidak ada; atau tanggal lahir saling bertentangan, peringatan tetap dihasilkan seperti yang dijelaskan di atas.

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 string short_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_DETECTED dan LOW_LIVENESS_SCORE saling eksklusif — pemeriksaan skor hanya berjalan jika wajah ditemukan. LOW_LIVENESS_SCORE terpicu berdasarkan face_liveness_score_decline_threshold permintaan (default 30) dan selalu membawa log_type: "error".
  • POSSIBLE_FACE_IN_BLOCKLIST diperlakukan sebagai penolakan (log_type: "error"), bukan peninjauan.
  • MULTIPLE_FACES_DETECTED membawa log_type: "warning", sedangkan risiko wajah duplikat tetap bersifat informasional. Hanya peringatan tingkat error yang mengubah status respons mandiri menjadi Declined.
  • Entri peringatan mandiri mencakup feature tetapi tidak menyertakan node_id.

Contoh

Penolakan otomatis pada serangan yang terdeteksi

Peringatan yang dapat dikonfigurasi pada pengambilan pasif

Wajah duplikat dengan payload

Di sini, tindakan wajah duplikat diatur ke Review, sehingga peringatan memuat 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

Contoh ini menunjukkan bukti pemutaran ulang (replay) dari rekaman yang berisi tiga salinan dari urutan gerakan. 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

Terakhir diubah pada 7 November 2026