واجهة برمجة تطبيقات الاعتماد الرقمي (2026): دعم مباشر في Chrome وSafari

آخر تحديث: 26 مارس 2026

نقدم هنا نظرة سريعة على دعم واجهة برمجة تطبيقات الاعتماد الرقمي (Digital Credentials API) في المتصفحات الرئيسية:

عالم الاعتمادات الرقمية يتحرك بسرعة. إليكم لقطة لأهم التطورات والتوقعات:

Want to experience digital credentials in action?

Try Digital Credentials

ما الذي تغير منذ أكتوبر 2025؟

• تحول في حوكمة البروتوكول: قامت مجموعة عمل W3C FedID بإلغاء سجل البروتوكول المفتوح في TPAC (نوفمبر 2025) وتقوم الآن بتضمين البروتوكولات المدعومة بشكل ثابت مباشرة في المواصفات: OpenID4VP، OpenID4VCI، و ISO 18013-7 Annex C. لم تعد واجهة برمجة التطبيقات مجرد "ناقل سلبي".
• وصول ميزة الإصدار: أطلق Chrome 143 تجربة أصل لإصدار الاعتمادات عبر navigator.credentials.create()، مما يوسع الواجهة لتشمل الإصدار وليس العرض فقط.
• Firefox ينفذ: على الرغم من عدم تغيير موقف المعايير السلبي، أدرجت Mozilla كود DC API الأساسي في Firefox 149 مع استمرار العمل على تجربة المستخدم.
• تفويض مشروط للاتحاد الأوروبي: يشترط إطار عمل البنية المرجعية لـ EUDI (الموضوع F) الآن دعم DC API بشكل مشروط لجميع محافظ الدول الأعضاء.
• التبني في العالم الحقيقي: أضافت إدارة المركبات في كاليفورنيا (California DMV) دعم DC API لمنصتها OpenCred (فبراير 2026).

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

في هذه المقالة، نهدف إلى مناقشة الوضع الحالي لواجهة برمجة تطبيقات الاعتماد الرقمي (Digital Credentials API)، وهو تطور مهم يعد بإعادة تشكيل كيفية تفاعلنا مع معلومات الهوية على الويب. سنستكشف آلياتها الأساسية، والبروتوكولات التي تدعمها، وتبني المتصفحات الحالي لها، ونقدم توصيات لكل من الأطراف المعتمدة ومصدري المحافظ الذين يتنقلون في هذا المشهد سريع التطور.

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

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

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

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

Want to experience digital credentials in action?

Try Digital Credentials

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

في جوهره، يدور مفهوم الاعتمادات الرقمية، خاصة في سياق واجهات برمجة تطبيقات الويب الجديدة، حول نموذج ثلاثي الأطراف:

1. المُصدر (Issuer): كيان (مثل الحكومة، الجامعة، صاحب العمل) يمتلك السلطة على معلومات معينة حول موضوع ما ويمكنه إصدار اعتماد رقمي يشهد بتلك المعلومات.
2. الحامل (Holder): موضوع المعلومات (أي المستخدم) الذي يتلقى الاعتماد من المُصدر ويخزنه في محفظة رقمية. يتحكم الحامل في وقت ومحتوى المعلومات التي يتم مشاركتها.
3. المتحقق (أو الجهة المعتمدة - Verifier/RP): كيان (مثل موقع ويب، خدمة عبر الإنترنت) يحتاج إلى التحقق من معلومات معينة حول الحامل لمنح الوصول إلى خدمة أو مورد. يطلب المتحقق المعلومات اللازمة من الحامل.

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

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

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

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

لفهم كيفية عمل الاعتمادات الرقمية، من المفيد تصور نموذج طبقي. تعالج كل طبقة جانبًا مختلفًا من النظام البيئي، من تنسيق البيانات نفسه إلى كيفية تقديمه للمستخدم في متصفح الويب. تركز هذه المقالة بشكل أساسي على واجهة برمجة تطبيقات الاعتماد الرقمي (Digital Credentials API)، التي تعمل في طبقة العرض.

المصطلحات الأساسية:

• الاعتماد الرقمي (Digital credential): أي اعتماد قابل للقراءة آليًا (PDF مع باركود، ISO mDL، W3C VC، SD-JWT، إلخ). كلمة "رقمي" لا تعني بالضرورة القابلية للتحقق التشفيري.
• الاعتماد القابل للتحقق (Verifiable Credential): نوع من الاعتمادات الرقمية، يُعرف بواسطة نموذج بيانات W3C VC. يضيف دليلاً على عدم التلاعب وإثباتًا تشفيريًا، ويعيش دائمًا في عالم ثلاثي الأطراف: مُصدر ← حامل ← متحقق.
• واجهة برمجة تطبيقات الاعتماد القابل للتحقق (VC API): واجهة خدمة REST/HTTP لإصدار وتخزين وتقديم والتحقق من VCs بين أنظمة الخلفية (المصدرين، المحافظ، المتحققين).
• واجهة برمجة تطبيقات الاعتمادات الرقمية (DC API): واجهة برمجة تطبيقات للمتصفح / نظام التشغيل (JavaScript + مكونات أصلية) تسمح لموقع الويب بأن يطلب من محفظة جهاز المستخدم تقديم أي اعتماد رقمي مدعوم (VC، ISO mDoc، SD-JWT ...) بطريقة تحترم الخصوصية.

فكر في VCs كنموذج بيانات، و VC API كمواصفات للأنظمة الخلفية (Back-end)، و DC API كواجهة أمامية (Front-end) تعرض الاعتمادات على الويب. كل شيء فوق الطبقة 1 (طبقة نموذج البيانات) هو محايد للتنسيق؛ كل شيء أدناه يعتمد على تنسيق الاعتماد.

التدفق من البداية للنهاية (مثال: التحقق من العمر عبر الإنترنت):

يوضح الرسم البياني التالي كيفية عمل هذه الطبقات معًا في سيناريو من العالم الحقيقي.

لاحظ كيف أن البيانات هي VC، والنقل على الويب هو DC API، وبروتوكول التبادل تحته هو OpenID4VP، والتحقق من جانب الخادم يستخدم VC API.

لماذا يوجد هذا التقسيم:

• نموذج بيانات قابل للتشغيل البيني (براهين تشفيرية، إفصاح انتقائي): تم حله بواسطة نموذج بيانات VC (وتنسيقات أخرى).
• نقاط نهاية REST قياسية لأنظمة الخلفية: تم حله بواسطة VC API.
• مصافحة (Handshake) بين المحفظة وموقع الويب تحافظ على الخصوصية: تم حله بواسطة DC API.
• مستويات ثقة / أنواع مستندات مختلفة (هوية حكومية مقابل شهادة دورة): تم حله باستخدام التنسيق الصحيح (ISO mDoc للهويات عالية الضمان؛ W3C VC للمطالبات العامة) تحت DC API.

النقاط الرئيسية:

1. "الاعتماد الرقمي" هو المصطلح الشامل.
2. الاعتماد القابل للتحقق هو نوع من الاعتمادات الرقمية مع قابلية تحقق تشفيرية مدمجة.
3. VC API هي البنية التحتية من خادم لخادم لعمليات دورة الحياة على VCs.
4. واجهة برمجة تطبيقات الاعتمادات الرقمية (DC API) هي الجسر بين المتصفح والمحفظة الذي يسمح أخيرًا لتلك الاعتمادات بالتدفق بسلاسة إلى تطبيقات الويب، مهما كان التنسيق الملموس الذي توجد به.
5. القطع الثلاث متكاملة، وليست متنافسة — فهي تقع في طبقات مختلفة من نفس المكدس وتمكن معًا هوية آمنة وتتمحور حول المستخدم على الويب المفتوح.

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

بصفتها المكون الحاسم في طبقة العرض، فإن واجهة برمجة تطبيقات الاعتماد الرقمي هي معيار ويب يتم تطويره حاليًا لتوفير طريقة آمنة وموحدة لمواقع الويب لطلب واستلام معلومات الهوية الرقمية من محافظ المستخدمين الرقمية. يقع هذا الجهد بشكل أساسي ضمن مجموعة عمل الهوية الموحدة في W3C (FedID WG)، بعد الانتقال من مجموعة مجتمع FedID في أبريل 2025. يمكن العثور على مسودة المواصفات الرسمية هنا: https://w3c-fedid.github.io/digital-credentials/.

اعتبارًا من أكتوبر 2025، تم شحن الواجهة في إصدارات مستقرة من كل من Chrome 141 (30 سبتمبر 2025) و Safari 26 (15 سبتمبر 2025). يدعم تنفيذ Chrome كلاً من OpenID4VP و ISO 18013-7 Annex C، بينما يدعم Safari حصريًا بروتوكول org-iso-mdoc.

هام (تحديث مارس 2026): لقد تغيرت علاقة واجهة برمجة التطبيقات بالبروتوكولات بشكل جذري. في مؤتمر TPAC في نوفمبر 2025، توصلت مجموعة عمل W3C FedID إلى إجماع لإلغاء سجل البروتوكول المفتوح وبدلاً من ذلك تضمين قائمة محدودة من البروتوكولات المدعومة بشكل ثابت مباشرة في المواصفات: openid4vp-v1-unsigned، openid4vp-v1-signed، openid4vp-v1-multisigned، org-iso-mdoc (للعرض)، و openid4vci-v1 (للإصدار). من المتوقع أن ترفض وكلاء المستخدم (المتصفحات) البروتوكولات غير المدرجة. هذا يجعل مجموعة العمل حارس بوابة فعلي لإضافات البروتوكولات المستقبلية — وهي مقايضة متعمدة لتمكين مراجعة شاملة للأمن والخصوصية لكل ما يتدفق عبر الواجهة (انظر مسودة العمل الحالية).

تغطي المواصفات الآن أيضًا إصدار الاعتمادات عبر navigator.credentials.create(). أطلق Chrome 143 تجربة أصل لهذا الغرض، مما يسمح لمواقع الويب بتشغيل تدفقات تزويد المحفظة باستخدام OpenID4VCI. ومع ذلك، لا تزال ثغرة ربط اختيار المحفظة — حيث يمكن لتطبيق محفظة ضار اعتراض رموز التفويض المسبق للإصدار — مصدر قلق مفتوح. أشارت الجهات الحكومية المصدرة إلى أنها لن تعتمد الإصدار عبر المتصفح حتى يتم حل هذه المشكلة.

يدعم Chrome العرض بشكل أصلي على Android من خلال نظام مدير الاعتماد الخاص به، ويدعم أيضًا واجهة برمجة تطبيقات الاعتماد الرقمي عبر الأجهزة على سطح المكتب عبر قناة مدعومة بـ CTAP/BLE لتسليم رمز الاستجابة السريعة (QR handoff).

تعمل واجهة برمجة التطبيقات على توسيع واجهة برمجة تطبيقات إدارة الاعتماد الحالية من خلال تمكين طلبات الاعتمادات الرقمية عبر navigator.credentials.get(). وفقًا لشارح الاعتمادات الرقمية لمجموعة عمل W3C FedID (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md)، عادت الواجهة لاستخدام هذه الواجهة المؤسسة بدلاً من navigator.identity المقترحة سابقًا. يطلب موقع الويب اعتمادًا رقميًا عن طريق استدعاء navigator.credentials.get() بمعلمات محددة للاعتمادات الرقمية.

فيما يلي مثال توضيحي لكيفية قيام موقع ويب باستدعاء الواجهة لطلب اعتماد باستخدام OpenID4VP:

async function requestCredential() {
    // التحقق من دعم واجهة برمجة تطبيقات الاعتماد الرقمي
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // عادةً ما يتم جلب هذه المعلمات من الخلفية.
            // محددة بشكل ثابت هنا لأغراض توضيح قابلية توسيع البروتوكول.
            const oid4vp = {
                protocol: "oid4vp", // مثال على طلب OpenID4VP للمحافظ. // بناءً على https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        // طلب Presentation Exchange، تم حذفه للإيجاز
                    },
                },
            };
 
            // إنشاء وحدة تحكم للإلغاء
            const controller = new AbortController();
 
            // استدعاء واجهة برمجة تطبيقات الاعتماد الرقمي باستخدام طلب العرض من الخلفية
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // إرسال الاستجابة المشفرة إلى الخلفية لفك التشفير والتحقق
            // تم الحذف للإيجاز
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // سيناريو احتياطي، توضيحي فقط
        alert("واجهة برمجة تطبيقات الاعتماد الرقمي غير مدعومة في هذا المتصفح.");
    }
}

هذا المثال مأخوذ من هنا.

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

تم تصميم واجهة برمجة تطبيقات الاعتماد الرقمي في الأصل لتكون محايدة تمامًا للبروتوكول، وتعمل كـ "ناقل مجرد" مع سجل مفتوح لأي بروتوكول للتسجيل. ومع ذلك، اعتبارًا من يناير 2026، تسمي المواصفات الآن صراحةً البروتوكولات التي تدعمها — ومن المتوقع أن يرفض وكلاء المستخدم تلك غير المدرجة. العائلتان الرئيسيتان للبروتوكولات المضمنة بشكل ثابت حاليًا في المواصفات هما: org.iso.mdoc (المشتقة من ISO 18013-5 وملحقها ISO 18013-7 "Annex C") ومواصفات مؤسسة OpenID لـ OpenID للعروض القابلة للتحقق (OpenID4VP) وإصدار الاعتماد القابل للتحقق (OpenID4VCI).

• الأصل والتوحيد القياسي: يشير org.iso.mdoc إلى تنسيق البيانات ونموذج التفاعل للمستندات المحمولة، وبشكل أساسي رخص القيادة المحمولة (mDLs)، التي وضعتها المنظمة الدولية للمعايير (ISO) واللجنة الكهروتقنية الدولية (IEC). المعيار الأساسي هو ISO/IEC 18013-5، الذي يحدد تطبيق mDL، وهيكل البيانات، وبروتوكولات التقديم الشخصي (عن قرب) باستخدام تقنيات مثل NFC أو Bluetooth أو رموز الاستجابة السريعة. يوسع ISO/IEC 18013-7 هذا لتمكين التقديم عبر الإنترنت/عن بعد لـ mDLs. تم تعريف سلسلة البروتوكول "org.iso.mdoc" تحديدًا في ISO/IEC TS 18013-7 (Annex C) للاستخدام مع واجهات برمجة التطبيقات مثل DC API.

• نموذج البيانات: تتمتع mdocs بهيكل بيانات محدد بصرامة يعتمد على CBOR (تمثيل الكائنات الثنائية الموجزة) من أجل الصغر والكفاءة. يحدد مساحات الأسماء وعناصر البيانات لسمات رخصة القيادة الشائعة ويدعم ميزات أمان تشفير قوية، بما في ذلك مصادقة المصدر، وربط الجهاز، ومصادقة الحامل (عبر الصورة)، وتشفير الجلسة، والإفصاح الانتقائي.

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

• الأصل والتوحيد القياسي: OpenID4VP (للعرض) و OpenID4VCI (للإصدار) هي مواصفات طورتها مؤسسة OpenID. وهي توسع OAuth 2.0 لدعم تبادل الاعتمادات القابلة للتحقق. هذه معايير مفتوحة تهدف إلى قابلية التشغيل البيني الواسعة لأنواع مختلفة من الاعتمادات، وليس فقط الحكومية. اعتبارًا من أوائل عام 2025، كانت OpenID4VP في مراحل مسودة متقدمة. OpenID4VCI تنضج أيضًا.
• نموذج البيانات: تم تصميم OpenID4VP/VCI لتكون محايدة لتنسيق الاعتماد. يمكنها حمل اعتمادات W3C القابلة للتحقق (VCs) بتنسيقات JSON/JSON-LD أو JWT، و mdocs، و SD-JWTs، وتنسيقات أخرى. يتضمن نموذج التفاعل طلب تفويض من المتحقق (RP) واستجابة من محفظة الحامل تحتوي على vp_token (رمز العرض القابل للتحقق). يُدار الإفصاح الانتقائي عادةً باستخدام لغات استعلام مثل Presentation Exchange (DIF PE) أو لغة استعلام الاعتمادات الرقمية الأحدث DCQL.
• حالات الاستخدام النموذجية: مجموعة واسعة من التطبيقات، بما في ذلك التحقق من الهوية، وتقديم دليل على المؤهلات (مثل الدبلومات التعليمية، والشهادات المهنية)، وتصديقات العضوية، والمزيد. وهي مناسبة تمامًا للتفاعلات عبر الإنترنت حيث تحتاج جهة معتمدة إلى التحقق من المطالبات من مصادر مختلفة.

من المهم أن ندرك أن هذه البروتوكولات ليست دائمًا حصرية بشكل متبادل. يمكن استخدام OpenID4VP، على سبيل المثال، لطلب ونقل [org.iso.mdoc]. غالبًا ما يعتمد الاختيار على حالة الاستخدام المحددة، ونوع الاعتماد، والمشاركين في النظام البيئي.

تعد محفظة الهوية الرقمية للاتحاد الأوروبي (EUDI) مبادرة كبرى تهدف إلى تزويد جميع مواطني ومقيمي الاتحاد الأوروبي بمحفظة رقمية آمنة لمستندات الهوية والتصديقات. تخطط البنية التحتية لمحفظة EUDI وإطار العمل المرجعي صراحةً لدعم كل من mdoc (خاصة لرخص القيادة المحمولة) و W3C Verifiable Credentials، باستخدام OpenID4VP و OpenID4VCI لتدفقات العرض والإصدار. يتضمن التنفيذ المرجعي دعمًا لـ OpenID4VP لنقل mDocs و OpenID4VCI لإصدار PIDs و mDLs بتنسيقات mDoc و SD-JWT-VC تنسيقات. يؤكد هذا الدعم المزدوج من قبل مشروع واسع النطاق كهذا على أهمية كلتا عائلتي البروتوكولات.

تحديث مارس 2026: أصبح التزام الاتحاد الأوروبي بواجهة برمجة تطبيقات الاعتماد الرقمي أكثر واقعية. يشترط موضوع F من إطار عمل البنية المرجعية (ARF) لـ EUDI الآن بشكل مشروط أن تدعم وحدات محفظة EUDI والجهات المعتمدة DC API للعرض عن بعد وتدفقات إصدار التصديق. تتضمن الشروط وصول DC API إلى حالة توصية W3C وتلبية التوقعات حول الوظائف وحيادية المتصفح/نظام التشغيل والخصوصية والحماية من رفض الخدمة. قام تحالف المحفظة الأوروبي (EWC) بدمج حالات اختبار DC API في برنامج اختبار المطابقة الخاص به، وأكمل تحالف NOBID تجريب المدفوعات باستخدام OpenID4VP — وهو نفس البروتوكول الذي تحمله DC API الآن.

ومع ذلك، فإن هذا الاتجاه لا يخلو من الانتقاد، حيث يلاحظ بعض المراقبين أن واجهة برمجة تطبيقات الاعتماد الرقمي، التي تأثرت بشدة بشركات "التكنولوجيا الأمريكية الكبرى"، قد تصبح مدمجة بعمق في المواصفات النهائية لمحفظة EUDI. أثيرت مخاوف بشأن التأثير المحتمل للكيانات غير التابعة للاتحاد الأوروبي على جزء مهم من البنية التحتية للاتحاد الأوروبي، كما نوقش في منتديات المجتمع مثل مناقشة GitHub هذه. بشكل منفصل، أثار قرار تضمين مرجع ISO 18013-7 بشكل ثابت في المواصفات اعتراضًا من Ping Identity، بحجة أن الإشارة المعيارية إلى مواصفات مدفوعة الأجر تتعارض مع مبادئ الويب المفتوح — وهو قلق قد يظهر كاعتراض رسمي عندما تنتقل المواصفات إلى توصية المرشح.

لقد تبلور مشهد المتصفح لواجهة برمجة تطبيقات الاعتماد الرقمي الآن، مع شحن Chrome 141 و Safari 26 لدعم مستقر في سبتمبر 2025. هناك اختلافات ملحوظة في النهج ومستويات الدعم عبر المتصفحات.

قام Chrome بشحن واجهة برمجة تطبيقات الاعتماد الرقمي في Chrome 141 (30 سبتمبر 2025). تنفيذ Chrome هو محايد للبروتوكول: متوافق مع OpenID4VP و ISO 18013-7 Annex C (mdoc عبر الإنترنت). يدعم سطح المكتب العرض عبر الأجهزة من محافظ الهواتف المحمولة عبر قناة مدعومة بـ CTAP/BLE (تسليم QR)، مع كون الاستجابة معتمة للمتصفح. انتقل شكل الواجهة إلى navigator.credentials.get()؛ تمت إعادة تسمية المعلمات: providers ← requests، request ← data.

اكتشاف الميزة:

if (typeof DigitalCredential !== "undefined") {
    // واجهة برمجة تطبيقات الاعتماد الرقمي مدعومة
}

يدعم مدير الاعتماد في Android بشكل أصلي OpenID4VP للعرض و OpenID4VCI للإصدار، مما يسمح لتطبيقات Android بالعمل كحاملي ومتحققين للاعتمادات باستخدام هذه المعايير. تلاحظ Google دعمًا متزايدًا للمحفظة؛ Google Wallet هي من أوائل المتبنين، مع الإعلان عن Samsung Wallet و 1Password.

في الإصدارات السابقة من هذه المقالة، توقعنا أن نهج Apple سيختلف عن Google من خلال التركيز على بروتوكول org.iso.mdoc. للسياق التاريخي، كان منطقنا كما يلي:

وكما توقعنا بشكل صحيح، أكد WWDC25 هذه الاستراتيجية. شحن Safari 26 (iOS/iPadOS/macOS) في 15 سبتمبر 2025 مع دعم واجهة برمجة تطبيقات الاعتماد الرقمي، مؤكدًا أن تنفيذهم يدعم حصريًا بروتوكول org-iso-mdoc للعرض.

تم تفصيل ذلك في جلسة WWDC25 بعنوان التحقق من مستندات الهوية على الويب. تسمح الواجهة لمواقع الويب بطلب معلومات يمكن التحقق منها من مستندات الهوية، مثل رخصة القيادة، المخزنة في Apple Wallet أو في تطبيقات مزودي المستندات التابعة لجهات خارجية.

النقاط الرئيسية من تنفيذ Apple:

• MDOC فقط: تستخدم الواجهة حصريًا سلسلة البروتوكول "org-iso-mdoc"، استنادًا إلى معيار ISO/IEC 18013-7 Annex C. لا يوجد دعم لـ OpenID4VP في تنفيذ Safari لواجهة برمجة تطبيقات الاعتماد الرقمي.
• للعرض فقط: الواجهة مخصصة لتقديم (التحقق من) الاعتمادات الحالية. يبقى الإصدار في Apple Wallet أو تطبيقات أخرى عملية منفصلة غير تابعة للمتصفح.
• تتمحور حول المستخدم وآمنة: يبدأ التدفق بإيماءة من المستخدم ويستفيد من آلية "طلب جزئي"، حيث يقوم نظام التشغيل أولاً بتحليل الطلب والتحقق منه في صندوق رمل (sandbox) قبل تمريره إلى تطبيق المحفظة، مما يعزز الأمان.
• قابلة للتوسيع للتطبيقات: بالإضافة إلى Apple Wallet، يمكن لتطبيقات الجهات الخارجية العمل كمزودي مستندات من خلال تنفيذ إطار عمل IdentityDocumentServices الجديد وامتداد للتطبيق.
• دعم عبر الأجهزة: يستخدم العرض عبر الأجهزة من المنصات غير التابعة لـ Apple بروتوكول CTAP للقرب بعد تسليم رمز الاستجابة السريعة؛ تظل استجابة JS مشفرة/معتمة للمتصفح.

قدمت Apple مثالًا واضحًا للرموز البرمجية لكيفية استخدام الجهة المعتمدة للواجهة:

async function verifyIdentity() {
    try {
        // يقوم الخادم بإنشاء وتوقيع بيانات الطلب بشكل مشفر.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // يحدد الطلب بروتوكول 'org-iso-mdoc'.
        const request = {
            protocol: "org-iso-mdoc",
            // تحتوي البيانات على طلب mdoc الموقع تشفيريًا.
            data,
        };
 
        // يجب استدعاء الواجهة من داخل إيماءة المستخدم.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // إرسال الاستجابة المشفرة من المحفظة إلى الخادم لفك التشفير والتحقق.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // عرض التفاصيل التي تم التحقق منها...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // معالجة الأخطاء، مثل إلغاء المستخدم.
    }
}

يرسخ هذا التأكيد الاستراتيجيات المتباينة في سوق المتصفحات. فبينما يبني Chrome على طبقة نقل OpenID4VP المرنة، تستفيد Apple من استثمارها العميق في نظام ISO mdoc البيئي لتوفير حل متكامل للغاية وآمن، وإن كان أقل مرونة، ومصمم خصيصًا لمستندات الهوية الرسمية.

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

تشمل المخاوف الرئيسية التي أثارتها Mozilla ما يلي:

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

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

تحديث مارس 2026 — التنفيذ جارٍ: على الرغم من بقاء الموقف الرسمي السلبي دون تغيير تقنيًا، بدأت Mozilla بتنفيذ نشط لواجهة برمجة تطبيقات الاعتماد الرقمي. في الربع الأول من عام 2026، وصل دعم DC API الأساسي إلى Firefox 149 (خلف علامة تفضيل)، ويتم تتبعه تحت meta bug 2004828. كود المصدر موجود في mozilla-central، بما في ذلك DigitalCredential.cpp، وربط WebIDL، ومكونات IPC. العمل على مطالبات الأذونات لسطح المكتب و Android (bug 2010091، bug 2010093) مستمر.

ثلاثة من مهندسي Mozilla — جون شانك، ومارتن طومسون، وبنجامين فاندر سلوت — هم أعضاء نشطون في مجموعة عمل W3C FedID، ويقدم شانك ملاحظات جوهرية مستنيرة بالتنفيذ على طلبات سحب المواصفات الرئيسية بما في ذلك خوارزمية تقديم الاعتماد وخوارزمية إعداد الطلب.

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

الجدول 1: دعم المتصفح لواجهة برمجة تطبيقات الاعتماد الرقمي والبروتوكولات (مارس 2026)

بالنسبة للمؤسسات (الجهات المعتمدة أو RPs) التي تنوي طلب الاعتمادات الرقمية والتحقق منها من المستخدمين، يتطلب المشهد الحالي تخطيطًا استراتيجيًا دقيقًا.

نظرًا لأن Safari (تم شحنه في 15 سبتمبر 2025) يدعم حصريًا تفاعلات org-iso-mdoc المباشرة (ISO 18013-7 Annex C) من خلال واجهة برمجة تطبيقات الاعتماد الرقمي، و Chrome (تم شحنه في 30 سبتمبر 2025) هو محايد للبروتوكول ويدعم كلاً من OpenID4VP و ISO 18013-7 Annex C (mdoc)، يجب على الجهات المعتمدة التي تهدف إلى أوسع نطاق ممكن الاستعداد لدعم التفاعلات بناءً على كلا النهجين.

هذا يعني هندسة أنظمة يمكنها التعامل مع كلا مساري البروتوكول، كما هو موضح أدناه.

بينما يضيف هذا تعقيدًا، فإن محاولة إجبار جميع المستخدمين على مسار بروتوكول واحد من المرجح أن يستبعد جزءًا كبيرًا من قاعدة المستخدمين، إما أولئك الذين يستخدمون iOS أو أولئك الذين يستخدمون Chrome/Android، اعتمادًا على المسار المختار. النهج العملي، وإن كان أكثر كثافة في التطوير، هو بناء المرونة للتعامل مع كليهما.

يجب أن تكون الجهات المعتمدة على دراية تامة بأنه حتى عند طلب نفس القطعة المنطقية من المعلومات (على سبيل المثال، "هل المستخدم فوق 21 عامًا؟")، فإن كيفية تعريف ذلك في الطلب وكيفية إرجاعه في الاستجابة يمكن أن تختلف بشكل كبير بين استعلام mdoc مباشر واستعلام OpenID4VP (الذي قد يستخدم Presentation Exchange أو DCQL).

• الإفصاح الانتقائي لـ mdoc: يحتوي org.iso.mdoc على آلياته الخاصة للإفصاح الانتقائي، والتي تتضمن عادةً قيام المصدر بإنشاء تجزئات مملحة لعناصر البيانات الفردية. تكشف محفظة الحامل بعد ذلك فقط العناصر المطلوبة مع أملاحها، مما يسمح للمتحقق بتأكيدها مقابل التجزئات دون رؤية بيانات أخرى. يرتبط طلب عناصر محددة بمساحات أسماء محددة مسبقًا ومعرفات عناصر البيانات داخل معيار mdoc.
• الإفصاح الانتقائي لـ OpenID4VP: يستخدم OpenID4VP عادةً لغة استعلام مثل Presentation Exchange (DIF PE) أو لغة استعلام الاعتمادات الرقمية الأحدث (DCQL) المضمنة في تعريف العرض التقديمي للطلب. يسمح هذا للجهات المعتمدة بتحديد أنواع الاعتماد والمطالبات الفردية التي يحتاجون إليها. تقوم المحفظة بعد ذلك ببناء عرض قابل للتحقق يحتوي فقط على المعلومات المطلوبة، إذا كان مدعومًا بتنسيق الاعتماد والمحفظة.

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

بالنسبة للكيانات التي تتطلع إلى إصدار اعتمادات رقمية وتوفير تطبيقات المحفظة للحاملي، تلعب بيئة نظام التشغيل دورًا حاسمًا.

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

• Android: يوفر بشكل عام نظامًا بيئيًا أكثر انفتاحًا. يتضمن مدير اعتماد Android واجهة برمجة تطبيقات للحامل (Holder API) تسمح لتطبيقات الجهات الخارجية الأصلية بالتسجيل كحاملي اعتمادات. يمكن لتطبيقات الحامل المسجلة هذه بعد ذلك المشاركة في تدفقات تقديم الاعتماد التي يتوسط فيها النظام، والاستجابة لطلبات واجهة برمجة تطبيقات الاعتماد الرقمي (عبر Chrome) أو المتحققين من التطبيقات الأصلية. يدعم Android أيضًا بشكل صريح OpenID4VCI لإصدار الاعتمادات، مما يسمح للمستخدمين باختيار محفظة متوافقة تابعة لجهة خارجية لتلقي الاعتمادات الصادرة حديثًا. بينما ينصب التركيز الأساسي للتطبيقات الأصلية على قدرات حامل الاعتماد الكاملة، تم تصميم النظام لمشاركة أوسع.

• iOS: تحافظ Apple على رقابة أكثر صرامة على نظامها البيئي. بينما يمكن أن توجد تطبيقات المحفظة التابعة لجهات خارجية على متجر التطبيقات، فإن قدرتها على الاندماج بعمق كحاملي اعتمادات على مستوى النظام للاعتمادات عالية الضمان (مثل mDLs المخصصة لـ Apple Wallet) تخضع غالبًا لعمليات واستحقاقات Apple المحددة. إضافة هوية إلى Apple Wallet، على سبيل المثال، هو تدفق خاضع للرقابة يتضمن سلطات الإصدار الحكومية وعملية التحقق الخاصة بـ Apple. بالنسبة لواجهة برمجة تطبيقات الاعتماد الرقمي في Safari، ستتم إدارة التفاعلات عن كثب على الأرجح، مع التركيز الأساسي على org.iso.mdoc المقدم من مصادر معتمدة، وهي Apple Wallet نفسها وتطبيقات مزودي المستندات المسجلة التابعة لجهات خارجية.

نهج "الحديقة المسورة" لشركة Apple راسخ، وتنفيذهم للاعتمادات الرقمية ليس استثناءً. ومع ذلك، أوضح WWDC25 المسار لمشاركة الجهات الخارجية.

بينما تعد Apple Wallet المزود الأساسي المدمج للاعتمادات مثل mDLs الحكومية، قدمت Apple إطار عمل IdentityDocumentServices لتطبيقات iOS الأصلية. يسمح هذا للمطورين الخارجيين ببناء تطبيقات يمكنها توفير وتقديم مستندات الهوية الخاصة بهم.

للمشاركة في تدفق الويب، يجب على التطبيق الأصلي:

1. تسجيل المستندات: استخدم IdentityDocumentProviderRegistrationStore لتسجيل mdocs التي يديرها التطبيق مع نظام التشغيل. يتضمن هذا التسجيل نوع المستند وسلطات الشهادات الموثوقة لتوقيع الطلب.
2. تنفيذ امتداد التطبيق: أضف امتداد واجهة مستخدم التطبيق "مزود مستند الهوية" إلى المشروع. هذا الامتداد مسؤول عن عرض واجهة المستخدم للتفويض للمستخدم عند اختيار التطبيق أثناء تدفق التحقق المستند إلى الويب.

يعني هذا أنه بينما يتطلب إنشاء محفظة متكاملة تمامًا على iOS بناء تطبيق أصلي واستخدام أطر عمل Apple المحددة — وليس تقنيات الويب مثل PWAs — هناك آلية واضحة، وإن كانت خاضعة لرقابة صارمة، لتطبيقات الجهات الخارجية للعمل كمزودي مستندات جنبًا إلى جنب مع Apple Wallet. يؤكد هذا أن التفاعل مع واجهة برمجة تطبيقات الاعتماد الرقمي في Safari يدار بواسطة نظام التشغيل، الذي يرسل بعد ذلك الطلبات إلى Apple Wallet أو أي تطبيق مزود مستندات آخر مسجل ومعتمد.

تمثل واجهة برمجة تطبيقات الاعتماد الرقمي تقدمًا كبيرًا في مجال الهوية الرقمية، حيث تقدم نهجًا أكثر أمانًا يتمحور حول المستخدم ويحافظ على الخصوصية للتحقق من الهوية وتقديم الاعتمادات. مع شحن Chrome 141 (30 سبتمبر 2025) و Safari 26 (15 سبتمبر 2025) لدعم عرض مستقر، و Firefox 149 الذي يحمل الآن كود التنفيذ الأساسي، فإن الواجهة في طريقها نحو تغطية ثلاثة متصفحات. سنبقي هذه المقالة محدثة مع تغير المشهد.

اتسمت الفترة منذ أكتوبر 2025 بنضج الواجهة من أنبوب تجريبي إلى معيار خاضع للحوكمة. إلغاء سجل البروتوكول المفتوح في TPAC (نوفمبر 2025) هو الإشارة الأكثر وضوحًا: تسمي مجموعة عمل W3C FedID الآن صراحة وتحكم البروتوكولات التي تدعمها الواجهة. يتيح هذا مراجعة شاملة للأمن والخصوصية ولكنه يجعل أيضًا مجموعة العمل حارس بوابة — وهي مقايضة متعمدة لا يشعر جميع المشاركين بالراحة تجاهها (لا سيما أن اعتراض ISO المدفوع من Ping Identity لا يزال دون حل).

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

على الصعيد التنظيمي، يشترط موضوع ARF F للاتحاد الأوروبي بشكل مشروط دعم DC API لجميع محافظ الدول الأعضاء في EUDI، في انتظار وصول المواصفات إلى توصية W3C. يتسارع التبني في العالم الحقيقي: أضافت إدارة المركبات في كاليفورنيا دعم DC API، ويتم تطوير مجموعات اختبار المطابقة بواسطة تحالف المحفظة الأوروبي.

التحديات لا تزال قائمة. واقع البروتوكول المزدوج (دعم Chrome متعدد البروتوكولات مقابل تركيز Safari على mdoc فقط) مستمر للجهات المعتمدة. مسألة ما إذا كان يجب على المتصفحات دعم جميع البروتوكولات المدرجة أم واحد فقط لم تحل — وهي مرتبطة مباشرة بقيود منصة Apple. وتظل اعتبارات الخصوصية أكبر فجوة تمنع التقدم نحو توصية المرشح، مع استمرار عدم كتابة المتطلبات المعيارية لمعايير تضمين البروتوكول. من المتوقع أن تكون المواصفات على بعد 1-2 سنوات من توصية W3C.

يستخدم Safari 26 حصريًا سلسلة بروتوكول org-iso-mdoc، بينما يدعم Chrome 141 كلاً من OpenID4VP و ISO 18013-7 Annex C. يجب على الجهات المعتمدة اكتشاف المتصفح وتوجيهه إلى مسار البروتوكول المناسب. يختلف الإفصاح الانتقائي أيضًا: يستخدم mdoc تجزئات مملحة على مساحات أسماء محددة مسبقًا، بينما يستخدم OpenID4VP لغات استعلام مثل Presentation Exchange أو DCQL.

أدرجت Mozilla كود DC API الأساسي في Firefox 149 (الربع الأول 2026) بينما ظل موقفها الرسمي السلبي تجاه المعايير دون تغيير تقنيًا. تختار Mozilla تشكيل الواجهة من الداخل بدلاً من التنازل عن التصميم لبائعي المتصفحات الآخرين. ثلاثة من مهندسي Mozilla هم أعضاء نشطون في مجموعة عمل W3C FedID ويقدمون ملاحظات مستنيرة بالتنفيذ على طلبات سحب المواصفات الرئيسية.

تسمح ثغرة ربط اختيار المحفظة لتطبيقات المحفظة الضارة باعتراض رموز التفويض المسبق للإصدار أثناء التدفقات التي يتم تشغيلها بواسطة navigator.credentials.create(). ذكرت الجهات الحكومية المصدرة أنها لن تعتمد الإصدار عبر المتصفح حتى يتم حل هذه المشكلة. أطلق Chrome 143 تجربة أصل للإصدار عبر OpenID4VCI، لكن الثغرة لا تزال مفتوحة اعتبارًا من أوائل عام 2026.

تتضمن شروط EUDI ARF Topic F وصول DC API إلى حالة توصية W3C وتلبية التوقعات حول الوظائف وحيادية المتصفح/نظام التشغيل والخصوصية والحماية من رفض الخدمة. قام تحالف المحفظة الأوروبي بدمج حالات اختبار DC API في برنامج اختبار المطابقة الخاص به. من المتوقع حاليًا أن تكون المواصفات على بعد 1 إلى 2 سنوات من توصية W3C.

قامت مجموعة عمل W3C FedID بتضمين خمسة معرفات بروتوكول بشكل ثابت: openid4vp-v1-unsigned و openid4vp-v1-signed و openid4vp-v1-multisigned و org-iso-mdoc للعرض، بالإضافة إلى openid4vci-v1 للإصدار. من المتوقع أن يرفض وكلاء المستخدم أي بروتوكول غير موجود في هذه القائمة. أثارت Ping Identity اعتراضًا رسميًا على تضمين ISO 18013-7، مشيرة إلى مخاوف بشأن الإشارة المعيارية إلى مواصفات مدفوعة الأجر.