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

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

הדרכה למשתמשים חדשים והתחלת העבודה

שאלה: מה התהליך ששותף חדש צריך לעבור כדי להצטרף כגורם מסתמך (RP)?

תשובה: פועלים לפי המדריך המפורט: בחירת הנתיב.

שאלה: כמה זמן נמשך בדרך כלל תהליך ההצטרפות של שותף הדיווח?

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

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

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

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

א:

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

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

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

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

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

א:

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

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

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

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

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

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

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

שאלה: במרשם הגורמים המאמתים, מי מתווסף לרשימת ההיתרים בהגדרות של Google: מרשם הגורמים המאמתים, הצד המסתמך הסופי או שניהם?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שאלה: מה הפורמט של השם הייחודי (נושא)?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תשובה: לא.

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

תשובה: שתי האפשרויות נתמכות. אתם יכולים לבקש את 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 כדי לפנות לתמיכה. לא מסופקים כלי רישום ביומן או כלי ניטור ספציפיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אחרים

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

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

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

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

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

תשובה: מומלץ להחליף את המפתחות פעם בשנה.

שאלה: מהי גרסת 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.