סקירה כללית

ה-Digital Credentials Provisioning API מאורגן לפי שלושה מודלים עיקריים של משאבים:

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

כגורם מנפיק, אתם אחראים ליצירה ולניהול של המשאבים האלה לאורך מחזור החיים של אישור ה-DC.

הנחות

ההנחה העיקרית של ה-API הזה היא שהמכשיר משתמש בAndroid Identity Credential API כדי לאחסן מסמכים דיגיטליים שמוגדרים על ידי ISO/IEC 18013-5.

הערה: כל שיטה שמפנה אל MobileDriversLicense היא ספציפית ל-mDL. שיטות אחרות לא תלויות בסוג המסמך.

מודלים של משאבים

מכשיר

במודל של Digital Credentials Provisioning API, מכשיר לא מייצג פשוט מכשיר מבוסס-Android שבו משתמש מנהל את ה-DC שלו באמצעות אפליקציית Google Wallet. במקום זאת, הוא מיוצג כשילוב של הדברים הבאים:

• המכשיר הפיזי שמבוסס על Android.
• זוג מפתחות ציבורי/פרטי (שנקרא 'מפתח זהות').
  • המפתח הציבורי משמש את המנפיק לאימות הזהות של המכשיר.
  • המפתח הפרטי מאוחסן באחסון המאובטח של המכשיר.

כשמבצעים קריאות ל-API, שילוב של מכשיר ופרטי כניסה מזוהה באמצעות מזהה הפניה למכשיר (מאפיין deviceReferenceId).

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

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

מידע נוסף על האישור מופיע במסמכי העזרה בנושא Android IdentityCredential.

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

הגהה

הגהה מייצגת את השילוב של הפעולות הבאות:

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

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

בטבלה הבאה מפורטים הסטטוסים האפשריים של הגהה.

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

סטטוסים שמסומנים בכוכבית (*) עשויים להיות לא סופיים במקרים שבהם בודק אנושי טועה ומעדכן את הסטטוס באופן ידני.

בתרשים המצבים הבא מתואר רצף הסטטוסים האפשרי:

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

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

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

פרטי כניסה

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

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

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

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

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

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

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

פרטי הכניסה יכולים להיות באחד מהסטטוסים הבאים:

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

בתרשים המצבים הבא מתואר רצף הסטטוסים האפשרי:

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

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