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

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

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

• שוטר בצד הדרך
• דלפק השכרת רכב בנקודת האיסוף
• מעסיק הבודק כשירות לצי רכב
• מבטח הבוחן תביעה

אם ה-IDP העתידי יציג את אותם הנתונים לכל ארבעתם, המערכת כבר נכשלה. לא משום שהאישור אינו מאובטח, אלא משום שמודל הגילוי פשוט מדי.

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

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

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

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

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

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

המודל הנכון הוא גילוי מבוסס מדיניות

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

NIST SP 800-205 מגדיר החלטות בקרת גישה כהערכות של תכונות הקשורות לנושא, לאובייקט, לפעולה המבוקשת ולתנאי הסביבה, אל מול מדיניות. זוהי בדיוק המבנה הנכון ל-IDP עתידי:

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

NIST מציין גם שמערכות תכונות זקוקות לפירוט, לממשל ולמנגנונים לצמצום, קיבוץ ומינימיזציה של תכונות.

לכן ה-IDP העתידי לא ישאל: האם מאמת זה יכול לקרוא את הרישיון? הוא ישאל: אילו טענות רשאי מאמת זה לקבל, לאיזה שימוש מיועד, באיזו סביבה, ועם אילו כללי שמירה?

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

ה-IDP העתידי לא יתחיל בכך שהארנק יציג נתונים. הוא יתחיל בכך שהמאמת יוכיח מי הוא.

ארכיטקטורת EUDI ברורה בנקודה זו. הצדדים המסתמכים חייבים:

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

המשתמש יוכל אז לראות מי שואל, מה מבוקש, והאם הבקשה נמצאת בתחום הרישום.

עבודת תעודת ה-wallet-relying-party של ETSI הנוכחית הופכת זאת לקונקרטי יותר. תעודת רישום של צד מסתמך על ארנק יכולה לתאר את השימוש המיועד של הצד המסתמך ואת התכונות שנרשם לבקש. תעודת הגישה הקשורה קיימת כדי להבטיח שהבקשה מגיעה מצד לגיטימי ומורשה. ETSI כולל גם מטא-נתונים של הצד המסתמך כגון:

• שם מסחרי
• URI תמיכה
• שימוש מיועד
• זכאויות
• URI רישום
• מידע על רשות פיקוח

העיקרון השני של IDP עתידי: ללא זיהוי מאמת, אין גילוי.

מדוע מסכי הסכמה אינם מספיקים

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

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

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

לכן IDP עתידי זקוק לשניהם:

• אימות קריפטוגרפי של המאמת לאישור מי שואל
• אילוצי מדיניות על מה שקטגוריית המאמת רשאית לבקש

ללא שניהם, “בחירת המשתמש” הופכת לדרך להעביר כשל מדיניות אל הפרט.

1. משטרה: אמת את הזכות לנהוג, לא את האדם כולו

תרחיש בדיקת המשטרה בצד הדרך הוא הממוקד ביותר.

מדריך ה-mDL של האיחוד האירופי מתאר זאת ישירות: משטרה או פקידים אחרים בודקים את הרישיון כנדרש, כולל תוקף הרישיון וזכאויות הרכב. במסע המשתמש, השוטר מאמת את הרישיון באמצעות זרימה המופעלת על ידי QR, Bluetooth, Wi-Fi Aware, או NFC. זוהי משימת אימות ממוקדת:

• האם אדם זה הוא המחזיק?
• האם האישור תקף?
• אילו זכאויות והגבלות רכב חלות?

מותר כברירת מחדל:

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

אסור כברירת מחדל:

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

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

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

2. דלפקי השכרה: כשירות, התאמת זהות, ולא כלום מיותר

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

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

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

הבדיקה המקדימה מרחוק צריכה לכלול:

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

האיסוף צריך לאשר:

• המחזיק הוא אותו האדם שהשלים את הבדיקה המקדימה
• תוקף נוכחי
• זכאויות רלוונטיות

אינו נדרש כברירת מחדל:

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

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

3. מעסיקים: קטגוריית מאמת, לא פתיחה לזהות מלאה

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

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

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

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

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

IDP עתידי לא יהפוך לתג כניסה לסביבת עבודה.

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

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

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

4. מבטחים: תביעות אינן הרשאה לנראות רציפה

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

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

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

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

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

דוגמאות לגיטימיות וספציפיות לאירוע:

• הוכחה שהרישיון היה בתוקף ברגע הרלוונטי
• הוכחת זכאות לרכב הרלוונטי
• הוכחת קישור זהות כנדרש לתביעה
• גילוי ספציפי לתביעה

אסור כברירת מחדל:

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

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

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

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

ארכיטקטורת EUDI מטפלת בכך על ידי:

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

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

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

שמירה היא חלק מבקרת הגישה

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

ההנחיות הנוכחיות כבר מתכנסות:

• AAMVA: הארנק חייב לומר בבירור למחזיק אילו נתונים התבקשו והאם המאמת מתכוון לשמור אותם; בעלי עניין אסור שיעקבו אחרי מחזיקים או שימוש ב-mDL אלא כנדרש על פי חוק
• W3C: תוכנת המחזיק צריכה לספק יומנים של מידע שנשתף עם מאמתים, כדי שניתן יהיה לזהות בקשות מופרזות
• EUDI: משתמשים צריכים לקבל גישה ליומני עסקאות, לדווח על בקשות חשודות ולבקש מחיקה

מחלקת השמירה צריכה להיות חלק ממדיניות הגילוי עצמה:

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

IDP עתידי המתעלם משמירה הוא רק בחלקו משמר פרטיות.

מה שהארנק באמת צריך להחליט

אם הייתי צריך לצמצם את כל המאמר הזה לכלל יישום אחד, זה יהיה:

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

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

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

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

הטיעון המרכזי

ה-IDP העתידי לא צריך לשאול האם ניתן לגלות נתונים. הוא צריך לשאול:

• מי שואל?
• לאיזו מטרה?
• תחת איזו סמכות?
• באיזה הקשר?
• עם אילו השלכות שמירה?

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

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