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

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

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

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

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

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

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

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

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

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

א:

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

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

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

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

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

א:

רשמים מאמתים

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

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

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

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

שאלה: מה ההבדל בין זה לבין שילוב ישיר של שותף הזמנות?

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

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

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

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

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

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

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

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

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

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

שאלה: מה משך הזמן הנדרש לתוקף של אישורים?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שילוב טכני ו-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. אם מכשיר אבד, אפשר לדווח על כך כדי לבטל את פרטי הכניסה.

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

ת: המשתמש יכול להפעיל את העדכון או שהמנפיק (DMV) יכול לשלוח אותו. האימות מתבצע בזמן אמת אם המכשיר מחובר לאינטרנט. אחרת, התוקף של אובייקטי האבטחה קצרי המועד (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.