تجاوز إلى المحتوى الرئيسي
Didit تجمع 7.5 مليون دولار لبناء البنية التحتية للهوية والاحتيال
Didit
العودة إلى المدونة
المدونة · 31 أكتوبر 2026

ربط الحامل في محفظة EUDI: ما الذي يثبته التقديم فعلاً

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

بواسطة Diditتحديث
eudi-wallet-holder-binding-cover.png

باختصار

ربط الحامل في EUDI Wallet هو الصلة بين الشخص الذي يقدّم المحفظة والشخص الذي صدرت له بيانات الهوية. ويسمّيه إطار البنية والمرجع (ARF) User binding، وفي معظم عمليات التقديم يثق الطرف المعتمِد بهذا الربط ولا يتحقق منه.[2]

  • يثبت التقديم المتحقَّق منه والمربوط بالجهاز أن البيانات أصلية ولم تُعدَّل، وأن المحفظة تحوز المفتاح المربوط.[2]
  • لكنه لا يثبت من يحمل الهاتف عند تسجيل الدخول التالي أو عند صرف المدفوعات أو إعادة تعيين كلمة المرور.
  • المستوى المرتفع ضمان حقيقي. أبقِ المحفظة الخيار الافتراضي، ولا تُضِف فحوص الوجه إلا حيث تبرّرها المخاطر.

آخر مراجعة: 31 أكتوبر 2026 · ليس استشارة قانونية

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

لا شيء من ذلك يجعل المحفظة ضعيفة. فهي تصدر في إطار نظام بمستوى ضمان مرتفع، والفريق الذي يعاملها بريبة يهدر قيمتها. يتناول هذا الدليل ما تجيب عنه المحفظة، وما تتركه مفتوحًا، وكيف تسد هذه الفجوة.

للاطلاع على التسجيل والشهادات، اقرأ دليل الطرف المعتمِد. ولاختيار مسار التكامل، اقرأ كيف تختار منصة تكامل مع EUDI Wallet.

ما الذي يثبته تقديم المحفظة فعلًا

يمر التقديم عن بُعد بعدة فحوص متتالية. بعضها من مسؤوليتك، وبعضها يجري داخل المحفظة حيث لا يمكنك رؤيته.

الشخص EUDI Wallet خدمتك
1طلب موقَّع مع nonce
2تعرض من يطلب ولأي غرض
3يصادق ويوافق

لا ترى الخطوة 3 أبدًا

4السمات مع إثبات المفتاح

التحقق من التوقيع والحالة

التحقق من الربط بالجهاز

تقديم عن بُعد مبسّط، مأخوذ من ARF v3.0.0 القسم 6.6.3. الخطوات 1 و2 و4 مرئية لك أو للشخص. أما الخطوة 3 فليست كذلك.[2]

الطبقةما الذي تثبتهمن يتحققالوضع بالنسبة إليكالحد
توقيع الجهة المُصدِرةالبيانات صادرة عن مزوّد أصلي ولم تُعدَّل[2]أنتتُلقي المادة 5b(9) هذا الالتزام على الأطراف المعتمِدة، بالنسبة إلى PID والإقرارات[1]لا يقول شيئًا عمّن يقدّمها
حالة الإلغاءلم يُلغِ مزوّد البيانات هذه البيانات[2]أنتموصى به، وليس إلزاميًا[3]حداثتها بقدر حداثة مصدر الحالة فقط
الربط بالجهازالبيانات موجودة في وحدة المحفظة التي صدرت لها، وليست نسخة[2]أنتموصى به، لكنه إلزامي إذا اعتمدت على مصادقة المحفظة نفسها[2]يثبت مفتاحًا، لا شخصًا
سلامة المحفظةكانت وحدة المحفظة وعتادها الآمن صالحين عند الإصدار[2]مزوّد البيانات، أثناء الإصدار[2]تثق بهذا بشكل غير مباشر[2]لا تملك وسيلة مباشرة للتحقق منه[2]
مصادقة المستخدمصادقت المحفظة على مستخدمها قبل الإفصاح عن البيانات[2][6]المحفظةتثق بهذا بشكل غير مباشر[2]لا تصلك أي نتيجة

يقسّم ARF v3.0.0 إقرار وحدة المحفظة الوارد في اللائحة إلى قسمين: Wallet Instance Attestation، ويتناول سلامة التطبيق وحالة إلغائه، وKey Attestation، ويتناول التخزين الآمن الذي يحفظ المفاتيح.[2] وعن موقعك أنت: "لا تملك Relying Party Instance وسيلة للتحقق مباشرةً من أصالة Wallet Unit وأصالة Wallet Provider."[2]

ARF Figure 12: trust model diagram linking the user, wallet unit, wallet provider, PID and attestation providers, relying party, registrars, access certificate authorities and the common trust infrastructure

الشكل 12 من ARF: يصل المستخدم إلى وحدة المحفظة عبر رابط مصادقة لا يراه الطرف المعتمِد أبدًا. المصدر: EUDI Wallet Architecture and Reference Framework، المفوضية الأوروبية، CC BY 4.0. دون تعديل.

سُدّ الفجوة التي تتركها المحفظة مفتوحة

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

الربط بالجهاز وربط الحامل والفجوة التي تليهما

تُدمج ثلاث روابط مختلفة تحت مسمى "ربط الحامل". الأول والثاني مفهومان من ARF. أما الثالث فهو تسمية خاصة بنا.

المفتاح بالمحفظة

الربط بالجهاز

  • البيانات مرتبطة بمفتاح في عتاد آمن[2]
  • ويُسمى أيضًا إثبات الحيازة[2]
  • يمنع النسخ وإعادة الاستخدام[2]

تتحقق منه أنت

من المحفظة إلى الشخص

ربط المستخدم

  • المُقدِّم هو الشخص الذي صدرت له البيانات[2]
  • يعتمد على ربط الجهاز[2]
  • يُفترض عادةً ولا يُتحقق منه[2]

تنفذه المحفظة

من الشخص إلى الإجراء

ربط الإجراء

  • هذا الشخص نفّذ هذا الإجراء اللاحق
  • يقع خارج التقديم
  • يكمن في جلستك وضوابطك

مسؤوليتك وحدك (مصطلحنا)

ربط الجهاز وربط المستخدم مصطلحان من ARF. أما ربط الإجراء فهو تسمية من Didit، وليس مصطلحًا من أي معيار.

تعرض ورقة النقاش الخاصة بـ ARF حول الشهادات المرتبطة بالجهاز هذا التمييز في سطر واحد: "قد تكون الشهادة مرتبطة بجهاز دون أن تكون مرتبطة بمستخدم."[11] والتعريف المهم هو التالي.

القسم 6.6.3.9ARF v3.0.0

"ربط المستخدم (ويُسمى أحيانًا 'ربط الحامل') هو الخاصية التي تعني أن الشخص الذي يقدّم PID أو الشهادة إلى الطرف المعتمِد هو فعلًا المستخدم الذي صدر له PID أو الشهادة."

المصدر: ARF v3.0.0، الفصل 6[2]

على مستوى البروتوكول، الخاصية التي تتحكم فيها هي require_cryptographic_holder_binding في OpenID4VP. قيمتها الافتراضية true، وضبطها على false يُبلغ المحفظة بأنك تقبل بيانات اعتماد دون هذا الإثبات.[12] يستخدم البروتوكول مصطلح ربط الحامل حيث يستخدم ARF مصطلح ربط الجهاز.[12][2] أبقِها مفعّلة. يشرح دليلنا للتحقق عبر OpenID4VP الفحوصات اللازمة.

ما يقوله القانون وARF بنصّهما

تنظم هذه الأحكام إصدار المحفظة وتقديمها، لا الإجراءات اللاحقة على حسابك.

القاعدةالنصما يعنيه ذلك لك
المادة 5a(4)(a)، اللائحة 910/2014يجب أن تُمكّن المحافظ المستخدمين من تقديم البيانات "تحت السيطرة الحصرية للمستخدم"[1]قراءتنا: متطلب يتعلق بكيفية بناء المحافظ، وليس حكمًا بشأن أي جلسة
المادة 5a(5)(d) و5a(11)تستوفي المحافظ متطلبات المستوى العالي وتُقدَّم بموجب نظام من المستوى العالي[1]أساس متين، ولا حاجة إلى إثبات إضافي لهذا الادعاء
المادة 5b(9)الأطراف المعتمِدة مسؤولة عن "مصادقة البيانات والتحقق من صلاحيتها"[1]فحص التوقيع والصلاحية مسؤوليتك
المادة 3(5)، اللائحة 2024/2977على مزودي PID أن "يضمنوا" أن PID الذي يصدرونه "مرتبط تشفيريًا بوحدة المحفظة التي صدر لها"[4]على مزودي PID ربط PID بوحدة المحفظة، وأنت تتحقق من النتيجة
المادة 3(1)، اللائحة 2024/2979لا وظائف أساسية "إلى أن تنجح وحدة المحفظة في مصادقة مستخدم المحفظة"[6]المحفظة تصادق قبل أن تتصرف
الملحق، البند 2.2.1، اللائحة التنفيذية 2015/1502بالنسبة إلى المستوى المرتفع: "تُصمَّم وسيلة التعريف الإلكتروني بحيث يمكن للشخص الذي تعود إليه حمايتها بشكل موثوق من استخدام الآخرين لها."[7]حماية من الآخرين، متاحة للمالك
WIAM_14، الملحق 2 من ARFالأجهزة الآمنة الخاصة بـ PID تصادق المستخدم بالمستوى المرتفع قبل العمليات التشفيرية على أصولها الحرجة[3]طبقة مصادقة ثانية داخل المحفظة

ينص القسم 6.5.3.3.1 من ARF على ما يلي: "أثناء تفعيل وحدة المحفظة، تضمن وحدة المحفظة أن يُعِدّ المستخدم آليتين لمصادقة المستخدم." إحداهما على مستوى نظام التشغيل، والأخرى في الأجهزة التشفيرية الآمنة المستخدمة عند إصدار PID أو تقديمه أو حذفه.[2] وعلى المستخدم اجتياز الاثنتين لتقديم PID.[2]

يتناول القسم 6.6.3.9 الثقة في هذه المصادقة: "لا تقوم هذه الثقة على نتيجة أي تحقق يجريه الطرف المعتمِد نفسه"، بل على "ثقة مسبقة في وحدة المحفظة المعتمدة و(بالنسبة إلى PID والشهادات ذات مستوى الأمان المرتفع) في WSCA/WSCD المعتمدة."[2] (WSCA وWSCD: التطبيق والجهاز التشفيريان الآمنان للمحفظة.) ويضيف ARF أن الاعتماد على هذه الطريقة "يعني أن على الأطراف المعتمِدة التحقق من ربط الجهاز".[2]

إذن يحدد ARF ثلاثة مسارات لربط المستخدم. الثقة في مصادقة المحفظة، وهي تعمل دائمًا. أو مقارنة الصورة الشخصية الموجودة في PID بالوجه الحي. أو مقارنة سمات PID بوثيقة هوية يمكنك التحقق من أنها تعود فعلًا إلى الشخص.[2]

لماذا يمثل المستوى المرتفع ضمانًا حقيقيًا

يتطلب المستوى المرتفع الحماية "من المهاجمين ذوي القدرة الهجومية العالية".[7] ويختبر الاعتماد هذه المقاومة.[8] ينبغي أن يفشل PID المزوّر أو المحفظة المستنسخة أو الاستجابة المعاد تشغيلها. قراءتنا: المستوى المرتفع يصف الوسيلة، ولا يقول شيئًا عن حامل حقيقي يختار إعارة استخدامها أو بيعه.

تسجل ورقة العمل الخاصة بالموضوع R في ARF بتاريخ 14 أكتوبر 2025 أنه "حتى اليوم لا تملك الأجهزة المحمولة وسيلة أو أساسًا لتشهد للأطراف المعتمِدة على المحفظة بأن مصادقة المستخدم قد أُجريت"، وأن القياسات الحيوية للجهاز، في رأي بعض الخبراء، "ليست موثوقة تمامًا".[10] وهي محضر نقاش، وليست متطلبًا.

  1. 11 أغسطس 2026قواعد تأكيد الصورة الشخصيةدخول اللائحة 2026/1731 حيز النفاذ: تحذيرات وتأكيد صريح.
  2. 24 ديسمبر 2026موعد إتاحة المحافظمحسوب: 24 شهرًا من تاريخ الأحكام.
  3. 10 يوليو 2027بدء تطبيق AMLRالمادة 22(6) تُلزم الجهات الملزَمة.
  4. 24 ديسمبر 2027القبولمحسوب: المادة 5f(2). الأطراف الخاصة الملزمة باستخدام مصادقة قوية للمستخدم بموجب القانون أو العقد، بناءً على طلب المستخدم، مع إعفاء الشركات الصغيرة جدًا والصغيرة.
  5. 11 أغسطس 2028الصورة الشخصية في PIDسمة إلزامية في PID اعتبارًا من هذا التاريخ، مع مراعاة خيارات عدم الإدراج.

تواريخ ديسمبر من حسابنا استنادًا إلى المادتين 5a(1) و5f(2)، محسوبة من تاريخ دخول الأحكام التنفيذية المشار إليها في المادتين 5a(23) و5c(6) حيز النفاذ (اللوائح من 2024/2977 إلى 2024/2982، النافذة في 24 ديسمبر 2024).[1][4][5][13] راجع دليلنا لمواعيد EUDI Wallet.

الصورة الشخصية: مفيدة واختيارية وخاضعة لتنظيم صارم

الصورة الشخصية هي الطريقة البديهية للتحقق من الشخص. وقد غيّرت اللائحة التنفيذية (EU) 2026/1731، المعتمدة في 15 يوليو 2026 والمنشورة في الجريدة الرسمية في 22 يوليو 2026، قواعدها.

  • التوقيت. "قد تكون الصورة الشخصية لمستخدم المحفظة جزءاً من بيانات تحديد هوية الشخص الإلزامية للشخص الطبيعي اعتباراً من 11 أغسطس 2028 فقط".[5] وفق جدول PID الحالي، تُدرج الصورة الشخصية "إلا إذا اختار المستخدم صراحةً عدم إدراجها، حيثما ينطبق ذلك".[5]
  • خيارات الرفض باقية. يجوز للدول الأعضاء "أن تنص على منح المستخدم خيار رفض إدراج الصورة الشخصية"، وعندها تُترك القيمة فارغة.[5]
  • تحذير المحفظة. تنبّه المحفظة المستخدم إلى أن الطلب يتضمن بيانات بيومترية، ويجب على المستخدم "أن يؤكد صراحةً وتحديداً تقديم الصورة الشخصية".[4] ويضيف المتطلب ARF RPA_07c: "لا يكفي السكوت أو مربع محدد مسبقاً."[3]
  • ليس أساساً قانونياً. تنص الحيثية 2 من اللائحة 2026/1731 على ما يلي: "ينبغي أن يكون التأكيد الصريح من مستخدم المحفظة ضمانةً تقنية، وألا يشكّل في حد ذاته أساساً قانونياً للمعالجة."[5] وتحيل الحيثية إلى المادتين 6 و9 من GDPR بشأن الأساس القانوني.[5]
  • الاحتفاظ. "لا يجوز للأطراف المعتمِدة على المحفظة الاحتفاظ" بالصورة الشخصية "ما لم تكن معالجتها ضرورية لأغراض تحديد الهوية والمصادقة" بموجب قانون حماية البيانات، أو ما لم ينص على ذلك قانون الاتحاد أو القانون الوطني.[4][5]
  • التسجيل. بموجب المادة 5b(3) لا يجوز لك طلب بيانات تتجاوز ما سجّلته، لذا يجب أن تكون الصورة الشخصية ضمن الاستخدام المسجّل لديك.[1]

للمطابقة عن بُعد، يطلب ARF إضاءة جيدة وتعليمات واضحة و"آلية معتمدة لكشف الحيوية تدعم كشف هجمات العرض"، "إضافةً إلى آليات لكشف هجمات الحقن، ولا سيما كشف التزييف العميق".[2] وتفصّل ENISA هجمات العرض على الوجه.[21] ويعرّف ETSI TS 119 461 هجوم الحقن بأنه "هجوم يتمثل في حقن محتوى يتحكم فيه المهاجم في عملية التقاط البيانات".[23]

Illustration of a smartphone projecting a light beam onto a polygon mesh of a human face

فحص الوجه على هاتف: خطوة الالتقاط هي سطح الهجوم. رسم توضيحي من mikemacmarketing, Wikimedia Commons، بترخيص CC BY 2.0. دون تعديل.

التحقق الفردي (واحد إلى واحد) الذي يقتصر غرضه على تأكيد هوية مُدّعاة مستثنى من بند الملحق الثالث من AI Act المتعلق بتحديد الهوية البيومترية عن بُعد.[16] تبقى البيانات البيومترية المستخدمة لتحديد هوية شخص بشكل فريد فئةً خاصة من البيانات بموجب المادة 9 من GDPR، لذا خطّط لأساس قانوني ولتقييم أثر.[15]

تهديدًا تلو الآخر: ما توقفه المحفظة وما يبقى على عاتقك

تتضمن لائحة الاعتماد سجلاً للمخاطر الخاصة بالمحافظ. معرّفات التهديدات أدناه هي المعرّفات الرسمية. أما العمودان الأخيران فهما تقييمنا.[8]

التهديدالسجلأثر المحفظةما يتبقىالضابط لديك
نسخ بيانات المحفظة أو تكرارهاTR60قوي: ربط الجهاز[2]قليل، إذا تحققت منهأبقِ إثبات الربط مفعّلاً
إعادة تشغيل التقديمType 5.3قوي: توقيع جديد على بياناتك[2]قليلقيمة nonce فريدة لكل طلب
هاتف مسروق ومقفلTR98قوي: طبقتان للمصادقة[2]سرقة عامل المعرفة (TR35)التحقق من حالة الإلغاء
جهاز منزلي مشتركTR35، TR98جزئيشخص يعرف رمز PIN أو الرمز[22]مصادقة إضافية عند الإجراءات عالية المخاطر
مستخدم مُكرَه أو مُتلاعَب بهTR28، TR99ضعيف: المستخدم الحقيقي هو من يوافقكله تقريبًامراقبة المعاملات، فترة تهدئة، مصادقة إضافية مع السياق
الترحيل عبر الأجهزةTR103جزئي: فحص القرب[24]تصيّد جلسة المتصفحالجهاز نفسه حيثما أمكن، وتسمية الإجراء
مصادقة محلية مُخترَقةTR113يعتمد على الاعتماد[8]مخاطر الجهاز المُخترَقالتحقق من الإلغاء، إشارات الجهاز
الاستيلاء على الحساب بعد الإعدادخارج المحفظةلا شيء ما لم يُقدَّم مجددًاكلمات المرور، الجلسات، مسارات الاستردادمصادقة إضافية عند التغييرات الحساسة
وسيط أموال بمحفظة حقيقيةخارج المحفظةلا شيء: كل الفحوصات تنجحكل شيءمراقبة السلوك، والروابط بين الشبكات

المستخدم الحقيقي الذي يوافق

ينص TR99 على ما يلي: "يمكن للمهاجم إقناع المستخدم بالمصادقة والموافقة على معاملات مع المهاجم أو مع طرف ثالث غير مصرح له."[8] كل عامل ينجح في التحقق. وبحسب ECB، فإن المصادقة القوية للعميل "لا تزال فعالة ضد أنواع الاحتيال التي صُممت للتخفيف منها"، وقد بلغ إجمالي الاحتيال المُبلغ عنه في المنطقة الاقتصادية الأوروبية €4.2 مليار في عام 2024.[19][20] وفي التحويلات الدائنة، ارتفع احتيال التلاعب بالدافع "من 65% إلى 74% من حيث القيمة ومن 55% إلى 71% من حيث الحجم، من 2023 إلى 2024".[19]

شخصان وجهازان

ينص TR103 على ما يلي: "قد يكون المستخدم الذي يقف خلف الاتصال بين الطرف المعتمد والمتصفح مختلفًا عن المستخدم الذي يقف خلف الاتصال بين الطرف المعتمد والمحفظة."[8] ويشير القسم 4.4.3.2 من ARF إلى أن "التدفقات عبر الأجهزة عرضة لهجمات التصيد الاحتيالي والترحيل"، ويجعل القسم 4.4.3 التحقق من القرب إلزاميًا لها.[24] ومع ذلك تبقى جلستك على الويب منفصلة عن موافقة المحفظة.

ARF Figure 5: remote cross-device flow, with the wallet instance on the user device, a web browser on another device, a CTAP-based flow with proximity check between them, and the relying party instance connected to the browser

الشكل 5 من ARF: في التدفق عبر الأجهزة تتواصل خدمتك مع متصفح، بينما توجد المحفظة على جهاز ثانٍ. المصدر: EUDI Wallet Architecture and Reference Framework، المفوضية الأوروبية، CC BY 4.0. دون تعديل.

وسيط الأموال الذي يملك محفظة حقيقية

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

تصميم للتحقق الإضافي يُبقي المحفظة هي الخيار الافتراضي

لم نجد في أي نص قرأناه ما يشترط التحقق من الحيوية إضافةً إلى المحفظة. تذكر المادة 22(6)(b) من AMLR، ضمن خياراتها، "استخدام وسائل التعريف الإلكتروني التي تستوفي متطلبات اللائحة (EU) رقم 910/2014 فيما يتعلق بمستويي الضمان 'الجوهري' أو 'العالي'".[13] وتنص مسودة المعايير النهائية الصادرة عن هيئة مكافحة غسل الأموال (AMLA) على أن ذلك "يشمل محافظ الهوية الرقمية الأوروبية"، وهذه المعايير لا تزال مسودة وليست قانونًا.[14] راجع دليلنا حول AMLR وقبول المحافظ.

تترك المادة 20(2) من AMLR نطاق التدابير إلى "تحليل فردي للمخاطر".[13] ونرى أن طلب صورة سيلفي عند كل تقديم يصعب تبريره في ضوء مبدأ تقليل البيانات في GDPR.[15] وهذه المستويات اقتراح منا، وليست فئات قانونية.

1صنّف الحدث

التسجيل، أو تسجيل الدخول، أو إجراء محدد، مع مستوى مخاطره.

ما حجم الضرر الذي قد يسببه الشخص الخطأ

منخفض

المحفظة وحدها

فحوصات تشفيرية كاملة. دون قياسات حيوية.

متوسط

أضف التحقق من الحيوية ومطابقة الوجه

مقارنةً بالصورة الشخصية، أو بوجه تحتفظ به بصورة مشروعة.

مرتفع

أعد التحقق عند تنفيذ الإجراء

فحص جديد مرتبط بهذا الإجراء، ثم مراجعة.

2سجّل الأدلة

ما الذي جرى تنفيذه، والنتيجة، والتاريخ. وليس الصورة الشخصية بشكل افتراضي.

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

المستوىالأحداث المعتادةالضوابطالسبب
المحفظة وحدهاالتحقق من العمر أو السمات، فتح الحساب المعتاد، تسجيل الدخول منخفض المخاطرالتوقيع، ربط الجهاز، الحالة، الرقم العشوائي (nonce)المستوى المرتفع يؤدي المهمة، وكلما قلّت البيانات كان أفضل
المحفظة مع الوجهعميل أعلى مخاطرة، جهاز أو موقع غير معتاد، أول استخدام بعد انقطاع طويلما سبق، مع التحقق من الحيوية ومطابقة الوجهيعالج ربط المستخدم مباشرة، كما يصفه ARF[2]
إعادة التحقق عند تنفيذ إجراءمستفيد جديد، دفعة كبيرة، تغيير البيانات المصرفية، استرداد الحساب، إضافة جهازتحقق جديد من الوجه أو موافقة مرتبطة بالمعاملة، مع المراجعةيربط الشخص بذلك الإجراء
لا محفظة أو لا صورة شخصيةعميل بلا محفظة، بلد متأخر في الإطلاق، رفض مشاركة الصورة الشخصيةالوثيقة، قراءة الشريحة، التحقق من الحيوية، مطابقة الوجهاستخدام المحفظة طوعي[1]

لا يمكن لـ PID أن يوافق على إجراء نيابة عنك: "لا يجوز لوحدات المحفظة استخدام المفتاح الخاص لـ PID لتوقيع بيانات المعاملات الواردة من طرف معتمِد في طلب تقديم."[9] الموافقة على المعاملات تعود إلى إفادات المصادقة القوية للمستخدم (SUA)، التي تحمل بيانات المعاملة وتندرج ضمن موضوع ARF الخاص بالمدفوعات الإلكترونية.[3] وقانون المدفوعات يعمل بالطريقة نفسها: يجب أن يكون الرمز "خاصًا بمبلغ معاملة الدفع وبالمستفيد".[18] وعبارة PSD2 "أي إجراء عبر قناة عن بُعد قد ينطوي على خطر احتيال في الدفع أو إساءات أخرى" نموذج مفيد لتحديد محفّزات إعادة التحقق.[17]

الخيار

المحفظة مرة أخرى

  • تقديم PID جديد
  • يؤكد المحفظة مرة أخرى
  • لا ارتباط بالإجراء

مناسب لتسجيل الدخول

الخيار

التحقق من الوجه

  • التحقق من الحيوية ومطابقة الوجه
  • يتحقق من الشخص الحاضر
  • يحتاج إلى مرجع مشروع قانونًا

مناسب للتغييرات عالية المخاطر

الخيار

إثبات المعاملة (Transaction attestation)

  • يوقّع بيانات الإجراء
  • يعرض على المستخدم ما تتم الموافقة عليه
  • يعتمد على دعم الجهة المُصدِرة

مناسب للمدفوعات

انتبه

لا تستخدم مفتاح PID كمعرّف للجهاز. يجوز لمزوّدي المحفظة إصدار إثباتات لا تُقدَّم إلا مرة واحدة، "للحد من خطر قابلية الربط من جانب الطرف المعتمِد".[2] طابِق العملاء العائدين على أساس السمات، كما يشرح دليلنا حول القبول عبر الحدود.

قائمة التحقق: ما يجب فعله هذا الشهر

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

الامتثال والمخاطر

  • دوِّن الأحداث التي تعتمد فيها على المحفظة وحدها.
  • حدِّد محفزات التحقق الإضافي لعمليات الصرف وتغيير المستفيد والاسترداد.
  • حدِّد الأساس القانوني لأي مقارنة للوجه.[5][15]
  • حدِّث تقييم الأثر على حماية البيانات بشأن استخدام الصورة الشخصية.[15]

الهندسة

  • أبقِ إثبات ربط الحامل مطلوبًا في كل طلب.[12]
  • تحقَّق من توقيع ربط الجهاز في كل استجابة.[2]
  • افحص حالة الإلغاء رغم أنها اختيارية.[3]
  • اربط كل تقديم بجلسة واحدة باستخدام nonce جديد.
  • صمِّم مسار الصورة الشخصية بحيث يُعالَج فيه غياب القيمة.[5]

المنتج والدعم

  • اطلب الصورة الشخصية فقط حيث تشملها الأغراض المسجَّلة لديك.[1]
  • أبقِ مسارًا قائمًا على الوثائق للأشخاص الذين لا يملكون محفظة.[1]
  • اكتب صياغة كل تحقق إضافي بحيث تذكر الإجراء المعني.
  • أخبِر العملاء بأنهم يستطيعون أن يطلبوا من مزوّد المحفظة إلغاء محفظة مسروقة.[6]

كيف تساعد Didit في مشكلة الحيازة

تُدرج وثائق Didit قبول EUDI Wallet بالحالة "قريبًا".[28] تقول صفحتنا الخاصة بـ EUDI Wallet: "لا توجد بعد واجهة API من Didit خاصة بـ EUDI" و"قم بالتكامل اليوم، واحتفظ به عند وصول المحفظة". يتناول هذا القسم ما يعمل اليوم. تُجري Biometric Authentication عمليات تحقق إضافي بفحص الحيوية ومطابقة الوجه.

  • إعادة التحقق. تتحقق Biometric Authentication من المستخدمين العائدين بفحص الحيوية وحده، أو بفحص الحيوية مع مطابقة الوجه مقابل صورة شخصية مخزَّنة، كجلسة ضمن سير عمل.[25][27]
  • الحضور. يتحقق Liveness من وجود شخص حقيقي أمام الكاميرا، باستخدام الطريقة السلبية أو طريقة الحركة ثلاثية الأبعاد 3D أو طريقة الوميض.[26]
  • التحقق الإضافي. توثّق Authentication من Didit استدعاءً يطبّق قواعد التحقق الإضافي الخاصة بك قبل أي إجراء حساس، ويُرجع ما إذا كان التحقق مطلوبًا. هذه الميزة جديدة وتُفعَّل لكل تطبيق على حدة.[31]
  • الشبكات. تكتشف Face Search الحسابات المكررة، وتجمع Networks مقدمي الطلبات الذين يتشاركون إشارات الجهاز أو عنوان IP أو البيانات البيومترية أو المستند أو بيانات الاتصال.[29][30]
  • المراقبة. تفحص Transaction Monitoring المعاملات في الوقت الفعلي وفق محرك قواعد قابل للتهيئة، مع إدارة الحالات.[32]
  • البديل. تخدم ID Verification وبطاقات الهوية الإلكترونية الوطنية العاملة العملاء الذين لا يملكون محفظة.[28]

ما توفره Didit

  • التحقق من الحيوية ومطابقة الوجه عند الطلب
  • مسارات المستندات والهوية الإلكترونية الوطنية
  • إشارات التكرار والشبكات
  • سجل كل عملية تحقق

ما يبقى على عاتقك

  • تقييم المخاطر وسياسة التحقق الإضافي
  • أساسك القانوني وتقييم الأثر
  • تسجيل الطرف المعتمِد
  • كل قرار يخص الإعداد أو المعاملة

الخطط والأسعار متاحة في صفحة الأسعار. تخضع البيانات المخزنة لمدة الاحتفاظ التي تحددها، وتعمل Didit بصفتها معالِج البيانات لديك.[33]

صمّم معنا التحقق الإضافي

أخبرنا بالإجراءات الأعلى مخاطرة، وابدأ بالتحقق من الحيوية ومطابقة الوجه ضمن سير عملك.

تحدث إليناابدأ مجانًا

أبرز النقاط

  • ربط الجهاز يثبت وجود مفتاح. أما ربط المستخدم فيربط هذا المفتاح بشخص، وعادةً ما تثق به بدلًا من التحقق منه.
  • المستوى العالي ضمانة قوية بشأن المحفظة، لكنه لا يشمل وسيط أموال متعاونًا أو مستخدمًا جرى التلاعب به.
  • تنضم الصورة الشخصية إلى بيانات PID الإلزامية اعتبارًا من 11 أغسطس 2028، مع مراعاة حالات الاستثناء، وتأكيد المستخدم ليس أساسًا قانونيًا.
  • لا يمكن لـ PID توقيع بيانات المعاملة، لذا تحتاج الإجراءات عالية المخاطر إلى موافقة أخرى.

الأسئلة الشائعة

ما هو ربط الحامل في EUDI Wallet؟

ربط الحامل هو الخاصية التي تضمن أن الشخص الذي يقدم البيانات هو الشخص الذي صدرت له. يسميه ARF ربط المستخدم (User binding)، ويذكر أنه يُسمى أحيانًا أيضًا ربط الحامل (holder binding).[2]

ما الفرق بين ربط الجهاز وربط الحامل؟

ربط الجهاز يربط البيانات بمفتاح في العتاد الآمن للمحفظة، ويمنع النسخ وإعادة الاستخدام. أما ربط الحامل فيربط البيانات بشخص. ويعدّ ARF ربط الجهاز شرطًا مسبقًا لربط المستخدم (User binding).[2]

هل ربط الجهاز إلزامي لبيانات PID؟

نعم، بالنسبة للمزوّدين. تُلزم اللائحة التنفيذية 2024/2977 مزوّدي PID بضمان أن تكون بيانات PID التي يصدرونها مرتبطة تشفيريًا بوحدة المحفظة.[4] ويُوصى الأطراف المعتمِدة بالتحقق من التوقيع، ويكون ذلك مطلوبًا إذا كنت تعتمد على مصادقة المحفظة نفسها.[2]

هل يمكنني إجراء مطابقة الوجه مع الصورة الشخصية في المحفظة؟

فقط إذا كانت بيانات PID تتضمّنها، وسجّلتَ هذا الاستخدام، وأكّد المستخدم ذلك، وكان لديك أساس قانوني. تنضمّ الصورة الشخصية إلى بيانات PID الإلزامية اعتبارًا من 11 أغسطس 2028، ويجوز للدول الأعضاء أن تسمح للمستخدمين بالانسحاب.[5]

هل يمكنني الاحتفاظ بالصورة الشخصية من تقديم المحفظة؟

ليس افتراضيًا. لا يجوز الاحتفاظ بها إلا إذا كانت المعالجة ضرورية للتعرّف على الهوية والمصادقة وفقًا لقانون الاتحاد لحماية البيانات، أو حيث ينصّ على ذلك قانون الاتحاد أو القانون الوطني.[4][5]

هل تشترط AMLR التحقق من الحيوية إضافةً إلى EUDI Wallet؟

لا يشترط ذلك أيّ نص اطّلعنا عليه. تُدرج المادة 22(6)(b)، كأحد الخيارات، وسائل التعريف الإلكتروني التي تستوفي متطلبات اللائحة 910/2014 عند المستوى الجوهري أو العالي، ويتحدّد نطاق التدابير وفق تحليل المخاطر الفردي الخاص بك.[13] وتنصّ مسودة المعايير النهائية الصادرة عن AMLA على أن ذلك يشمل المحافظ، وهي ليست قانونًا بعد.[14]

هل يمكن لتقديم المحفظة أن يعتمد عملية دفع؟

ليس باستخدام PID. يحظر PID Rulebook استخدام المفتاح الخاص لـ PID لتوقيع بيانات المعاملات.[9] ويتوقّع ARF أن يعتمد الموافقة الخاصة بكل معاملة على إقرارات المصادقة القوية للمستخدم، التي تحمل بيانات المعاملة.[3]

هل يمنع المستوى العالي الاستيلاء على الحساب؟

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

هل يمكن لوسيط أموال اجتياز فحوصات EUDI Wallet؟

نعم. حامل حقيقي يستخدم محفظة حقيقية يجتاز كل فحص، لأن الفحوصات صحيحة. الضابط هو المراقبة المستمرة بموجب المادة 26 من AMLR، إضافةً إلى الروابط بين الحسابات.[13]

هل تقبل Didit محفظة EUDI Wallet؟

تُدرج وثائق Didit قبول EUDI Wallet بالحالة "قريبًا"، وتذكر صفحة الحلول أنه لا توجد بعدُ API خاصة بـ EUDI لدى Didit.[28] وتعمل اليوم وسائل الهوية الإلكترونية الوطنية، والتحقق من المستندات، والتحقق من الحيوية، ومطابقة الوجه، وتصف صفحة الحلول الخطة.

المصادر

  1. اللائحة (EU) No 910/2014 بصيغتها المعدّلة باللائحة (EU) 2024/1183، النص الموحّد بتاريخ 18 أكتوبر 2024، EUR-Lex.
  2. Architecture and Reference Framework v3.0.0، الفصل 6، نموذج الثقة، المفوضية الأوروبية، 23 يوليو 2026.
  3. Architecture and Reference Framework v3.0.0، الملحق 2، المتطلبات عالية المستوى، المفوضية الأوروبية.
  4. اللائحة التنفيذية (EU) 2024/2977، النص الموحّد بتاريخ 11 أغسطس 2026، EUR-Lex.
  5. اللائحة التنفيذية (EU) 2026/1731، EUR-Lex، الجريدة الرسمية بتاريخ 22 يوليو 2026.
  6. اللائحة التنفيذية (EU) 2024/2979، النص الموحّد بتاريخ 11 أغسطس 2026، EUR-Lex.
  7. اللائحة التنفيذية (EU) 2015/1502 بشأن مستويات الضمان، EUR-Lex.
  8. اللائحة التنفيذية (EU) 2024/2981 بشأن اعتماد المحافظ، الملحق I سجل المخاطر، EUR-Lex.
  9. PID Rulebook v1.7، المفوضية الأوروبية، 17 يوليو 2026.
  10. Topic R، مصادقة المستخدم على الجهاز، v1.0، ورقة نقاش ARF، 14 أكتوبر 2025.
  11. Topic Z، الإقرارات المرتبطة بالجهاز، v1.0، ورقة نقاش ARF، 29 سبتمبر 2025.
  12. OpenID for Verifiable Presentations 1.0، OpenID Foundation.
  13. اللائحة (EU) 2024/1624 (AMLR)، EUR-Lex، الجريدة الرسمية بتاريخ 19 يونيو 2024.
  14. التقرير النهائي، مسودة RTS بموجب المادة 28(1) من AMLR، AMLA، 30 سبتمبر 2026 (مسودة نهائية، ليست قانونًا).
  15. اللائحة (EU) 2016/679 (GDPR)، EUR-Lex.
  16. اللائحة (EU) 2024/1689 (AI Act)، EUR-Lex.
  17. التوجيه (EU) 2015/2366 (PSD2)، EUR-Lex.
  18. اللائحة المفوضة (EU) 2018/389، EUR-Lex.
  19. تقرير 2025 عن الاحتيال في المدفوعات، EBA وECB، ديسمبر 2025.
  20. التقرير المشترك بين EBA وECB عن الاحتيال في المدفوعات، بيان صحفي، ECB، 15 ديسمبر 2025.
  21. Remote Identity Proofing: Attacks and Countermeasures، ENISA.
  22. TechDispatch عن محافظ الهوية الرقمية، European Data Protection Supervisor، ديسمبر 2025.
  23. ETSI TS 119 461 v2.1.1، إثبات هوية أصحاب خدمات الثقة، ETSI.
  24. Architecture and Reference Framework v3.0.0، الفصل 4، البنية عالية المستوى، European Commission.
  25. المصادقة البيومترية، وثائق Didit.
  26. كشف الحيوية، وثائق Didit.
  27. مطابقة الوجه 1:1، وثائق Didit.
  28. محافظ الهوية الرقمية، وثائق Didit.
  29. البحث بالوجه، وثائق Didit.
  30. الشبكات، وثائق Didit.
  31. إنشاء تحقق إضافي (step-up)، وثائق Didit.
  32. مراقبة المعاملات، وثائق Didit.
  33. الاحتفاظ بالبيانات، وثائق Didit.

تجيب المحفظة عن سؤال: لمن تعود بيانات الاعتماد، ويبدأ عملك في تقييم المخاطر من هذه الإجابة. للحالات التي تتطلب التحقق من الشخص نفسه، راجع المصادقة البيومترية. وللجاهزية للمحفظة، راجع صفحة EUDI Wallet لدينا والتحقق من الهوية الإلكترونية (eID).

تحقق من الشخص، لا من المفتاح فقط

أضف كشف الحيوية ومطابقة الوجه حيث يقضي تقييمك للمخاطر بذلك.

ابدأ مجانًاتحدث إلينا

بنية تحتية للهوية والاحتيال.

واجهة برمجية واحدة لـ KYC و KYB ومراقبة المعاملات وفحص المحافظ. ادمجها في 5 دقائق.

اطلب من الذكاء الاصطناعي تلخيص هذه الصفحة