Полиција, Шалтери за изнајмување, Работодавци, Осигурители: Зошто не смеат да гледаат исти податоци

Најголемата грешка во дизајнот на идната Меѓународна дозвола за управување со возило (МДВ) би било да се третира секој верификатор исто. Полицаец, шалтер за изнајмување автомобили, работодавец и осигурител не го поставуваат истото прашање — па затоа не треба да добиваат ист одговор.

Еден возач. Едно основно право на управување. Еден паричник. Но четири сосема различни верификатори:

• Полицаец на патот
• Шалтер за изнајмување автомобили при преземање
• Работодавец кој проверува право на користење на флота
• Осигурител кој разгледува барање за штета

Ако идната МДВ им прикажува исти податоци на сите четворица, системот веќе не успеал. Не затоа што акредитивот е несигурен, туку затоа што моделот на откривање е премногу едноставен.

Заедницата за стандарди веќе се оддалечува од тој едноставен модел. Работата на W3C за верификувани акредитиви го опишува екосистемот на издавачи, носители и верификатори, користејќи работодавци и веб-сајтови како примери за верификатори. Работата на ЕУ за мобилни возачки дозволи веќе ги третира патните проверки и изнајмувањето автомобили како одделни сценарија за верификација, вклучувајќи далечинско споделување однапред за изнајмување и лични проверки за полицијата. Архитектурата е веќе дизајнирана за повеќе видови верификатори. Грешката би биле да се дизајнира корисничкото искуство како да постои само еден вид.

Зошто физичката картичка нè научи погрешно да размислуваме

Физичката дозвола нè навикна на пристапот „прикажи сè”. Ја предаваш картичката. Другата личност го гледа она што е на картичката. Тоа е целата интеракција.

Тој пристап е прифатлив во хартиениот свет затоа што нема алтернатива. Станува неприфатлив во дигиталниот.

W3C VC Data Model 2.0 директно наведува: возачката дозвола може да содржи ID број, висина, тежина, датум на раѓање и домашна адреса — но тоа сепак може да биде многу повеќе од потребното за одредена трансакција. Клучни точки од тековните стандарди:

• Најдобра практика на W3C: поддржи селективно откривање и барај само она што е строго неопходно
• Насоки за заштита на податоци на ЕУ: обработката мора да биде ограничена на наведени цели, а обработените податоци мора да бидат неопходни и пропорционални
• Прв принцип на идната МДВ: ист акредитив не значи исто право на увид

Правиот модел е откривање засновано на политика

Ако сакате сериозна архитектура, вистинскиот модел е поблиску до контрола на пристап заснована на атрибути отколку до презентација на дигитална картичка.

NIST SP 800-205 ги дефинира одлуките за контрола на пристап како евалуации на атрибути поврзани со субјектот, објектот, бараната операција и условите на околината, наспроти политиката. Тоа е токму вистинската структура за идна МДВ:

• Субјект: возачот
• Објект: бараните полиња со податоци
• Дејство: не „види дозвола” во апстрактна смисла, туку нешто конкретно како „верификувај право на управување со возило категорија Б на патот” или „верификувај подобност за изнајмување за одредена резервација”
• Околина: патот, шалтерот за изнајмување, далечинска претходна проверка, воведување во флота и преглед на барање за штета по настан — тоа се различни околини и треба да водат до различни одлуки

NIST исто така напоменува дека системите на атрибути имаат потреба од гранулација, управување и механизми за намалување, групирање и минимизирање на атрибути.

Затоа идната МДВ не треба да прашува: Може ли овој верификатор да ја прочита дозволата? Треба да прашува: Кои тврдења може да ги прими овој верификатор, за која намена, во оваа околина, со какви правила за задржување?

Верификаторот треба прво да се идентификува пред да побара нешто

Идната МДВ не треба да почнува со тоа дека паричникот прикажува податоци. Треба да почнува со тоа дека верификаторот докажува кој е.

Архитектурата на EUDI е јасна по ова прашање. Засегнатите страни мора да:

• Регистрираат кои атрибути имаат намера да ги бараат и за која цел
• Добијат сертификати за пристап
• Се автентицираат кај паричникот пред какво и да е откривање
• Бидат проверени наспроти нивниот регистриран опсег, каде што е достапна информацијата за регистрација

Корисникот потоа може да види кој прашува, што се бара и дали барањето е во рамките на регистрираниот опсег.

Тековната работа на ETSI за сертификати на засегнати страни на паричникот го прави ова поконкретно. Сертификатот за регистрација на засегнатата страна на паричникот може да ја опише намената на засегнатата страна и атрибутите кои ги регистрирала за барање. Поврзаниот сертификат за пристап постои за да осигура дека барањето доаѓа од легитимна, овластена страна. ETSI исто така вклучува метаподатоци за засегнатата страна, како:

• Трговско име
• URI за поддршка
• Намена
• Овластувања
• URI на регистар
• Информации за надзорен орган

Втор принцип на идната МДВ: без идентитет на верификаторот, нема откривање.

Зошто екраните за согласност не се доволни

Овде постои уште една грешка: да се третира одобрувањето на корисникот исто со правна легитимност.

Архитектурата на EUDI изречно вели дека одобрувањето на корисникот за презентирање атрибути не смее да се третира како законска основа за обработка на лични податоци од страна на засегнатата страна. Засегнатата страна сепак мора да има своја законска основа. EUDI исто така бара одобрување на корисникот во сите случаи на употреба, вклучувајќи случаи каде засегнатата страна може да биде дел од органите за спроведување на законот или друга владина агенција.

Добар интерфејс на паричникот може да помогне, но не може сам да го реши прекумерното барање на верификаторот. Правилото мора да постои пред интерфејсот.

Затоа идната МДВ треба и двете:

• Криптографска автентикација на верификаторот за потврда на тоа кој прашува
• Ограничувања на политиката за тоа што таа категорија верификатори може да бара

Без двете, „изборот на корисникот” станува начин за пренесување на неуспехот на политиката врз поединецот.

1. Полиција: Верификувај право на управување, не целата личност

Сценариото со полицијата на патот е најфокусираното.

Прирачникот на ЕУ за мобилна возачка дозвола (мДВ) го опишува директно: полицијата или други службеници ја проверуваат дозволата кога е потребно, вклучувајќи валидност на дозволата и права за возила. Во патувањето на корисникот, службеникот ја верификува дозволата преку QR-поток, Bluetooth, Wi-Fi Aware или NFC. Тоа е фокусирана задача за верификација:

• Дали оваа личност е носителот?
• Дали акредитивот е валиден?
• Кои права и ограничувања за возила важат?

Стандардно дозволено:

• Ime и презиме
• Портрет
• Статус на дозволата
• Датуми на издавање и истекување
• Категории
• Ограничувања поврзани со управување
• Издавач и јурисдикција
• Резултат за свежина/статус

Стандардно недозволено:

• Домашна адреса
• Внатрешни идентификатори кои не се потребни за употреба на патот
• Несврзани атрибути од други потврди
• Историски дневници на презентации
• Комерцијални метаподатоци

Упатствата за имплементација на AAMVA ја нагласуваат точката за портретот: ако е побаран портрет и е ослободен кој и да е друг елемент, портретот треба да биде споделен за да може верификаторот да ги поврзе податоците со личноста која ги презентира. Истото упатство исто така вели дека засегнатите страни не смеат да го следат носителот на мДВ или употребата на мДВ освен каде е предвидено со закон.

Случајот со полицијата не е за тоа државата да прима сè. Тој е за тоа државата да прима специфични за управување податоци потребни за спроведување на сообраќајот. Тоа е важна разлика.

2. Шалтери за изнајмување: Подобност, потврда на идентитет и ништо непотребно

Случајот со изнајмувањето е подетален затоа што всушност постојат два момента: далечинска претходна проверка пред пристигнување и преземање кога личност или киоск ги предава клучевите.

Прирачникот на ЕУ за мДВ веќе ги моделира двата. Услугата за изнајмување автомобили може да побара мДВ заедно со доказ за идентитет за време на резервацијата, да ги валидира потврдите, а подоцна лично да го верификува клиентот при преземање пред да го предаде возилото. Корисниците можат да ги споделат своите мДВ со компании за изнајмување автомобили или лично или далечински однапред.

Шалтерот за изнајмување примарно нема потреба да истражува инцидент. Треба да одлучи: Можам ли да му го изнајмам ова возило на овој клиент според оваа резервација и политика?

Далечинската претходна проверка треба да вклучи:

• Поврзување на идентитетот
• Портрет или еквивалентен елемент за поврзување на идентитетот
• Релевантна категорија на возило
• Датуми на издавање и истекување
• Тековна валидност
• Можно прагова вредност за возраст или возрасна лента

Преземањето треба да потврди:

• Носителот е истата личност која ја завршила претходната проверка
• Тековна валидност
• Релевантни права

Стандардно не е потребно:

• Целосна домашна адреса кога профилот на резервацијата веќе содржи контакт-детали
• Целосен датум на раѓање каде е доволна потврда за возраст или возрасна лента
• Несврзани атрибути на идентитет
• Повторена повторна презентација на целосниот акредитив ако веќе постои потврда за резервација

Тековната архитектура на мДВ на NIST ја покажува засегнатата страна која користи DCQL за барање само на потребните атрибути, и изречно вели дека ова ја поддржува минимизацијата на податоци и согласноста на носителот со структурирање на барањето наместо третирање на акредитивот како единечна единица. AAMVA додава дека апликацијата треба јасно да покаже кои податоци биле побарани и дали верификаторот има намера да ги задржи информациите.

3. Работодавци: Категорија на верификатор, не отворање кон целосен идентитет

Прегледот на W3C го користи дигиталниот систем на работодавец кој проверува универзитетска диплома како пример за верификатор. Тоа нè потсетува дека верификацијата на работодавецот е веќе препознаен образец во екосистемите на акредитиви.

Работодавецот или операторот на флота може легитимно да треба да знае:

• Дали работникот тековно има право да управува со одредени категории возила
• Дали постојат клучни ограничувања
• Дали правото останува валидно

Тоа е реална деловна потреба. Но таа автоматски не оправдува постојан пристап до целосниот акредитив за управување, целосните податоци за идентитет или континуиран тек на повторни презентации.

NIST предупредува дека честото пренесување на повторно употреблив идентификатор и навикувањето на корисниците постојано да презентираат акредитив кој содржи идентитет е несакано, и вели дека секојдневната автентикација треба да се потпира на технологии дизајнирани за автентикација, како клучеви за пристап (passkeys). NIST ја претпочита локалната автентикација на уредот пред биометриско поклопување на страната на серверот, бидејќи подобро ја зачувува приватноста.

Идната МДВ не треба да стане значка за пристап на работното место.

За употреба од страна на работодавци и флоти, вистинскиот образец обично е:

• Проверка на право релевантно за работата
• Можна периодична потврда за усогласеност
• Можна тврдење дека носителот останува валиден за наведени категории
• Но не стандарден пренос на сите податоци на дозволата секогаш кога вработениот се најавува во систем или почнува смена

Усогласеноста на флотата е одделна категорија на засегнатa страна, со одделна намена и одделен профил на откривање.

4. Осигурители: Барањата за штета не се дозвола за континуирана видливост

Случајот со осигурувањето е честопати реален. Во материјалот за случаи на употреба на мДВ на ЕУ, осигурителите се јавуваат индиректно во сценариото со изнајмување: осигурителните компании бараат од компаниите за изнајмување автомобили да проверат дали лицето кое го изнајмува автомобилот има право да управува. Осигурувањето веќе влијае на текот на верификација на управувањето.

Но тоа не значи дека осигурителот треба да добие исти податоци како полицијата или постојано право на пристап до акредитивот.

Идната МДВ треба да ги третира осигурителите како одделна категорија верификатори со одделни намени:

• Преземање (underwriting)
• Верификација на ризик при изнајмување
• Обработка на барање за штета по настан
• Преглед за измами

Тоа не е иста цел. Според принципите за заштита на податоци на ЕУ, личните податоци мора да се собираат за наведени цели и ограничени на она што е неопходно и пропорционално за таа цел. Насоките на W3C за VC го достигнуваат истиот заклучок технички: верификаторите треба да бараат само она што е строго неопходно.

• Доказ дека дозволата била валидна во релевантниот момент
• Доказ за релевантно право на возило
• Доказ за поврзување на идентитетот каде е неопходно за барање
• Откривање специфично за барањето

Стандардно не е дозволено:

• Постојан пристап до основниот акредитив
• Повторена генеричка верификација секогаш кога клиентот комуницира со осигурителот
• Употреба на акредитивот за управување како токен за најава
• Собирање несврзани атрибути

Акредитивот за управување не е претплата за следење. И не треба тивко да стане таква.

Зошто посредниците мора да бидат видливи

Реалните пазари вклучуваат посредници. Платформи за изнајмување, продавачи на флоти, системи за човечки ресурси на работодавци и процесори на барања за штета кај осигурителите честопати работат преку трети страни.

Архитектурата на EUDI го решава ова на следниов начин:

• Ги третира посредниците како засегнати страни
• Бара нивна регистрација
• Бара атрибутите побарани за посредуваната засегната страна да бидат регистрирани
• Му ги прикажува на корисникот и посредникот и крајната засегната страна
• Им забранува на посредниците да складираат податоци за содржината на трансакцијата

Идната МДВ никогаш не смее да дозволи образец каде корисникот верува дека открива на компанијата за изнајмување, но во реалноста открива на невидлив синџир на посредници за верификација, процесори на аналитика и продавачи на барања.

ETSI помага овде. Неговиот модел на сертификат за засегнати страни на паричникот вклучува URI за поддршка, намена, URI на регистар и метаподатоци на надзорен орган. Тоа е видот на машински читлива инфраструктура потребна за корисниците да разберат кој всушност е на другиот крај на барањето и каде да одат кога ќе сакаат бришење или корекција.

Задржувањето е дел од контролата на пристап

Повеќето дискусии за селективно откривање завршуваат премногу рано. Се фокусираат на тоа што е откривено. Не се фокусираат доволно на тоа колку долго останува потоа.

Тековните насоки веќе конвергираат:

• AAMVA: паричникот мора јасно да му кажи на носителот кои податоци биле побарани и дали верификаторот има намера да ги задржи; засегнатите страни не смеат да ги следат носителите или употребата на мДВ освен каде е предвидено со закон
• W3C: софтверот на носителот треба да обезбедува дневници на информациите споделени со верификаторите, за да можат да се идентификуваат прекумерни барања
• EUDI: корисниците треба да можат да пристапат до дневници на трансакции, да пријавуваат сомнителни барања и да бараат бришење

Класата на задржување треба да биде дел од самата политика на откривање:

• Полиција на пат: без задржување стандардно, освен законски оперативен запис
• Претходна проверка за изнајмување: запис на трансакција поврзан со резервацијата, а не повторно употреблива копија на идентитетот
• Усогласеност на флотата на работодавецот: запис за усогласеност или резултат на потврда, а не сирови податоци на акредитивот
• Барање за штета кај осигурителот: запис за барањето ограничен на барањето, а не постојан пристап

Идната МДВ која го игнорира задржувањето само делумно ја зачувува приватноста.

Што треба всушност да одлучи паричникот

Ако мораше да го сведам целиот овој напис на едно правило за имплементација, тоа би било ова:

Паричникот не треба да одговара на „Можам ли да го презентирам овој акредитив?” Треба да одговара на „Можам ли да го презентирам овој сет на тврдења на овој автентициран верификатор, за оваа намена, во овој контекст, под оваа класа на задржување?”

Таа одлука треба да биде водена барем од овие влезови:

• Идентитет на верификаторот
• Категорија на верификаторот
• Намена
• Регистриран опсег на атрибути
• Политика на откривање од издавачот, ако постои
• Околина (пат, преземање, далечинска, флота, барање)
• Одобрување на носителот
• Применлива политика за задржување

Стандардите веќе содржат голем дел од механизмите за ова: селективно откривање, автентикација на засегнатата страна, регистрирана намена, сертификати за пристап, евалуација на политика на откривање и барања поврзани со цел. Она што сè уште недостасува е дисциплината да се третираат тие делови како една кохерентна архитектура на откривање.

Основниот аргумент

Идната МДВ не треба да прашува дали може да се откријат податоци. Треба да прашува:

• Кој прашува?
• За каква цел?
• Врз основа на кое овластување?
• Во кој контекст?
• Со какви последици за задржување?

Полицијата, шалтерите за изнајмување, работодавците и осигурителите не се четири лога на другиот крај на барање. Тие се четири различни модели на ризик, четири различни правни контексти, четири различни причини за прашување — и треба да произведат четири различни сетови на откривање.

Тоа не е непотребна сложеност. Тоа е тоа како изгледа современ акредитив за управување кога ќе престане да го третира секој верификатор исто.