واجهة برمجة التطبيقات الخاصة ببيانات الاعتماد الرقمية: هوية آمنة وخاصة على الويب

Natalia Markoborodova

José Luis Zapata

تاريخ النشر: 3 أكتوبر 2025

يسرّنا الإعلان عن أنّه تم تفعيل واجهة برمجة التطبيقات Digital Credentials API تلقائيًا بدءًا من الإصدار 141 من Chrome. بالإضافة إلى ذلك، يتيح الإصدار 26 من نظام التشغيل iOS استخدام واجهة برمجة التطبيقات Digital Credentials API في Chrome والمتصفّحات الأخرى. توفّر واجهة برمجة التطبيقات هذه مستوى جديدًا من الأمان والخصوصية لعمليات إثبات الهوية على الويب، ما يتيح للمواقع الإلكترونية طريقة موحّدة لطلب معلومات يمكن التحقّق منها من المستخدمين وتلقّيها.

بعد انتهاء التجربة الأصلية بنجاح، أصبحت واجهة برمجة التطبيقات Digital Credentials API تتيح الآن عرض المستندات على الجهاز نفسه على Android، بالإضافة إلى عرضها على أجهزة مختلفة من خلال متصفّح Chrome على الكمبيوتر.

الخلفية

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

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

إدراكًا لإمكانية استخدام بيانات الاعتماد الرقمية في تلبية متطلبات المستخدمين المتعلقة بالخصوصية واحتياجات المطوّرين للتحقّق من بيانات المستخدمين، طوّر منتدى معايير الويب في W3C حلاً، وهو واجهة برمجة التطبيقات Digital Credentials API. تهدف واجهة برمجة التطبيقات Digital Credentials API إلى حلّ هذه المشكلة من خلال توفير واجهة مدمجة للتحقّق من معلومات المستخدمين، ما يؤدي إلى تحسين مستوى الأمان والخصوصية وتجربة المستخدم مقارنةً بالبدائل الأخرى. باستخدام واجهة برمجة التطبيقات هذه، لن يحتاج المستخدمون بعد الآن إلى تحميل مستندات حساسة، مثل صور ممسوحة ضوئيًا لبطاقات التعريف، إلى مواقع إلكترونية متعددة. بدلاً من ذلك، يمكن للمواقع الإلكترونية أن تكسب ثقة المستخدمين من خلال طلب البيانات المحدّدة والموقّعة تشفيرًا التي تحتاج إليها فقط من جهات إصدار موثوقة.

الميزات الأساسية

تستند واجهة برمجة التطبيقات Digital Credentials API إلى ثلاثة مبادئ أساسية: الخصوصية، والتوافق مع عدّة منصات، والتوحيد.

الخصوصية

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

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

التوافق مع عدّة منصات

تهدف واجهة برمجة التطبيقات Digital Credentials API إلى توفير الدعم لمختلف المنصات، ما يتيح للمستخدمين عرض المعلومات التي تم التحقّق منها بسهولة على جميع الأجهزة.

على أجهزة Android: توفّر واجهة مستخدم مدمجة تتيح للمستخدمين اختيار بيانات الاعتماد من تطبيق المحفظة المثبَّت على أجهزتهم.

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

توحيد المقاييس

إمكانية التشغيل التفاعلي هي الأساس. في Chrome، لا تعتمد واجهة برمجة التطبيقات الخاصة ببيانات الاعتماد الرقمية على بروتوكول المنصة وهي متوافقة مع بروتوكولات العرض المختلفة، مثل OpenID4VP و الملحق C من معيار ISO 18013-7. أتاحت Apple أيضًا إمكانية استخدام واجهة برمجة التطبيقات Digital Credentials API من الإصدار 26.0 من Safari.

بالإضافة إلى ذلك، تستند واجهة برمجة التطبيقات Digital Credentials API إلى ميزة إدارة بيانات الاعتماد المضمّنة في Android وإلى منظومة متكاملة متنامية من المحافظ المتوافقة. تُعدّ "محفظة Google" من أوائل التطبيقات التي توفّر هذه الميزة، ومن المتوقّع أن تتيحها أيضًا Samsung Wallet و1Password قريبًا.

الميزات الجديدة منذ التجربة الأصلية

بالنسبة إلى المشاركين في التجربة الأصلية السابقة، سيلاحظون أنّ واجهة برمجة التطبيقات Digital Credentials API قد انتقلت من navigator.identity.get() إلى navigator.credentials.get()، ما يتماشى مع الجهود الأوسع نطاقًا لتوحيد الهوية باستخدام واجهة برمجة التطبيقات Credential Management API. بالإضافة إلى ذلك، تمت إعادة تسمية المَعلمة providers لتصبح requests، كما تمت إعادة تسمية request لتصبح data.

التنفيذ

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

رصد الميزات

قبل عرض الزر "التحقّق باستخدام المستند الرقمي"، تحقَّق مما إذا كانت واجهة برمجة التطبيقات Digital Credentials API متاحة في متصفّح المستخدم.

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

طلب بيانات اعتماد

يتضمّن طلب الحصول على بيانات اعتماد إجراء اتصال بـ navigator.credentials.get() مع المَعلمة digital. ضمن نوع بيانات الاعتماد الرقمية، أضِف مصفوفة requests تحتوي على DigitalCredentialGetRequest مع المَعلمات الأساسية التالية:

• protocol: حدِّد بروتوكول تبادل باستخدام سلسلة. على سبيل المثال،"openid4vp" أو "org-iso-mdoc". يمكنك رصد ما إذا كان المتصفّح يتيح استخدام البروتوكول باتّباع الخطوات التالية:

  if (DigitalCredential.userAgentAllowsProtocol("example-protocol")) {
      // Create a request with this protocol
    } else {
      // Protocol is not supported
  }
  

• ‫data: كائن يتضمّن المَعلمات التي تقبلها تطبيقات المحفظة الرقمية للبروتوكول المحدّد. تم تحديد مَعلمات "openid4vp" في OpenID for Verifiable Presentation (OID4VP) لمواصفات W3C Digital Credentials API.

  try {
    const digitalCredential = await navigator.credentials.get({
      digital: {
        requests: [{
          protocol: "openid4vp-v1-unsigned",
          data: {
            response_type: "vp_token",
        nonce: "[some-nonce]",
            client_metadata: {...},
        dcql_query: {...}
          }
      }]
      }
    });
  
    // Decrypt payload respons and verify credentials on the backend
    const response = await fetch("/verify", {
      method: "POST",
        body: JSON.stringify(digitalCredential.data),
        headers: {
            'Content-Type': 'application/json'
        }
    });
  } catch (e) {
    // Handle errors, such as the user canceling the request
    console.error(e);
  }
  

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

{
  protocol: 'openid4vp-v1-unsigned',
  data: {
    response_type: 'vp_token',
    nonce: '[some-nonce]',
    // Contains the Verifier metadata values, including supported credential formats and response encryption public key
    client_metadata: {
  // Supported credential formats. Refer to the documentation for specific values
        vp_formats_supported: {...},
   // Public key(s). Refer to the documentation for more detail.
        jwks: {...}
    },
    dcql_query: {
      // A wallet will try to find credentials it holds that match these definitions.
      credentials: [
        {
          // A locally unique identifier for this credential definition within the query.
          id: "cred_vc",
          format: "dc+sd-jwt",
          meta: {
            // 'vct_values' specifies the Verifiable Credential allowed type.
            // In this case, it's a European Digital Identity (EUDI) Personal Identification Data (PID) credential.
            vct_values: [
              "urn:eudi:pid:1"
            ]
          },
          // 'claims' is an array of specific data that's being requested.
          claims: [
            {
              // The path ["age_equal_or_over", "18"] corresponds to accessing `credential.age_equal_or_over['18']`.
              path: [
                "age_equal_or_over",
                "18"
              ]
            }
          ]
        }
      ]
    }
  }
}

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

في ما يلي مثال على حمولة الرد المشفرة الخاصة بكائن DigitalCredential:

{
    // This is an example for a response using an OpenID4VP protocol.
    // The format of the 'data' object will differ for other protocols.
    "protocol": "openid4vp-v1-unsigned",
    "data": {
        // To decrypt this JWE payload, use the private key.
   // The decrypted payload will be a JSON object containing the
       // Verifiable Presentation in the 'vp_token' claim.
        "response": "[jwe-token]"
    }
}

في هذا المثال، يطلب النظام بيانات الاعتماد باستخدام بروتوكول openid4vp-v1-unsigned، ويتضمّن الردّ response في السمة data.

تعتمد الطريقة الدقيقة لتحليل الردّ على البروتوكول. عليك عادةً إجراء ما يلي:

1. فك تشفير حمولة الردّ تعتمد طريقة فك التشفير على البروتوكول المستخدَم. يمكنك الاطّلاع على كيفية فك تشفير الحمولة لكل من openid4vp (باستخدام JWE) وorg-iso-mdoc (باستخدام Hybrid Public Key Encryption).
2. التحقّق من التواقيع والجهة المُصدرة لمزيد من التفاصيل، يُرجى الاطّلاع على مستندات قبول المستندات الرقمية على الإنترنت.

للاطّلاع على نماذج رموز لبروتوكولات مختلفة، يمكنك الاطّلاع على الرمز البرمجي للعرض التوضيحي أو النسخة المستضافة المباشرة.

التحقّق من موثوقية جهة الإصدار

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

البدء

هل أنت مستعد لبدء إنشاء الأدوات؟ إليك المعلومات التي يجب معرفتها.

• التوفّر: يتيح الإصدار 141 من Chrome أو الإصدارات الأحدث واجهة برمجة التطبيقات الخاصة ببيانات الاعتماد الرقمية تلقائيًا على جميع المنصات.
• المتطلبات الأساسية: يحتاج المستخدمون إلى جهاز متوافق، مثل جهاز Android يعمل بالإصدار 24.0 أو إصدار أحدث من خدمات Google Play، أو جهاز iOS يعمل بالإصدار 26 أو إصدار أحدث. يجب أن يتضمّن الجهاز تطبيق محفظة رقمية مثبّتًا يتوافق مع واجهة برمجة التطبيقات الخاصة بمستندات التعريف الرقمية، مثل "محفظة Google" أو محفظة تجريبية.
• تجربة العرض التوضيحي: أفضل طريقة لفهم تجربة المستخدم واختبار عملية التنفيذ هي تجربة العرض التوضيحي المباشر على https://verifier.multipaz.org باستخدام الإصدار 141 من Chrome أو إصدار أحدث.

الموارد

لمزيد من المعلومات، يُرجى الاطّلاع على المراجع التالية:

• دليل المطوّرين: واجهة برمجة التطبيقات Digital Credentials API
• المواصفات: مستندات التعريف الرقمية من W3C
• التوافق مع Android: التوافق مع Android بشأن المستندات الرقمية

مشاركة ملاحظاتك

بعد إطلاق واجهة برمجة التطبيقات Digital Credentials API، يهمّنا معرفة رأيك بشأن تجربتك في استخدامها. قدِّم بلاغًا لمشاركة ملاحظاتك أو الإبلاغ عن أي أخطاء.