> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# ادعاءات الهوية عبر المؤسسات

> كيف تعرض Didit أدلة الهوية الواردة من مؤسسات أخرى دون وصف أي شخص بالاحتيال: أبعاد نتائج منفصلة ومشاركة معطّلة افتراضياً.

## القاعدة التي وُضعت هذه الصفحة من أجلها

الوجه هوية ثابتة. وهو ليس تصنيفاً للاحتيال، ولن تعامله Didit على هذا النحو.

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

لذلك يُربط معنى الاحتيال بـ**ادعاء الهوية**، وهو حدث، ولا يُربط أبداً بالشخص الذي قدّمه ولا بالهوية التي ادّعاها.

## أربعة أبعاد، أربعة حقول

لا يُختزل القرار أبداً في كلمة واحدة تُختار نيابةً عنك. يُبلَّغ عن كل بُعد من هذه الأبعاد بشكل مستقل، وأنت تقرّر ما يفعله منتجك بالمزيج الناتج:

| البُعد | ما الذي يجيب عنه | أين يظهر |
| - | - | - |
| **سلامة الإدخال** | هل كان الالتقاط حياً وغير معدّل وصادراً من كاميرا حقيقية؟ | تحذيرات كشف الحيوية (`LIVENESS_FACE_ATTACK`, `VIRTUAL_CAMERA_DETECTED`, …) |
| **تطابق الهوية** | هل طابق الشخص الهوية التي ادّعاها، مقارنةً بمرجع موثوق؟ | تحذيرات مطابقة الوجه وتحذيرات الوجه المكرر في الجلسة |
| **السلوك وأدلة الشبكة** | هل رأت مؤسسات أخرى أحداث ادعاء لهذا الشخص نفسه لم تتطابق؟ | `CROSS_ORG_IDENTITY_CLAIM_PATTERN` |
| **القرار النهائي** | إلى ما آلت إليه حالة الجلسة | `status` في حمولة القرار |

فشل فحص الحيوية، وعدم تطابق الهوية، ونمط الشبكة ثلاثة بيانات مختلفة عن ثلاثة أشياء مختلفة. قراءتها كرقم واحد هي الطريقة التي تتحول بها صورة سيئة إلى اتهام.

### تطابق الهوية يحتاج إلى مرجع موثوق

لا تُنتَج `match` و`mismatch` إلا عندما يوجد ما يمكن مقارنة الوجه به بثقة: صورة شخصية في مستند حكومي، أو هوية ارتبطت بهذا الوجه ارتباطاً قوياً من قبل. عنوان البريد الإلكتروني أو رقم الهاتف دون ارتباط قوي سابق لا يمنحك شيئاً تقارن به الوجه. في هذه الحالة تكون الإجابة **لا يوجد مرجع**، وليس `mismatch` أبداً، ولا `match` مستنتجة من سجل الوجه وحده.

## ماذا يمكن لأدلة المؤسسات المتعددة أن تقول وماذا لا يمكنها أن تقول

عندما تكون مؤسستك على خطة Enterprise وتكون وضعية المشاركة فيها `global`، يمكن للجلسة أن تُطلق `CROSS_ORG_IDENTITY_CLAIM_PATTERN`. أما دون خطة Enterprise، أو عند ضبط المشاركة على `private` أو `off`، فلا يعمل فحص المؤسسات المتعددة. ولا تأتي أدلة الادعاء إلا من مؤسسات أخرى هي أيضاً على خطة Enterprise وتشارك عالمياً. ويعني التحذير:

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

إنه **لا** يعني أن الشخص محتال، ولن تقول أي استجابة من Didit ذلك أبداً. ثلاثة ضمانات تدعم هذا:

* **يُكبح عندما ينجح فحصك أنت.** إذا كانت مطابقة الهوية في هذه الجلسة `match`، فلا يُطلق التحذير أصلاً. الشخص الذي يتحقق بنجاح مقابل مرجعه الموثوق الخاص يكون متحققاً منه، وأي شيء ربما شارك فيه قبل ذلك يعود إلى تلك الادعاءات، لا إلى هذا الادعاء.
* **لا يمكنه أن يؤدي إلى الرفض.** الإجراء هو المراجعة أو بلا إجراء. ضبط الرفض على `cross_org_identity_claim_pattern_action` يُخفَّض إلى المراجعة، لأن التاريخ المتعلق بشخص ما قد يفتح تحقيقاً في الادعاء الحالي، لكنه لا يحق له أن يرفضه.
* **مجمّعة فقط.** تحمل الحمولة عدد المؤسسات، وعدد الادعاءات غير المتطابقة، وعدد الهويات المختلفة التي ادُّعيت، ومدى حداثتها. ولا تكشف أبداً هوياتهم أو جلساتهم أو أيّاً من بياناتهم.

`CROSS_ORG_FRAUD_FACE` هو الإصدار القديم من هذا التحذير ولم يعد يُطلق. ويظل محفوظاً كقيمة كي تستمر السجلات والقواعد الحالية في حله، أما حالات ظهوره التاريخية فهي سجلات لا أحكام على شخص.

## البحث بالوجه فقط: معرّف شخص، لا حكم

التعرّف على الإنسان نفسه مرة أخرى قدرة منفصلة عن اتخاذ أي قرار بشأنه. يعيد البحث بالوجه فقط **معرّف شخص ثابتاً وغير دال** لالتقاطات متكررة لوجه نفسه بثقة عالية، ولا شيء غيره.

* المعرّف رمز عشوائي. لا يُشتق من وجه، ولا من تضمين الوجه، ولا من جلسة، ولا من مؤسسة، ولا من مرجع عميل، فلا يكشف إلا أن "هذا الالتقاط رُئي من قبل".
* لا يحمل أي حالة احتيال. لا يوجد فيه حقل يمكن أن يحملها.
* لا تؤدي مطابقة منخفضة الثقة أو مطابقة محتملة إلى دمج شخصين أبداً. الدمج المفرط يوحّد إنسانين في هوية واحدة، ولا يمكن التراجع عنه من البيانات؛ أما الدمج الناقص فلا يؤدي إلا إلى انخفاض الاستدعاء.

## كشف الحسابات المتعددة يقتصر على المؤسسة نفسها ويُقسَّم بالشرائح

"هل فتح هذا الوجه عدة حسابات لدينا؟" سؤال منتج مختلف عن أدلة المؤسسات المتعددة، ويُجاب عنه داخل مؤسستك وحدها.

اضبط `multi_account_segment` عند إنشاء الجلسة لإعطاء ذلك البحث نطاقاً صريحاً. لا تُعدّ جلستان في شريحتين مختلفتين مكررتين إحداهما للأخرى، وهذا ما يتيح لك تشغيل مجموعتي حسابات شخصية وتجارية منفصلتين، أو شريحة لكل عميل فرعي، دون أن يبدو شخص يملك حساباً مشروعاً في كل منها كمن يُنشئ حسابات بالجملة. إذا أغفلته فكل جلسة تقع في النطاق الافتراضي الواحد، وهذا هو السلوك الحالي تماماً.

مطابقة القائمة المحظورة والقائمة المسموحة تتجاهل الشرائح عن قصد: الوجه المحظور محظور في كل مكان داخل مؤسستك، فلا يمكن استخدام الشريحة للإفلات من الحظر.

## الخصوصية

* لا تعبر الوجوه حدود المؤسسة أبداً. فالفهرس المشترك لمكافحة الاحتيال لا يستطيع من الناحية المادية احتواء وجه، إذ ترفض قاعدة البيانات عملية الكتابة.
* ما يعبر الحدود فعلاً هو تجزئة (hash) أحادية الاتجاه ومعتمدة على مفتاح لقيمة دقيقة (رقم وثيقة، أو جهاز، أو عنوان IP، أو رقم هاتف، أو بريد إلكتروني) وسمتها مؤسسة مشاركة بأنها احتيال.
* تُجاب الاستعلامات عبر المؤسسات بأعداد وفئات زمنية بحسب حداثة البيانات. لا تُذكر المؤسسة المساهمة أبداً، ولا تغادر أي قيمة خام أو صورة أو جلسة.
* المشاركة متبادلة وتتطلب خطة Enterprise ووضع المشاركة `global` معاً. المؤسسة التي لا تساهم لا تستعلم، والمؤسسة دون خطة Enterprise لا تساهم ولا تستعلم، مهما كان وضع مشاركتها.
* معلومات **الوجه** عبر المؤسسات تحديداً معطلة افتراضياً، وتبقى معطلة حتى يكتمل تقييم أثر حماية البيانات والمراجعة القانونية لمعرّف الشخص البيومتري ونموذج أحداث المطالبات.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.