نظرة عامة
تُشير التحذيرات في تقرير كشف الحيوية إلى كل حالة رصدتها Didit أثناء تشغيل فحص الحيوية. تظهر هذه التحذيرات في مصفوفةwarnings[] الخاصة بكل عنصر داخل liveness_checks[] (راجع تقرير كشف الحيوية)، مع تعيين قيمة feature إلى "LIVENESS". يتبع كل إدخال هيكل كائن التحذير المشترك: feature وrisk وadditional_data وlog_type وshort_description وlong_description وnode_id.
يتكون كل تحذير من ثلاث طبقات:
- رمز
risk— معرّف ثابت يمكنك مطابقته برمجياً في الكود الخاص بك (الرموز الموضحة أدناه). - نوع السجل
log_type— إماinformationأوwarningأوerror. تحمل مخاطر الرفض التلقائي دائماً القيمةerror. أما بالنسبة للمخاطر القابلة للتكوين، فتُشتق القيمة من الإجراء المضبوط: لا يوجد إجراء ←information، المراجعة ←warning، رفض ←error. وبالنسبة للمخاطر المرتبطة بالحدود (LOW_LIVENESS_SCOREوLOW_FACE_QUALITY)، تكون القيمةerrorعندما تنخفض القيمة إلى حد الرفض أو دونه، وتكونwarningعندما تنخفض إلى حد المراجعة أو دونه فقط. - التأثير على القرار — يوجّه منطق التوجيه نفسه حالة تقرير كشف الحيوية
status: ينقله إجراء المراجعة إلىIn Review(قيد المراجعة)، وينقله إجراء الرفض (أو أي خطر رفض تلقائي) إلىDeclined(مرفوضة)، بينما يتركه خيار “لا يوجد إجراء” دون تغيير.
PASSIVE (فحوصات الوجوه المتعددة والجودة والإضاءة). توضح الجداول أدناه المجموعة الكاملة لرموز مخاطر كشف الحيوية ومستويات خطورتها — ولا توجد أي رموز مخاطر أخرى لكشف الحيوية.
شروط الرفض التلقائي
تؤدي المخاطر التالية دائماً إلى فرض حالةDeclined على تقرير كشف الحيوية (وكذلك على الجلسة)، مع log_type: "error":
عند إطلاق
NO_FACE_DETECTED، يتم حجب LOW_LIVENESS_SCORE (لعدم وجود وجه لاحتساب درجته).
إعدادات التحقق القابلة للتكوين
في لوحة تحكم Didit، يتم تجميع مخاطر كشف الحيوية تحت إعدادات سير العمل التالية:التحذيرات الناتجة
كشف الحيوية الأساسي
سلامة قناة الالتقاط
إشارات هجوم الحقن التي يُبلغ عنها العميل وقت الالتقاط. على عكس هجمات العرض (عرض عنصر مصطنع أمام كاميرا حقيقية)، تصف هذه الإشارات استبدال بث الكاميرا نفسه أو اعتراضه. كل منها قابل للتكوين لكل سير عمل ويكون افتراضياً بلا إجراء، لذا فإن تفعيل الميزة لا يغير أي قرارات حتى تختار ذلك.لا توفر المتصفحات أي إقرار لمصدر الكاميرا على مستوى نظام التشغيل لأي مزوّد، لذا فإن هذه الإشارات على الويب تُعد أدلة مؤيدة وليست إثباتاً قاطعاً. على الويب، تعني النتيجة
null غير محددة (تسميات الأجهزة غير متوفرة حتى يتم منح إذن الكاميرا) ولا تُطلق خطراً أبداً.FRAME_INJECTION_SUSPECTED بدلاً من ذلك: حيث يتم اكتشافها من بيئة الجهاز - مكدس العرض وطراز الجهاز المُبلغ عنه في وكيل المستخدم - بدلاً من اسم الكاميرا. تحمل النتائج الصادرة من بيئة الجهاز additional_data.reason: "emulated_capture_device"، مما يميزها عن تحليل الإطارات الخاص بنموذج كشف الحيوية نفسه.
إن اكتشاف الجهاز من المتصفح هو دليل وليس إقراراً، ويمكن لمهاجم متمرس التدخل فيه. تُبلغ حزم SDK الأصلية للهاتف المحمول عن إشارات سلامة أقوى على مستوى نظام التشغيل لا يمكن للمتصفح رؤيتها (المحاكي، أو الأجهزة التي تتمتع بصلاحيات الجذر أو الأجهزة مكسورة الحماية، أو الربط وقت التشغيل، أو أداة تصحيح أخطاء متصلة)، ولكل منها إجراء خاص بها قابل للتكوين ضمن سلامة الجهاز وبيئة التشغيل. ترفع هذه الإشارات تكلفة المهاجم بشكل كبير، ولكنها بمفردها لا تثبت أن الالتقاط جاء من جهاز حقيقي. إشارات سلامة الجهاز مستقلة عن طريقة كشف الحيوية، لذا يمكن دمجها مع أي من التقنيات: Passive أو 3D Flash أو 3D Action & Flash.
التحليل الجنائي لسلامة التسجيل
يتم احتسابLIVENESS_VIDEO_ANOMALY على جانب الخادم على تسجيل كشف الحيوية المخزن، بشكل مستقل عن نموذج كشف الحيوية. ويكتشف تسلسلاً متحركاً يتكرر عبر دورات متعددة، بما يتوافق مع بث متكرر.
حدد الإجراء في عقدة كشف الحيوية أو تقدير العمر الخاصة بك: يسجل
NO_ACTION نتيجة معلوماتية، ويمكن لـ REVIEW تصعيد عملية تحقق تم البت فيها إلى قيد المراجعة، ويمكن لـ DECLINE تصعيدها إلى مرفوضة. يعمل الفحص بشكل غير متزامن، لذا قد يصل التصعيد بعد النتيجة الأولية. لا يتم خفض رتبة أي قرار حالي أكثر صرامة، ويتم الحفاظ على قرارات المراجعة اليدوية.
تتضمن نتائج الإصدار 2 forensics_version: 2، وأدلة repeated_sequence وrepeated_moving_sequence في anomaly_reasons. تظل قياسات التسليم مثل unique_frame_ratio وstatic_pair_ratio وdecoded_fps_ratio وmax_frame_gap_seconds تشخيصية؛ ولا يمكنها إثبات إعادة التشغيل بمفردها. تصف النتائج الأقدم إصدار أداة الكشف المستخدمة في ذلك الوقت ولا يُعاد تصنيفها بأثر رجعي.
هذه إشارة إضافية متحفظة، وليست كشفاً شاملاً للوسائط الاصطناعية أو الفيديو المحقون. التسجيل الخالي من الحالات الشاذة ليس إثباتاً للحيوية. تظل عمليات الالتقاط القصيرة أو الغامضة وعمليات الالتقاط الخالية من أدلة إعادة تشغيل قابلة للاستخدام دون وضع علامة عليها بواسطة هذا الفحص. لا ينتج عن التسجيلات المفقودة أو غير القابلة للقراءة أي نتيجة من هذا الفحص؛ وتظل فحوصات التحقق الأخرى سارية.
مطابقة الوجه عبر الجلسات
بالنسبة لحالات التطابق مع الوجوه المستوردة أو الوجوه المدرجة في القوائم (التي ليس لها جلسة)، تكون قيم
*_session_id و*_session_number وapi_service في additional_data هي null.
تُستثنى الوجوه العائدة لنفس المستخدم (نفس vendor_data، أو نفس مستخدم المورّد عند توفره) من بحث الفهرس بأكمله — سواء كشف التكرار أو فحص قائمة الحظر. تكون أولوية التطابق: التطابق التام مع قائمة الحظر → التطابق التام مع قائمة السماح → التطابق التام المكرر → التطابق المحتمل مع قائمة الحظر → التطابق المحتمل مع قائمة السماح → التطابق المحتمل المكرر — يظهر رمز واحد فقط من هذه الرموز الستة المتنافية في كل تقرير. لا يُعد DUPLICATED_FACE_NAME_MISMATCH جزءًا من مجموعة الأولوية تلك: فهو رمز إضافي يُصدر بالإضافة إلى DUPLICATED_FACE عند فشل التحقق من الهوية أيضًا، ولا يحل محله أبدًا. لا يحتوي additional_data.name_match_score إطلاقًا على الأسماء التي تتم مقارنتها — بل المعرّفات والدرجة فقط، حتى لا تصل أي معلومات تعريف شخصية إلى payload التحذير.
قد يحصل الاسم المكتوب بنظام كتابة مختلف في كل مستند (على سبيل المثال العبرية في أحدهما واللاتينية في الآخر) على درجة أقل من الحد حتى لو كانت كلتا الجلستين تعودان لنفس الشخص. في تلك الحالة تحديدًا، لا يُصدر DUPLICATED_FACE_NAME_MISMATCH عندما يثبت مستندا الهوية للجلستين صحة بعضهما البعض في كل ما يلي:
- يحمل كلا المستندين نفس دولة الإصدار.
- يتطابق معرّف تطابقًا تامًا بين المستندين. يُعامل
document_numberوpersonal_numberبالتبادل، لأن الرقم الوطني نفسه قد يوضع في أيٍّ من الحقلين وفقًا لنوع المستند. - إذا كان كلا المستندين يتضمنان تاريخ ميلاد، فيجب أن يكون التاريخ نفسه.
جودة كشف الحيوية السلبي (فقط عندما يكون method = "PASSIVE")
LOW_FACE_LUMINANCE وHIGH_FACE_LUMINANCE متنافيان — فالسطوع إما أن يكون أقل من الحد الأدنى أو أعلى من الحد الأقصى، ولا يمكن أن يكون كلاهما معًا أبدًا.
تقدير العمر (مسارات سير العمل التكيفية وعُقد AGE_ESTIMATION)
نصوص الوصف الدقيقة
تعيد واجهة برمجة التطبيقات (API) سلاسلshort_description وlong_description الدقيقة هذه لكل خطر:
واجهة API المستقلة لكشف الحيوية السلبي
تعيد Liveness API المستقلة استخدام رموز المخاطر نفسها مع بعض الاختلافات في السلوك:- الرمزان
NO_FACE_DETECTEDوLOW_LIVENESS_SCOREمتنافيان — لا يُجرى فحص الدرجة إلا عند العثور على وجه. ينطلق الرمزLOW_LIVENESS_SCOREبناءً علىface_liveness_score_decline_thresholdالخاص بالطلب (القيمة الافتراضية 30) ويحمل دائماًlog_type: "error". - يُعامل
POSSIBLE_FACE_IN_BLOCKLISTكحالة رفض (log_type: "error") بدلاً من المراجعة. - يحمل
MULTIPLE_FACES_DETECTEDالقيمةlog_type: "warning"، بينما تظل مخاطر تكرار الوجه معلوماتية فقط. تؤدي التحذيرات بمستوىerrorفقط إلى تحويلstatusللاستجابة المستقلة إلىDeclined. - تتضمن مدخلات التحذيرات المستقلة الحقل
featureولكن بدونnode_id.
أمثلة
الرفض التلقائي عند اكتشاف هجوم
تحذيرات قابلة للتكوين في الالتقاط السلبي
وجه مكرر مع payload
log_type: "warning" وتكون حالة تقرير كشف الحيوية In Review. مع الإجراء الافتراضي (بدون إجراء)، كان سيحمل log_type: "information" بدلاً من ذلك. تكون قيمة api_service هي null لأن الوجه المطابق جاء من جلسة سير عمل، وليس من استدعاء API مستقل.
وجه مكرر باسم مختلف
DUPLICATED_FACE عند الإجراء المُكوَّن له (هنا، بدون إجراء — log_type: "information") بينما يحمل DUPLICATED_FACE_NAME_MISMATCH الإجراء الخاص به، والذي يكون افتراضياً مراجعة (log_type: "warning"). تتبع حالة تقرير كشف الحيوية الإجراء الأكثر شدة بين الاثنين: In Review هنا، حتى لو لم يكن إعداد الوجه المكرر العادي وحده سيُفعِّله.
شذوذ في سلامة التسجيل مع قياساته
log_type هي information لأن الإجراء المُكوَّن هو NO_ACTION. لا تؤدي تشخيصات تسليم الإطارات، التي حُذفت من هذا المثال للاختصار، إلى تفعيل هذه النتيجة.
أنواع التحذيرات
يتم تعيين مستوى شدة لكل خطر بناءً على تكوين تطبيقك. مستويات الشدة الثلاثة هي:مواضيع ذات صلة
- تقرير كشف الحيوية — مخطط التقرير الكامل وحالاته.
- تحذيرات مطابقة الوجه — تحذيرات مطابقة الوجه 1:1 المصاحبة.
- webhook — يحمل
session.status.updatedالتحذيرات بمجرد انتهاء خطوة كشف الحيوية. - نماذج البيانات — فحص كشف الحيوية — المخطط المرجعي مع كل حقل.
- نماذج البيانات — كائن التحذير — شكل كل مدخل في
warnings[].