בדף הזה תמצאו תשובות לשאלות נפוצות על שילוב עם Google Wallet לניהול זהויות ואישורים דיגיטליים.
הדרכה למשתמשים חדשים ותחילת השימוש
ש: מהו התהליך המפורט להצטרפות של שותף חדש כצד מסתמך (RP)?
תשובה: אפשר לעיין בשלבים במאמר איך מקבלים תעודות מזהות מ-Wallet באינטרנט.
ש: מהו משך הזמן האופייני לתהליך ההצטרפות של ספקי תוכן?
ת: בדרך כלל, תהליך ההצטרפות נמשך 3-5 ימי עסקים.
ש: איך אפשר לעקוב אחרי הסטטוס של הבקשה שלנו ל-Relying Party (RP) אחרי השליחה?
ת: אם לא קיבלת תשובה אחרי 5 ימים, אפשר לפנות לצוות התמיכה שלנו בכתובת wallet-identity-rp-support@google.com.
ש: איפה אפשר למצוא את טופס ההצטרפות לתוכנית השותפים ואת מאמרי העזרה הרשמיים למפתחים?
א:
- טופס הצטרפות: טופס יצירת קשר עם שותפים מסתמכים של Google Wallet Identity
- מאמרי עזרה למפתחים: סקירה כללית על זהות דיגיטלית
ש: איך המידע שאנחנו מספקים (כמו שם המוצר והלוגו) ישמש בחוויית השימוש במוצר?
ת: שם המוצר והלוגו מוצגים במסך ההסכמה שמוצג למשתמשים, כדי לעזור להם לזהות איזה צד נסמך מבקש את התעודה המזהה הדיגיטלית שלהם. יכול להיות שכתובות URL וקישורים למדיניות יופיעו גם בחוויית השימוש במוצר.
ש: האם אנחנו צריכים לחתום על התנאים וההגבלות אם אנחנו מתכננים להשתמש בסביבת הארגז רק לפיתוח ולבדיקות?
ת: לא, אישור התנאים וההגבלות הוא לא שלב חובה בבדיקה.
שאלה: איפה אפשר למצוא הטמעה לדוגמה, קוד לדוגמה או אפליקציית הדגמה כדי להתחיל?
א:
- מאגר GitHub: Identity Reference Implementation (הטמעה לדוגמה של זהות).
- אתר לבדיקה: verifier.multipaz.org
רשמי אימות
ש: מהו רשם מאמת ואיך הוא פועל?
תשובה: רשם האימות פועל כרשות אישורים שמצרפת לקוחות במורד הזרם (End RPs). ה-End RP לא מתקשר ישירות עם Google Wallet.
שאלה: מהו תהליך ההצטרפות הספציפי לרשם מאמת וללקוחות שלו?
תשובה: אפשר לעיין בשלבים במאמר מדריך לרשם מאמת.
ש: מה ההבדל בין השילוב הזה לבין שילוב ישיר של RP?
תשובה: רשמי אימות מנהלים את יחסי האמון של הלקוחות שלהם ומבצעים את השילוב עם Google Wallet בשמם, בעוד שספקי זהויות ישירים מנהלים את ההגדרה שלהם בעצמם עם Google.
ש: ב-Verifier Registrar, מי נכלל ברשימת ההיתרים בהגדרות של Google: Verifier Registrar, ספק השירות (RP) של משתמש הקצה או שניהם?
תשובה: Google מוסיפה לרשימת ההיתרים את אישור CA של רשות האישורים של רשם המאמת. לאחר מכן, רשם המאמתים מנפיק אישורי עלים חדשים לכל נקודת קצה במורד הזרם.
ש: איך זרימת הנתונים בין ה-RP הסופי, רשם המאמתים ו-Google Wallet?
תשובה: רשם המאמת שולח את בקשת ה-API ל-Google Wallet עבור ספק ה-RP. ארנק Google מחזיר נתוני אישורים מוצפנים ל-Verifier Registrar, שמעבד אותם ושולח את האות הסופי ל-End RP.
ש: בפתרונות עם מיתוג משותף, האם צריך להציג את השם של רשם המאמת בתהליך קבלת ההסכמה מהמשתמש, או שאפשר להציג רק את השם של ה-RP הסופי?
תשובה: לא. רשם מאמת יכול לבחור שלא להציג את הפרטים שלו.
ש: אילו סוגי מפתחות ועקומות מותרים עבור רשויות אישורים בסיסיות ואישורי RP?
ת: צריך ליצור את האישורים באמצעות P-256 / ECDSA.
ש: האם אפשר להשתמש באישור חתימה של רשות ביניים בין אישור ה-CA הבסיסי שלנו לבין אישורי העלה של ספק הזהויות?
תשובה: כן. אפשר לאחסן באופן מאובטח אישור בסיס לטווח ארוך (למשל ב-HSM) כדי לחתום לעיתים רחוקות על אישורים תפעוליים ביניים. אחר כך אפשר להשתמש באישורים הביניים האלה כדי לחתום על אישורי עלים של RP, וכך לאפשר החלפה קלה יותר במקרה של פריצה בלי להשפיע על השורש.
שאלה: מהו משך החיים הנדרש של אישורים?
תשובה: תוקף של 10 שנים הוא תוקף מקובל לחלוטין לאישור CA בסיסי. בדרך כלל, מומלץ לחדש אישורי עלים של נקודות סיום של RP כל שנה בערך, כדי שאפשר יהיה להחליף אותם ביעילות אם יתעוררו בעיות.
ש: האם צריך לנהל אישור עלים נפרד לכל לקוח Relying Party (RP) בנפרד?
תשובה: כן. במהלך תקופת ההשקה הראשונית, המצטברים צריכים לנהל אישורים נפרדים לכל RP במורד הזרם. כך אפשר להגדיר תצוגה לכל דף תוצאות חיפוש ולעקוב אחרי מקרים של התנהלות פוגעת בצורה מדויקת. השיטה הזו מוסיפה עומס תפעולי בהיקף גדול, אבל אנחנו מתכוונים לבדוק חלופות אפשריות (כמו שימוש בגיבובים של מטא-נתונים של RP) אחרי ההשקה הראשונית.
ש: האם מותר לשותפים להחזיק בכמה אישורים פעילים בו-זמנית?
ת: כן, ההגדרה תומכת בכל מספר של אישורים פעילים לכל RP או צובר, וזה שימושי לשותפים שפועלים תחת שמות עסקיים שונים.
ש: באיזה פורמט צריך להיות השם המובחן (הנושא)?
תשובה: השם המובחן חייב להיות ייחודי באופן גלובלי לכל שותף. המזהה הזה הוא סטטי ומשמש את Google למעקב אחרי בקשות נכנסות משותפים ולווידוא האמינות של הסביבה העסקית.
ש: איך פועל קישור הדומיין? האם צריך להטמיע מקורות באישור?
ת: אין צורך להטמיע דומיינים ישירות בתוך האישור עצמו. במקום זאת, אימות הדומיין מתבצע באמצעות פרמטר המקורות הצפויים בקריאה ל-API. בנוסף, אפשר לשייך כמה דומיינים לאותו אישור בצורה חלקה. בבקשות לא חתומות, הקישור מתבצע באמצעות שם הדומיין או שם חבילת ה-APK של האפליקציה, לצד טביעת אצבע.
שאלה: האם אפשר להשמיט את פרטי האגרגטור מממשק המשתמש של האימות כדי ליצור חוויה עם מיתוג משותף?
ת: כן, פרטי האגרגטור (כמו שם, לוגו, כתובת URL ומדיניות פרטיות) הם אופציונליים לחלוטין במטא-נתונים של הכלי לאימות. כך מתקבל פתרון עם מיתוג מלא שבו מוצגים למשתמש רק הפרטים של ספק הזהויות הסופי.
שאלה: מה צריך לספק כדי להתחיל לבדוק בסביבת ארגז החול?
תשובה: מבחינה טכנית, צריך לספק רק את אישור הבסיס של ארגז החול. ארגז החול מתוכנן לשקף באופן זהה את סביבת הייצור.
שאלה: מה ההבדל בתהליך ההצטרפות בין רשמי אימות (מצברים) לבין ספקי זהויות ישירים?
תשובה: אגרגטורים עוברים תהליך שונה במקצת. אחרי שתאשרו את התנאים וההגבלות הספציפיים של רשם מאמתים, תהליך ההצטרפות יתחלק לשני חלקים: טופס ראשי להגדרת הסטטוס שלכם כרשם מאמתים, ולאחר מכן טופס פשוט שנדרש לכל RP שאתם מצרפים. בדרך כלל, כל שליחה של RP מחייבת הקלטת וידאו של השילוב, ותהליך הבדיקה נמשך בדרך כלל 2-3 ימי עסקים.
ש: האם אפשר לצרף לקוחות שמתכוונים לפעול כמתווכים או למכור מחדש שירותי אימות לישויות אחרות?
תשובה: לא. המודל הנוכחי של Google וההעדפה שלה הם לעבוד ישירות עם רשמי אימות (מצברים) ועם ספקי זהויות ישירים שלהם, ולא לתמוך במודלים של משווקים או מתווכים משניים.
שילוב טכני ו-API
ש: מהו הפרוטוקול הבסיסי לבקשות? אילו גרסאות נתמכות?
ת: הפרוטוקול העיקרי הוא OpenID ל-Verifiable Presentations (OpenID4VP) גרסה 1.0.
ש: אילו נספחים של ISO 18013-7 (למשל, נספח B, C, D) נתמכים על ידי Google בהצגת mDL?
ת: Google תומכת בנספח D [בשלב הטיוטה] (OpenID4VP באמצעות DC API).
ש: איך יוצרים בקשת API בצורה נכונה כדי לבקש כמה פרטי כניסה בהצגה אחת של המשתמש?
ת: צריך לבקש את שני סוגי האישורים באובייקט שאילתה dcql אחד באותה בקשת JSON.
ש: האם ה-API מאפשר לבקש פרטי כניסה כלליים בלי לפרט כל סוג אפשרי של פרטי כניסה?
תשובה: לא.
שאלה: איך ה-API מטפל באימות גיל? האם אפשר לבקש את תאריך הלידה המדויק, או רק אות 'מעל גיל X'?
תשובה: שניהם נתמכים. אתם יכולים לבקש את birth_date, את age_in_years או אות להבטחת שמירה על פרטיות 'מעל X'. אפשר גם להשתמש בהוכחות אפס ידע (ZKPs) כדי לקבל אות אמת/שקר.
שאלה: מהן הדרישות לתשתית ה-PKI שלנו?
ת: ספקי זהויות צריכים PKI כדי לחתום על בקשות. רשמי אימות פועלים כרשות אישורים משלהם.
שאלה: האם אפשר להשתמש באישור קיים משלנו, או שצריך לקבל אישור חדש שחתום על ידי Google?
תשובה: ספקי זהויות צריכים לקבל אישור חדש שחתום על ידי Google או על ידי רשם מאמת. לרשמי אימות, Google תיתן אמון בתעודת הבסיס שלכם אם תפעלו לפי השלבים בנושא 'ביסוס אמון' במסמכי התיעוד.
שאלה: מהי אסטרטגיית השילוב המומלצת לאתר לעומת אפליקציית Android?
תשובה: צריך ליצור את הבקשה כולה בצד השרת. ב-Android, משתמשים ב-Credman API; באינטרנט, משתמשים ב-Digital Credentials (DC) API.
שאלה: אילו כלים לניפוי באגים, לרישום ביומן ולמעקב זמינים למפתחים?
ת: שותפים יכולים להשתמש בכינוי התמיכה wallet-identity-rp-support@google.com. לא מסופקים כלי רישום או כלי ניטור ספציפיים.
פרטי כניסה ונתונים
שאלה: אילו תעודות מזהות דיגיטליות, גורמים מנפיקים ואישורים נתמכים לפי מדינה ואזור?
תשובה: כאן מפורטים האזורים הנתמכים.
ש: מתי אתם מתכננים לתמוך במסמכי זהות ממדינות או מאזורים חדשים?
תשובה: אנחנו מוסיפים באופן פעיל אזורים חדשים. כדאי לעיין בדף של המנפיקים הנתמכים כדי לראות אם יש עדכונים.
ש: כשגורם מנפיק מעדכן פרטי כניסה, האם משתמש הקצה מקבל התראה?
ת: כן, המשתמש מקבל הודעה והעדכון מוחל באופן אוטומטי.
בדיקות וסביבות
ש: איך מקבלים גישה לסביבת ארגז חול כדי לבדוק את התהליך המלא מקצה לקצה?
תשובה: ארגז החול פתוח בכתובת: Sandbox Mode.
ש: מה התהליך להוספת שותפים שלא נמצאים באזור שהושק באופן רשמי לרשימת ההיתרים לצורך בדיקה?
תשובה: שולחים אימייל עם מזהי Gmail של ארנקים לבדיקה אל wallet-identity-rp-support@google.com.
ש: מה התהליך להפעלת אתר או אפליקציה לצורכי הדגמה, כך שכל מי שיש לו אישור הפקה יוכל להציג אותם?
ת: השותפים צריכים להשלים את תהליך ההצטרפות הרגיל לתוכנית השותפים של YouTube, כולל הדגמה של סרטון בסביבת ארגז חול.
חוויית משתמש (UX)
שאלה: מה חוויית המשתמש אם למשתמש אין תעודה מזהה דיגיטלית או את אפליקציית Google Wallet כשהוא מתחיל תהליך אימות?
תשובה: משתמשים שלא התקינו את האפליקציה מועברים לחנות Play. משתמשים שאין להם מזהה יכולים ליצור אותו בתהליך באמצעות ממשק המשתמש של חצי המסך.
ש: האם אפשר לזהות באופן אוטומטי אם למשתמש יש תעודה מזהה דיגיטלית ב-Wallet לפני שמציגים לו את אפשרות האימות?
תשובה: לא, כדי להגן על הפרטיות, המשתמש צריך להפעיל את ה-API.
ש: האם אפשר לדרוש מהמשתמש לבטל את נעילת המכשיר באמצעות נתונים ביומטריים לפני הצגת פרטי הכניסה?
ת: אימות משתמש (ביומטרי, קוד אימות או קו ביטול נעילה) נדרש כברירת מחדל ואי אפשר להשבית אותו.
ש: אפשר להתאים אישית את הסדר של המאפיינים המבוקשים במסך בקשת ההסכמה מהמשתמש?
תשובה: לא, Google Wallet מסדר אותם מחדש לפי סדר אלפביתי.
אבטחה ותאימות
שאלה: בתרחיש השימוש שלנו, אנחנו משתפים מחדש נתוני משתמשים עם צדדים שלישיים. האם זה מותר לפי התנאים וההגבלות?
ת: כן, יכול להיות שיחולו הגבלות. לפרטים נוספים, אפשר לעיין בתנאים ובהגבלות שלנו.
שאלה: אילו מסמכים זמינים לגבי האבטחה, המהימנות והנגישות של פתרונות הזהות הדיגיטלית למטרות תאימות?
ת: שותפים יכולים לעיין בבדיקות האבטחה של Trail of Bits.
תכונות מתקדמות ומפת דרכים
שאלה: מהן היכולות של הוכחות אפס ידע (ZKP) לאימות גיל תוך שמירה על הפרטיות?
תשובה: הוכחת אפס ידע (ZKP) היא שיטה קריפטוגרפית שמאפשרת לאדם (המוכיח) להוכיח למאמת שיש לו פיסת מידע מסוימת לגבי הזהות שלו או שהוא עומד בקריטריון ספציפי (למשל, שהוא מעל גיל 18 או שיש לו אישור תקף) בלי לחשוף את הנתונים הבסיסיים בפועל.
ש: איך המערכת מטפלת בגרסאות שונות של מעגלי ZK?
ת: צדדים מסתמכים צריכים להטמיע שירותי אימות ZK כדי לבקש את המעגלים הזמינים העדכניים ביותר.
שאלה: איך עובד שיתוף פרטי הכניסה וניהול שלהם במכשירים שונים, כמו טלפון ומכשיר לביש?
ת: פרטי הכניסה מוקצים למכשיר יחיד ואי אפשר לשתף אותם.
אחרים
ש: איך Google מטפלת בביטולים של מסמכי זיהוי אם דרכון בוטל?
תשובה: המשתמשים יכולים למחוק כרטיסים מהגדרות חשבון Google. אפשר לדווח על מכשירים שאבדו כדי לבטל את פרטי הכניסה.
ש: איך מתבצעת ביטול של mDL? האם זה בזמן אמת?
תשובה: יכול להיות שהמשתמש יפעיל את העדכון או שהמנפיק (DMV) יבצע אותו. ההגנה היא בזמן אמת אם המכשיר מחובר לאינטרנט. אחרת, תוקף האובייקטים הקצרים של האבטחה (MSOs) יפוג.
ש: מהי מדיניות רוטציית המפתחות עבור RPs?
תשובה: מומלץ להשתמש בסבב שנתי.
שאלה: מהי גרסת Android המינימלית שנתמכת ב-Digital Credentials API?
תשובה: Android מגרסה 9 (רמת API 28) ואילך.
שאלה: מהי גרסת Chrome המינימלית שתומכת ב-Digital Credentials API?
תשובה: Chrome מגרסה 128 ומעלה.
שאלה: באילו דפדפנים יש תמיכה ב-Digital Credentials API?
תשובה: פרטים על תמיכה בדפדפן זמינים כאן: https://digitalcredentials.dev/ecosystem-support
ש: אילו משתמשים יוכלו להוסיף מזהה כשמשיקים מדינה חדשה?
ת: הגישה מבוססת על הגדרת המדינה של המשתמש בחנות Play.
שאלה: האם Digital Credentials API פועל עם iOS?
ת: כן, ה-API פועל בדפדפנים נתמכים כמו Safari. עם זאת, אפל לא תומכת ב-OpenID4VP.