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