שאלות נפוצות בנושא זהות דיגיטלית ופרטי כניסה

בדף הזה תמצאו תשובות לשאלות נפוצות בנושא שילוב עם Google Wallet לזהויות דיגיטליות ולאישורים.

הצטרפות והתחלת העבודה

ש: מהו התהליך המפורט להצטרפות של שותף חדש כצד מסתמך (RP)?

תשובה: אפשר לעיין בשלבים במאמר איך מקבלים תעודות מזהות מ-Wallet באינטרנט.

ש: מהו משך הזמן האופייני לתהליך ההצטרפות של ספקי תוכן?

ת: בדרך כלל, תהליך ההצטרפות נמשך 3-5 ימי עסקים.

ש: איך אפשר לעקוב אחרי הסטטוס של הבקשה שלנו ל-Relying Party (RP) אחרי השליחה?

ת: אם לא קיבלת תשובה אחרי 5 ימים, אפשר לפנות לצוות התמיכה שלנו בכתובת wallet-identity-rp-support@google.com.

שאלה: איפה אפשר למצוא את טופס ההצטרפות של RP ואת מאמרי העזרה הרשמיים למפתחים?

א:

ש: איך המידע שאנחנו מספקים (כמו שם המוצר והלוגו) ישמש בחוויית השימוש במוצר?

ת: שם המוצר והלוגו מוצגים במסך ההסכמה שמוצג למשתמשים, כדי לעזור להם לזהות איזה צד נסמך מבקש את התעודה המזהה הדיגיטלית שלהם. יכול להיות שכתובות URL וקישורים למדיניות יוצגו גם בחוויית השימוש במוצר.

ש: האם אנחנו צריכים לחתום על התנאים וההגבלות אם אנחנו מתכננים להשתמש בסביבת ארגז החול רק לפיתוח ולבדיקות?

ת: לא, אישור התנאים וההגבלות הוא לא שלב חובה בבדיקה.

שאלה: איפה אפשר למצוא הטמעה לדוגמה, קוד לדוגמה או אפליקציית הדגמה כדי להתחיל?

א:

רשמים של מאמתים

ש: מהו רשם מאמת ואיך הוא פועל?

תשובה: רשם האימות פועל כרשות אישורים שמצרפת לקוחות במורד הזרם (End RPs). ה-RP של הצד השני לא מתקשר ישירות עם Google Wallet.

שאלה: מהו תהליך ההצטרפות הספציפי לרשם מאמת וללקוחות שלו?

תשובה: אפשר לעיין בשלבים במאמר מדריך לרשם מאמת.

ש: מה ההבדל בין השילוב הזה לבין שילוב ישיר של RP?

תשובה: רשמי אימות מנהלים את יחסי האמון של הלקוחות שלהם ומטפלים בשילוב עם Google Wallet בשמם, בעוד שספקי זהויות ישירים מנהלים את ההגדרה שלהם עם Google בעצמם.

ש: ב-Verifier Registrar, מי נכלל ברשימת ההיתרים בהגדרה של Google: ה-Verifier Registrar, ה-RP של משתמש הקצה או שניהם?

תשובה: Google מוסיפה לרשימת ההיתרים את אישור CA של רשות האישורים של רשם המאמת. לאחר מכן, רשם האישורים של המאמת מנפיק אישורי עלים חדשים לכל נקודת קצה במורד הזרם.

ש: איך זרימת הנתונים בין ספק הזהויות הסופי, רשם המאמתים ו-Google Wallet?

תשובה: רשם המאמת שולח את בקשת ה-API ל-Google Wallet עבור ה-RP של משתמש הקצה. ארנק Google מחזיר נתוני אישורים מוצפנים ל-Verifier Registrar, שמעבד אותם ושולח את האות הסופי ל-End RP.

תשובה: לא. רשם מאמת יכול לבחור שלא להציג את הפרטים שלו.

ש: מהם סוגי המפתחות והעקומות המותרים עבור רשויות אישורים בסיסיות ואישורי RP?

ת: צריך ליצור את האישורים באמצעות P-256 / ECDSA.

ש: האם אפשר להשתמש באישור חתימה של רשות ביניים בין אישור ה-CA הבסיסי שלנו לבין אישורי קצה של ספק הזהויות?

תשובה: כן. אפשר לאחסן באופן מאובטח אישור בסיס לטווח ארוך (למשל ב-HSM) כדי לחתום לעיתים רחוקות על אישורים תפעוליים ביניים. אפשר להשתמש באישורים הביניים האלה כדי לחתום על אישורי עלים של ספקי זהויות, וכך לאפשר החלפה קלה יותר במקרה של פריצה בלי להשפיע על אישור הבסיס.

שאלה: מהו משך החיים הנדרש של אישורים?

תשובה: תוקף של 10 שנים הוא תוקף מקובל לאישור CA בסיסי. בדרך כלל, מומלץ לחדש אישורי עלים של נקודות קצה של RP כל שנה בערך, כדי שאפשר יהיה להחליף אותם ביעילות אם יתעוררו בעיות.

ש: האם צריך לנהל אישור עלים נפרד לכל לקוח Relying Party (RP) בנפרד?

תשובה: כן. במהלך תקופת ההשקה הראשונית, המצטברים צריכים לנהל אישורים נפרדים לכל RP במורד הזרם. כך אפשר להגדיר תצוגה לכל RP ולעקוב אחרי מקרים של התנהלות פוגעת בצורה מדויקת. השיטה הזו מוסיפה עומס תפעולי בהיקף גדול, אבל אנחנו מתכוונים לבדוק חלופות אפשריות (כמו שימוש בגיבוב של מטא-נתונים של RP) אחרי ההשקה הראשונית.

ש: האם מותר לשותפים להחזיק בכמה אישורים פעילים בו-זמנית?

ת: כן, ההגדרה תומכת בכל מספר של אישורים פעילים לכל RP או צובר, וזה שימושי לשותפים שפועלים תחת שמות עסקיים שונים.

ש: באיזה פורמט צריך להיות השם המובחן (הנושא)?

תשובה: השם המובחן חייב להיות ייחודי באופן גלובלי לכל שותף. המזהה הזה הוא סטטי ומשמש את Google למעקב אחרי בקשות נכנסות של שותפים כדי להבטיח את האמינות של המערכת האקולוגית.

ש: איך פועל קישור הדומיין? האם צריך להטמיע מקורות באישור?

ת: אין צורך להטמיע דומיינים ישירות בתוך האישור עצמו. במקום זאת, אימות הדומיין מתבצע באמצעות פרמטר המקורות הצפויים בקריאה ל-API. בנוסף, אפשר לשייך כמה דומיינים לאותו אישור בצורה חלקה. בבקשות לא חתומות, הקישור מתבצע באמצעות שם הדומיין או שם חבילת האפליקציה (APK), לצד טביעת אצבע.

שאלה: האם אפשר להשמיט את פרטי האגרגטור מממשק המשתמש של האימות כדי ליצור חוויה עם מיתוג של צד שלישי?

ת: כן, הפרטים של האגרגטור (כמו שם, לוגו, כתובת URL ומדיניות פרטיות) הם אופציונליים לחלוטין במטא-נתונים של הכלי לאימות. כך מתקבל פתרון עם מיתוג מלא, שבו מוצגים למשתמש רק הפרטים של ספק הזהויות הסופי.

שאלה: מה צריך לספק כדי להתחיל לבדוק בסביבת ארגז החול?

תשובה: מבחינה טכנית, צריך לספק רק את אישור הבסיס של ארגז החול. ארגז החול מתוכנן לשקף באופן זהה את סביבת הייצור.

שאלה: מה ההבדל בתהליך ההצטרפות בין רשמי אימות (צד שלישי) לבין ספקי זהויות ישירים?

תשובה: אגרגטורים עוברים תהליך שונה במקצת. אחרי שמאשרים את התנאים וההגבלות הספציפיים של רשם מאמתים, תהליך ההצטרפות מתחלק לשני חלקים: טופס ראשי להגדרת הסטטוס שלכם כרשם מאמתים, ולאחר מכן טופס פשוט שנדרש לכל RP שאתם מצרפים. בדרך כלל, כל שליחה של RP דורשת הקלטת וידאו של השילוב, ותהליך הבדיקה נמשך בדרך כלל 2-3 ימי עסקים.

ש: האם אפשר לצרף לקוחות שמתכוונים לפעול כמתווכים או למכור מחדש שירותי אימות לישויות אחרות?

תשובה: לא. המודל הנוכחי של Google וההעדפה שלה הם לעבוד ישירות עם רשמי אימות (מצבירי אימות) ועם ספקי האימות הישירים שלהם, ולא לתמוך במודלים של משווקים או מתווכים משנה.

שילוב טכני ו-API

ש: מהו הפרוטוקול הבסיסי לבקשות? אילו גרסאות נתמכות?

ת: הפרוטוקול העיקרי הוא OpenID ל-Verifiable Presentations‏ (OpenID4VP) גרסה 1.0.

ש: אילו נספחים של ISO 18013-7 (למשל, נספח ב', ג', ד') נתמכים על ידי Google להצגת mDL?

תשובה: Google תומכת בנספח D [בשלב הטיוטה] (OpenID4VP באמצעות DC API).

ש: איך יוצרים מבנה נכון של בקשת API כדי לבקש כמה פרטי כניסה בהצגה אחת של משתמש?

ת: צריך לבקש את שני סוגי פרטי הכניסה באותו אובייקט שאילתה dcql באותה בקשת JSON.

ש: האם ה-API מאפשר לבקש פרטי כניסה כלליים בלי לפרט כל סוג אפשרי של פרטי כניסה?

תשובה: לא.

שאלה: איך ה-API מטפל באימות גיל? האם אפשר לבקש את תאריך הלידה המדויק, או רק אות שמציינת שהמשתמש הוא מעל גיל מסוים?

תשובה: שניהם נתמכים. אתם יכולים לבקש אות birth_date,‏ age_in_years או אות להבטחת שמירה על פרטיות 'מעל X'. אפשר גם להשתמש בהוכחות אפס ידע (ZKP) כדי לקבל אות אמת/שקר.

ש: מהן הדרישות לתשתית ה-PKI שלנו?

ת: ספקי זהויות צריכים PKI כדי לחתום על בקשות. רשמי אימות פועלים כרשות אישורים משלהם.

שאלה: האם אפשר להשתמש באישור קיים משלנו, או שצריך לקבל אישור חדש שחתום על ידי Google?

תשובה: ספקי זהויות צריכים לקבל אישור חדש שחתום על ידי Google או על ידי רשם מאמת. לרשמי מאמתים, Google תיתן אמון באישור הבסיס שלכם אם תפעלו לפי השלבים של 'ביסוס אמון' במסמכי התיעוד.

תשובה: צריך ליצור את הבקשה כולה בצד השרת. ב-Android, משתמשים ב-Credman API; באינטרנט, משתמשים ב-Digital Credentials (DC) API.

שאלה: אילו כלים לניפוי באגים, לרישום ביומן ולמעקב זמינים למפתחים?

ת: שותפים יכולים להשתמש בכינוי התמיכה wallet-identity-rp-support@google.com. לא מסופקים כלי רישום או כלי ניטור ספציפיים.

פרטי כניסה ונתונים

שאלה: אילו תעודות מזהות דיגיטליות, גורמים מנפיקים ואמצעי זיהוי נתמכים לפי מדינה ואזור?

תשובה: כאן מפורטים האזורים הנתמכים.

ש: מתי אתם מתכננים לתמוך במסמכי זהות ממדינות או מאזורים חדשים?

תשובה: אנחנו מוסיפים באופן פעיל אזורים חדשים. כדאי לעיין בדף של המנפיקים הנתמכים כדי לראות אם יש עדכונים.

ש: כשגורם מנפיק מעדכן פרטי כניסה, האם משתמש הקצה מקבל התראה?

ת: כן, המשתמש מקבל הודעה והעדכון מוחל באופן אוטומטי.

ש: אילו נתוני אישורים, אם בכלל, Google מאחסנת בשרתים שלה, במיוחד בהקשר של GDPR?

תשובה: Google לא שומרת נתונים שקשורים לפרטי הכניסה בשרתים שלה. הנתונים מאוחסנים באופן מקומי ומאובטח במכשיר של המשתמש.

בדיקות וסביבות

שאלה: איך מקבלים גישה לסביבת ארגז חול כדי לבדוק את התהליך המלא מקצה לקצה?

תשובה: ארגז החול פתוח בכתובת: מצב ארגז חול.

ש: מה התהליך להוספת שותפים שלא נמצאים באזור שבו הושקה התוכנית באופן רשמי לרשימת ההיתרים לצורך בדיקה?

תשובה: שולחים אימייל עם מזהי Gmail של ארנקים לבדיקה אל wallet-identity-rp-support@google.com.

ש: מה התהליך להפעלת אתר או אפליקציה לצורכי הדגמה, כך שכל מי שיש לו אישור הפקה יוכל להציג אותם?

תשובה: השותפים צריכים להשלים את תהליך ההצטרפות הרגיל לתוכנית השותפים, כולל הדגמה של סרטון בסביבת ארגז חול.

חוויית משתמש (UX)

שאלה: מה חוויית המשתמש אם למשתמש אין תעודה מזהה דיגיטלית או את אפליקציית Google Wallet כשהוא מתחיל תהליך אימות?

ת: משתמשים שלא התקינו את האפליקציה מועברים לחנות Play. משתמשים שאין להם מזהה יכולים ליצור אותו בתהליך באמצעות ממשק המשתמש של חצי המסך.

ש: האם אפשר לזהות באופן אוטומטי אם למשתמש יש תעודה מזהה דיגיטלית ב-Wallet לפני שמציגים לו את אפשרות האימות?

תשובה: לא, כדי להגן על הפרטיות, המשתמש צריך להפעיל את ה-API.

ש: האם אפשר לדרוש מהמשתמש לבטל את נעילת המכשיר באמצעות נתונים ביומטריים לפני הצגת פרטי הכניסה?

ת: אימות משתמש (ביומטרי, קוד אימות או קו ביטול נעילה) נדרש כברירת מחדל ואי אפשר להשבית אותו.

תשובה: לא, Google Wallet מסדר אותם מחדש לפי סדר אלפביתי.

אבטחה ותאימות

שאלה: בתרחיש השימוש שלנו, אנחנו משתפים מחדש נתוני משתמשים עם צדדים שלישיים. האם זה מותר לפי התנאים וההגבלות?

ת: כן, יכול להיות שיחולו הגבלות. לפרטים נוספים, אפשר לעיין בתנאים ובהגבלות שלנו.

שאלה: אילו מסמכים זמינים לגבי האבטחה, המהימנות והנגישות של פתרונות הזהות הדיגיטלית למטרות התאימות שלנו?

ת: שותפים יכולים לעיין בביקורות האבטחה של Trail of Bits.

תכונות מתקדמות ומפת דרכים

שאלה: מהן היכולות של הוכחות אפס ידע (ZKP) לאימות גיל תוך שמירה על הפרטיות?

תשובה: הוכחת אפס ידע (ZKP) היא שיטה קריפטוגרפית שמאפשרת לאדם (המוכיח) להוכיח למאמת שיש לו פיסת מידע מסוימת לגבי הזהות שלו או שהוא עומד בקריטריון ספציפי (למשל, שהוא מעל גיל 18 או שיש לו אישור תקף), בלי לחשוף את הנתונים הבסיסיים בפועל.

ש: איך המערכת מטפלת בגרסאות שונות של מעגלי ZK?

ת: ספקי זהויות צריכים להטמיע שירותי אימות ZK כדי לבקש את המעגלים הזמינים העדכניים ביותר.

שאלה: איך עובד שיתוף וניהול של פרטי כניסה בכמה מכשירים, כמו טלפון ומכשיר לביש?

תשובה: פרטי הכניסה מוקצים למכשיר יחיד ואי אפשר לשתף אותם.

אחרים

ש: איך Google מטפלת בביטולים של מסמכי זיהוי אם דרכון בוטל?

תשובה: המשתמשים יכולים למחוק כרטיסים בהגדרות של חשבון Google. אפשר לדווח על מכשירים שאבדו כדי לבטל את פרטי הכניסה.

ש: איך מתבצעת ביטול של mDL? האם זה בזמן אמת?

תשובה: יכול להיות שההפעלה תהיה על ידי המשתמש או על ידי המנפיק (DMV). העדכון מתבצע בזמן אמת אם המכשיר מחובר לאינטרנט. אחרת, תוקף האובייקטים הקצרים של האבטחה (MSO) יפוג.

שאלה: מהי מדיניות רוטציית המפתחות עבור ספקי זהויות?

ת: מומלץ להשתמש בסבב שנתי.

שאלה: מהי גרסת Android המינימלית שנתמכת ב-Digital Credentials API?

תשובה: Android מגרסה 9 (רמת API‏ 28) ואילך.

שאלה: מהי גרסת Chrome המינימלית שתומכת ב-Digital Credentials API?

תשובה: Chrome מגרסה 128 ואילך.

שאלה: באילו דפדפנים יש תמיכה ב-API של אישורים דיגיטליים?

תשובה: פרטים על תמיכה בדפדפן זמינים כאן: https://digitalcredentials.dev/ecosystem-support

ש: אילו משתמשים יוכלו להוסיף מזהה כשמשיקים מדינה חדשה?

ת: הגישה מבוססת על הגדרת המדינה של המשתמש בחנות Play.

שאלה: האם Digital Credentials API פועל עם iOS?

ת: כן, ה-API פועל בדפדפנים נתמכים כמו Safari. עם זאת, אפל לא תומכת ב-OpenID4VP.