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

آخر تحديث: 30 أكتوبر 2025

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

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

Want to experience digital credentials in action?

Try Digital Credentials

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

• تم الإطلاق: Chrome 141 (30 سبتمبر 2025) و Safari 26 (15 سبتمبر 2025).
• Chrome: محايد للبروتوكول (OpenID4VP و ISO 18013-7 الملحق C)، عبر الأجهزة لسطح المكتب باستخدام CTAP.
• Safari: mdoc-فقط (org-iso-mdoc)، تدفق عبر الأجهزة باستخدام CTAP.
• شكل الواجهة: navigator.credentials.get()؛ تسمية requests/data؛ اكتشاف ميزة DigitalCredential.

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

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

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

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

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

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

Want to experience digital credentials in action?

Try Digital Credentials

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

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

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

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

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

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

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

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

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

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

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

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

1. الإصدار (VC API - المصدر ↔ المحفظة): تصدر إدارة المركبات في الولاية اعتمادًا قابلاً للتحقق يقول "الحامل فوق 18 عامًا".
2. التخزين (تطبيق المحفظة - نظام التشغيل): يبقى الاعتماد في محفظة المستخدم مع إثباته المشفر.
3. الطلب (navigator.credentials.get() عبر DC API - موقع الويب ← المتصفح): يطلب موقع متجر المشروبات: "أرني دليلاً على أن عمر المستخدم ≥ 18".
4. التقديم (DC API يرسل إلى المحفظة ← OpenID4VP (بروتوكول) ← حمولة VC): تعرض المحفظة واجهة مستخدم للموافقة، يوافق المستخدم، وترسل المحفظة عرضًا قابلاً للتحقق مرة أخرى.
5. التحقق (VC API - الواجهة الخلفية لمتجر المشروبات): تتحقق الواجهة الخلفية للموقع من التوقيع و DID/المفتاح العام لـ المصدر؛ وتمنح الوصول.

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

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

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

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

1. "الاعتماد الرقمي" هو المصطلح الشامل.
2. الاعتماد القابل للتحقق هو نوع من الاعتماد الرقمي مع إمكانية تحقق مشفرة مدمجة.
3. VC API هو توصيلات بين الخوادم لعمليات دورة حياة VCs.
4. واجهة برمجة تطبيقات الاعتماد الرقمي هي الجسر بين المتصفح والمحفظة الذي يسمح أخيرًا بتدفق تلك الاعتمادات بسلاسة إلى تطبيقات الويب، بغض النظر عن التنسيق المحدد الذي هي فيه.
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 الملحق C، بينما يدعم Safari حصريًا بروتوكول org-iso-mdoc. يدعم Chrome هذا أصليًا على Android من خلال نظام Credential Manager ويدعم أيضًا واجهة برمجة تطبيقات الاعتماد الرقمي عبر الأجهزة على سطح المكتب عبر تسليم QR المدعوم بـ CTAP/BLE.

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

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

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

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

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

تم تصميم واجهة برمجة تطبيقات الاعتماد الرقمي لتكون محايدة للبروتوكول، مما يعني أنها يمكن أن تدعم بروتوكولات أساسية مختلفة لتبادل الاعتمادات. ومع ذلك، هناك عائلتان رئيسيتان من البروتوكولات محوريتان للتطبيقات والمناقشات الحالية: org.iso.mdoc (المشتق من ISO 18013-5 وامتداده ISO 18013-7 "الملحق C") ومواصفات مؤسسة OpenID لـ OpenID for Verifiable Presentations (OpenID4VP) و OpenID for Verifiable Credential Issuance (OpenID4VCI).

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

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

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

• الأصل والتوحيد القياسي: OpenID4VP (للعرض) و OpenID4VCI (للإصدار) هما مواصفتان طورتهما مؤسسة OpenID. إنهما يوسعان OAuth 2.0 لدعم تبادل الاعتمادات القابلة للتحقق. هذه معايير مفتوحة تهدف إلى قابلية التشغيل البيني الواسعة لأنواع مختلفة من الاعتمادات، وليس فقط الحكومية. اعتبارًا من أوائل عام 2025، كان OpenID4VP في مراحل مسودة متقدمة (على سبيل المثال، المسودة 28 اعتبارًا من أبريل). 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، باستخدام OpenID4VP و OpenID4VCI لتدفقات العرض والإصدار. يتضمن التنفيذ المرجعي دعمًا لـ OpenID4VP لنقل mDocs و OpenID4VCI لإصدار PIDs و mDLs بتنسيقات mDoc و SD-JWT-VC formats. يؤكد هذا الدعم المزدوج من قبل مشروع بهذا الحجم الكبير على أهمية كلتا عائلتي البروتوكولات. ومع ذلك، لا يخلو هذا الاتجاه من النقد، حيث يلاحظ بعض المراقبين أن واجهة برمجة تطبيقات الاعتماد الرقمي، المتأثرة بشدة بشركات "التكنولوجيا الأمريكية الكبرى"، قد تصبح مدمجة بعمق في مواصفات محفظة EUDI النهائية. أثيرت مخاوف بشأن التأثير المحتمل للكيانات غير الأوروبية على جزء حاسم من البنية التحتية للاتحاد الأوروبي، كما نوقش في منتديات المجتمع مثل هذه المناقشة على GitHub.

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

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

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

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

يدعم Credential Manager في 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 الملحق C. لا يوجد دعم لـ OpenID4VP في تطبيق Safari لواجهة برمجة تطبيقات الاعتماد الرقمي.
• العرض فقط: الواجهة مخصصة لعرض (التحقق من) الاعتمادات الموجودة. يظل الإصدار في Apple Wallet أو تطبيقات أخرى عملية منفصلة غير مرتبطة بالمتصفح.
• متمحور حول المستخدم وآمن: يبدأ التدفق بإيماءة من المستخدم ويستفيد من آلية "الطلب الجزئي"، حيث يقوم نظام التشغيل أولاً بتحليل الطلب والتحقق من صحته في بيئة معزولة (sandbox) قبل تمريره إلى تطبيق المحفظة، مما يعزز الأمان.
• قابل للتوسيع إلى التطبيقات: بالإضافة إلى Apple Wallet، يمكن للتطبيقات التابعة لجهات خارجية أن تعمل كموفري مستندات من خلال تطبيق إطار العمل الجديد IdentityDocumentServices وامتداد تطبيق.
• دعم عبر الأجهزة: يستخدم العرض عبر الأجهزة من المنصات غير التابعة لـ Apple بروتوكول CTAP للقرب بعد تسليم رمز QR؛ تظل استجابة JS مشفرة/مبهمة للمتصفح.

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

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

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

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

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

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

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

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

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

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

وهذا يعني تصميم أنظمة يمكنها:

1. بدء طلبات الاعتماد عبر واجهة navigator.credentials.get()، مع تحديد معلمات بروتوكول مختلفة ("org-iso-mdoc" لـ Safari أو "openid4vp" لـ Chrome/تدفقات OID4VP) بناءً على اكتشاف المتصفح أو قدرات وكيل المستخدم.
2. معالجة الاستجابات التي قد تأتي مباشرة بتنسيق mdoc (ISO 18013-7 الملحق C) أو كـ vp_token عبر OpenID4VP، والتي تحتاج بعد ذلك إلى تحليل لاستخراج الاعتماد الأساسي (والذي يمكن أن يكون هو نفسه mdoc أو تنسيق VC آخر).

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

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

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

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

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

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

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

• iOS: تحافظ Apple على سيطرة أكثر إحكامًا على نظامها البيئي. بينما يمكن أن توجد تطبيقات المحافظ التابعة لجهات خارجية على App Store، فإن قدرتها على التكامل العميق كحاملي اعتمادات على مستوى النظام للاعتمادات عالية الضمان (مثل 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. تنفيذ امتداد تطبيق: إضافة امتداد تطبيق واجهة المستخدم "Identity Document Provider" إلى المشروع. هذا الامتداد مسؤول عن عرض واجهة مستخدم التفويض للمستخدم عند تحديد التطبيق أثناء تدفق التحقق القائم على الويب.

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

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

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