SD-JWT VC مقابل mdoc (ISO/IEC 18013-5): مقارنة صيغ محفظة EUDI

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

بيانات الاعتماد SD-JWT VC هي بيانات اعتماد قابلة للتحقق مُعبّأة في صورة رمز ويب JSON موقَّع (JSON Web Token)، ويمكن الكشف عن مطالباته واحدةً تلو الأخرى. أما mdoc فهو مستند محمول بصيغة ISO/IEC 18013-5، وهو المعيار الذي كُتب في الأصل لرخص القيادة المحمولة. ويُدرج إطار البنية والمرجعية (ARF) لمحفظة EUDI الصيغتين كصيغتين إلزاميتين للمحافظ، ويُدرج صيغة ثالثة هي نموذج بيانات بيانات الاعتماد القابلة للتحقق W3C Verifiable Credentials Data Model 2.0 كصيغة اختيارية و"مخصصة للإثباتات الإلكترونية للسمات (EAA) غير المؤهلة فقط".^[1]

يقارن هذا الدليل بين الصيغتين للمطورين الذين يبنون جهة متحققة، استنادًا إلى ARF الإصدار v3.0.0، ونص OpenID for Verifiable Presentations (OpenID4VP) 1.0، والجريدة الرسمية. ويرمز PID إلى بيانات تعريف الشخص.

ما هي SD-JWT VC

يصف ARF "بيانات الاعتماد القابلة للتحقق المبنية على SD-JWT" بأنها صيغة بيانات وقواعد معالجة للتعبير عن بيانات الاعتماد القابلة للتحقق، حيث إن SD-JWT "يرمز إلى 'Selectively Disclosable JSON Web Token'".^[1] وتشمل ترميز JSON، وآلية إثبات مع الكشف الانتقائي، وربطًا اختياريًا بالجهاز.^[1]

في OpenID4VP يكون معرّف الصيغة dc+sd-jwt، ويحدد الاستعلام نوع بيانات الاعتماد عبر vct_values.^[4] وفيما يلي مثال المواصفة لحمولة مُصدَرة، مختصرًا إلى اثنتين من قيم التجزئة الثماني:^[4]

{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }

ما هو mdoc (ISO/IEC 18013-5)

يحدد ISO/IEC 18013-5 سمات الرخصة، وترميزها بصيغة التمثيل الثنائي الموجز للكائنات (CBOR)، ومساحات أسماء تمنع تعارض المعرّفات، وآلية إثبات مع الكشف الانتقائي، وربطًا إلزاميًا بالجهاز، والتبادل عن قرب.^[1]

نموذج بيانات الرخصة وحده هو الخاص بالقيادة. ويشير ARF إلى أن جميع الجوانب الأخرى "عامة ويمكن استخدامها لأي نوع آخر من الشهادات، بما في ذلك PID".^[1]

يصف OpenID4VP بيانات الاعتماد هذه بأنها "مرمّزة بصيغة CBOR ومؤمّنة باستخدام COSE_Sign1"، ويمنحها معرّف الصيغة mso_mdoc. ويحدد الاستعلام نوع المستند عبر doctype_value.^[4]

كيف يعمل الكشف الانتقائي في كل صيغة

يتيح الكشف الانتقائي للمستخدم مشاركة بعض السمات وإخفاء البقية، مع بقاء قدرة الجهة المتحققة على التحقق من توقيع المُصدِر. ويُلزم eIDAS 2 المحافظ بإتاحة ذلك.^[6] ويسمي ARF آلية SD-JWT "قيم تجزئة مملّحة"، ويقول إنها "مطابقة من حيث المفهوم للآلية المستخدمة للغرض نفسه في [ISO/IEC 18013-5]".^[1]

آلية واحدة، وترميزان.^[1][4]

في المثال أعلاه، تحمل المصفوفة _sd قيم تجزئة SHA-256. كل إفصاح هو مصفوفة تضم قيمة عشوائية واسم المطالبة وقيمة المطالبة. بالنسبة للاسم الأول، يكون الإفصاح ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]، وقيمة تجزئته هي القيمة الأولى في القائمة. يحسب المُتحقِّق قيمة تجزئة كل إفصاح يتلقاه ويبحث عن قيمة التجزئة في الحمولة الموقّعة.^[4]

تُحدَّد المطالبات بطريقة مختلفة. في بيانات الاعتماد بصيغة JSON، يكون مسار المطالبات قائمة مفاتيح مثل ["address", "street_address"]. أما في mdoc، فإن المسار "يحتوي على عنصرين من نوع string": مساحة الأسماء ومعرّف عنصر البيانات، مثل ["org.iso.18013.5.1", "first_name"].^[4]

ربط المفتاح وإشراك الجهاز

يقرن ربطُ الجهاز بيانات الاعتماد بمفاتيح محفوظة في محفظة المستخدم، فلا يمكن استنساخ بيانات الاعتماد. يتحقق منه المُتحقِّق بأن يطلب من المحفظة توقيع بيانات عشوائية جديدة بالمفتاح الخاص المطابق للمفتاح العام الموجود داخل بيانات الاعتماد.^[1] وتختلف التسميات: "في [ISO/IEC 18013-5] يُسمّى 'مصادقة mdoc'. وفي [SD-JWT VC] يُسمّى 'ربط المفتاح'."^[1]

ربط الجهاز إلزامي لبيانات PID في كلتا الصيغتين.^[1][4]

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

إشراك الجهاز (device engagement) خاص بـ mdoc وحده. في مسار العرض عن قرب، يعرض المستخدم رمز QR أو يقدّم وسم NFC. ويحمل هذا الرمز أو الوسم ما يحتاجه القارئ لفتح اتصال NFC أو Bluetooth Low Energy أو Wi-Fi Aware، وبناء قناة مصادَق عليها ومشفّرة عبره، دون أي اتصال بالإنترنت بين الطرفين.^[1]

عرض عن قرب باستخدام mdoc (ISO/IEC 18013-5)، بصورة مبسّطة.^[1]

ما يراه المستخدم:

بروتوكولات العرض: OpenID4VP وISO/IEC 18013-7 والعرض عن قرب

يحدد ARF ما تتعامل معه المحفظة: ISO/IEC 18013-5 في العرض عن قرب، وOpenID4VP أو ISO/IEC 18013-7 في العرض عن بُعد.^[1]

أي بروتوكول ينقل أي صيغة، وفقًا لـ ARF.^[1]

شهادات SD-JWT VC "لا يمكن استخدامها في العرض عن قرب". ويمكن استخدام ISO/IEC 18013-7 "فقط لطلب الشهادات وعرضها بالصيغة المتوافقة مع [ISO/IEC 18013-5]". أما OpenID4VP فهو "مناسب فقط لتدفقات معاملات العرض عن بُعد" وينقل الصيغتين معًا.^[1] وأصبح OpenID4VP 1.0 مواصفة نهائية في 10 يوليو 2025.^[5]

لا يوصي ARF باستخدام مخططات URI المخصصة بين الأجهزة، لأن هذه التدفقات "عرضة لهجمات التصيد الاحتيالي وهجمات الترحيل"، ويحدد Digital Credentials API بديلًا عنها.^[1] ولا تزال هذه الواجهة مسودة لدى W3C، ويفعّلها Chrome 141 افتراضيًا.^[9][10] وتدرج ISO المواصفة الفنية لعام 2024 من 18013-7 على أنها مسحوبة ومستبدلة، مع إصدار ثالث قيد الإعداد، لذا تحقق من الإصدار الذي يستهدفه الكود لديك.^[7][8] وتفاصيل الطلب موجودة في دليل المتحقق في OpenID4VP.

ما تشترطه اللائحة التنفيذية (EU) 2026/1731 بشأن PID

نصت القاعدة الأولى بشأن صيغ PID، وهي اللائحة التنفيذية (EU) 2024/2977، على أن PID "يجب أن يُصدر بصيغتين": ISO/IEC 18013-5:2021 وVerifiable Credentials Data Model 1.1.^[2][3] واستبدل القانون المعدِّل الصادر في يوليو 2026 هذه الجملة. فبات النص يقضي الآن بأن PID "يجب أن يُصدر وفقًا للمعايير المحددة في الملحق II من اللائحة التنفيذية (EU) 2024/2979، البندين 5 (صيغة SD-JWT VC) و6 (صيغة ISO/IEC-mdoc)".^[2]

1. 4 ديسمبر 2024القاعدة الأولى2024/2977: 18013-5 وVCDM 1.1.
2. 22 يوليو 2026التعديل2026/1731: SD-JWT VC وmdoc.
3. 23 يوليو 2026ARF v3.0.0متوائم مع القوانين المعدِّلة.
4. 24 ديسمبر 2026موعد استحقاق المحافظمحفظة واحدة لكل دولة عضو.
5. 11 أغسطس 2028الصورة الشخصيةيسري اشتراط الصورة الشخصية، ما لم يختر المستخدم صراحةً عدم تطبيقه عليه، حيثما كان ذلك منطبقًا.

كيف تطوّر القانون بشأن صيغ PID.^[1][2][3][6]

يحدد القانون نفسه ملفَّي تعريف للعرض في ملحقه باللائحة التنفيذية (EU) 2024/2982: «ملف تعريف ISO/IEC-mdoc» و«ملف تعريف OpenID4VC-HAIP».^[2]

• أرسل شهادة التسجيل الخاصة بك: أحد عناصر verifier_info «يجب أن يتضمن شهادة التسجيل».^[2]
• استخدم شهادة الوصول الخاصة بك بوصفها الشهادة الطرفية مع بادئة معرّف العميل x509_hash.^[2]
• اتبع «الملحق C من ISO/IEC 18013-7:2025» لتقديم mdoc عبر Digital Credentials API.^[2]

يتناول دليل الطرف المعتمد على محفظة EUDI موضوع التسجيل، ويتناول مقال مواعيد محفظة EUDI النهائية لعامي 2026 و2027 الجدول الزمني.

SD-JWT VC مقابل mdoc (ISO/IEC 18013-5): جدول مقارنة

المصدر هو ARF، باستثناء صف PID (اللائحة التنفيذية 2026/1731) والصفين الأخيرين (OpenID4VP 1.0).^[1][2][4]

تعتمد رخص القيادة على الهاتف المحمول في الولايات المتحدة على ISO/IEC 18013-5 للعرض عن قرب.^[7][8] ويحدد حل التحقق من العمر في الاتحاد الأوروبي إثبات المعرفة الصفرية بوصفه آلية العرض الإلزامية، "مع عرض mDoc العادي كبديل احتياطي".^[13] وتوثّق EVO Wallet في مولدوفا استخدام OpenID4VP 1.0 مع mdoc وفق ISO/IEC 18013-5، بملف تعريف مطابق لـ HAIP 1.0.^[11]

أي صيغة يجب أن يدعمها الطرف المعتمِد

تتعامل وحدات المحفظة مع الصيغتين، ويُصدر PID بالصيغتين.^[1][2] ولا تتضمن النصوص التي رُوجعت لإعداد هذا الدليل أي سطر يُلزم الطرف المعتمِد بطلب الصيغتين. القراءة العملية: يمكن للمتحقق عن بُعد أن يطلب أياً منهما، أما القارئ الذي لا يملك اتصالاً بالإنترنت فيحتاج إلى mdoc، وهي الصيغة الوحيدة التي تعمل عن قرب.^[1]

تتيح لغة استعلام بيانات الاعتماد الرقمية (DCQL) في OpenID4VP أن يحمل طلب واحد استعلام dc+sd-jwt واستعلام mso_mdoc جنباً إلى جنب، وتعرض المواصفة مثالاً على هذا الطلب.^[4] ووفقاً لـ ARF، يتحقق الطرف المعتمِد من توقيع الجهة المُصدِرة مقابل مرساة ثقة مأخوذة من قائمة موثوقة أو من قائمة الكيانات الموثوقة، ويفحص الإلغاء عبر قائمة حالة أو قائمة إلغاء، ويتحقق من ربط الجهاز.^[1]

بموجب eIDAS 2، أي اللائحة (EU) 2024/1183، يجب على كل دولة عضو توفير محفظة واحدة على الأقل بحلول 24 ديسمبر 2026، ويجب على الأطراف المعتمِدة الخاصة الملزمة باستخدام مصادقة قوية للمستخدم أن تقبلها بناءً على طلب المستخدم بحلول 24 ديسمبر 2027، مع إعفاء المؤسسات متناهية الصغر والصغيرة من هذا الالتزام.^[6] ويمكن الاطلاع على وضع كل دولة في متتبع إطلاق محفظة EUDI.

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

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

• شغّل اختبارات المطابقة على conformance.eudi.dev، المذكورة في ملاحظات إصدار ARF v3.0.0.^[1]
• اقرأ وثائق التنفيذ المرجعي على docs.eudi.dev.^[1]
• ادرس أداة تحقق منشورة: أصدر البنك الوطني المولدوفي أداة تحقق تجريبية مع شيفرتها المصدرية للمؤسسات المالية.^[12]
• تأكد من أن المكتبة تتبع HAIP، وليس المواصفات الأساسية فقط.^[1]
• تأكد من إصدار ISO/IEC 18013-7 الذي تطبقه المكتبة.^[2][8]

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

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

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

توضح وثائق المحفظة كيفية تفعيل الهويات الإلكترونية لكل بلد.

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

المصادر

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

SD-JWT VC وmdoc (ISO/IEC 18013-5) ترميزان لالتزام واحد: سمات موقّعة يتحكم فيها المستخدم. اطّلع على نهج Didit في قبول المحافظ في صفحة حل محفظة EUDI، وعلى كل نظام وطني في أنظمة الهوية الإلكترونية حسب الدولة.