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

آخر تحديث: 15 يوليو 2025 (بعد مؤتمر WWDC25)

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

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

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

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

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

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

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

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

Want to try digital credentials yourself in a demo?

Try Digital Credentials

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. "بيان اعتماد رقمي" هو المصطلح الشامل.
2. بيان اعتماد قابل للتحقق هو نوع من بيانات الاعتماد الرقمية مع قابلية تحقق مشفرة مدمجة.
3. VC API هو توصيلات من خادم إلى خادم لعمليات دورة حياة VCs.
4. واجهة برمجة تطبيقات بيانات الاعتماد الرقمية هي الجسر بين المتصفح و wallet الذي يسمح أخيرًا بتدفق بيانات الاعتماد هذه بسلاسة إلى تطبيقات الويب، بغض النظر عن التنسيق المحدد الذي تستخدمه.
5. الأجزاء الثلاثة متكاملة وليست متنافسة - فهي تقع في طبقات مختلفة من نفس المكدس وتمكّن معًا من هوية آمنة تتمحور حول المستخدم على الويب المفتوح.

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

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

اعتبارًا من عام 2025، لا تزال واجهة برمجة التطبيقات توصف بأنها تخضع لتغييرات كبيرة. وهذا يسلط الضوء على مرحلة تطويرها النشطة. على الرغم من ذلك، فإن إمكاناتها كبيرة. كان Chrome أول من أطلق شيئًا عامًا، من خلال تجربة Origin Trial الخاصة به، مما سمح للمطورين بتجربة قدراته. يدعم Chrome أيضًا هذا أصليًا على Android من خلال نظام Credential Manager الخاص به، وقد نشر مؤخرًا أيضًا دعمًا لاستخدام واجهة برمجة تطبيقات بيانات الاعتماد الرقمية عبر الأجهزة على سطح المكتب.

توسع واجهة برمجة التطبيقات واجهة برمجة تطبيقات إدارة بيانات الاعتماد الحالية من خلال تمكين طلبات بيانات الاعتماد الرقمية عبر navigator.credentials.get(). وفقًا لمشروع شرح بيانات الاعتماد الرقمية لمجموعة W3C FedID WG (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.");
    }
}

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

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

تم تصميم واجهة برمجة تطبيقات بيانات الاعتماد الرقمية لتكون محايدة من حيث البروتوكول، مما يعني أنها يمكن أن تدعم بروتوكولات أساسية مختلفة لتبادل بيانات الاعتماد. ومع ذلك، هناك عائلتان رئيسيتان من البروتوكولات محوريتان في التطبيقات والمناقشات الحالية: 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 (تمثيل الكائنات الثنائية المختصر) للاكتناز والكفاءة. يحدد مساحات الأسماء وعناصر البيانات لسمات رخصة القيادة الشائعة ويدعم ميزات الأمان المشفرة القوية، بما في ذلك مصادقة issuer، وربط الجهاز، ومصادقة الحامل (عبر الصورة الشخصية)، وتشفير الجلسة، والإفصاح الانتقائي.

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

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

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

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

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

كان Google Chrome، خاصة على Android، من أوائل المتبنين والمنفذين لواجهة برمجة تطبيقات بيانات الاعتماد الرقمية. لقد أجروا تجارب Origin Trials ودمجوها مع Credential Manager الأصلي في Android. يعتمد تطبيق Chrome بشكل أساسي على OpenID4VP كبروتوكول لطلب بيانات الاعتماد عبر استدعاء واجهة برمجة التطبيقات navigator.credentials.get(). في حين أن OpenID4VP نفسه محايد من حيث التنسيق ويمكنه حمل org.iso.mdoc أو بيانات اعتماد W3C القابلة للتحقق كحمولات، يبدو أن التركيز العملي من Google ينصب على تدفق OpenID4VP كآلية نقل. يدعم Credential Manager في Android أيضًا أصليًا OpenID4VP للتقديم و OpenID4VCI للإصدار. يسمح هذا لتطبيقات Android بالعمل كحاملي بيانات اعتماد ومحققين باستخدام هذه المعايير.

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

وكما توقعنا بشكل صحيح، أكد مؤتمر WWDC25 هذه الاستراتيجية. في المؤتمر، أعلنت Apple رسميًا عن دعم واجهة برمجة التطبيقات في Safari 26 (الذي سيصدر مع iOS 26 وتحديثات أنظمة التشغيل الأخرى في خريف 2025)، مؤكدة أن تطبيقها يدعم حصريًا بروتوكول org.iso.mdoc للتقديم.

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

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

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

قدمت 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: دعم المتصفحات لواجهة برمجة تطبيقات بيانات الاعتماد الرقمية والبروتوكولات

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

نظرًا لأن Safari، بحصته السوقية الكبيرة، من المرجح أن يعطي الأولوية لتفاعلات org.iso.mdoc المباشرة من خلال واجهة برمجة تطبيقات بيانات الاعتماد الرقمية، وأن Chrome/Android يركزان على OpenID4VP (الذي يمكن أن يحمل mdocs أو تنسيقات بيانات اعتماد قابلة للتحقق أخرى)، يجب على RPs التي تهدف إلى أوسع وصول ممكن الاستعداد لدعم التفاعلات القائمة على كلا النهجين.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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