الموافقة البيومترية لقوانين BIPA وCUBI وكولورادو

تتطلب ولايات إلينوي (BIPA) وتكساس (CUBI) وكولورادو إشعارًا وإقرارًا صريحًا قبل أن تجمع أي شركة هندسة الوجه، سواء من صورة سيلفي أو من الصورة الموجودة على مستند الهوية. يمكن لـ Didit عرض خطوة الموافقة قبل أول التقاط للوجه للأشخاص الذين تشملهم تلك القوانين، والاحتفاظ بالإجابة في الجلسة كدليل إثبات. توضح هذه الصفحة متى تظهر الخطوة، والتطبيقات التي يمكنها عرضها، وكيف تصل الإجابة إلى قرارك وwebhooks الخاصة بك.

تعرض Didit الخطوة وتسجل الإجابة. وتقرر أنت ما إذا كانت رحلة المستخدم الخاصة بك تلبي القوانين البيومترية المطبقة على شركتك. هذه الصفحة ليست استشارة قانونية: راجع طريقة تنفيذك مع مستشارك القانوني.

متى تظهر الخطوة

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

يلتقط سير العمل وجهًا. خطوة كشف الحيوية أو مطابقة الوجه أو تقدير العمر، أو صورة السيلفي بالكاميرا الأمامية التي تلتقطها خطوة التحقق من الهوية (ما لم تكن قد عطلتها)، أو تسجيل فيديو الجلسة بالكامل.
يتطلب وضع الموافقة في التطبيق ذلك. في وضع تلقائي، ينطبق أحد المُشغِّلات أدناه. وفي وضع دائمًا، تطلب ذلك كل جلسة تلتقط وجهًا.

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

أوضاع الموافقة

اختر الوضع في لوحة التحكم، ضمن Settings > Data and privacy > Biometric consent الخاصة بالتطبيق. ويتم تسجيل كل تغيير في سجل التدقيق.

الوضع	ما يحدث
تلقائي (الافتراضي، موصى به)	يعرض الخطوة فقط عند انطباق مُشغِّل. ويرى باقي الأشخاص الإشعار القياسي المكون من سطر واحد.
دائمًا	يرى كل شخص يُلتقط وجهه الخطوة، أينما كان. ويسجل القرار `trigger: "forced"`.
أبدًا	لا تعرض Didit الخطوة أبدًا. وحيثما يتطلب قانون الولاية الموافقة، تقوم بجمعها بنفسك قبل صورة السيلفي وتحتفظ بالسجل.

ما الذي يُشغّل الخطوة في الوضع التلقائي

تتحقق Didit من هذه القواعد بالترتيب وتسجل أول قاعدة تنطبق في biometric_consent.trigger:

المُشغِّل	متى ينطبق
`declared_state`	صرحتَ بولاية مشمولة عند إنشاء الجلسة: `user_state`، أو عنوان في الولايات المتحدة في `expected_details`.
`ip_state`	عنوان IP الخاص بالشخص يقع في إلينوي أو تكساس أو كولورادو.
`ip_unknown`	يبدو أن الشخص موجود في الولايات المتحدة (عنوان IP أمريكي، أو مستند أمريكي، أو تفاصيل أمريكية أرسلتَها) ولكن يتعذر تحديد ولايته: عنوان IP يقع في الولايات المتحدة بدون ولاية محددة، أو لا يمكن تحديد موقعه بينما تحدد تفاصيلك أو المستند أن الشخص في الولايات المتحدة.
`document_issuer`	تم إصدار مستند الهوية المقروء عند التقاط المستند من قِبل ولاية مشمولة.

لا تطلب شبكات VPN والبروكسي وشبكات الاستضافة الخطوة تلقائيًا بمفردها. تحدد Didit موقع عنوان IP الخاص بالشخص كأي عنوان آخر: يظهر العنوان في إلينوي أو تكساس أو كولورادو الخطوة، بينما لا يظهرها أي عنوان في مكان آخر. ولا تُطلب الخطوة إلا عند وجود دليل واضح على ولاية مشمولة (عنوان IP، أو الولاية التي أصدرت مستند الهوية، أو ولاية صرحتَ بها)، أو عندما يتم تحديد موقع الشخص في الولايات المتحدة دون ولاية محددة (ip_unknown). والشخص الموجود في ولاية مشمولة خلف شبكة VPN تخرج في مكان آخر، ويحمل مستند هوية لم تصدره أي ولاية مشمولة، لن يُطلب منه ذلك؛ استخدم وضع دائمًا، أو أرسل user_state، إذا كنت بحاجة إلى تغطية هذه الحالة. تصف قيمتان إضافيتان كيفية حسم موافقة الجلسة بدلًا من سبب طلبها:

المُشغِّل	المعنى
`forced`	وضع التطبيق هو دائمًا.
`customer_collected`	أرسلتَ الموافقة التي جمعتَها بالفعل عند إنشاء الجلسة (انظر أدناه).

إبلاغ Didit بما تعرفه بالفعل

يقبل Create Session حقلين اختياريين لهذا الغرض:

الحقل	وظيفته
`user_state`	مكان إقامة الشخص، عندما تعرفه: رمز تقسيم فرعي وفق ISO 3166-2 (مثل `US-IL` أو `ES-M`) أو رمز ولاية أمريكية أو اسمها (`IL` أو `Illinois`). وتظهر الخطوة عند تحديد ولاية مشمولة مع `trigger: "declared_state"`. وتُرجع `400` عند إدخال قيمة غير معروفة.
`biometric_consent`	الموافقة التي جمعتَها بالفعل: `{ "given_at": "<ISO 8601>", "text_version": "<your version id>" }`. ولن يطلب المسار الموافقة مجددًا، ويسجل القرار `status: "given"` مع `trigger: "customer_collected"`. ولا يمكن أن يكون `given_at` في المستقبل.

{
  "workflow_id": "YOUR_WORKFLOW_ID",
  "vendor_data": "user-42",
  "user_state": "US-IL",
  "biometric_consent": {
    "given_at": "2026-10-13T09:12:00Z",
    "text_version": "consent-v3"
  }
}

ما التطبيقات التي تعرض الخطوة

تحتاج الخطوة إلى تطبيق قادر على عرضها. تحدد Didit ذلك عند كل طلب يرسله التطبيق:

مكان تحقق الشخص	يعرض الخطوة
مسار التحقق المستضاف: متصفح، أو Web SDK، أو WebView	نعم
Native SDK بإصدار 4.10.0 أو أحدث (إصدارات iOS وAndroid وReact Native أو Flutter التي تدمج Native SDK بالإصدار 4.10.0 أو أحدث)	نعم
إصدار من Native SDK أقدم من 4.10.0، أو إصدار لا يبلغ عن رقم إصداره	لا

إصدارات Native SDK الأقدم من 4.10.0

لا تتعرف إصدارات Native SDK الصادرة قبل 4.10.0 على خطوة الموافقة، لذا لا تطلبها Didit منها مطلقاً. تعمل عملية التحقق تماماً كما كانت في السابق: يتم قبول صورة السيلفي واللقطات الأخرى للوجه ومعالجتها، وتصل الجلسة إلى قرارها كالمعتاد. لا تسجل Didit إطلاقاً موافقة لم يتم تقديمها. عندما تتطلب الجلسة الموافقة ويلتقط SDK أقدم صورة للوجه، يُظهر القرار ما يلي:

"biometric_consent": {
  "required": true,
  "trigger": "ip_state",
  "status": "pending",
  "given_at": null,
  "reason": "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"
}

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

إذا واصل الشخص الجلسة نفسها في المسار المستضاف (على جهاز آخر، أو في WebView يفتحه التطبيق لبعض أنواع كشف الحيوية)، فسيعرض المسار المستضاف الخطوة ولن يلتقط أي وجه هناك حتى يجيب. تبقى قيمة reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" كما هي للموافقة المقدمة هناك، نظراً لأنه تم التقاط وجوه بالفعل بدونها.

ما يراه الشخص

توضح الخطوة للشخص ما يتم جمعه، وسبب ذلك، والجهة التي بحوزتها البيانات ومدة الاحتفاظ بها، وتتضمن رابطاً إلى سياسة البيانات البيومترية. وتحتوي على زر واحد: أوافق وأتابع، والذي يظل معطلاً حتى يحدد الشخص مربع الموافقة. تحتفظ Didit بالإجابة كدليل: وقت تقديمها، وإصدار النص المعروض وقيمة التجزئة له، واللغة، وخطوة سير العمل، وعنوان IP والموقع ووكيل المستخدم للطلب. وبمجرد موافقة الشخص، تصبح الإجابة نهائية.

عندما لا يوافق الشخص

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

الموافقة المرفوضة في API

يحتفظ القرار بحالة declined والسبب BIOMETRIC_CONSENT_DECLINED كقيم في API. لا توفر أي شاشة من شاشات Didit خيار الرفض حالياً، لذا لا يسجل المسار المستضاف وNative SDKs أي رفض. وأي جلسة تسجل رفضاً:

تنتهي كـ Declined، ويتم إطلاق webhook لـ status.updated كما هو الحال مع أي رفض آخر.
تعرض biometric_consent.status بالقيمة declined، وreason وdecline_reason بالقيمة BIOMETRIC_CONSENT_DECLINED، وdeclined_at مع وقت الرفض.
لا تلتقط أي وجه بعد الرفض. ويتم حذف كل صورة وجه وقالب بيومتري للوجه تحتفظ به الجلسة بالفعل: صور السيلفي، وصورة السيلفي الملتقطة بالكاميرا الأمامية أثناء تصوير الهوية، وقصاصة الوجه المأخوذة من الصورة الشخصية في المستند، ومقاطع فيديو كشف الحيوية والجلسة الكاملة. ويسجل face_data_deleted_at وقت الحذف. ولا يعيد القرار هذه البيانات مجدداً، والحذف غير قابل للتراجع.
تحتفظ بصور المستند والبيانات المقروءة منها: فالرفض لا يؤثر عليها.

في القرار وwebhooks

يتضمن كل قرار في التحقق من المستخدمين كائن biometric_consent، وذلك في استرداد الجلسة وفي حقل decision ضمن webhooks الجلسة. ويكون null عندما لا يتم تقييم الجلسة على الإطلاق، على سبيل المثال في سير عمل لا يتضمن التقاطاً للوجه.

`status`	المعنى
`not_required`	لم تتطلب الجلسة موافقة.
`pending`	الموافقة مطلوبة ولم يتم تقديمها. اقرأ `reason` للتمييز بين حالة SDK أقدم وحالة شخص لم يجب بعد.
`given`	وافق الشخص في المسار، أو قمت بإرسال `biometric_consent` عند الإنشاء.
`declined`	تم تسجيل رفض، وانتهت الجلسة كـ `Declined`. لا توفر أي شاشة من شاشات Didit خيار الرفض حالياً (انظر أعلاه).

`reason`	المعنى
`BIOMETRIC_CONSENT_UNSUPPORTED_SDK`	التقط Native SDK أقدم من 4.10.0، أو SDK لم يبلغ عن إصداره، صورةً للوجه بدون هذه الخطوة.
`BIOMETRIC_CONSENT_DECLINED`	تم تسجيل رفض. لا توفر أي شاشة من شاشات Didit خيار الرفض حالياً.
`null`	لا يوجد ما يلزم توضيحه. دائماً ما يكون `null` عندما لا تتطلب الجلسة موافقة.

جلسة وافق فيها الشخص ضمن المسار المستضاف:

"biometric_consent": {
  "required": true,
  "trigger": "declared_state",
  "status": "given",
  "given_at": "2026-10-13T18:31:07.412000Z",
  "declined_at": null,
  "text_version": "bio-consent-2026-10-12",
  "locale": "en",
  "policy_url": "https://didit.me/legal/biometric-data-policy",
  "step": "LIVENESS",
  "ip_address": "198.51.100.23",
  "ip_country_code": "ES",
  "detected_ip_address": "198.51.100.23",
  "detected_country_code": "ES",
  "jurisdictions": ["IL"],
  "retention_months": 36,
  "reason": null,
  "decline_reason": null,
  "face_data_deleted_at": null
}

المثال مختصر. يتوفر كل حقل مع نوعه في نماذج البيانات.

نظرة عامة

الأسعار

سير العمل والتحقق

المراجعة والعمليات

الكيانات (المستخدمون والشركات)

الإعدادات والتخصيص

الأمان والامتثال

Didit Academy

الموارد

الموافقة البيومترية لقوانين BIPA وCUBI وكولورادو

متى تظهر الخطوة

أوضاع الموافقة

ما الذي يُشغّل الخطوة في الوضع التلقائي

إبلاغ Didit بما تعرفه بالفعل

ما التطبيقات التي تعرض الخطوة

إصدارات Native SDK الأقدم من 4.10.0

ما يراه الشخص

عندما لا يوافق الشخص

الموافقة المرفوضة في API

في القرار وwebhooks

مواضيع ذات صلة

​متى تظهر الخطوة

​أوضاع الموافقة

​ما الذي يُشغّل الخطوة في الوضع التلقائي

​إبلاغ Didit بما تعرفه بالفعل

​ما التطبيقات التي تعرض الخطوة

​إصدارات Native SDK الأقدم من 4.10.0

​ما يراه الشخص

​عندما لا يوافق الشخص

​الموافقة المرفوضة في API

​في القرار وwebhooks

​مواضيع ذات صلة

متى تظهر الخطوة

أوضاع الموافقة

ما الذي يُشغّل الخطوة في الوضع التلقائي

إبلاغ Didit بما تعرفه بالفعل

ما التطبيقات التي تعرض الخطوة

إصدارات Native SDK الأقدم من 4.10.0

ما يراه الشخص

عندما لا يوافق الشخص

الموافقة المرفوضة في API

في القرار وwebhooks

مواضيع ذات صلة