الانتقال إلى المحتوى الرئيسي

نظرة عامة

تحدد التحذيرات في تقرير التحقق من الهوية كل حالة لاحظتها Didit أثناء قراءة المستند والتحقق من صحته. وتصل هذه التحذيرات في مصفوفة warnings[] ضمن كل عنصر من id_verifications[] (راجع تقرير التحقق من الهوية)، بالبنية الموضحة في نماذج البيانات — كائن التحذير: feature، وrisk، وadditional_data، وlog_type، وshort_description، وlong_description، وnode_id. يتكون كل تحذير من ثلاث طبقات:
  1. رمز risk — معرّف ثابت يمكنك مطابقته برمجياً في كودك.
  2. نوع log_type — مشتق من الإجراء الذي يحدده تكوينك للمخاطر وقت التقييم: رفض → error، المراجعة → warning، وأي شيء آخر → information.
  3. التأثير على القرار — تحدده مجموعات المخاطر القابلة للتكوين في سير العمل. يمكن توجيه رمز risk نفسه إلى موافقة، أو المراجعة، أو رفض بناءً على كيفية تكوين تطبيقك.

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

في سير العمل، تؤدي المخاطر التالية دائماً إلى تحويل تقرير الهوية (والجلسة) إلى Declined بشكل إلزامي. ولا يمكن تكوينها: بالنسبة إلى واجهة OCR المستقلة، فإن مجموعة الرفض غير المشروط هي DOCUMENT_EXPIRED، وMINIMUM_AGE_NOT_MET، وPORTRAIT_IMAGE_NOT_DETECTED، وSCREEN_CAPTURE_DETECTED، وPRINTED_COPY_DETECTED، وPORTRAIT_MANIPULATION_DETECTED، وPUBLIC_DOCUMENT_IMAGE_DETECTED. أما في سير العمل، فيكون الحد الأدنى للسن قابلاً للتكوين (الافتراضي هو الرفض)، وتعتمد مخاطر حيوية المستند الثلاثة على حدود معينة (انظر أدناه). تستقبل المخاطر القابلة للتكوين في تلك الـ API القيمتين DECLINE أو NO_ACTION كمعاملات للطلب بدلاً من قرار المراجعة. وتوجد نتيجة مراجعة واحدة فقط يمكن إرجاعها ولا تكون قابلة للتكوين: عندما لا يسفر فحص حيوية المستند المطلوب عن درجة قابلة للاستخدام، تكون الاستجابة In Review مع تحذير DOCUMENT_LIVENESS_NOT_COMPUTED (راجع حيوية المستند).

إعدادات التحقق القابلة للتهيئة

في لوحة تحكم Didit، يتم تجميع مخاطر الهوية المتبقية في إعدادات يمكنك توجيهها إلى موافقة، أو المراجعة، أو رفض (لكل سير عمل، ولكل عقدة في مسارات عمل المخطط): تأتي مخاطر التكرار في الالتقاط الصامت ومخاطر قائمة الحظر من البحث بالوجه على صورة السيلفي الملتقطة أثناء التقاط المستند. يتم تشغيل البحث طالما كان خيار البحث بالوجه عبر الالتقاط الصامت (document_selfie_face_search_enabled) مفعّلاً، وهو الإعداد الافتراضي، ولم يتم إيقاف البحث بالوجه في خطوة كشف الحيوية؛ وإلا فلن يتم إطلاق أي من هذه المخاطر الستة. تعتمد عائلتان من مخاطر الهوية على الحدود بدلاً من خيارات التبديل موافقة/المراجعة/رفض:
  • كشف حيوية المستند — SCREEN_CAPTURE_DETECTED، PRINTED_COPY_DETECTED، PORTRAIT_MANIPULATION_DETECTED. لكل نوع احتيال حدوده الخاصة للرفض والمراجعة: درجة أقل من حد الرفض ← error + مرفوضة؛ أقل من حد المراجعة ← warning + قيد المراجعة؛ وإلا فستكون information.
  • مطابقة الوجه بين الكاميرات — LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY، ويحكمه document_selfie_portrait_match_decline_threshold / document_selfie_portrait_match_review_threshold.

ضبط حدود كشف حيوية المستند

في محرر سير العمل، توجد هذه الحدود في علامة تبويب تزوير ضمن خطوة التحقق من الهوية، وتأتي في بطاقة واحدة لكل نوع احتيال: استبدال الصورة الشخصية، ونسخة مطبوعة، ولقطة شاشة. يمنح كل فحص المستندَ درجة تتراوح بين 0 و100 لمدى كونه أصلياً. الدرجة الأعلى تعني أن المستند على الأرجح أصلي. تقسم القيمتان الموجودتان في كل بطاقة هذا المقياس إلى ثلاثة نطاقات: رفع أيٍّ من القيمتين يجعل الفحص أكثر صرامة: تنتقل جلسات أكثر إلى النطاق الذي يعلوها. وخخفض القيمة يسمح لعدد أكبر من الجلسات بالمرور. في المحرر، لا يمكن لقيمة الرفض أن تتجاوز قيمة المراجعة. وعبر API، تؤدي قيمة الرفض التي تتجاوز قيمة المراجعة إلى إزالة نطاق قيد المراجعة. القيم الافتراضية للمنصة، والمستخدمة عندما لا يحدد سير العمل قيمة معينة: ابدأ من الإعدادات الافتراضية وعدّل قيمة واحدة في كل مرة. تعرض كل بطاقة قيمتها الافتراضية وزر إعادة التعيين إلى الافتراضي، بحيث يمكنك دوماً الرجوع إليها. يرسل المحرر أيضاً تحذيراً بشأن هذه التهيئات:
  • المراجعة عند 100. فقط الدرجة الكاملة تجتاز بنجاح، لذا فإن كل الجلسات تقريباً تنتقل إلى قيد المراجعة أو يتم رفضها.
  • الرفض عند 100. فقط الدرجة الكاملة تتجنب الرفض، لذا يتم رفض كل الجلسات تقريباً.
  • كلا القيمتين عند 0. لا تُصنَّف أي درجة على أنها مخالفة على الإطلاق، وبالتالي يكون الفحص معطلاً فعلياً.
تعيين كلا القيمتين على الرقم نفسه يزيل نطاق قيد المراجعة: يتم رفض أي درجة أدنى منه وتجتاز أي درجة أخرى بنجاح. عندما يؤدي كل من نسخة مطبوعة ولقطة شاشة إلى الإبلاغ عن المستند نفسه، يتم الإبلاغ فقط عن SCREEN_CAPTURE_DETECTED. تستخدم مطابقة الوجه بين الكاميرات الفكرة ذاتها مع وجود فارق واحد عند الحد الفاصل: الدرجة المساوية لحد المراجعة الخاص بها تنتقل مع ذلك إلى قيد المراجعة. أربعة مخاطر تتعلق بالهوية ليست قابلة للتهيئة ولا تعتمد على الحدود. يُوجَّه الخطر POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST دائماً إلى المراجعة: فصورة السيلفي القريبة من وجه مدرج في قائمة الحظر، دون أن تكون تطابقاً مؤكداً، يُترك الحكم عليها لشخص، ولا تُرفض تلقائياً أبداً ولا يتم تجاهلها على الإطلاق. يُوجَّه BARCODE_SIGNATURE_INVALID دائماً إلى المراجعة. ولا يتم إطلاقه إلا عندما يحمل الرمز الشريطي توقيعاً من جهة الإصدار يفشل في التحقق التشفيري، لذا لا يوجد أي تكوين يتم فيه تجاهل التزوير المؤكد. يُعد DOCUMENT_BACK_SIDE_NOT_AVAILABLE دائماً مجرد معلومات ولا يؤثر أبداً على القرار: فهو يُفيد بوجود قيد في كتالوج مستندات Didit، وليس خاصية في المستند المقدّم، لذا لا يوجد أي تكوين يمكنه أن يؤدي إلى رفض الحامل الحقيقي للمستند أو إحالته إلى المراجعة. يُوجَّه FRONT_CAMERA_CAPTURED_DOCUMENT دائماً إلى المراجعة. ولا يتم إطلاقه إلا عندما يُظهر إطار الكاميرا الأمامية الملتقط أثناء مسح المستند مستند هوية دون وجود أي شخص، وبذلك فإن أي التقاط لا يُظهر من كان يحمل المستند يصل دائماً إلى إنسان. يتم التحقق منه كلما كانت مطابقة السيلفي مع صورة المستند الملتقطة (is_document_selfie_portrait_match_enabled) مفعّلة.

التحذيرات الصادرة

تم التحقق منها وفقاً لـ collect_ocr_logs، وسير عمل التقاط المستندات، وprocess_ocr_logs_and_get_status. الأوصاف القصيرة الموضحة أدناه هي سلاسل short_description الدقيقة التي تُرجعها API.

التعرّف على المستند وجودته

يمكن لمسار الالتقاط أيضاً رفض الرفع باستخدام رموز الملاحظات IMAGE_RESOLUTION_TOO_LOW، وDOCUMENT_NOT_FULLY_VISIBLE، وIMAGE_QUALITY_TOO_LOW، وDOCUMENT_OCCLUSION_DETECTED (يُحكَم على أن إصبعاً أو جسماً يغطي النص المطبوع فعلياً). يطالب كل منها بإعادة الالتقاط في SDK ويتم تسجيله في التقرير كخطر خاص به، يتم توجيهه بواسطة إعدادات جودة الصورة — يتشارك DOCUMENT_OCCLUSION_DETECTED وIMAGE_QUALITY_TOO_LOW في إجراء واحد. وهي تصف الالتقاط: إعادة الالتقاط الناجحة تمسح التحذير. أما ما إذا كان الحقل المغطى يجب أن يؤثر على القرار فهو أمر منفصل خاص بالنزاهة CRITICAL_FIELD_OCCLUSION_DETECTED أدناه، والذي يتم إطلاقه في وقت اتخاذ القرار ويكون افتراضياً Review.
إذا كان سير العمل الخاص بك يبني التحقق من الهوية على مطابقة الوجه بدلاً من الصورة الشخصية للمستند، فيُرجى مراعاة توجيه Document Without Portrait إلى الرفض — وإلا فستصل عائلة مستندات بدون صورة شخصية إلى مطابقة الوجه مع عدم وجود شيء للمقارنة به.

استخراج الحقول

MRZ وQR والباركود

يتم تخطي مخاطر MRZ الثلاثة لجميع أنواع المستندات التي تتضمن مناطق MRZ معروفة بعدم موثوقيتها.
يغطي التحقق من توقيع الباركود حالياً بطاقات الهوية الوطنية الفرنسية، التي يتم توقيع باركود ANTS 2D-Doc الخاص بها من قبل الجهة المصدرة. يتم إطلاق BARCODE_SIGNATURE_INVALID فقط عندما يرفض فحص التوقيع نفسه الـ payload. يُعامل الباركود الذي لا يحتوي على توقيع، أو الموقع من قبل جهة ليست مدرجة بعد في مخزن الثقة لدى Didit، أو الذي يتعذر فك ترميز توقيعه، كبيانات غير مصادق عليها ويتم التحقق من صحتها مقابل MRZ والنص المطبوع كما كان في السابق، دون إثارة هذا الخطر.لا يتم التحقق من رموز باركود رخص القيادة في الولايات المتحدة وكندا (AAMVA) تشفيرياً: فالتوقيع الرقمي هناك اختياري ويختلف حسب الولاية القضائية، ولا تنشر أي ولاية قضائية مفاتيح التحقق، لذلك تكتشف Didit وتسجل فقط ما إذا كان الـ payload يحمل توقيعاً؛ ولا يتم فحص التوقيع نفسه مطلقاً. إن حالات فشل توقيع AAMVA لا تُعد إشارة مخاطر حالياً. ولا يظهر الـ payload المتلاعب به في AAMVA إلا كـ BARCODE_VALIDATION_FAILED، وفقط إذا أدى التلاعب أيضاً إلى عدم تطابق الباركود مع MRZ أو البيانات المطبوعة/OCR - ويمر التوقيع المزور على payload متسق داخلياً دون أي إشارة على الإطلاق.لا يُطلب من المستخدم أبداً إعادة الالتقاط عند ظهور BARCODE_SIGNATURE_INVALID: فالتوقيع الذي لا يطابق الـ payload لا يمكن إصلاحه بالتقاط صورة أفضل.

مطابقة الهوية

كشف حيوية المستند (التلاعب)

تعتمد على الحدود لكل نوع من أنواع الاحتيال في مسارات سير العمل. في API المستقل لـ OCR، ترفض هذه المخاطر الثلاث دون شروط، والفحص المطلوب الذي لا يُنتج أي درجة قابلة للاستخدام يُرجع In Review بدلاً من القبول. توجد الدرجات نفسها في كل تقرير V3 كـ document_liveness، بما في ذلك الحالات التي لم يُطلق فيها أي تحذير، بحيث يظل بالإمكان تدقيق المستند المقبول.

سلامة قناة الالتقاط

يعكس log_type الإجراء المُهيأ: error للرفض، وwarning للمراجعة، وinformation لعدم اتخاذ أي إجراء. الإجراء الموصى به: تعامل مع الجلسة المرفوضة على أنها عملية التقاط محقونة واطلب من الشخص إعادة المحاولة على جهاز فعلي باستخدام كاميرته المدمجة. الإشارات التي يمكن لشخص حقيقي إنتاجها لا تطلق أبدًا INJECTION_ATTACK_DETECTED وتظل معلوماتية. التطبيقات التي تنقل بث كاميرا حقيقية، مثل هاتف يُستخدم ككاميرا ويب أو طبقة تأثيرات فوق كاميرا ويب حقيقية، لا يتم الإبلاغ عنها كهجمات حقن. هذا هو كشف هجوم الحقن، وهو منفصل عن كشف هجوم العرض (عنصر مزيف معروض أمام كاميرا حقيقية).

صور المستندات العامة المعروفة

حالات عدم تطابق التفاصيل المتوقعة

عند تمرير expected_details إلى جلسة، تصدر Didit تحذير عدم تطابق لكل حقل لا يتطابق. يتحكم إعداد واحد (expected_details_mismatch_action، والافتراضي فيه هو المراجعة) في توجيه كل هذه التحذيرات: يحمل كل تحذير عدم تطابق القيم المتوقعة والمستخرجة في additional_data.

العمر

العنوان

مطابقة المستندات عبر الجلسات

بالإضافة إلى التحذيرات المذكورة أعلاه، يوفر تقرير الهوية V3 مصفوفة matches[] — حتى 5 مستندات أخرى في تطبيقك لها نفس تاريخ الميلاد، ونفس دولة الإصدار، واسم كامل شديد التشابه (تتطلب المستندات المدرجة في قائمة الحظر بالإضافة إلى ذلك تطابقًا تامًا في رقم المستند)، باستثناء الجلسات التي تنتمي إلى نفس المستخدم. تظهر المستندات المضافة إلى قائمة الحظر الخاصة بك مع القيمة is_blocklisted: true. بينما تظل المستندات الموجودة في قائمة السماح تظهر في المطابقات، ولكن يتم تخطي الإجراء الخاص بالمستخدم المكرّر. تتضمن كل مطابقة session_id، وsession_number، وvendor_data، وverification_date، وuser_details (name، وdocument_type، وdocument_number)، وstatus، وis_blocklisted، وapi_service، ورابط front_image_url موقّع.

أمثلة

تحذير قابل للتهيئة عند توجيهه الافتراضي (معلوماتي)

رفض تلقائي عند انتهاء صلاحية المستند

عدم تطابق التفاصيل المتوقعة مع payload

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

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

ذات صلة

آخر تعديل في ٧ نوفمبر ٢٠٢٦