پلیس، میزهای اجاره خودرو، کارفرمایان، بیمه‌گران: چرا نباید داده‌های یکسانی ببینند

بزرگ‌ترین اشتباه طراحی در گواهینامه رانندگی بین‌المللی (IDP) آینده، این خواهد بود که همه تأییدکنندگان را یکسان فرض کنیم. یک مأمور پلیس، یک میز اجاره خودرو، یک کارفرما و یک بیمه‌گر سؤال یکسانی نمی‌پرسند — پس نباید پاسخ یکسانی دریافت کنند.

یک راننده. یک حق بنیادی برای رانندگی. یک کیف پول. اما چهار تأییدکننده بسیار متفاوت:

• یک مأمور پلیس در کنار جاده
• یک میز اجاره خودرو در هنگام تحویل
• یک کارفرما که واجد شرایط بودن برای ناوگان را بررسی می‌کند
• یک بیمه‌گر که یک ادعا را بررسی می‌کند

اگر IDP آینده داده‌های یکسانی به هر چهار نفر نشان دهد، سیستم از پیش شکست خورده است. نه به این دلیل که مدرک ناامن است، بلکه به این دلیل که مدل افشای اطلاعات بیش از حد ساده است.

جامعه استانداردسازی در حال حرکت از آن مدل ساده است. کار اعتبارنامه‌های قابل تأیید کنسرسیوم جهانی وب (W3C) اکوسیستم صادرکنندگان، دارندگان و تأییدکنندگان را توصیف می‌کند و از کارفرمایان و وب‌سایت‌ها به عنوان نمونه‌هایی از تأییدکنندگان استفاده می‌کند. کار گواهینامه رانندگی موبایل اتحادیه اروپا از پیش بررسی‌های کنار جاده و اجاره خودرو را به عنوان سناریوهای تأیید جداگانه در نظر می‌گیرد، از جمله اشتراک‌گذاری پیشاپیش از راه دور برای اجاره و بررسی‌های حضوری برای پلیس. معماری از پیش برای انواع مختلف تأییدکننده طراحی شده است. اشتباه این خواهد بود که تجربه کاربری را طوری طراحی کنیم که گویی فقط یک نوع وجود دارد.

چرا کارت فیزیکی ما را به تفکر نادرست عادت داد

یک گواهینامه فیزیکی ما را به رویکرد «نشان دادن همه چیز» عادت داده است. کارت را تحویل می‌دهید. طرف مقابل آنچه را که روی کارت است می‌بیند. این تمام تعامل است.

این رویکرد در دنیای کاغذی قابل قبول است زیرا هیچ جایگزینی وجود ندارد. اما در دنیای دیجیتال غیرقابل قبول می‌شود.

مدل داده W3C VC نسخه ۲.۰ به صراحت بیان می‌کند: یک گواهینامه رانندگی ممکن است شامل شماره شناسایی، قد، وزن، تاریخ تولد و آدرس منزل باشد — اما این هنوز هم می‌تواند بسیار بیشتر از آنچه برای یک تراکنش مشخص لازم است باشد. نکات کلیدی از استانداردهای فعلی:

• بهترین روش W3C: پشتیبانی از افشای انتخابی، و درخواست تنها آنچه کاملاً ضروری است
• راهنمای حفاظت از داده اتحادیه اروپا: پردازش باید به اهداف مشخص محدود شود، و داده‌های پردازش‌شده باید ضروری و متناسب باشند
• اصل اول یک IDP آینده: مدرک یکسان به معنای حق بازرسی یکسان نیست

مدل صحیح، افشا بر اساس سیاست است

اگر می‌خواهید یک معماری جدی داشته باشید، مدل صحیح به کنترل دسترسی مبتنی بر ویژگی نزدیک‌تر است تا به ارائه کارت دیجیتال.

NIST SP 800-205 تصمیمات کنترل دسترسی را به عنوان ارزیابی ویژگی‌های مرتبط با موضوع، شیء، عملیات درخواست‌شده و شرایط محیطی در برابر سیاست تعریف می‌کند. این دقیقاً ساختار مناسب برای یک IDP آینده است:

• موضوع: راننده
• شیء: فیلدهای داده درخواست‌شده
• اقدام: نه «دیدن گواهینامه» به صورت انتزاعی، بلکه چیزی مشخص مانند «تأیید حق رانندگی در دسته B در کنار جاده» یا «تأیید واجد شرایط بودن برای اجاره یک رزرو»
• محیط: کنار جاده، میز اجاره، بررسی پیشاپیش از راه دور، ورود به ناوگان و بررسی ادعا پس از خسارت، محیط‌های متفاوتی هستند و باید به تصمیمات متفاوتی منجر شوند

NIST همچنین خاطرنشان می‌کند که سیستم‌های ویژگی به دانه‌بندی، حاکمیت و مکانیزم‌هایی برای کاهش، گروه‌بندی و به حداقل رساندن ویژگی‌ها نیاز دارند.

بنابراین IDP آینده نباید بپرسد: آیا این تأییدکننده می‌تواند گواهینامه را بخواند؟ باید بپرسد: کدام ادعاها ممکن است این تأییدکننده دریافت کند، برای کدام کاربرد مورد نظر، در این محیط، با چه قوانین نگهداری؟

یک تأییدکننده باید قبل از هر درخواستی هویت خود را اثبات کند

IDP آینده نباید با نشان دادن داده توسط کیف پول آغاز شود. باید با اثبات هویت تأییدکننده آغاز شود.

معماری EUDI در این مورد صریح است. طرف‌های متکی باید:

• ثبت کنند که قصد درخواست چه ویژگی‌هایی را دارند و برای چه هدفی
• گواهی‌های دسترسی دریافت کنند
• قبل از هر افشایی در کیف پول احراز هویت کنند
• در برابر محدوده ثبت‌شده خود بررسی شوند، در صورتی که اطلاعات ثبت‌نام موجود باشد

کاربر می‌تواند ببیند چه کسی سؤال می‌کند، چه چیزی درخواست می‌شود و آیا درخواست در محدوده ثبت‌شده است.

کار فعلی ETSI در زمینه گواهی طرف متکی کیف پول این را ملموس‌تر می‌کند. یک گواهی ثبت طرف متکی کیف پول می‌تواند کاربرد مورد نظر طرف متکی و ویژگی‌هایی که برای درخواست ثبت کرده را توصیف کند. گواهی دسترسی مرتبط برای اطمینان از اینکه درخواست از یک طرف مجاز و قانونی می‌آید وجود دارد. ETSI همچنین شامل فراداده طرف متکی مانند:

• نام تجاری
• آدرس اینترنتی پشتیبانی
• کاربرد مورد نظر
• اختیارات
• آدرس اینترنتی ثبت
• اطلاعات مرجع نظارتی

اصل دوم یک IDP آینده: بدون هویت تأییدکننده، هیچ افشایی صورت نمی‌گیرد.

چرا صفحه‌های رضایت کافی نیستند

اشتباه دیگری هم اینجا وجود دارد: یکی دانستن تأیید کاربر با مشروعیت قانونی.

معماری EUDI صراحتاً می‌گوید تأیید کاربر برای ارائه ویژگی‌ها نباید به عنوان مبنای قانونی برای پردازش داده‌های شخصی توسط طرف متکی تلقی شود. طرف متکی باید همچنان مبنای قانونی خاص خود را داشته باشد. EUDI همچنین در تمام موارد کاربرد، از جمله مواردی که طرف متکی ممکن است بخشی از مجری قانون یا یک سازمان دولتی دیگر باشد، به تأیید کاربر نیاز دارد.

یک رابط کیف پول خوب می‌تواند کمک کند، اما نمی‌تواند تجاوز تأییدکننده را به تنهایی حل کند. قانون باید قبل از رابط وجود داشته باشد.

بنابراین یک IDP آینده به هر دو نیاز دارد:

• احراز هویت رمزنگاری تأییدکننده برای تأیید اینکه چه کسی درخواست می‌کند
• محدودیت‌های سیاستی بر آنچه آن دسته تأییدکننده مجاز به درخواست است

بدون هر دوی اینها، «انتخاب کاربر» تبدیل به روشی می‌شود برای انتقال شکست سیاستی به فرد.

۱. پلیس: تأیید حق رانندگی، نه تمام هویت فرد

سناریوی کنار جاده پلیس متمرکزترین سناریو است.

راهنمای mDL اتحادیه اروپا آن را مستقیماً توصیف می‌کند: پلیس یا سایر مقامات گواهینامه را در صورت لزوم بررسی می‌کنند، از جمله اعتبار گواهینامه و مجوزهای وسیله نقلیه. در مسیر کاربری، افسر گواهینامه را از طریق یک جریان فعال‌شده با کد QR، بلوتوث، Wi-Fi Aware یا NFC تأیید می‌کند. این یک وظیفه تأیید متمرکز است:

• آیا این شخص دارنده گواهینامه است؟
• آیا مدرک معتبر است؟
• چه مجوزها و محدودیت‌های وسیله نقلیه‌ای اعمال می‌شود؟

به طور پیش‌فرض مجاز:

• نام
• تصویر
• وضعیت گواهینامه
• تاریخ صدور و انقضا
• دسته‌ها
• محدودیت‌های مرتبط با رانندگی
• صادرکننده و حوزه قضایی
• نتیجه تازگی/وضعیت

به طور پیش‌فرض غیرمجاز:

• آدرس منزل
• شناسه‌های داخلی که برای استفاده کنار جاده لازم نیستند
• ویژگی‌های نامرتبط از سایر تأییدیه‌ها
• گزارش‌های تاریخی ارائه
• فراداده تجاری

راهنمای پیاده‌سازی AAMVA نکته مربوط به تصویر را تأیید می‌کند: اگر تصویر درخواست شود و هر عنصر دیگری آزاد شود، باید تصویر به اشتراک گذاشته شود تا تأییدکننده بتواند داده را به فردی که آن را ارائه می‌دهد ربط دهد. همین راهنما همچنین می‌گوید ذینفعان نباید دارندگان mDL یا استفاده از mDL را ردیابی کنند مگر آنجا که قانون الزامی کرده باشد.

پرونده پلیس در مورد دریافت همه چیز توسط دولت نیست. در مورد دریافت داده‌های خاص رانندگی مورد نیاز برای اجرای کنار جاده توسط دولت است. این تفاوت مهمی است.

۲. میزهای اجاره: واجد شرایط بودن، تطابق هویت، و هیچ چیز غیرضروری

پرونده اجاره جزئیات بیشتری دارد زیرا واقعاً دو لحظه وجود دارد: بررسی پیشاپیش از راه دور قبل از ورود، و تحویل وقتی یک فرد یا کیوسک کلیدها را تحویل می‌دهد.

راهنمای mDL اتحادیه اروپا هر دو را مدل‌سازی کرده است. یک سرویس اجاره خودرو ممکن است در طول رزرو از mDL در کنار مدرک هویت درخواست کند، تأییدیه‌ها را اعتبارسنجی کند و بعداً مشتری را در محل در هنگام تحویل قبل از آزاد کردن وسیله نقلیه تأیید کند. کاربران می‌توانند mDL خود را با شرکت‌های اجاره خودرو به صورت حضوری یا از راه دور از پیش به اشتراک بگذارند.

یک میز اجاره در درجه اول نیازی به بررسی یک حادثه ندارد. باید تصمیم بگیرد: آیا می‌توانم این وسیله نقلیه را تحت این رزرو و سیاست به این مشتری اجاره دهم؟

بررسی پیشاپیش از راه دور باید شامل باشد:

• پیوند هویت
• تصویر یا عنصر معادل مرتبط‌کننده هویت
• دسته وسیله نقلیه مرتبط
• تاریخ صدور و انقضا
• اعتبار فعلی
• احتمالاً یک آستانه سنی یا باند سنی

تحویل باید تأیید کند:

• دارنده همان فردی است که بررسی پیشاپیش را تکمیل کرده
• اعتبار فعلی
• مجوزهای مرتبط

به طور پیش‌فرض لازم نیست:

• آدرس کامل منزل وقتی پروفایل رزرو از پیش حاوی جزئیات تماس است
• تاریخ تولد کامل جایی که تأیید سن یا باند سنی کافی است
• ویژگی‌های هویت نامرتبط
• ارائه مجدد تکراری مدرک کامل اگر یک تأییدیه رزرو از قبل وجود داشته باشد

معماری فعلی mDL موسسه ملی استاندارد و فناوری آمریکا (NIST) نشان می‌دهد طرف متکی از DCQL برای درخواست تنها ویژگی‌های مورد نیاز استفاده می‌کند، و صراحتاً می‌گوید این از طریق ساختاردهی به درخواست به جای برخورد با مدرک به عنوان یک واحد واحد، از حداقل‌سازی داده و رضایت دارنده پشتیبانی می‌کند. AAMVA اضافه می‌کند که برنامه باید به وضوح نشان دهد چه داده‌ای درخواست شده و آیا تأییدکننده قصد نگهداری اطلاعات را دارد.

۳. کارفرمایان: یک دسته تأییدکننده، نه دریچه‌ای به هویت کامل

مرور کلی W3C از یک سیستم دیجیتال کارفرما که مدرک دانشگاهی را بررسی می‌کند به عنوان نمونه تأییدکننده استفاده می‌کند. این به ما یادآوری می‌کند که تأیید کارفرما از پیش یک الگوی شناخته‌شده در اکوسیستم‌های اعتبارنامه است.

یک کارفرما یا اپراتور ناوگان ممکن است به طور مشروع نیاز داشته باشد بداند:

• آیا یک کارگر در حال حاضر مجاز به رانندگی با دسته‌های خاصی از وسایل نقلیه است
• آیا محدودیت‌های کلیدی وجود دارد
• آیا مجوز همچنان معتبر است

این یک نیاز تجاری واقعی است. اما به طور خودکار دسترسی دائمی به اعتبارنامه رانندگی کامل، داده‌های هویت کامل، یا جریان مداوم ارائه‌های مکرر را توجیه نمی‌کند.

NIST هشدار می‌دهد که انتقال مکرر یک شناسه قابل استفاده مجدد و عادت دادن کاربران به ارائه مکرر یک اعتبارنامه حاوی هویت نامطلوب است، و می‌گوید احراز هویت روزانه باید به فناوری‌هایی طراحی‌شده برای احراز هویت متکی باشد، مانند کلیدهای عبور. NIST احراز هویت محلی دستگاه را نسبت به تطابق بیومتریک سمت سرور ترجیح می‌دهد زیرا حریم خصوصی را بهتر حفظ می‌کند.

یک IDP آینده نباید به یک کارت دسترسی محل کار تبدیل شود.

برای استفاده کارفرما و ناوگان، الگوی صحیح معمولاً این است:

• یک بررسی مجوز مرتبط با شغل
• شاید یک تأییدیه انطباق دوره‌ای
• شاید یک ادعا که دارنده برای دسته‌های مشخص همچنان معتبر است
• اما نه انتقال پیش‌فرض همه داده‌های گواهینامه هر بار که کارمند وارد یک سیستم می‌شود یا شیفت خود را شروع می‌کند

انطباق ناوگان یک دسته طرف متکی جداگانه است، با یک کاربرد مورد نظر جداگانه، و یک پروفایل افشای جداگانه.

۴. بیمه‌گران: ادعاها مجوز دید مستمر نیستند

پرونده بیمه اغلب واقعی است. در مواد موردی استفاده mDL اتحادیه اروپا، بیمه‌گران به طور غیرمستقیم در سناریوی اجاره ظاهر می‌شوند: شرکت‌های بیمه از شرکت‌های اجاره خودرو می‌خواهند بررسی کنند که آیا فردی که خودرو را اجاره می‌کند حق رانندگی دارد. بیمه از پیش بر جریان تأیید رانندگی تأثیر می‌گذارد.

اما این به این معنی نیست که یک بیمه‌گر باید داده‌های یکسانی با پلیس دریافت کند، یا حق دسترسی دائمی به اعتبارنامه داشته باشد.

یک IDP آینده باید بیمه‌گران را به عنوان یک دسته تأییدکننده جداگانه با کاربردهای مورد نظر جداگانه در نظر بگیرد:

• پذیره‌نویسی
• تأیید ریسک اجاره
• رسیدگی به ادعای پس از خسارت
• بررسی تقلب

اینها هدف یکسانی ندارند. طبق اصول حفاظت از داده اتحادیه اروپا، داده‌های شخصی باید برای اهداف مشخص جمع‌آوری شوند و به آنچه برای آن هدف لازم و متناسب است محدود شوند. راهنمای VC کنسرسیوم جهانی وب (W3C) از نظر فنی به همان نتیجه می‌رسد: تأییدکنندگان باید تنها آنچه را که کاملاً ضروری است درخواست کنند.

نمونه‌های مشروع و مرتبط با رویداد:

• اثبات اینکه گواهینامه در لحظه مربوطه معتبر بوده
• اثبات مجوز وسیله نقلیه مرتبط
• اثبات پیوند هویت در صورت لزوم برای یک ادعا
• افشای مختص ادعا

به طور پیش‌فرض مجاز نیست:

• دسترسی مستمر به اعتبارنامه پایه
• تأیید عمومی مکرر هر بار که مشتری با بیمه‌گر تعامل دارد
• استفاده از اعتبارنامه رانندگی به عنوان توکن ورود
• جمع‌آوری ویژگی‌های نامرتبط

یک اعتبارنامه رانندگی اشتراک نظارتی نیست. و نباید به آرامی تبدیل به یکی شود.

چرا واسطه‌ها باید قابل مشاهده باشند

بازارهای واقعی شامل واسطه‌ها می‌شوند. پلتفرم‌های اجاره، فروشندگان ناوگان، سیستم‌های منابع انسانی کارفرما و پردازشگران ادعاهای بیمه اغلب از طریق اشخاص ثالث عمل می‌کنند.

معماری EUDI این را با موارد زیر مدیریت می‌کند:

• در نظر گرفتن واسطه‌ها به عنوان طرف‌های متکی
• الزام آنها به ثبت‌نام
• الزام ثبت ویژگی‌های درخواست‌شده برای طرف متکی واسطه‌شده
• نشان دادن هم واسطه و هم طرف متکی نهایی به کاربر
• ممنوع کردن ذخیره‌سازی داده‌ها درباره محتوای تراکنش توسط واسطه‌ها

یک IDP آینده هرگز نباید الگویی را مجاز بداند که در آن کاربر فکر می‌کند به شرکت اجاره افشا می‌کند، اما در واقع به یک کارگزار تأیید نامرئی، پردازشگر تحلیلی و زنجیره فروشنده ادعاها افشا می‌کند.

ETSI در اینجا کمک می‌کند. مدل گواهی طرف متکی کیف پول آن شامل آدرس‌های اینترنتی پشتیبانی، کاربرد مورد نظر، آدرس‌های اینترنتی ثبت و فراداده مرجع نظارتی است. این نوع زیرساخت قابل خواندن توسط ماشین مورد نیاز است تا کاربران بفهمند چه کسی واقعاً در طرف دیگر درخواست است و در صورت تمایل به حذف یا اصلاح کجا مراجعه کنند.

نگهداری بخشی از کنترل دسترسی است

اکثر بحث‌ها درباره افشای انتخابی خیلی زود تمام می‌شوند. آنها بر آنچه افشا می‌شود تمرکز می‌کنند. به اندازه کافی بر مدت زمانی که بعد از آن باقی می‌ماند تمرکز نمی‌کنند.

راهنمای فعلی در حال همگرایی است:

• AAMVA: کیف پول باید به وضوح به دارنده بگوید چه داده‌ای درخواست شده و آیا تأییدکننده قصد نگهداری آن را دارد؛ ذینفعان نباید دارندگان یا استفاده از mDL را ردیابی کنند مگر آنجا که قانون الزامی کرده باشد
• W3C: نرم‌افزار دارنده باید گزارش‌هایی از اطلاعات به اشتراک گذاشته‌شده با تأییدکنندگان ارائه دهد تا درخواست‌های بیش از حد قابل شناسایی باشند
• EUDI: کاربران باید بتوانند به گزارش‌های تراکنش دسترسی داشته باشند، درخواست‌های مشکوک را گزارش دهند و درخواست پاک‌سازی کنند

دسته نگهداری باید بخشی از سیاست افشا باشد:

• پلیس کنار جاده: به طور پیش‌فرض بدون نگهداری فراتر از سابقه عملیاتی قانونی
• پیش‌بررسی اجاره: سابقه تراکنش مرتبط با رزرو، نه یک نسخه هویتی قابل استفاده مجدد
• انطباق ناوگان کارفرما: سابقه انطباق یا نتیجه تأییدیه، نه داده خام اعتبارنامه
• ادعای بیمه‌گر: سابقه ادعا محدود به ادعا، نه دسترسی دائمی

یک IDP آینده که نگهداری را نادیده می‌گیرد تنها تا حدی حریم خصوصی را حفظ می‌کند.

کیف پول واقعاً باید چه تصمیمی بگیرد

اگر بخواهم کل این مقاله را به یک قانون پیاده‌سازی تقلیل دهم، این خواهد بود:

کیف پول نباید به این سؤال پاسخ دهد که «آیا می‌توانم این اعتبارنامه را ارائه کنم؟» باید به این سؤال پاسخ دهد که «آیا می‌توانم این مجموعه از ادعاها را به این تأییدکننده احراز هویت‌شده، برای این کاربرد مورد نظر، در این زمینه، تحت این دسته نگهداری ارائه کنم؟»

آن تصمیم باید حداقل توسط این ورودی‌ها هدایت شود:

• هویت تأییدکننده
• دسته تأییدکننده
• کاربرد مورد نظر
• محدوده ویژگی ثبت‌شده
• سیاست افشا از صادرکننده، در صورت وجود
• محیط (کنار جاده، تحویل، از راه دور، ناوگان، ادعا)
• تأیید دارنده
• سیاست نگهداری قابل اعمال

استانداردها از پیش بیشتر ماشین‌آلات این کار را دارند: افشای انتخابی، احراز هویت طرف متکی، کاربرد مورد نظر ثبت‌شده، گواهی‌های دسترسی، ارزیابی سیاست افشا و درخواست‌های مقید به هدف. آنچه هنوز کم است انضباط برای برخورد با آن قطعات به عنوان یک معماری افشای منسجم است.

استدلال اصلی

IDP آینده نباید بپرسد آیا داده می‌تواند افشا شود. باید بپرسد:

• چه کسی درخواست می‌کند؟
• برای چه هدفی؟
• تحت کدام اختیار؟
• در کدام زمینه؟
• با چه پیامدهای نگهداری؟

پلیس، میزهای اجاره، کارفرمایان و بیمه‌گران چهار آرم در انتهای یک درخواست نیستند. آنها چهار مدل ریسک متفاوت، چهار زمینه قانونی متفاوت، چهار دلیل متفاوت برای پرسش هستند — و باید چهار مجموعه افشای متفاوت ایجاد کنند.

این پیچیدگی غیرضروری نیست. این شکل یک اعتبارنامه رانندگی مدرن است وقتی از برخورد با هر تأییدکننده به عنوان تأییدکننده یکسان دست برمی‌دارد.