الأسئلة الشائعة حول الهوية الرقمية وبيانات الاعتماد

تقدّم هذه الصفحة إجابات عن الأسئلة الشائعة حول عملية الدمج مع Google Wallet لتوفير مستندات التعريف الرقمية.

الإعداد وبدء الاستخدام

س: ما هي العملية التفصيلية التي يجب أن يتبعها شريك جديد لإعداد حسابه كجهة معتمدة (RP)؟

ج: يُرجى الرجوع إلى الخطوات الواردة في قبول مستندات التعريف من "محفظة Google" على الإنترنت.

س: ما هي المدة النموذجية لعملية إعداد "الشريك الموثوق به"؟

ج: من المفترض أن تستغرق عملية الإعداد عادةً من 3 إلى 5 أيام عمل.

س: كيف يمكننا تتبُّع حالة طلب "الطرف المعتمِد" بعد إرساله؟

ج: إذا لم يصلك ردّ بعد 5 أيام، يُرجى التواصل مع فريق الدعم على wallet-identity-rp-support@google.com.

س: أين يمكننا العثور على نموذج إعداد "برنامج الشركاء الموصى بهم" ومستندات المطوّرين الرسمية؟

ج:

س: كيف سيتم استخدام المعلومات التي نقدّمها (مثل اسم المنتج وشعاره) في تجربة المنتج؟

ج: يتم عرض اسم المنتج وشعاره على شاشة طلب الموافقة التي تظهر للمستخدمين لمساعدتهم في تحديد الجهة التي تعتمد على الهوية والتي تطلب مستند تعريفهم الرقمي. قد يتم أيضًا عرض عناوين URL وروابط السياسات في تجربة المنتج.

س: هل علينا التوقيع على "بنود الخدمة" إذا كنا نخطّط لاستخدام بيئة وضع الحماية للتطوير والاختبار فقط؟

ج: لا، قبول بنود الخدمة ليس خطوة مطلوبة للاختبار.

س: أين يمكننا العثور على تنفيذ مرجعي أو رمز نموذجي أو تطبيق تجريبي للبدء؟

ج:

جهات التسجيل المعتمدة لإثبات ملكية الشركات

س: ما هي جهة تسجيل أدوات التحقّق وكيف تعمل؟

ج: يعمل مسجّل التحقّق كمرجع مصدّق يتيح للعملاء المتلقّين (الأطراف المستندة إلى التحقّق) استخدام الخدمة. لا يتفاعل "مقدّم الخدمة النهائي" مباشرةً مع "محفظة Google".

س: ما هي عملية الإعداد المحدّدة لجهة تسجيل التحقّق وعملائها المباشرين؟

ج: يُرجى الرجوع إلى الخطوات الواردة في: دليل مسجّل المدقّق.

س: كيف يختلف عن عملية دمج مباشرة مع "شركاء الإحالة"؟

ج: يدير مسجّلو جهات التحقّق علاقة الثقة لعملائهم ويتولّون عملية الدمج مع "محفظة Google" نيابةً عنهم، بينما تدير الجهات المعتمدة المباشرة عملية الإعداد الخاصة بها مع Google.

س: في "مسجّل جهات التحقّق"، مَن يتم إدراجه في القائمة المسموح بها في إعدادات Google: "مسجّل جهات التحقّق" أو "جهة الاعتماد النهائية" أو كلاهما؟

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

س: كيف يتم نقل البيانات بين الجهة المعتمدة النهائية، ومسجّل التحقّق، و"محفظة Google"؟

ج: يرسل مسجّل المدقّق طلب بيانات من واجهة برمجة التطبيقات إلى محفظة Google من أجل الطرف المعتمد النهائي. ترسل "محفظة Google" بيانات الاعتماد المشفّرة إلى "مسجّل أدوات التحقّق"، الذي يعالجها بعد ذلك ويرسل الإشارة النهائية إلى "جهة الاعتماد النهائية".

ج: لا، يمكن لمسجّل جهة التحقّق اختيار عدم عرض تفاصيله.

س: ما هي أنواع المفاتيح والمنحنيات المسموح بها لشهادات مراجع التصديق الجذر وشهادات الجهات الاعتمادية؟

ج: يجب إنشاء الشهادات باستخدام P-256 / ECDSA.

س: هل يمكننا استخدام شهادات توقيع وسيطة بين شهادات CA الجذر وشهادات RP الطرفية؟

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

س: ما هي مدة الصلاحية المطلوبة للشهادات؟

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

س: هل علينا إدارة شهادة فرعية منفصلة لكل عميل من عملاء الجهات المعتمِدة (RP)؟

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

س: هل يُسمح للشركاء بالحصول على شهادات نشطة متعددة في الوقت نفسه؟

ج: نعم، يتيح الإعداد أي عدد من الشهادات النشطة لكلّ جهة معتمدة أو جهة تجميع، وهو أمر مفيد للشركاء الذين يعملون تحت أسماء أنشطة تجارية مختلفة.

س: كيف يجب تنسيق الاسم المميز (الموضوع)؟

ج: يجب أن يكون الاسم المميز فريدًا على مستوى العالم لكل شريك. ويُستخدَم هذا المعرّف الثابت من قِبل Google لتتبُّع طلبات الشركاء الواردة وضمان موثوقية المنظومة المتكاملة.

س: كيف تعمل عملية ربط النطاق؟ هل يجب تضمين المصادر في الشهادة؟

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

س: هل يمكن إغفال تفاصيل الجهة المجمّعة من واجهة مستخدم التحقّق لتوفير تجربة ذات علامة تجارية بيضاء؟

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

س: ما هي المعلومات التي يجب تقديمها لبدء الاختبار في بيئة وضع الحماية؟

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

س: كيف تختلف عملية الإعداد لمسجّلي الجهات المُحقّقة (المجمّعين) عن عملية الإعداد لمزوّدي خدمات الاعتماد المباشرين؟

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

س: هل يمكننا إعداد العملاء الذين ينوون العمل كوسطاء أو إعادة بيع خدمات إثبات الملكية إلى جهات أخرى؟

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

الدمج الفني وواجهة برمجة التطبيقات

س: ما هو البروتوكول الأساسي للطلبات؟ ما هي الإصدارات المتوافقة؟

ج: البروتوكول الأساسي هو OpenID للإثباتات القابلة للتحقّق (OpenID4VP) الإصدار 1.0.

س: ما هي ملاحق معيار ISO 18013-7 (مثل الملحق B أو C أو D) التي تتيحها Google لعرض رخصة قيادة رقمية (mDL)؟

ج: تتيح Google استخدام الملحق D [في مرحلة الصياغة حاليًا] (OpenID4VP باستخدام DC API).

س: كيف يمكننا إنشاء طلب بيانات من واجهة برمجة التطبيقات بشكل صحيح لطلب بيانات اعتماد متعددة في عرض واحد للمستخدم؟

ج: يجب طلب كلا نوعَي بيانات الاعتماد ضمن عنصر طلب dcql واحد في طلب JSON نفسه.

س: هل تتيح واجهة برمجة التطبيقات طلب بيانات اعتماد عامة بدون إدراج كل نوع ممكن من بيانات الاعتماد؟

ج: لا.

س: كيف تتعامل واجهة برمجة التطبيقات مع عملية تأكيد العمر؟ هل يمكننا طلب تاريخ الميلاد الدقيق، أو فقط إشارة "أكبر من X"؟

ج: يمكن استخدام كليهما. يمكنك طلب birth_date أو age_in_years أو إشارة "أكثر من X" تحافظ على الخصوصية. يمكن أيضًا استخدام إثباتات عدم الإفصاح عن المعلومات (ZKPs) للحصول على إشارة صحيحة/خاطئة.

سؤال: ما هي متطلبات البنية التحتية للمفاتيح العامة (PKI)؟

ج: تحتاج الأطراف المعتمِدة إلى بنية أساسية للمفتاح العام (PKI) لتوقيع الطلبات. تعمل جهات تسجيل أدوات التحقّق كمرجع تصديق خاص بها.

س: هل يمكننا استخدام شهاداتنا الحالية، أم علينا الحصول على شهادة جديدة موقّعة من Google؟

ج: تحتاج الجهات الاعتمادية إلى شهادة جديدة موقّعة من Google أو من مسجّل مدقّق. بالنسبة إلى مسجّلي التحقّق، ستثق Google في شهادة الجذر إذا اتّبعت خطوات "إنشاء الثقة" الواردة في المستندات.

ج: يجب إنشاء الطلب بأكمله من جهة الخادم. على أجهزة Android، استخدِم Credman API، وعلى الويب، استخدِم Digital Credentials (DC) API.

س: ما هي أدوات تصحيح الأخطاء والتسجيل وإمكانية تتبّع البيانات المتاحة للمطوّرين؟

ج: يمكن للشركاء استخدام الاسم المستعار wallet-identity-rp-support@google.com للدعم. لا يتم توفير أدوات تسجيل أو مراقبة محدّدة.

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

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

ج: يمكنك الاطّلاع على المناطق التي تتوفّر فيها هذه الميزة هنا: الجهات المعتمدة لإصدار البطاقات والشهادات.

س: متى تخطّط لإتاحة استخدام مستندات تعريف من بلدان أو مناطق جديدة؟

ج: نعمل حاليًا على إضافة مناطق جديدة، لذا يُرجى مراجعة صفحة جهات الإصدار المتوافقة للاطّلاع على آخر المعلومات.

س: عندما تعدّل جهة إصدار بيانات الاعتماد هذه البيانات، هل يتلقّى المستخدم النهائي إشعارًا؟

ج: نعم، يتم إشعار المستخدم ويتم تطبيق التحديث تلقائيًا.

الاختبارات والبيئات

س: كيف يمكننا الوصول إلى بيئة وضع الحماية لاختبار مسار العملية الكاملة؟

ج: يمكنك فتح وضع الحماية من خلال وضع الحماية.

س: ما هي العملية التي يجب أن يتّبعها الشركاء غير المقيمين في منطقة تم إطلاق البرنامج فيها رسميًا لإضافتهم إلى قائمة السماح لإجراء الاختبار؟

ج: أرسِل عبر البريد الإلكتروني معرّفات Gmail الخاصة بالمحافظ التجريبية إلى wallet-identity-rp-support@google.com.

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

ج: على الشركاء إكمال عملية الإعداد العادية لبرنامج "شركاء المحتوى"، بما في ذلك عرض توضيحي للفيديو في بيئة الاختبار.

تجربة المستخدم (UX)

س: ما هي تجربة المستخدم إذا لم يكن لديه مستند تعريف رقمي أو تطبيق "محفظة Google" مثبّتًا عند بدء عملية إثبات الهوية؟

ج: يتم توجيه المستخدمين الذين لم يثبِّتوا التطبيق إلى "متجر Google Play". يمكن للمستخدمين الذين ليس لديهم معرّف إنشاء معرّف أثناء عملية الإعداد باستخدام واجهة المستخدم التي تملأ نصف الشاشة.

س: هل يمكننا رصد ما إذا كان المستخدم لديه مستند تعريف رقمي في "محفظة Google" بشكل آلي قبل عرض خيار إثبات الهوية؟

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

س: هل يمكننا أن نطلب من المستخدم فتح قفل جهازه باستخدام المقاييس الحيوية قبل عرض بيانات الاعتماد؟

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

ج: لا، تعيد "محفظة Google" ترتيبها أبجديًا.

الأمان والتوافق

س: تتضمّن حالة الاستخدام لدينا إعادة مشاركة بيانات المستخدمين مع جهات خارجية. هل هذا مسموح به بموجب بنود الخدمة؟

ج: نعم، قد تنطبق قيود. يُرجى الاطّلاع على بنود الخدمة لمزيد من التفاصيل.

س: ما هي المستندات المتاحة بشأن أمان حلول الهوية الرقمية وموثوقيتها وإمكانية الوصول إليها لأغراض الامتثال؟

ج: يمكن للشركاء الرجوع إلى مراجعات الأمان التي أجرتها شركة Trail of Bits.

الميزات المتقدّمة وخريطة الطريق

س: ما هي إمكانات Zero-Knowledge Proofs (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. ومع ذلك، لا تتوافق Apple مع OpenID4VP.