تقدّم هذه الصفحة إجابات عن الأسئلة الشائعة حول التكامل مع "محفظة Google" لإدارة الهوية الرقمية وبيانات الاعتماد.
الإعداد والبدء
س: ما هي الخطوات التي يجب أن يتّبعها الشريك الجديد للانضمام كـ "جهة معتمِدة"؟
ج: اتّبِع الدليل المفصّل على الرابط: اختيار المسار المناسب.
س: ما هي المدة المعتادة لعملية إعداد الجهة المعتمِدة؟
ج: تستغرق عملية الإعداد عادةً من 3 إلى 5 أيام عمل.
س: كيف يمكننا تتبُّع حالة طلب "الجهة المعتمدة" (RP) بعد إرساله؟
ج: إذا لم يصلك ردّ بعد 5 أيام، يُرجى التواصل مع فريق الدعم على wallet-identity-rp-support@google.com.
س: أين يمكننا العثور على نموذج إعداد الجهة المعتمدة ومستندات المطوّرين الرسمية؟
ج:
- نموذج الإعداد: نموذج التواصل مع الشركاء الذين يعتمدون على "محفظة Google" لإثبات الهوية
- مستندات المطوّرين: نظرة عامة على الهوية الرقمية
س: كيف سيتم استخدام المعلومات التي نقدّمها (مثل اسم المنتج وشعاره) في تجربة المنتج؟
ج: يتم عرض اسم المنتج وشعاره على شاشة طلب الموافقة الموجّهة للمستخدمين لمساعدتهم في تحديد "الجهة المعتمِدة" التي تطلب مستند التعريف الرقمي الخاص بهم. قد تظهر أيضًا عناوين URL وروابط السياسات في تجربة المنتج.
س: هل علينا التوقيع على بنود الخدمة إذا كنّا نخطّط لاستخدام بيئة وضع الحماية لأغراض التطوير والاختبار فقط؟
ج: لا، قبول بنود الخدمة ليس خطوة مطلوبة للاختبار.
س: أين يمكننا العثور على نموذج مرجعي أو رمز نموذجي أو تطبيق تجريبي للبدء؟
ج:
- مستودع GitHub: Identity Reference Implementation.
- الموقع الإلكتروني التجريبي: verifier.multipaz.org
جهات التسجيل المسؤولة عن التحقّق
س: ما هي "جهة تسجيل جهات التحقّق" وكيف تعمل؟
ج: يعمل "سجلّ أداة التحقّق" كـ "هيئة إصدار الشهادات" التي تُعدّ عملاء المصب (الجهات المعتمِدة النهائية). لا تتفاعل الجهة المعتمدة النهائية مباشرةً مع "محفظة Google".
س: ما هي عملية الإعداد المحدّدة لـ "مسجّل جهات التحقّق" وعملائه النهائيين؟
ج: يُرجى الرجوع إلى الخطوات الواردة في: دليل جهة التحقّق من التسجيل.
س: ما هي أوجه الاختلاف بين هذه الميزة والدمج المباشر مع الجهة المعتمِدة؟
ج: تدير جهات التسجيل المسؤولة عن التحقّق علاقة الثقة لعملائها وتتولّى عملية الدمج مع "محفظة Google" نيابةً عنهم، بينما تدير الجهات الموثوقة المباشرة إعداداتها الخاصة مع Google.
س: في "أداة تسجيل جهات التحقّق"، مَن الذي تتم إضافته إلى القائمة المسموح بها في إعدادات Google: "أداة تسجيل جهات التحقّق" أم "الجهة المعتمدة" النهائية أم كلاهما؟
ج: تضع Google شهادة CA الجذر الخاصة بجهة التسجيل المسؤولة عن التحقّق في القائمة المسموح بها. بعد ذلك، يُصدر "أمين سجلّ جهة التحقّق" شهادات غير مخوّلة للتصديق جديدة لكل "جهة مستفيدة نهائية" تابعة.
س: كيف تتدفق البيانات بين الجهة الموثوقة النهائية ومسؤول تسجيل جهات التحقّق و"محفظة Google"؟
ج: يرسل "مسجّل جهات التحقّق" طلب البيانات من واجهة برمجة التطبيقات إلى "محفظة Google" نيابةً عن "الجهة المعتمدة النهائية". تعيد "محفظة Google" بيانات الاعتماد المشفّرة إلى "مسجّل جهة التحقّق" الذي يعالجها بعد ذلك ويرسل الإشارة النهائية إلى "الجهة المعتمدة النهائية".
س: بالنسبة إلى الحلول التي تحمل علامة بيضاء، هل يجب عرض اسم "أمين سجلّ جهات التحقّق" في مسار موافقة المستخدم، أم يمكن أن يكون اسم "الجهة المعتمدة" النهائية فقط؟
ج: لا، يمكن لمسجّل جهة التحقّق اختيار عدم عرض تفاصيله.
س: ما هي أنواع المفاتيح والمنحنيات المسموح بها لمراجع التصديق الجذرية وشهادات الجهات المعتمِدة؟
ج: يجب إنشاء الشهادات باستخدام P-256 / ECDSA.
س: هل يمكننا استخدام شهادات الموقِّع الوسيطة بين شهادات CA الجذر وشهادات RP غير المخوّلة للتصديق؟
ج: نعم. يمكنك تخزين شهادة جذر طويلة الأجل بشكل آمن (على سبيل المثال، في وحدة HSM) لتوقيع الشهادات الوسيطة التشغيلية بشكل غير متكرر. ويمكن بعد ذلك استخدام هذه الشهادات الوسيطة لتوقيع الشهادات غير المخوّلة للتصديق الخاصة بالجهات المعتمِدة النهائية، ما يتيح تدويرها بسهولة في حال حدوث اختراق بدون التأثير في شهادة الجذر.
س: ما هي مدة الصلاحية المطلوبة للشهادات؟
ج: إنّ مدة الصلاحية التي تبلغ 10 سنوات مقبولة تمامًا لشهادة مرجع تصديق جذر. يجب أن تتّبع الشهادات غير المخوّلة للتصديق الخاصة بالطرف المعتمِد النهائي بشكل عام جدولاً زمنيًا للتجديد مدته عام واحد تقريبًا لضمان إمكانية تدويرها بكفاءة في حال حدوث مشاكل.
س: هل نحتاج إلى إدارة شهادة غير مخوّلة للتصديق منفصلة لكل عميل من عملاء "الجهة المعتمِدة" (RP)؟
ج: نعم. خلال فترة الإطلاق الأولية، على مجمّعي البيانات إدارة شهادات منفصلة لكل جهة معتمِدة تابعة. يتيح ذلك إعدادات العرض لكل جهة اعتماد وتتبُّع إساءة الاستخدام بدقة. ومع أنّ ذلك يضيف أعباء تشغيلية على نطاق واسع، ننوي إعادة النظر في البدائل المحتملة (مثل استخدام تجزئات البيانات الوصفية للطرف المعتمِد) بعد الطرح الأولي.
س: هل يُسمح للشركاء بالحصول على شهادات نشطة متعددة في الوقت نفسه؟
ج: نعم، تتيح الإعدادات استخدام أي عدد من الشهادات النشطة لكل جهة موثوقة أو مجمِّع، وهو أمر مفيد للشركاء الذين يعملون بأسماء تجارية مختلفة.
س: كيف يجب تنسيق الاسم المميّز (الموضوع)؟
ج: يجب أن يكون الاسم المميّز فريدًا على مستوى العالم لكل شريك. ويُعدّ هذا المعرّف ثابتًا تستخدمه Google لمراقبة طلبات الشركاء الواردة وضمان الثقة في المنظومة المتكاملة.
س: كيف يعمل ربط النطاق؟ هل يجب تضمين المصادر في الشهادة؟
ج: ليس من الضروري تضمين النطاقات مباشرةً في الشهادة نفسها. بدلاً من ذلك، يتم التحقّق من النطاق باستخدام مَعلمة المصادر المتوقّعة ضمن طلب البيانات من واجهة برمجة التطبيقات. بالإضافة إلى ذلك، يمكن ربط نطاقات متعددة بشهادة واحدة بسلاسة. بالنسبة إلى الطلبات غير الموقَّعة، يتم تنفيذ عملية الربط باستخدام اسم النطاق أو حزمة التطبيق مع بصمة الإصبع.
س: هل يمكن حذف تفاصيل مجمّع الخدمات من واجهة المستخدم الخاصة بعملية التحقّق من المعلِن في تجربة العلامة البيضاء؟
ج: نعم، معلومات مجمّع البيانات (مثل الاسم والشعار وعنوان URL وسياسة الخصوصية) اختيارية تمامًا ضمن البيانات الوصفية لجهة التحقّق. يتيح ذلك استخدام حلّ يحمل علامة تجارية بيضاء بالكامل، حيث يتم عرض تفاصيل الجهة المعتمدة النهائية فقط للمستخدم.
س: ما الذي يجب تقديمه لبدء الاختبار في بيئة وضع الحماية؟
ج: من الناحية الفنية، ما عليك سوى تقديم شهادة الجذر في وضع الحماية. تم تصميم بيئة الاختبار لتعكس بيئة التشغيل الفعلي بشكل مماثل.
س: كيف تختلف عملية الإعداد لجهات تسجيل جهات التحقّق (مجمّعي البيانات) مقارنةً بالجهات الموثوقة المباشرة؟
ج: تخضع منصات التجميع لعملية معدَّلة قليلاً. بعد تنفيذ بنود الخدمة المحدّدة لـ "مسجّل جهات التحقّق"، يتم تقسيم عملية التسجيل إلى جزأين: نموذج أساسي لتحديد حالتك كـ "مسجّل جهات التحقّق"، يليه نموذج مبسّط مطلوب لكل "جهة موثوق بها" فردية يتم تسجيلها. يتطلّب كل طلب عادةً تسجيل فيديو لعملية الدمج، وتستغرق عملية المراجعة بشكل عام من يومَين إلى 3 أيام عمل.
س: هل يمكننا ضمّ العملاء الذين ينوون العمل كوسطاء أو إعادة بيع خدمات التحقّق لجهات أخرى؟
ج: لا، فالنموذج الحالي الذي تفضّله Google هو العمل مباشرةً مع جهات تسجيل جهات التحقّق (مجمّعي البيانات) والجهات المعتمدة النهائية المباشرة، بدلاً من التعامل مع نماذج المورّدين أو الوسطاء المتداخلة.
الدمج الفني وواجهة برمجة التطبيقات
س: ما هو البروتوكول الأساسي للطلبات؟ ما هي الإصدارات المتوافقة؟
ج: البروتوكول الأساسي هو OpenID for Verifiable Presentations (OpenID4VP) الإصدار 1.0.
س: ما هي ملاحق ISO 18013-7 (مثل الملحق "ب" و"ج" و"د") التي يتيحها فريق الدعم في Google لعرض رخصة القيادة على الأجهزة الجوّالة؟
ج: تتيح Google استخدام الملحق "د" [حاليًا في مرحلة المسودة] (OpenID4VP باستخدام واجهة برمجة التطبيقات DC API).
س: كيف يمكننا تنظيم طلب بيانات من واجهة برمجة التطبيقات بشكل صحيح لطلب بيانات اعتماد متعددة في عرض تقديمي واحد للمستخدم؟
ج: يجب طلب كلا نوعَي بيانات الاعتماد ضمن عنصر طلب بحث dcql واحد في طلب JSON نفسه.
س: هل تسمح واجهة برمجة التطبيقات بطلب بيانات اعتماد عامة بدون إدراج كل نوع ممكن من بيانات الاعتماد؟
ج: لا.
س: كيف تتعامل واجهة برمجة التطبيقات مع عملية التحقّق من العمر؟ هل يمكننا طلب تاريخ الميلاد الدقيق، أم فقط إشارة "أكبر من X"؟
ج: كلاهما متاح. يمكنك طلب birth_date أو age_in_years أو إشارة "أكبر من X" تحافظ على الخصوصية. يمكن أيضًا استخدام "براهين المعرفة الصفرية" (ZKP) لإرسال إشارة صحيحة أو خاطئة.
س: ما هي متطلبات البنية الأساسية للمفاتيح العامة (PKI)؟
ج: تحتاج الجهات المعتمِدة إلى بنية أساسية للمفاتيح العامة (PKI) لتوقيع الطلبات. تعمل جهات التسجيل المسؤولة عن التحقّق كمرجع تصديق خاص بها.
س: هل يمكننا استخدام شهاداتنا الحالية أم نحتاج إلى الحصول على شهادة جديدة موقَّعة من Google؟
ج: تحتاج الجهات الموثوقة إلى شهادة جديدة موقَّعة من Google أو من جهة تسجيل التحقّق. بالنسبة إلى جهات التسجيل التي تتحقّق من الهوية، ستثق Google في شهادة الجذر إذا اتّبعت خطوات "إنشاء الثقة" الواردة في المستندات.
س: ما هي استراتيجية الدمج المقترَحة للويب مقابل تطبيق Android؟
ج: يجب إنشاء الطلب بالكامل من جهة الخادم. على أجهزة Android، استخدِم واجهة برمجة التطبيقات Credman API، وعلى الويب، استخدِم واجهة برمجة التطبيقات Digital Credentials (DC) API.
س: ما هي أدوات تصحيح الأخطاء والتسجيل وإمكانية تتبّع البيانات المتاحة للمطوّرين؟
ج: يمكن للشركاء استخدام عنوان البريد الإلكتروني البديل للدعم wallet-identity-rp-support@google.com. لا يتم توفير أي أدوات تسجيل أو إمكانية تتبّع بيانات محدّدة.
بيانات الاعتماد والبيانات
س: ما هي مستندات التعريف الرقمية وجهات إصدارها وبيانات الاعتماد المتوافقة حسب البلد والمنطقة؟
ج: يمكنك الاطّلاع على المناطق المعتمدة هنا: جهات الإصدار والشهادات المعتمدة.
س: متى سيتم توفير بيانات الاعتماد من بلدان أو مناطق جديدة؟
ج: نحن نعمل باستمرار على إضافة مناطق جديدة، لذا يُرجى مراجعة صفحة جهات الإصدار المعتمَدة للاطّلاع على آخر المعلومات.
س: هل يتلقّى المستخدم النهائي إشعارًا عندما تعدّل جهة الإصدار بيانات الاعتماد؟
ج: نعم، يتم إشعار المستخدم ويتم تطبيق التحديث تلقائيًا.
الاختبار والبيئات
س: كيف يمكننا الوصول إلى بيئة وضع الحماية لاختبار العملية الكاملة؟
ج: يتوفّر وضع الحماية على الرابط: وضع الحماية.
س: ما هي الإجراءات التي يجب أن يتّبعها الشركاء غير المقيمين في منطقة تم إطلاق الميزة فيها رسميًا لإضافتهم إلى القائمة المسموح بها من أجل إجراء الاختبارات؟
ج: أرسِل رسالة إلكترونية تتضمّن معرّفات Gmail للمحافظ التجريبية إلى wallet-identity-rp-support@google.com.
س: ما هي عملية تفعيل موقع إلكتروني أو تطبيق تجريبي لأغراض العرض التوضيحي، ما يسمح لأي شخص لديه بيانات اعتماد إنتاج بتقديمه؟
ج: على الشركاء إكمال عملية الإعداد العادية لبرنامج RP، بما في ذلك عرض فيديو توضيحي في وضع الحماية.
تجربة المستخدم (UX)
س: ما هي تجربة المستخدم إذا لم يكن لديه مستند تعريف رقمي أو لم يكن تطبيق "محفظة Google" مثبّتًا على جهازه عند بدء عملية إثبات الهوية؟
ج: يتم توجيه المستخدمين الذين لم يثبِّتوا التطبيق إلى "متجر Google Play". ويمكن للمستخدمين الذين ليس لديهم مستند تعريف إنشاء مستند تعريف أثناء العملية باستخدام واجهة المستخدم التي تظهر على نصف الشاشة.
س: هل يمكننا رصد ما إذا كان لدى المستخدم مستند تعريف رقمي في "محفظة Google" قبل عرض خيار إثبات الهوية؟
ج: لا، يجب أن يستدعي المستخدم واجهة برمجة التطبيقات لحماية الخصوصية.
س: هل يمكننا أن نطلب من المستخدم فتح قفل جهازه باستخدام مقياس حيوي قبل تقديم بيانات الاعتماد؟
ج: تكون مصادقة المستخدم (المقاييس الحيوية أو رقم التعريف الشخصي أو النقش) مطلوبة تلقائيًا ولا يمكن إيقافها.
س: هل يمكن تخصيص ترتيب السمات المطلوبة على شاشة طلب موافقة المستخدم؟
ج: لا، تعيد "محفظة Google" ترتيبها أبجديًا.
الأمان والتوافق
س: تتضمّن حالة الاستخدام لدينا إعادة مشاركة بيانات المستخدمين مع جهات خارجية. هل هذا مسموح به بموجب بنود الخدمة؟
ج: نعم، قد تنطبق قيود، لذا يُرجى الاطّلاع على بنود الخدمة لمزيد من التفاصيل.
س: ما هي المستندات المتاحة بشأن أمان حلول الهوية الرقمية وموثوقيتها وإمكانية الوصول إليها لأغراض الامتثال؟
ج: يمكن للشركاء الرجوع إلى مراجعات الأمان التي تجريها شركة Trail of Bits.
الميزات المتقدّمة وخطة العمل
س: ما هي إمكانات "إثباتات المعرفة الصفرية" (ZKP) في التحقّق من العمر مع الحفاظ على الخصوصية؟
ج: "إثبات المعرفة الصفرية" (ZKP) هو طريقة تشفير تتيح لشخص (المُثبِت) أن يثبت للمُدقِّق أنّه يمتلك معلومة معيّنة عن هويته أو يستوفي معيارًا محدّدًا (مثلاً، أنّه تجاوز الـ 18 عامًا أو يحمل بيانات اعتماد صالحة) بدون الكشف عن البيانات الأساسية الفعلية نفسها.
س: كيف يتم التعامل مع الإصدارات المختلفة من دوائر ZK؟
ج: على الجهات المعتمِدة تنفيذ خدمات التحقّق من المعرفة الصفرية لطلب أحدث الدوائر المتاحة.
س: كيف تتم مشاركة بيانات الاعتماد وإدارتها على أجهزة متعددة، مثل الهاتف والجهاز القابل للارتداء؟
ج: يتم توفير بيانات الاعتماد لجهاز واحد ولا يمكن مشاركتها.
غير ذلك
س: كيف تتعامل Google مع عمليات إبطال بطاقات الهوية الرقمية في حال إبطال جواز السفر؟
ج: يمكن للمستخدمين حذف البطاقات من إعدادات حساب Google، ويمكن الإبلاغ عن الأجهزة المفقودة لإبطال بيانات الاعتماد.
س: كيف يتم التعامل مع إبطال رخصة القيادة على الأجهزة الجوّالة؟ هل يتم ذلك في الوقت الفعلي؟
ج: يمكن أن يفعّل المستخدم هذه الميزة أو أن تفرضها جهة الإصدار (إدارة المركبات). ويتم ذلك في الوقت الفعلي إذا كان الجهاز متصلاً بالإنترنت، وإلا ستنتهي صلاحية عناصر الأمان القصيرة الأجل (MSO).
س: ما هي سياسة تدوير المفاتيح للجهات المعتمِدة؟
ج: ننصحك بتغييرها سنويًا.
س: ما هو الحد الأدنى لإصدار Android المتوافق مع Digital Credentials API؟
ج: الإصدار 9 من نظام التشغيل Android (المستوى 28 لواجهة برمجة التطبيقات) والإصدارات الأحدث.
س: ما هو الحدّ الأدنى لإصدار Chrome المتوافق مع Digital Credentials API؟
ج: الإصدار 128 من Chrome والإصدارات الأحدث.
س: ما هي المتصفّحات المتوافقة مع Digital Credentials API؟
ج: يمكنك العثور على تفاصيل حول المتصفّحات المتوافقة هنا: https://digitalcredentials.dev/ecosystem-support
س: مَن هم المستخدمون الذين سيتمكّنون من إضافة مستند تعريف عند إطلاق الميزة في بلد جديد؟
ج: يعتمد الوصول على إعدادات بلد المستخدم في "متجر Google Play".
س: هل تعمل واجهة Digital Credentials API مع نظام التشغيل iOS؟
ج: نعم، تعمل واجهة برمجة التطبيقات باستخدام المتصفّحات المتوافقة، مثل Safari. ومع ذلك، لا يتوافق OpenID4VP مع Apple.