دليل المحقق في OpenID4VP: قبول محفظة EUDI

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

OpenID4VP هو الطريقة التي يطلب بها موقع إلكتروني أو تطبيق من محفظة أن تثبت أمرًا ما عن شخص، مثل الاسم أو تاريخ الميلاد. تحدد جهة التحقق بيانات الاعتماد والمطالبات التي تريدها، ويوافق المستخدم في المحفظة، ثم تعيد المحفظة عرضًا تتحقق منه جهة التحقق تشفيريًا. وبعبارة المواصفة نفسها، فهو «يحدد بروتوكولًا لطلب بيانات الاعتماد وعرضها».^[1]

هذا الدليل موجّه إلى المطورين الذين يبنون جهة تحقق بـ OpenID4VP لمحفظة EUDI: كائن الطلب، وDCQL، وأنماط الاستجابة، وتدفقات الأجهزة، وفحوص SD-JWT VC وmdoc، وقواعد HAIP في قانون الاتحاد الأوروبي، والأخطاء الشائعة، وأماكن الاختبار.

OpenID4VP بكلمات بسيطة

يعيد OpenID4VP استخدام بنية طلب التفويض في OAuth 2.0. تطلب جهة التحقق نوع الاستجابة vp_token، ويجب أن تتضمن الاستجابة الناجحة المعامل vp_token الذي يحمل العروض.^[1] لا يوجد رمز (code) ولا رمز وصول (access token) للتبادل: تصل البيانات في الاستجابة نفسها.

تتحقق المحفظة من هوية الطرف المعتمِد، وتتأكد من أنه لا يطلب أكثر مما سجّله، وتجمع موافقة المستخدم، وتوقّع العرض. ثم يتحقق الطرف المعتمِد من توقيع الجهة المُصدِرة، وحالة الإلغاء، وربط الجهاز.^[3] تُصدَر بيانات تعريف الشخص (PID) بصيغتين، SD-JWT VC وISO/IEC mdoc، وتستخدم كلتاهما تجزئات مملّحة كي يتمكن المستخدم من مشاركة بعض السمات وإخفاء البقية.^[5][3]

1. 10 يوليو 2025المواصفة النهائيةاعتماد OpenID4VP 1.0.
2. 22 يوليو 2026النشرنشر CIR 2026/1731 (المعتمَدة في 15 يوليو 2026) في الجريدة الرسمية.
3. 23 يوليو 2026ARF v3.0.0الإصدار الحالي من البنية.
4. 24 ديسمبر 2026المحافظمحفظة واحدة على الأقل لكل دولة عضو.
5. 24 ديسمبر 2027القبولالأطراف المعتمِدة الخاصة الخاضعة للتنظيم.

من المواصفة النهائية إلى تاريخ القبول في القطاع الخاص.^[2][3][4][5]

كيف يجري تبادل البيانات مع جهة تحقق OpenID4VP

ينشر OpenID4VP تصميمًا مرجعيًا لنمط الاستجابة direct_post، حيث ترسل المحفظة الاستجابة إلى نقطة نهاية على الخادم بدلًا من تمريرها عبر المتصفح.^[1]

التصميم المرجعي لـ direct_post في OpenID4VP 1.0، القسم 13.3، بشكل مبسّط.^[1]

• أنشئ قيمة nonce من «16 بايت على الأقل، جديدة ومولّدة عشوائيًا بطريقة تشفيرية» لكل طلب.
• أرسِل request-id المأخوذ من نقطة نهاية الاستجابة إلى المحفظة بصفته state.
• أعِد عنوان URI لإعادة التوجيه مع response_code جديد بمجرد أن تُرسل المحفظة طلب POST.
• استرجع VP Token باستخدام transaction-id وذلك الرمز، ثم تحقّق من قيمة nonce.

يمنع response_code هجمات تثبيت الجلسة (session fixation)، حيث يمرر المهاجم طلبك إلى محفظة الضحية. وتشير المواصفة إلى أنه لا يفيد عند استخدام أجهزة مختلفة، وتوصي في هذه الحالة بآليات إضافية.^[1]

كائن الطلب في OpenID4VP ومعرّفات العميل

يبدأ client_id ببادئة معرّف العميل التي تُبلغ المحفظة بالطريقة التي تصادق بها على هوية جهة التحقق.^[1] تُنقل الطلبات الكبيرة بالإحالة، إذ تجلب المحفظة كائن الطلب الموقّع من request_uri. وبالنسبة إلى رموز QR، توصي المواصفة باستخدام direct_post مع request_uri، لأن الطلب "قد لا يتسع له رمز QR".^[1]

بادئات معرّف العميل (Client Identifier Prefixes)، OpenID4VP 1.0 القسم 5.9.^[1]

بالنسبة إلى جهات التحقق في EUDI، يحدد قانون الاتحاد الأوروبي البادئة: الشهادة الطرفية "المخصصة للاستخدام مع بادئة معرّف العميل x509_hash يجب أن تكون شهادة وصول للطرف المعتمِد (RP access certificate) كما هو محدد في ETSI TS 119 475"، وأحد عناصر verifier_info "يجب أن يتضمن شهادة التسجيل".^[5]

استعلامات DCQL: اطلب ما سجّلته

لغة الاستعلام عن بيانات الاعتماد الرقمية (Digital Credentials Query Language أو DCQL) هي استعلام بصيغة JSON يحدد بيانات الاعتماد والمطالبات التي تطلبها. يتضمن هذا الاستعلام مصفوفة credentials إلزامية ومصفوفة credential_sets اختيارية. ويحتاج كل استعلام عن بيانات اعتماد إلى id وformat وكائن meta.^[1] وفيما يلي مثال SD-JWT VC الوارد في المواصفة:^[1]

{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }

بالنسبة إلى mdoc، يكون التنسيق mso_mdoc ويحمل meta قيمة doctype_value.^[1] وبالنسبة إلى PID، استبدل بها نوعه وأسماء مطالباته. والسمات الإلزامية في PID هي اسم العائلة والاسم الأول وتاريخ الميلاد ومكان الميلاد والجنسية.^[7]

• القيمة الافتراضية لـ require_cryptographic_holder_binding هي true. أبقِ عليها، فهي تجعل المحفظة تُعيد إثبات ربط المفتاح.^[1]
• trusted_authorities يقتصر دوره على تصفية ما تعرضه المحفظة. ويتعيّن على جهات التحقق "أن تتحقق بنفسها من أن مُصدِر العرض المستلَم جهة موثوقة".^[1]
• الأطراف المعتمِدة "لا يجوز لها أن تطلب من المستخدمين تقديم أي بيانات غير" ما سجّلته، والمحفظة تتحقق من ذلك.^[4][3]

أوضاع الاستجابة في OpenID4VP

يحدد وضع الاستجابة طريقة إعادة VP Token. القيمة الافتراضية لـ vp_token هي fragment، أي في الجزء الختامي (fragment) من عنوان URI لإعادة التوجيه.^[1]

أوضاع الاستجابة في OpenID4VP 1.0.^[1]

مع direct_post، يكون response_uri إلزاميًا ويجب ألا يُرسل redirect_uri، وإلا تُرجع المحفظة invalid_request.^[1] على سبيل المثال، توثّق EVO Wallet في مولدوفا استخدام OpenID4VP 1.0 مع direct_post.jwt في تدفق على الجهاز نفسه، وmdoc وفق ISO/IEC 18013-5 بملف تعريف مطابق لـ OpenID4VC HAIP 1.0، وIETF Token Status List لإلغاء الصلاحية.^[11]

على الجهاز نفسه، وعبر الأجهزة، وواجهة Digital Credentials API

يحدد ARF التركيبات المدعومة للتقديم عن بُعد: OpenID4VP مع آلية نقل قائمة على عمليات إعادة التوجيه ومخططات URI المخصصة، وOpenID4VP أو ISO/IEC 18013-7 مع W3C Digital Credentials API، واختياريًا ISO/IEC 18013-7 مع عمليات إعادة التوجيه ومخططات URI المخصصة.^[3]

ثلاث طرق تتلقى بها المحفظة طلب OpenID4VP.^[3][1][10]

يذكر ARF أن مخططات URI المخصصة "غير موصى بها للتدفقات عبر الأجهزة"، ويسمي Digital Credentials API بديلًا عنها.^[3] عبر هذه الواجهة، تعرف المحفظة مصدر جهة التحقق كما يصادق عليه المتصفح، "وهو أمر مهم لمقاومة التصيد الاحتيالي".^[1] ولا تزال مواصفة W3C مسودة.^[9] ما يراه المستخدم على الهاتف:

التحقق من عرض SD-JWT VC خطوة بخطوة

يتضمن عرض SD-JWT VC رمز JWT الموقّع من الجهة المُصدِرة، والإفصاحات التي كشفها المستخدم، ورمز Key Binding JWT. ويجب على جهة التحقق "التحقق من صحة كل عرض قابل للتحقق (Verifiable Presentation) على حدة"، ورفض أي عرض يحمل قيمة nonce خاطئة.^[1]

عمليات التحقق التي تُجريها جهة التحقق على عرض واحد لـ SD-JWT VC.^[1][3]

توقيع الجهة المُصدِرة. يضعه ARF في المرتبة الأولى ضمن عمليات التحقق التي يجريها الطرف المعتمِد. تُستمد مراسي الثقة من القوائم الموثوقة (ETSI TS 119 612) ومن قوائم الكيانات الموثوقة (ETSI TS 119 602).^[3]

الإفصاحات. تحتوي الحمولة الموقّعة على مصفوفة _sd من الملخصات التجزيئية، وكل إفصاح يتكوّن من قيمة ملح (salt) واسم مطالبة وقيمة، مثل ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"].^[1] احسب تجزئة كل إفصاح وابحث عن ملخصه. إذا لم تجد تطابقاً، فهذا يعني أن الجهة المُصدِرة لم توقّعه.

Key Binding JWT. عندما يكون ربط الحامل مطلوبًا، فإن المحفظة "يجب (MUST) أن تُعيد SD-JWT مع Key Binding JWT". يجب أن تساوي قيمة nonce فيه قيمة nonce في طلبك، وأن تساوي قيمة aud معرّف العميل (Client Identifier) الخاص بك، أو عند الاستخدام عبر Digital Credentials API، الأصل (origin) الخاص بك مسبوقًا بـ origin:.^[1] المثال الوارد في المواصفة:

{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }

الإلغاء. يتحقق الطرف المعتمِد من أن المزوّد "لم يُلغِ PID أو الإقرار".^[3] وتوثّق محفظة EVO Wallet في مولدوفا، على سبيل المثال، قائمة IETF Token Status List لهذا الغرض.^[11]

عمليات تقديم mdoc عبر ISO/IEC 18013-7، باختصار

بالنسبة إلى mdoc، يحمل VP Token استجابة DeviceResponse مُرمَّزة بصيغة base64url وفق ISO/IEC 18013-5، و"تحتوي على توقيع أو MAC على SessionTranscript"، بما في ذلك بنية تسليم (handover) خاصة بـ OpenID4VP.^[1] وتربط بنية التسليم هذه الـ mdoc بطلبك، كما تربط قيمة nonce وقيمة audience بيانات SD-JWT VC بالطلب.

تشرح مقارنتنا بين SD-JWT VC و mdoc متى تناسب كل صيغة.

ما الذي يضيفه ملف التعريف HAIP لجهات التحقق في EUDI

يُضيّق ملف التشغيل البيني عالي الضمان (HAIP) الخيارات المتاحة في OpenID4VP. ويشترطه ARF بالفعل للإصدار، إذ ينص على أن استخدامه "ضروري لضمان التشغيل البيني".^[3] وبالنسبة إلى العرض، تحدد CIR 2026/1731 "ملف تعريف OpenID4VC-HAIP" و"ملف تعريف ISO/IEC-mdoc".^[5]

شهادة التسجيل «تصف الاستخدام المقصود للطرف المعتمد وتبيّن السمات» التي سجّلها، وتسري لائحة التسجيل اعتبارًا من 24 ديسمبر 2026.^[6] ولا يشمل تاريخ 11 أغسطس 2028 إلا تحقق المحفظة من تلك الشهادة، ولا يشمل التسجيل.^[5] وتلخّص ألمانيا الأمر بقولها إن المؤسسة «تحصل على شهادة وصول وتسجيل خاصة بالمؤسسة وبحالة الاستخدام».^[12] ويتناول دليلنا للطرف المعتمِد على محفظة EUDI التسجيل بالتفصيل الكامل.

الأخطاء الشائعة عند بناء جهة تحقق OpenID4VP

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

موارد الاختبار

ابدأ بالبرمجيات المرجعية واختبارات المطابقة قبل أن تجري الاختبارات على المحافظ الوطنية.

• أجرِ اختبارات المطابقة على conformance.eudi.dev.^[3]
• اقرأ وثائق التنفيذ المرجعي على docs.eudi.dev، وهي وثائق وليست اختبارات.^[3]
• ادرس جهة التحقق التجريبية التابعة للبنك الوطني المولدوفي وشيفرتها المصدرية.^[13]
• راجع مسودة Digital Credentials API قبل الاعتماد على مسار المتصفح.^[9]

للاطلاع على التواريخ التي تستند إليها خطة الاختبار لديك، راجع المواعيد النهائية لمحفظة EUDI في عامي 2026 و2027.

كيف تساعد Didit في التحقق عبر محفظة EUDI

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

• تعمل اليوم خمس هويات إلكترونية وطنية في Didit عبر محافظ الهوية الرقمية: MitID وBankID Sweden وFinnish Trust Network وSmart-ID وMobile-ID. راجع التحقق من الهوية الإلكترونية (eID).
• إذا لم تكن لدى الشخص هوية إلكترونية، يلجأ المسار بدلًا من ذلك إلى التحقق من المستندات مع قراءة شريحة NFC والتحقق من الحيوية ومطابقة الوجه، وفق إعدادات خاصة بكل دولة. تبلغ تكلفة فحص KYC الكامل $0.33.
• فحص مكافحة غسل الأموال يُجرى ضمن التدفق نفسه بسعر $0.20.

تبقى واجباتك بصفتك طرفًا معتمِدًا قائمة عليك. توضح وثائق المحفظة كيفية تفعيل الهويات الإلكترونية لكل دولة على حدة.

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

المصادر

1. OpenID for Verifiable Presentations 1.0، OpenID Foundation، المواصفة النهائية.
2. اعتماد المواصفة النهائية لـ OpenID for Verifiable Presentations 1.0، OpenID Foundation، 10 يوليو 2025.
3. Architecture and Reference Framework v3.0.0، eu-digital-identity-wallet على GitHub، إصدار 23 يوليو 2026.
4. اللائحة (الاتحاد الأوروبي) 2024/1183 (eIDAS 2)، EUR-Lex، الجريدة الرسمية بتاريخ 30 أبريل 2024.
5. لائحة المفوضية التنفيذية (الاتحاد الأوروبي) 2026/1731، EUR-Lex، الجريدة الرسمية بتاريخ 22 يوليو 2026.
6. اللائحة التنفيذية للمفوضية (EU) 2025/848 بشأن تسجيل الأطراف المعتمِدة على المحفظة، EUR-Lex، الجريدة الرسمية الصادرة في 7 مايو 2025.
7. اللائحة التنفيذية للمفوضية (الاتحاد الأوروبي) 2024/2977 بشأن بيانات تعريف الشخص، EUR-Lex، الجريدة الرسمية الصادرة في 4 ديسمبر 2024.
8. ISO/IEC 18013-7، صفحة المعيار على موقع ISO.
9. Digital Credentials، مسودة W3C.
10. إطلاق Digital Credentials API، Chrome for Developers.
11. دليل المطورين الخاص بـ EVO Wallet، حكومة مولدوفا، egov4dev.
12. الأسئلة الشائعة حول محفظة EUDI، eudi-wallet.gov.de.
13. جهة التحقق التجريبية لـ BNM، حكومة مولدوفا، egov4dev.

يمثل OpenID4VP الجزء من محفظة EUDI الذي يتعامل معه المطورون أكثر من غيره، وهو مستقر بما يكفي للبناء عليه. اطّلع على نهج Didit في قبول المحافظ في صفحة حل محفظة EUDI، وعلى الصورة الأشمل في نظرتنا العامة على eIDAS 2.