این صفحه به پرسش‌های متداول درباره ادغام با «کیف پول Google» برای «هویت دیجیتال» و «اعتبارنامه‌ها» پاسخ می‌دهد.
آماده‌سازی و شروع به کار
س: فرایند گام‌به‌گام برای آماده‌سازی شریک جدید به‌عنوان «طرف اتکاکننده» (RP) چیست؟
پاسخ: راهنمای گام‌به‌گام را در Choose Your Path (مسیرتان را انتخاب کنید) دنبال کنید.
پرسش: مدت زمان معمول برای فرایند آماده‌سازی «طرف محدود» چقدر است؟
پاسخ: معمولاً آماده‌سازی ۳ تا ۵ روز کاری طول می‌کشد.
س: چگونه می‌توانیم وضعیت درخواست «طرف معتمد» (RP) خود را پس‌از ارسال پیگیری کنیم؟
پاسخ: اگر پس‌از ۵ روز پاسخی دریافت نکردید، لطفاً با تیم پشتیبانی ما در wallet-identity-rp-support@google.com تماس بگیرید.
س: از کجا می‌توانیم فرم آماده‌سازی RP و مستندات رسمی توسعه‌دهنده را پیدا کنیم؟
الف:
- فرم آماده‌سازی: فرم تماس با شرکای متکی به هویت «کیف پول Google»
- مستندات توسعه‌دهنده: نمای کلی هویت دیجیتال
س: اطلاعاتی که ارائه می‌دهیم (مثل «نام محصول» و «نشان‌واره») چگونه در تجربه محصول استفاده خواهد شد؟
پاسخ: «نام محصول» و «نشان‌واره» در صفحه رضایت سَمت کاربر نمایش داده می‌شود تا به کاربران کمک کند تشخیص دهند کدام «طرف اتکاکننده» شناسه دیجیتالی آن‌ها را درخواست می‌کند. نشانی‌های وب و پیوندهای خط‌مشی نیز ممکن است در تجربه محصول نشان داده شوند.
س: اگر فقط قصد داشته باشیم از محیط جعبه امن برای توسعه و آزمایش استفاده کنیم، آیا لازم است «شرایط خدمات» را امضا کنیم؟
پاسخ: نه، پذیرفتن «شرایط خدمات» مرحله‌ای الزامی برای آزمایش نیست.
س: از کجا می‌توانیم پیاده‌سازی مرجع، کد نمونه، یا برنامه نمایشی برای شروع پیدا کنیم؟
الف:
- مخزن GitHub: پیاده‌سازی مرجع هویت.
- وب‌سایت آزمایشی: verifier.multipaz.org
ثبت‌کنندگان درستی‌سنج
س: «ثبت‌کننده تأییدکننده» چیست و چگونه کار می‌کند؟
پاسخ: «ثبت‌کننده درستی‌سنج» به‌عنوان «مرجع گواهینامه» عمل می‌کند که مشتریان پایین‌دست (طرف‌های متکی نهایی) را وارد می‌کند. «طرف اتکاکننده نهایی» مستقیماً با «کیف پول Google» تعامل ندارد.
س: فرایند آماده‌سازی خاص برای «ثبت‌کننده تأییدکننده» و مشتریان پایین‌دستی آن‌ها چیست؟
پاسخ: به مراحل موجود در راهنمای ثبت‌کننده درستی‌سنج مراجعه کنید.
س: چه تفاوتی با ادغام مستقیم RP دارد؟
پاسخ: «ثبت‌کنندگان تأییدکننده» رابطه اعتماد را برای مشتریانشان مدیریت می‌کنند و ادغام با «کیف پول Google» را ازطرف آن‌ها انجام می‌دهند، درحالی‌که «طرف‌های متکی» مستقیم پیکربندی خودشان را با Google مدیریت می‌کنند.
س: در «ثبت‌کننده تأییدکننده»، چه کسی در پیکربندی Google در فهرست مجازها قرار می‌گیرد: «ثبت‌کننده تأییدکننده»، «طرف اتکاکننده» نهایی، یا هر دو؟
پاسخ: Google گواهینامه «مرجع صدور گواهی ریشه» «ثبت‌کننده تأییدکننده» را در فهرست مجاز قرار می‌دهد. سپس «ثبت‌کننده درستی‌سنج» گواهینامه‌های نهایی جدیدی برای هر «طرف نهایی» پایین‌دست صادر می‌کند.
س: جریان داده بین «طرف نهایی تکیه‌کننده»، «ثبت‌کننده تأییدکننده»، و «کیف پول Google» چگونه است؟
پاسخ: «ثبت‌کننده تأییدکننده» درخواست API را برای «طرف اتکاکننده نهایی» به «کیف پول Google» ارسال می‌کند. «کیف پول Google» داده‌های اطلاعات کاربری رمزگذاری‌شده را به «ثبت‌کننده درستی‌سنج» برمی‌گرداند، سپس «ثبت‌کننده درستی‌سنج» آن را پردازش می‌کند و سیگنال نهایی را به «طرف نهایی متکی» ارسال می‌کند.
س: برای راه‌حل‌های برچسب سفید، آیا لازم است نام «ثبت‌کننده تأییدکننده» در جریان کسب موافقت کاربر نشان داده شود یا فقط نام «طرف نهایی متکی» کافی است؟
پاسخ: نه. «ثبت‌کننده تأییدکننده» می‌تواند انتخاب کند جزئیاتش نمایش داده نشود.
س: انواع کلید و منحنی‌های مجاز برای «مرجع صدور گواهی ریشه» و «گواهی‌های طرف اعتمادکننده» چیست؟
پاسخ: گواهی‌ها باید بااستفاده از P-256 / ECDSA تولید شوند.
سؤال: آیا می‌توانیم از گواهینامه‌های امضاکننده واسط بین گواهینامه‌های نهایی «طرف متکی» و «مرجع صدور گواهی ریشه» خودمان استفاده کنیم؟
پاسخ: بله. می‌توانید گواهینامه ریشه با عمر طولانی را به‌طور ایمن ذخیره کنید (مثلاً در HSM) تا گواهینامه‌های واسط عملیاتی را به‌ندرت امضا کنید. سپس می‌توان از آن گواهینامه‌های واسط برای امضای گواهینامه‌های نهایی «طرف اتکاکننده» استفاده کرد که امکان چرخش آسان‌تر را درصورت نقض بدون تأثیر بر ریشه فراهم می‌کند.
س: طول عمر موردنیاز برای گواهینامه‌ها چقدر است؟
پاسخ: طول عمر ۱۰ ساله برای گواهینامه CA ریشه‌ای کاملاً قابل‌قبول است. گواهینامه‌های نهایی RP نهایی معمولاً باید از یک خط زمان تمدید حدوداً ۱ ساله پیروی کنند تا اطمینان حاصل شود که درصورت بروز مشکل، می‌توان آن‌ها را به‌طور مؤثر چرخاند.
س: آیا باید برای هر مشتری «طرف متکی» (RP) گواهینامه نهایی جداگانه‌ای را مدیریت کنیم؟
پاسخ: بله. برای دوره راه‌اندازی اولیه، جمع‌کنندگان باید گواهینامه‌های جداگانه‌ای را برای هر «طرف اعتمادکننده» پایین‌دستی مدیریت کنند. این کار پیکربندی‌های نمایش برای هر RP و ردیابی دقیق سوءاستفاده را فعال می‌کند. اگرچه این کار باعث افزایش هزینه‌های عملیاتی در مقیاس بزرگ می‌شود، قصد داریم پس‌از عرضه اولیه، جایگزین‌های احتمالی (مانند استفاده از درهم‌سازی‌های فراداده RP) را دوباره بررسی کنیم.
س: آیا شرکا مجازند به‌طور هم‌زمان چندین گواهینامه فعال داشته باشند؟
پاسخ: بله، این پیکربندی از هر تعداد گواهی فعال برای هر «طرف تکیه‌کننده» یا تجمیع‌کننده پشتیبانی می‌کند که برای شرکایی که تحت نام‌های تجاری مختلف فعالیت می‌کنند مفید است.
س: «نام متمایز» (موضوع) باید چه قالبی داشته باشد؟
پاسخ: «نام متمایز» باید در سطح جهانی برای هر شریک منحصربه‌فرد باشد. این شناسه به‌عنوان شناسه ثابتی عمل می‌کند که Google از آن برای نظارت بر درخواست‌های شریک ورودی و اطمینان از اعتماد به بوم‌سازگان استفاده می‌کند.
س: اتصال دامنه چگونه کار می‌کند؟ آیا مبدأها باید در گواهی جاسازی شوند؟
پاسخ: لازم نیست دامنه‌ها مستقیماً در خود گواهی جاسازی شوند. درعوض، درستی‌سنجی دامنه بااستفاده از پارامتر مبدأهای موردانتظار در فراخوانی میانای برنامه‌سازی کاربردی انجام می‌شود. علاوه‌براین، چندین دامنه را می‌توان به‌طور یکپارچه با یک گواهینامه مرتبط کرد. برای درخواست‌های امضانشده، اتصال بااستفاده از نام بسته «برنامه» یا «دامنه» درکنار اثر انگشت اجرا می‌شود.
سؤال: آیا می‌توان جزئیات تجمیع‌گر را از واسط کاربر درستی‌سنجی برای تجربه برچسب سفید حذف کرد؟
پاسخ: بله، اطلاعات تجمیع‌کننده (مانند نام، نشان‌واره، نشانی وب، و خط‌مشی رازداری) در فراداده تأییدکننده کاملاً اختیاری است. این کار راه‌حل کاملاً سفیدبرچسبی را فعال می‌کند که در آن فقط جزئیات «طرف نهایی اتکاکننده» به کاربر نشان داده می‌شود.
س: برای شروع آزمایش در محیط «جعبه شنی» چه چیزی باید ارائه دهیم؟
س: از دیدگاه فنی، فقط باید «گواهینامه ریشه جعبه شنی» خود را ارائه دهید. «جعبه امن» به‌گونه‌ای طراحی شده است که دقیقاً محیط تولید را منعکس کند.
س: فرایند آماده‌سازی برای «ثبت‌کنندگان تأییدکننده» (انبوهش‌گران) در مقایسه با «طرف‌های متکی» مستقیم چه تفاوتی دارد؟
پاسخ: تجمیع‌کننده‌ها فرایند کمی متفاوتی را طی می‌کنند. پس‌از اجرای «شرایط خدمات» خاص «ثبت‌کننده درستی‌سنج»، فرایند پذیرش به دو بخش تقسیم می‌شود: یک فرم اصلی برای تعیین وضعیت شما به‌عنوان «ثبت‌کننده درستی‌سنج»، و سپس یک فرم ساده‌شده که برای هر «طرف معتمد» تکی که وارد می‌کنید لازم است. هر ارسال RP معمولاً به ضبط ویدیویی از ادغام نیاز دارد و فرایند بازبینی معمولاً ۲ تا ۳ روز کاری طول می‌کشد.
س: آیا می‌توانیم مشتریانی را که قصد دارند به‌عنوان واسطه عمل کنند یا خدمات درستی‌سنجی را به نهادهای دیگر بازفروش کنند، آماده‌سازی کنیم؟
پاسخ: نه. مدل و اولویت فعلی Google این است که به‌جای پشتیبانی از مدل‌های واسطه یا بازفروش تودرتو، مستقیماً با «ثبت‌کنندگان تأییدکننده» (تجمیع‌کنندگان) و «طرف‌های متکی» نهایی مستقیم آن‌ها کار کند.
یکپارچه‌سازی فنی و میانای برنامه‌سازی کاربردی
س: پروتکل اساسی برای درخواست‌ها چیست؟ از چه نسخه‌هایی پشتیبانی می‌شود؟
پاسخ: پروتکل اصلی OpenID برای «ارائه‌های قابل‌تأیید» (OpenID4VP) نسخه ۱.۰ است.
س: Google از کدام پیوست‌های ISO 18013-7 (برای مثال، پیوست B، C، D) برای ارائه گواهینامه رانندگی دیجیتال پشتیبانی می‌کند؟
پاسخ: Google از Annex D [درحال‌حاضر در نسخه پیش‌نویس] (OpenID4VP بااستفاده از DC API) پشتیبانی می‌کند.
س: چگونه می‌توانیم درخواست میانای برنامه‌سازی کاربردی را به‌درستی ساختاربندی کنیم تا چندین اعتبارنامه را در یک ارائه کاربر درخواست کنیم؟
پاسخ: هر دو نوع اطلاعات کاربری باید در یک شیء پُرسمان dcql در همان درخواست JSON درخواست شوند.
س: آیا این API امکان درخواست اعتبارنامه عمومی را بدون فهرست کردن همه انواع اعتبارنامه‌های ممکن فراهم می‌کند؟
ج: نه.
س: API چگونه درستی‌سنجی سن را انجام می‌دهد؟ آیا می‌توانیم تاریخ تولد دقیق را درخواست کنیم یا فقط سیگنال «بالای X سال» را؟
پاسخ: هر دو پشتیبانی می‌شوند. می‌توانید birth_date، age_in_years، یا نشان «بیش‌از X» حافظ حریم خصوصی را درخواست کنید. از «اثبات با دانش صفر» (ZKP) نیز می‌توان برای سیگنال درست/غلط استفاده کرد.
پرسش: الزامات زیرساخت PKI ما چیست؟
پاسخ: طرف‌های متکی برای امضای درخواست‌ها به PKI نیاز دارند. «ثبت‌کنندگان درستی‌سنج» به‌عنوان CA خودشان عمل می‌کنند.
س: آیا می‌توانیم از گواهی‌های موجود خودمان استفاده کنیم یا باید گواهی جدیدی بگیریم که 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» را نصب نکرده باشد، تجربه کاربری او چگونه خواهد بود؟
پاسخ: کاربرانی که برنامه را ندارند به «فروشگاه Play» هدایت می‌شوند. افرادی که شناسه ندارند می‌توانند در جریان بااستفاده از میانای کاربر نیم‌صفحه شناسه ایجاد کنند.
س: آیا می‌توانیم به‌صورت برنامه‌نویسی‌شده تشخیص دهیم که کاربر مدرک شناسایی دیجیتال در «کیف پول» خود دارد یا نه، قبل‌از اینکه گزینه درستی‌سنجی را به او نشان دهیم؟
پاسخ: نه، برای محافظت از حریم خصوصی، API باید توسط کاربر فراخوانی شود.
سؤال: آیا می‌توانیم کاربر را ملزم کنیم قبل‌از ارائه اطلاعات اعتباری، قفل دستگاهش را با زیست‌سنجشی باز کند؟
پاسخ: اصالت‌سنجی کاربر (زیست‌سنجشی، پین، یا الگو) به‌طور پیش‌فرض الزامی است و نمی‌توان آن را غیرفعال کرد.
س: آیا می‌توان ترتیب مشخصه‌های درخواست‌شده را در صفحه رضایت کاربر سفارشی‌سازی کرد؟
پاسخ: نه، «کیف پول Google» آن‌ها را به‌ترتیب حروف الفبا مرتب می‌کند.
امنیت و مطابقت با قوانین
س: مورد استفاده ما شامل هم‌رسانی مجدد داده‌های کاربر با اشخاص ثالث است. آیا این کار طبق «شرایط خدمات» مجاز است؟
پاسخ: بله، ممکن است محدودیت‌هایی اعمال شود، برای جزئیات بیشتر به شرایط خدمات ما مراجعه کنید.
س: چه اسنادی درباره امنیت، قابلیت اطمینان، و دسترس‌پذیری راهکارهای هویت دیجیتال برای اهداف رعایت مقررات ما دردسترس است؟
پاسخ: شرکا می‌توانند به بازبینی‌های امنیتی Trail of Bits مراجعه کنند.
ویژگی‌های پیشرفته و نقشه راه
س: قابلیت‌های «اثبات با دانش صفر» (ZKP) برای درستی‌سنجی سن با حفظ حریم خصوصی چیست؟
پاسخ: «اثبات با دانش صفر» (ZKP) روشی رمزنگاری است که به فرد (اثبات‌کننده) اجازه می‌دهد به درستی‌سنج ثابت کند که اطلاعات هویتی خاصی دارد یا معیار خاصی را برآورده می‌کند (مثلاً بالای ۱۸ سال دارد، اعتبارنامه معتبری دارد) بدون اینکه داده‌های واقعی زیربنایی را فاش کند.
س: نسخه‌های مختلف مدارهای ZK چگونه مدیریت می‌شوند؟
پاسخ: طرف‌های متکی باید سرویس‌های درستی‌سنج ZK را پیاده‌سازی کنند تا بتوانند جدیدترین مدارهای دردسترس را درخواست کنند.
سؤال: هم‌رسانی و مدیریت اطلاعات کاربری در چندین دستگاه، مانند تلفن و دستگاه پوشیدنی، چگونه کار می‌کند؟
پاسخ: اطلاعات اعتباری برای یک دستگاه تدارک دیده شده است و نمی‌توان آن را هم‌رسانی کرد.
موارد دیگر
س: اگر گذرنامه‌ای باطل شود، Google چگونه باطل شدن شناسه دیجیتال را مدیریت می‌کند؟
پاسخ: کاربران می‌توانند مجوزها را از تنظیمات «حساب Google» حذف کنند؛ دستگاه‌های گم‌شده را می‌توان گزارش کرد تا اطلاعات کاربری باطل شود.
س: ابطال گواهینامه رانندگی دیجیتال چگونه انجام می‌شود؟ آیا هم‌زمان است؟
پاسخ: این کار می‌تواند توسط کاربر راه‌اندازی شود یا توسط صادرکننده (DMV) ارسال شود. اگر دستگاه آنلاین باشد، این فرایند هم‌زمان است؛ درغیراین‌صورت، اشیای امنیتی کوتاه‌مدت (MSO) منقضی خواهند شد.
س: خط‌مشی تغییر کلید برای طرف‌های تکیه‌کننده چیست؟
پاسخ: چرخش سالانه توصیه می‌شود.
س: حداقل نسخه Android پشتیبانی‌شده برای Digital Credentials API چیست؟
پ: Android 9 (سطح API ۲۸) و بالاتر.
س: حداقل نسخه Chrome که از Digital Credentials API پشتیبانی می‌کند چیست؟
پاسخ: Chrome نسخه ۱۲۸ و بالاتر.
س: کدام مرورگرها از Digital Credentials API پشتیبانی می‌کنند؟
پاسخ: جزئیات پشتیبانی مرورگر را می‌توانید در اینجا پیدا کنید: https://digitalcredentials.dev/ecosystem-support
س: کدام کاربران می‌توانند هنگام راه‌اندازی کشور جدید، مدرک شناسایی اضافه کنند؟
پ: دسترسی براساس تنظیمات کشور کاربر در «فروشگاه Play» است.
س: آیا Digital Credentials API با iOS کار می‌کند؟
پاسخ: بله، این API بااستفاده از مرورگرهای پشتیبانی‌شده‌ای مثل Safari کار می‌کند. اما Apple از OpenID4VP پشتیبانی نمی‌کند.