الانتقال إلى المحتوى الرئيسي
تجمع المصادقة البيومترية بين فحص كشف الحيوية ومطابقة الوجه الاختيارية بنسبة 1:1 مع الوجه المرجعي الذي تم تحديده عند إنشاء الجلسة (إما portrait_image المُقدّمة، أو وجه المستخدم المخزن الذي يتم البحث عنه عبر vendor_data). وتُصدر كل خطوة تحذيراتها الخاصة في payload القرار الخاص بـ V3. تسرد هذه الصفحة كل رمز، ومكان ظهوره، وكيفية ترجمة الحدود إلى حالة الجلسة النهائية.

نظرة عامة

عند تشغيل جلسة مصادقة بيومترية، تقوم Didit بما يلي:
  • التقاط صورة سيلفي حية باستخدام 3D Action، أو Flash، أو Passive Liveness (method: ACTIVE_3D، أو FLASHING، أو PASSIVE).
  • استخراج الوجه الأكبر من الصورة الملتقطة واحتساب درجة الحيوية له.
  • إذا كان سير العمل يتضمن مطابقة الوجه، فستتم مقارنة الوجه الملتقط بالوجه المرجعي للجلسة (portrait_image المُقدّمة أو وجه المستخدم المخزن).
  • كتابة نتيجة كل خطوة بالإضافة إلى أي تحذيرات في قرار الجلسة.
تحتفظ التحذيرات ببنية كائن التحذير المشتركة والمستخدمة في جميع أنحاء المنصة: feature، وrisk، وadditional_data، وlog_type، وshort_description، وlong_description، وnode_id.

أين تظهر التحذيرات

في جلسة المصادقة البيومترية النموذجية، يوجد عنصر واحد في كل مصفوفة. وفي مسارات العمل متعددة المثيلات، يزيل node_id الموجود في كل تحذير أي لبس بشأن الخطوة التي أنتجته.

شروط الرفض التلقائي

تؤدي التحذيرات التالية دائماً إلى رفض خطوتها (log_type: "error") بغض النظر عن طريقة تكوينك لسير العمل: عند إطلاق NO_FACE_DETECTED، يتم حجب LOW_LIVENESS_SCORE (نظراً لعدم وجود وجه لاحتساب درجاته).

الحدود والإجراءات القابلة للتكوين

يتم احتساب درجات هذه التحذيرات ثم تعيينها لحالة معينة من خلال الحدود والإجراءات التي تحددها لكل سير عمل: إنّ POSSIBLE_FACE_IN_BLOCKLIST (LIVENESS) غير قابل للتكوين — إذ يتم دائماً توجيه التطابق ذي الثقة الأقل في قائمة الحظر إلى المراجعة (log_type: "warning").

محاولات إعادة الالتقاط

تدخل حالات الفشل الناتجة فقط عن مخاطر جودة الالتقاط القابلة للإصلاح (درجة منخفضة، عدم وجود وجه، الجودة، السطوع، الوجوه المتعددة — والتشابه المنخفض في مطابقة الوجه) في حلقة إعادة المحاولة قبل تثبيت الحالة: يحصل المستخدم على ما يصل إلى إجمالي محاولات face_liveness_max_attempts / face_match_max_attempts (الافتراضي 3، وقابل للتكوين من 2 إلى 5 لكل عقدة سير عمل). وعند استنفاد هذا العدد، يتم تطبيق الحالة المحسوبة للمحاولة الأخيرة ويتم تسجيل LIVENESS_MAX_ATTEMPTS_EXCEEDED أو FACE_MATCH_MAX_ATTEMPTS_EXCEEDED كـ information لتوثيق ذلك.

تحذيرات كشف الحيوية

تُرجع API نصوص short_description و long_description الدقيقة التالية: تحمل حالات التطابق مع قائمة الحظر وقائمة السماح والوجوه المكررة كائن additional_data يتضمن الجلسة المطابقة (blocklisted_session_id / allowlisted_session_id / duplicated_session_id، ورقم الجلسة المطابق *_session_number، وapi_service). يظهر رمز واحد فقط من هذه الرموز الستة في كل تقرير. ويُعد DUPLICATED_FACE_NAME_MISMATCH هو الاستثناء: حيث يصدر بالإضافة إلى DUPLICATED_FACE، ولا يحل محله مطلقاً، وذلك عندما لا تتطابق هوية الجلسة المطابقة مع الاسم المحدد لهذه الجلسة. ويضيف كائن additional_data الخاص به الحقل name_match_score إلى نفس حقول الجلسة المكررة. لا يُعد الاسم المكتوب بنظام كتابة مختلف في كل جانب عدم تطابق إذا كانت مستندات التحقق من الهوية لكلا الجلستين تشترك في دولة الإصدار، ورقم مستند مطابق تماماً أو رقم شخصي مطابق تماماً، وتاريخ ميلاد غير متناقض. راجع تحذيرات كشف الحيوية.

تحذيرات مطابقة الوجه

مثال — مرفوضة بسبب هجوم على كشف الحيوية

مثال — قيد المراجعة بسبب انخفاض درجة التشابه

تقع الدرجة (58.70) بين حد الرفض (الافتراضي 50) وحد المراجعة (الافتراضي 70)، لذا يحمل التحذير القيمة log_type: "warning" وتكون حالة مطابقة الوجه هي In Review. في هذا المثال، تم إطلاق التحذير في جلسة كان معرّفها session_id هو 11111111-2222-3333-4444-555555555555 — ويحمل source_image_session_id المعرّف الخاص بالجلسة نفسها لأن الصورة المرجعية جاءت من الصورة الشخصية المخزنة عند إنشاء الجلسة.

أنواع التحذيرات

يتم تعيين نوع تحذير لكل خطر بناءً على تهيئة تطبيقك. تندرج التحذيرات ضمن ثلاث فئات من حيث مستوى الخطورة:

صفحات ذات صلة

تقرير المصادقة البيومترية

أين تظهر liveness_checks[] و face_matches[] في قرار V3.

تحذيرات كشف الحيوية

المرجع الكامل لتحذيرات كشف الحيوية بما في ذلك مطابقة الوجه المكرر.

تحذيرات مطابقة الوجه

المرجع الكامل لتحذيرات مطابقة الوجه للمقارنات بنسبة 1:1.
آخر تعديل في ٧ نوفمبر ٢٠٢٦