למה בלוקצ'יין הוא אופציונלי עבור רישיון הנהיגה הבינלאומי (IDP) העתידי

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

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

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

מה שהתקנים אכן קובעים לגבי בלוקצ’יין

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

• מסדי נתונים מהימנים
• מסדי נתונים מבוזרים
• מסדי נתונים של זהות ממשלתית
• פנקסי חשבונות מבוזרים

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

זו נקודת המוצא הנכונה עבור IDP עתידי. השאלה השימושית אינה “בלוקצ’יין או ללא בלוקצ’יין?” אלא:

איזו שכבה באמת זקוקה לשקיפות, ואיזו שכבה בהחלט לא צריכה להפוך לתשתית ציבורית כברירת מחדל?

בלוקצ’יין הוא אוסף של תכונות, לא דרישה

הטעות הראשונה היא לטפל ב”בלוקצ’יין” כדרישה אחת. הוא אינו כך. הוא חבילה של תכונות אפשריות, כולל:

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

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

שלוש בעיות שאין לשלב

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

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

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

מה שקיפות תעודות מלמדת אותנו

מודל השקיפות האפקטיבי ביותר באינטרנט הציבורי אינו בלוקצ’יין צרכני. הוא שקיפות תעודות (CT).

RFC 9162 מתאר את CT כפרוטוקול לרישום ציבורי של תעודות שרת TLS כך שכל אחד יכול:

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

שיעור העיצוב המרכזי מ-CT: שקיפות היא בעלת ערך ביותר כאשר היא מתעדת התנהגות מנפיק וחומר אמון — לא פעילות משתמשי קצה.

מיושם על IDP עתידי, הדבר אומר רישום דברים כמו:

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

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

SCITT: למה שקיפות אינה זהה לאמת

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

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

SCITT ברור גם לגבי גבולות השקיפות:

• הצהרה רשומה מוכיחה רק שמנפיק הפיק ורשם אותה — לא שההצהרה נכונה לנצח.
• הצהרה חתומה מאוחרת יותר עשויה להחליף קודמת.
• שקיפות אינה מונעת ממנפיקים לא כנים או שנפרצו; היא מחזיקה אותם אחראים.

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

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

הפרדת הארכיטקטורה הנכונה עבור IDP עתידי

IDP עתידי צריך להפריד בין עניינים לארבע שכבות נפרדות:

1. רשומות מוסמכות של מי רשאי לנהוג (רשויות הרישוי הלאומיות)
2. רשומות אמון למפתחות מנפיק ומאמת
3. תשתית סטטוס לרעננות וביטול
4. שכבת שקיפות אופציונלית לביקורת ציבורית של מדיניות, עוגני אמון, קבלות והצהרות תאימות

ברגע שאתה מפריד בין שכבות אלה, שאלת הבלוקצ’יין הופכת הרבה יותר חדה. היא כבר אינה “האם ה-IDP העתידי צריך להיות על בלוקצ’יין?” אלא הופכת ל:

איזו שכבה, אם בכלל, מרוויחה באמת מביקורת ציבורית שניתן רק להוסיף אליה?

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

1. היא יוצרת אותות מעקב בני-קיימא

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

• מלחים (salts)
• ערכי hash
• מזהי ביטול
• מפתחות ציבוריים לקישור התקן
• חתימות
• חותמות זמן

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

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

2. היא חושפת אירועי ביטול ורעננות

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

ברירת המחדל הטובה יותר שרשימת Bitstring Status מציעה:

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

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

3. היא מבלבלת בין סטטוס אישור לסטטוס נהיגה משפטי

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

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

4. היא מכוונת לבעיית הממשל הלא-נכונה

זהות נהג חוצת-גבולות אינה בעיקרה בעיית קונסנזוס. היא בעיית ממשל:

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

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

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

זהו ניהול אמון ציבורי מפורש — לא ממשל מבוזר.

5. היא אינה פותרת את מציאות הכביש

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

הנחיות היישום של AAMVA מציינות כי:

• אחזור מהתקן עובד ללא קישוריות חיצונית הן עבור המחזיק והן עבור הקורא בזמן העסקה.
• ISO/IEC 18013-5 דורש תמיכה באחזור מהתקן.
• גישת המאמת למפתחות הציבוריים של המנפיק אינה צריכה להתרחש בזמן העסקה. ניתן להוריד מפתחות מראש.

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

מה צריך להיות שקוף ב-IDP עתידי

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

הפוך את אלה לשקופים כברירת מחדל:

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

אל תפוך את אלה לציבוריים כברירת מחדל:

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

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

דפוס טוב יותר: שקיפות סביב האקוסיסטמה, לא דרך האדם

ארכיטקטורה נקייה עבור IDP עתידי נראית כך:

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

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

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

ה-IDP העתידי צריך לאמץ את הרעיון הטוב ביותר מהבלוקצ’יין — אחריות ציבורית לתשתית — מבלי לאמץ את ברירת המחדל הגרועה שלו לאנשים: מעקב בר-קיימא וגלוי-עולמית.

בפועל, זה אומר:

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

זהו לא טיעון נגד בלוקצ’יין. זהו טיעון נגד יישום בלוקצ’יין על השכבה הלא-נכונה.

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