این صفحه به سوالات متداول در مورد ادغام با Google Wallet برای هویت و اعتبارنامههای دیجیتال پاسخ میدهد.
سوار شوید و شروع کنید
س: فرآیند گام به گام برای پیوستن یک شریک جدید به عنوان طرف اتکا (RP) چیست؟
پاسخ: به مراحل موجود در: پذیرش شناسهها از کیف پول آنلاین مراجعه کنید.
س: مدت زمان معمول برای فرآیند جذب RP چقدر است؟
الف) معمولاً ثبتنام اولیه ۳ تا ۵ روز کاری طول میکشد.
س: چگونه میتوانیم وضعیت درخواست طرف مورد اعتماد (RP) خود را پس از ارسال پیگیری کنیم؟
پاسخ: اگر پس از ۵ روز پاسخی دریافت نکردید، لطفاً با تیم پشتیبانی ما از طریق wallet-identity-rp-support@google.com تماس بگیرید.
س: فرم استخدام RP و مستندات رسمی توسعهدهنده را از کجا میتوانیم پیدا کنیم؟
الف:
- فرم شروع به کار: فرم تماس با شرکای مبتنی بر هویت گوگل والت
- مستندات توسعهدهنده: بررسی اجمالی هویت دیجیتال
س: اطلاعاتی که ما ارائه میدهیم (مانند نام محصول و لوگو) چگونه در تجربه محصول استفاده خواهد شد؟
الف) نام و لوگوی محصول در صفحه رضایتنامه که روبروی کاربر قرار دارد نمایش داده میشود تا به کاربران کمک کند تا تشخیص دهند کدام طرفِ مورد اعتماد، درخواست شناسه دیجیتال آنها را دارد. همچنین ممکن است URLها و پیوندهای مربوط به خطمشی در تجربه محصول نمایش داده شوند.
س: آیا اگر فقط قصد داریم از محیط سندباکس برای توسعه و آزمایش استفاده کنیم، باید شرایط خدمات را امضا کنیم؟
الف) خیر، پذیرش شرایط خدمات، مرحلهای الزامی برای آزمایش نیست.
س: از کجا میتوانیم یک پیادهسازی مرجع، کد نمونه یا یک برنامه آزمایشی برای شروع پیدا کنیم؟
الف:
- مخزن گیتهاب: پیادهسازی مرجع هویت
- وبسایت تست: verifier.multipaz.org
ثبتکنندگان تأییدکننده
س: ثبت کننده تأیید کننده چیست و چگونه کار می کند؟
الف) ثبتکننده تأییدکننده به عنوان یک مرجع صدور گواهی عمل میکند که کلاینتهای پاییندستی (End RPs) را ثبت میکند. End RP مستقیماً با Google Wallet تعامل ندارد.
س: فرآیند خاص پذیرش برای یک ثبتکننده تأییدکننده و مشتریان پاییندستی او چیست؟
پاسخ: به مراحل موجود در: راهنمای ثبت کننده تأییدکننده مراجعه کنید.
س: چه تفاوتی با ادغام مستقیم RP دارد؟
الف) ثبتکنندگان تأییدکننده، رابطه اعتماد را برای مشتریان خود مدیریت میکنند و از طرف آنها ادغام با Google Wallet را انجام میدهند، در حالی که RPهای مستقیم، پیکربندی خود را با Google مدیریت میکنند.
س: در ثبتکننده تأییدکننده، چه کسی در پیکربندی گوگل مجوز میگیرد: ثبتکننده تأییدکننده، RP نهایی یا هر دو؟
الف) گوگل گواهینامهی ریشهی CA مربوط به ثبتکنندهی تأییدکننده را در فهرست خود قرار میدهد. سپس ثبتکنندهی تأییدکننده گواهینامههای برگ جدیدی را برای هر RP انتهایی پاییندستی صادر میکند.
س: دادهها چگونه بین RP نهایی، ثبتکننده تأییدکننده و کیف پول گوگل جریان مییابند؟
الف) ثبتکننده تأییدکننده، درخواست API را برای پایان RP به Google Wallet ارسال میکند. Google Wallet دادههای رمزگذاریشدهی اعتبارنامه را به ثبتکننده تأییدکننده برمیگرداند، که سپس آن را پردازش کرده و سیگنال نهایی را به پایان RP ارسال میکند.
س: برای راهکارهای دارای برچسب سفید، آیا لازم است نام ثبتکننده تأییدکننده در جریان رضایت کاربر نمایش داده شود، یا میتواند فقط نام نهایی RP باشد؟
الف) خیر. مسئول ثبت تأییدکننده میتواند اطلاعات آنها را نمایش ندهد.
س: انواع کلید و منحنیهای مجاز برای Root CAها و گواهینامههای RP کدامند؟
الف) گواهیها باید با استفاده از P-256 / ECDSA تولید شوند.
س: آیا میتوانیم از گواهیهای امضاکننده میانی بین گواهیهای Root CA و RP leaf خود استفاده کنیم؟
بله. شما میتوانید یک گواهی ریشه با طول عمر بالا (مثلاً در یک HSM) را به طور ایمن ذخیره کنید تا به ندرت گواهیهای میانی عملیاتی را امضا کنید. سپس میتوان از آن گواهیهای میانی برای امضای گواهیهای برگ end-RP استفاده کرد و در صورت نقض امنیتی، چرخش آسانتر را بدون تأثیر بر ریشه امکانپذیر ساخت.
س: طول عمر مورد نیاز برای گواهینامهها چقدر است؟
الف) طول عمر ۱۰ ساله برای گواهی Root CA کاملاً قابل قبول است. گواهیهای برگ End-RP معمولاً باید از یک جدول زمانی تمدید تقریباً ۱ ساله پیروی کنند تا در صورت بروز مشکل، امکان چرخش کارآمد آنها وجود داشته باشد.
س: آیا لازم است برای هر مشتری طرف اتکا (RP) یک گواهی برگ جداگانه مدیریت کنیم؟
الف) بله. برای دوره اولیه راهاندازی، تجمیعکنندهها باید برای هر RP پاییندستی، گواهیهای جداگانهای مدیریت کنند. این امر امکان پیکربندی نمایش هر RP و ردیابی دقیق سوءاستفاده را فراهم میکند. اگرچه این امر سربار عملیاتی را در مقیاس افزایش میدهد، ما قصد داریم پس از راهاندازی اولیه، جایگزینهای بالقوه (مانند استفاده از هشهای فراداده RP) را دوباره بررسی کنیم.
س: آیا شرکا مجاز به داشتن چندین گواهی فعال به طور همزمان هستند؟
الف) بله، این پیکربندی از هر تعداد گواهی فعال به ازای هر RP یا تجمیعکننده پشتیبانی میکند، که برای شرکایی که تحت نامهای تجاری مختلف فعالیت میکنند مفید است.
س: نام برجسته (موضوع) چگونه باید قالب بندی شود؟
الف) نام متمایز باید به صورت جهانی برای هر شریک منحصر به فرد باشد. این به عنوان یک شناسه ثابت عمل میکند که گوگل از آن برای نظارت بر درخواستهای ورودی شرکا و اطمینان از اعتماد اکوسیستم استفاده میکند.
س: اتصال دامنه چگونه کار میکند؟ آیا لازم است مبداها در گواهی تعبیه شوند؟
الف) دامنهها نیازی به جاسازی مستقیم در خود گواهی ندارند. در عوض، تأیید دامنه با استفاده از پارامتر مبدا مورد انتظار در فراخوانی API انجام میشود. علاوه بر این، چندین دامنه میتوانند به طور یکپارچه با یک گواهی مرتبط شوند. برای درخواستهای امضا نشده، اتصال با استفاده از نام بسته دامنه یا برنامه در کنار اثر انگشت انجام میشود.
س: آیا میتوان جزئیات تجمیعکننده را از رابط کاربری تأیید برای یک تجربه با برچسب سفید حذف کرد؟
پاسخ: بله، اطلاعات تجمیعکننده (مانند نام، لوگو، URL و سیاست حفظ حریم خصوصی) کاملاً اختیاری در فراداده تأییدکننده است. این امر یک راهکار کاملاً برچسبگذاری شده را امکانپذیر میکند که در آن فقط جزئیات پایان RP به کاربر نمایش داده میشود.
س: برای شروع آزمایش در محیط Sandbox چه چیزهایی باید ارائه دهیم؟
الف) از نظر فنی، شما فقط باید گواهی ریشه Sandbox خود را ارائه دهید. Sandbox به گونهای طراحی شده است که به طور یکسان محیط تولید را منعکس کند.
س: فرآیند پذیرش برای ثبتکنندگان تأییدکننده (تجمیعکنندگان) در مقایسه با RPهای مستقیم چگونه متفاوت است؟
الف) تجمیعکنندهها فرآیندی با کمی تغییر را طی میکنند. پس از اجرای شرایط خدمات خاص ثبتکننده تأییدکننده، فرم پذیرش به دو بخش تقسیم میشود: یک فرم اولیه برای تعیین وضعیت شما به عنوان ثبتکننده تأییدکننده، و به دنبال آن یک فرم ساده که برای هر RP که وارد سیستم میشوید لازم است. ارسال هر RP معمولاً نیاز به ضبط ویدیویی از ادغام دارد و فرآیند بررسی عموماً ۲-۳ روز کاری طول میکشد.
س: آیا میتوانیم مشتریانی را که قصد دارند به عنوان واسطه عمل کنند یا خدمات تأیید را به اشخاص دیگر بفروشند، جذب کنیم؟
الف) خیر. مدل و ترجیح فعلی گوگل این است که مستقیماً با ثبتکنندگان تأییدکننده (تجمیعکنندگان) و RPهای نهایی مستقیم آنها کار کند، نه اینکه از مدلهای توزیعکننده تودرتو یا واسطهای پشتیبانی کند.
ادغام فنی و API
س: پروتکل اساسی برای درخواستها چیست؟ چه نسخههایی پشتیبانی میشوند؟
الف) پروتکل اصلی، OpenID برای ارائههای قابل تأیید (OpenID4VP) نسخه ۱.۰ است.
س: گوگل از کدام پیوستهای ISO 18013-7 (مثلاً پیوستهای B، C، D) برای ارائه mDL پشتیبانی میکند؟
الف) گوگل از پیوست D [که در حال حاضر در مرحله پیشنویس است] (OpenID4VP با استفاده از DC API) پشتیبانی میکند.
س: چگونه میتوانیم یک درخواست API را به درستی ساختار دهیم تا چندین اعتبارنامه را در یک ارائه کاربری واحد درخواست کند؟
الف) هر دو نوع اعتبارنامه باید در یک شیء پرسوجوی dcql واحد در یک درخواست JSON یکسان درخواست شوند.
س: آیا API اجازه درخواست یک اعتبارنامه عمومی را بدون فهرست کردن تمام انواع اعتبارنامههای ممکن میدهد؟
الف) خیر.
س: API چگونه تأیید سن را انجام میدهد؟ آیا میتوانیم تاریخ دقیق تولد را درخواست کنیم یا فقط یک سیگنال «بالای X»؟
الف) هر دو پشتیبانی میشوند. شما میتوانید birth_date ، age_in_years یا سیگنال «بیش از X» با حفظ حریم خصوصی را درخواست کنید. اثباتهای دانش صفر (ZKP) همچنین میتوانند برای سیگنال درست/غلط استفاده شوند.
س: الزامات زیرساخت PKI ما چیست؟
الف) RPها برای امضای درخواستها به PKI نیاز دارند. Verifier Registrarها به عنوان CA خودشان عمل میکنند.
س: آیا میتوانیم از گواهینامههای موجود خودمان استفاده کنیم یا باید یک گواهینامه جدید با امضای گوگل دریافت کنیم؟
الف) RPها به یک گواهی جدید امضا شده توسط گوگل یا یک ثبتکننده تأییدکننده نیاز دارند. برای ثبتکنندههای تأییدکننده، گوگل در صورتی به گواهی ریشه شما اعتماد خواهد کرد که مراحل «ایجاد اعتماد» در مستندات را دنبال کنید.
س: استراتژی ادغام پیشنهادی برای وب در مقابل برنامه اندروید چیست؟
الف) کل درخواست باید سمت سرور تولید شود. در اندروید، از API Credman استفاده کنید؛ در وب، از API اعتبارنامههای دیجیتال (DC) استفاده کنید.
س: چه ابزارهای اشکالزدایی، ثبت وقایع و مشاهدهپذیری برای توسعهدهندگان در دسترس است؟
پاسخ: شرکا میتوانند از نام مستعار پشتیبانی wallet-identity-rp-support@google.com استفاده کنند. هیچ ابزار خاصی برای ثبت وقایع یا مشاهده ارائه نشده است.
اعتبارنامهها و دادهها
س: کدام شناسههای دیجیتال، صادرکنندگان و اعتبارنامهها توسط کشور و منطقه پشتیبانی میشوند؟
پاسخ: مناطق پشتیبانیشده را اینجا پیدا کنید: صادرکنندگان و گواهیهای پشتیبانیشده .
س: چه زمانی قصد دارید از اعتبارنامههای کشورها یا مناطق جدید پشتیبانی کنید؟
الف) ما به طور فعال در حال اضافه کردن مناطق جدید هستیم؛ برای بهروزرسانیها، صفحه صادرکنندگان پشتیبانیشده را بررسی کنید.
س: وقتی یک اعتبارنامه توسط صادرکننده بهروزرسانی میشود، آیا کاربر نهایی اعلانی دریافت میکند؟
الف) بله، به کاربر اطلاع داده میشود و بهروزرسانی بهطور خودکار اعمال میشود.
س: گوگل، به ویژه در زمینه GDPR، چه دادههای مربوط به اعتبارنامهها، در صورت وجود، را در سرورهای خود ذخیره میکند؟
الف) گوگل دادههای مربوط به اعتبارنامهها را در سرورهای خود ذخیره نمیکند؛ این دادهها به صورت محلی و ایمن در دستگاه کاربر ذخیره میشوند.
آزمایش و محیطها
س: چگونه میتوانیم به یک محیط سندباکس دسترسی پیدا کنیم تا جریان کامل سرتاسری را آزمایش کنیم؟
الف) محیط بازی در آدرس زیر باز است: حالت محیط بازی (Sandbox Mode ).
س: روند اضافه شدن شرکایی که در منطقهی رسماً راهاندازی شده مستقر نیستند به لیست مجاز برای آزمایش چگونه است؟
الف) شناسههای جیمیل کیف پولهای آزمایشی را به wallet-identity-rp-support@google.com ایمیل کنید.
س: فرآیند فعالسازی یک وبسایت یا برنامه آزمایشی برای اهداف نمایشی، که به هر کسی که دارای مجوز تولید است اجازه ارائه آن را میدهد، چگونه است؟
الف) شرکا باید مراحل استاندارد RP، از جمله یک ویدیوی نمایشی در محیط سندباکس، را تکمیل کنند.
تجربه کاربری (UX)
س: اگر کاربری هنگام شروع فرآیند تأیید هویت، شناسه دیجیتال یا برنامه کیف پول گوگل را نصب نکرده باشد، چه تجربهای خواهد داشت؟
الف) کاربرانی که برنامه را ندارند به فروشگاه Play هدایت میشوند. کسانی که شناسه ندارند میتوانند با استفاده از رابط کاربری نیمصفحه، یک جریان ورودی ایجاد کنند.
س: آیا میتوانیم قبل از نمایش گزینه تأیید، به صورت برنامهنویسی تشخیص دهیم که آیا کاربر شناسه دیجیتال در کیف پول خود دارد یا خیر؟
الف) خیر، API باید توسط کاربر فراخوانی شود تا از حریم خصوصی محافظت شود.
س: آیا میتوانیم از کاربر بخواهیم که قبل از ارائه اعتبارنامه، دستگاه خود را با استفاده از اطلاعات بیومتریک باز کند؟
الف) احراز هویت کاربر (بیومتریک، پین یا الگو) به طور پیشفرض الزامی است و نمیتوان آن را غیرفعال کرد.
س: آیا میتوان ترتیب ویژگیهای درخواستی را در صفحه رضایت کاربر سفارشی کرد؟
الف) خیر، گوگل والت آنها را به ترتیب حروف الفبا مرتب میکند.
امنیت و انطباق
س: مورد استفاده ما شامل اشتراکگذاری مجدد دادههای کاربر با اشخاص ثالث است. آیا این کار طبق شرایط خدمات مجاز است؟
پاسخ: بله، ممکن است محدودیتهایی اعمال شود، برای جزئیات بیشتر به شرایط خدمات ما مراجعه کنید.
س: چه اسنادی در مورد امنیت، قابلیت اطمینان و دسترسی به راهکارهای هویت دیجیتال برای اهداف انطباق ما موجود است؟
الف) شرکا میتوانند به بررسیهای امنیتی Trail of Bits مراجعه کنند.
ویژگیهای پیشرفته و نقشه راه
س: قابلیتهای اثبات دانش صفر (ZKP) برای تأیید سن با حفظ حریم خصوصی چیست؟
الف) اثبات دانش صفر (ZKP) یک روش رمزنگاری است که به یک فرد (اثباتکننده) اجازه میدهد تا به یک تأییدکننده ثابت کند که دارای یک قطعه اطلاعات هویتی خاص است یا یک معیار خاص (مثلاً بالای ۱۸ سال سن دارد، دارای مدرک معتبر است) را بدون آشکار کردن دادههای اصلی خود، برآورده میکند.
س: نسخههای مختلف مدارهای ZK چگونه مدیریت میشوند؟
الف) RPها باید سرویسهای تأییدکننده ZK را برای درخواست جدیدترین مدارهای موجود پیادهسازی کنند.
س: اشتراکگذاری و مدیریت اعتبارنامهها چگونه در چندین دستگاه، مانند تلفن و یک دستگاه پوشیدنی، انجام میشود؟
الف) اعتبارنامهها به یک دستگاه واحد اختصاص داده میشوند و قابل اشتراکگذاری نیستند.
دیگران
س: در صورت ابطال گذرنامه، گوگل چگونه ابطال کارت شناسایی را مدیریت میکند؟
پاسخ: کاربران میتوانند رمزهای عبور را از تنظیمات حساب گوگل حذف کنند؛ گم شدن دستگاهها میتواند برای لغو اعتبارنامهها گزارش شود.
س: ابطال مجوز mDL چگونه انجام میشود؟ آیا این کار به صورت آنی (realtime) انجام میشود؟
الف) میتواند توسط کاربر فعال شود یا توسط صادرکننده (DMV) اعمال شود. اگر دستگاه آنلاین باشد، بهصورت بلادرنگ (real-time) عمل میکند؛ در غیر این صورت، اشیاء امنیتی کوتاهمدت (MSO) منقضی میشوند.
س: سیاست کلیدی چرخش شغلی برای RP ها چیست؟
الف) تناوب سالانه توصیه میشود.
س: حداقل نسخه اندروید پشتیبانی شده برای API اعتبارنامههای دیجیتال چیست؟
الف) اندروید ۹ (سطح API 28) و بالاتر.
س: حداقل نسخه کروم که از API اعتبارنامههای دیجیتال پشتیبانی میکند، چیست؟
الف) کروم نسخه ۱۲۸ و بالاتر.
س: کدام مرورگرها از API اعتبارنامههای دیجیتال پشتیبانی میکنند؟
پاسخ: میتوانید جزئیات پشتیبانی مرورگر را اینجا پیدا کنید: https://digitalcredentials.dev/ecosystem-support
س: کدام کاربران میتوانند هنگام راهاندازی یک کشور جدید، شناسه اضافه کنند؟
الف) دسترسی بر اساس تنظیمات کشور کاربر در فروشگاه Play است.
س: آیا API اعتبارنامههای دیجیتال با iOS کار میکند؟
بله، این API با مرورگرهای پشتیبانیشده مانند سافاری کار میکند. با این حال، OpenID4VP توسط اپل پشتیبانی نمیشود.