نظرة عامة
يلتقط تقرير كشف الحيوية كل ما رصده 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 سليم
قيد المراجعة — كشف حيوية سلبي، والتقاط منخفض الجودة، وتكرار محتمل
log_type: "warning" ويستقر التقرير على In Review.
ملاحظة أمنية
تُعد مقاطع فيديو وصور السيلفي الخاصة بكشف الحيوية بيانات بيومترية — فالروابط الموقّعة مؤقتة وتنتهي صلاحيتها (بعد 4 ساعات افتراضياً). تعامل معها كعناصر قصيرة الأجل: لا تقم بتخزينها مؤقتاً أو عرضها علناً. عادةً ما يحتاج تطبيقك فقط إلىstatus وscore والتحذيرات — خزّن أقل قدر ممكن لتقليل البيانات البيومترية على خوادمك.
ذات صلة
- تحذيرات كشف الحيوية — تعداد التحذيرات الكامل، والأسباب، وإجراءات المعالجة.
- webhook — الاستماع إلى
session.status.updatedلاستلام التقرير. - نماذج البيانات — فحص الحيوية — المخطط القياسي مع كل حقل.
- تقرير مطابقة الوجه — مطابقة الوجه المرافقة بنسبة 1:1 مع الصورة الشخصية في المستند.