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

نظرة عامة

يلتقط تقرير كشف الحيوية كل ما رصده Didit أثناء التحقق من وجود شخص حقيقي وحي أمام الكاميرا — وليس صورة مطبوعة أو إعادة تشغيل عبر شاشة أو تزييفاً عميقاً. ويتضمن طريقة كشف الحيوية، ودرجة ثقة من 0 إلى 100، وصورة سيلفي مرجعية وفيديو الالتقاط، وتقديراً اختيارياً للعمر، ومقاييس جودة كشف الحيوية السلبي، وتطابقات الوجه عبر الجلسات مع سجل تطبيقك وقائمة الحظر. يتم إنشاء التقرير بعد أن يكمل المستخدم خطوة كشف الحيوية في سير العمل (أو يستدعي endpoint الوجه المستقل). يُشغّل Didit إحدى طرق كشف الحيوية الثلاث (ثلاثية الأبعاد النشطة، أو الوميض، أو السلبية)، ويحتسب درجات الالتقاط، ويفحص أنماط الانتحال المعروفة، ويقارن الوجه بيومترياً مع كل وجه آخر ظهر في تطبيقك. يحمل كل تقرير قيمة status خاصة به — مستقلة عن حالة الجلسة الإجمالية — تعكس النتيجة التي انتهت إليها خطوة كشف الحيوية وحدها:
  • مقبولة — تم اكتشاف الوجه، ودرجة كشف الحيوية أعلى من حد المراجعة، ولم يتم إطلاق أي تحذير للرفض التلقائي.
  • قيد المراجعة — تم إطلاق تحذير واحد أو أكثر موجّه للمراجعة، أو أن الدرجة عند حد المراجعة أو أدنى منه ولكنها أعلى من حد الرفض.
  • مرفوضة — تم إطلاق شرط رفض تلقائي (NO_FACE_DETECTED، أو LIVENESS_FACE_ATTACK، أو FACE_IN_BLOCKLIST، أو مخاطر العمر في مسارات تقدير العمر)، أو تم توجيه تحذير قابل للتهيئة إلى الرفض، أو أن الدرجة عند حد الرفض أو أدنى منه.
  • لم تكتمل — لم يكمل المستخدم خطوة كشف الحيوية مطلقاً.

أين يظهر في استجابات API

يظهر تقرير كشف الحيوية كـ liveness_checks[] في GET /v3/session/{sessionId}/decision/ — دائماً كمصفوفة JSON، وليس ككائن liveness مفرد أبداً. تظهر إدخالات متعددة عندما يُشغّل سير العمل كشف الحيوية أكثر من مرة (على سبيل المثال، فحص أساسي بالإضافة إلى إعادة الالتقاط).
  • API قرار الجلسة — يُرجع GET /v3/session/{sessionId}/decision/ مصفوفة liveness_checks[] في المستوى الأعلى. راجع استرداد قرار الجلسة.
  • webhook — تتضمن payload الخاصة بـ session.status.updated مصفوفة liveness_checks[] نفسها بمجرد أن تُنتج الخطوة بيانات. راجع webhook.
  • API كشف الحيوية المستقل — راجع API كشف الحيوية المستقل.
اقرأ response.liveness_checks[0] وتنقّل عبر المصفوفة — بنية liveness المفردة التي أشارت إليها بعض الشروحات القديمة غير موجودة في endpoint القرار v3.

المخطط

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

مطابقات الوجه عبر الجلسات

يسرد matches[] الوجوه في سجل تطبيقك التي تجاوزت حد التشابه البيومتري مقارنةً بصورة السيلفي هذه — ما يصل إلى 5 إدخالات، الوجوه المدرجة في قائمة الحظر وقائمة السماح أولاً، ثم بترتيب تنازلي للتشابه. المرشحون المؤهلون هم الوجوه المدرجة في قائمة الحظر، والوجوه المدرجة في قائمة السماح، والوجوه من الجلسات المقبولة (Approved)، والوجوه المستوردة لمستخدمي المورّد لديك. تُستبعد الوجوه التي تنتمي إلى نفس المستخدم (نفس vendor_data، أو نفس مستخدم المورّد عند توفره) من عملية البحث بأكملها — سواء في اكتشاف التكرار أو فحص قائمة الحظر. يتضمن كل إدخال:

قيم الحالة

تأتي الحالات من التعداد المشترك لحالات الميزات (FeatureStatusChoices).

أمثلة

مقبولة — التقاط active-3D سليم

قيد المراجعة — كشف حيوية سلبي، والتقاط منخفض الجودة، وتكرار محتمل

هنا تكون جودة الوجه (12.4) أقل من حد المراجعة الافتراضي (15)، والإضاءة (18.7) أقل من الحد الأدنى الافتراضي (20)، وإجراء الوجه المكرر في سير العمل مضبوط على المراجعة — لذا تحمل التحذيرات الثلاثة log_type: "warning" ويستقر التقرير على In Review.

ملاحظة أمنية

تُعد مقاطع فيديو وصور السيلفي الخاصة بكشف الحيوية بيانات بيومترية — فالروابط الموقّعة مؤقتة وتنتهي صلاحيتها (بعد 4 ساعات افتراضياً). تعامل معها كعناصر قصيرة الأجل: لا تقم بتخزينها مؤقتاً أو عرضها علناً. عادةً ما يحتاج تطبيقك فقط إلى status وscore والتحذيرات — خزّن أقل قدر ممكن لتقليل البيانات البيومترية على خوادمك.

ذات صلة

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