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

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

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

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

Ако будућа МВД свим четворима приказује исте податке, систем је већ затајио. Не зато што је акредитив несигуран, већ зато што је модел откривања података прeједноставан.

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

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

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

Тај приступ је прихватљив у папирном свету јер нема алтернативе. У дигиталном постаје неприхватљив.

W3C VC модел података 2.0 директно наводи: возачка дозвола може садржати број личне карте, висину, тежину, датум рођења и кућну адресу — али то може и даље бити далеко више него што је потребно за одређену трансакцију. Кључне тачке из тренутних стандарда:

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

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

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

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

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

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

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

Верификатор треба да се идентификује пре него што нешто затражи

Будућа МВД не би требало да почиње тако да новчаник приказује податке. Требало би да почне тако да верификатор доказује ко је.

EUDI архитектура је јасна по том питању. Ослоњене стране морају да:

• Региструју које атрибуте намеравају да захтевају и у коју сврху
• Приме приступне сертификате
• Аутентификују се новчанику пре сваког откривања података
• Буду проверене у односу на регистровани обим, где је информација о регистрацији доступна

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

Тренутни рад ETSI-ја на сертификатима за ослоњене стране новчаника чини ово конкретнијим. Регистрациони сертификат ослоњене стране новчаника може описати намену ослоњене стране и атрибуте које је регистровала за захтевање. Повезани приступни сертификат постоји да би се осигурало да захтев долази од легитимне, овлашћене стране. ETSI такође укључује метаподатке ослоњене стране, као што су:

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

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

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

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

EUDI архитектура изричито наводи да одобрење корисника за представљање атрибута не сме бити третирано као законити основ за обраду личних података ослоњене стране. Ослоњена страна мора да има сопствени законити основ. EUDI такође захтева одобрење корисника у свим случајевима употребе, укључујући случајеве у којима ослоњена страна може бити dio органа за спровођење закона или другог државног органа.

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

Будућа МВД стога потребује обоје:

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

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

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

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

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

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

Подразумевано дозвољено:

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

Подразумевано забрањено:

• Кућна адреса
• Интерни идентификатори непотребни за употребу поред пута
• Неповезани атрибути из других атестација
• Историјски записи представљања
• Комерцијални метаподаци

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

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

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

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

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

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

Удаљена претходна провера треба да укључи:

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

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

• Да је носилац иста особа која је завршила претходну проверу
• Тренутну важност
• Релевантна права

Подразумевано непотребно:

• Пуна кућна адреса када профил резервације већ садржи контакт информације
• Пун датум рођења тамо где је довољно „старији од” или старосна група
• Неповезани атрибути идентитета
• Поновљено представљање пуног акредитива ако атестација резервације већ постоји

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

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

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

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

• Да ли је радник тренутно овлашћен да управља одређеним категоријама возила
• Да ли постоје кључна ограничења
• Да ли право остаје важеће

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

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

Будућа МВД не би требало да постане приступна значка на радном месту.

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

• Провера права релевантног за посао
• Евентуално периодична атестација усклађености
• Евентуално тврдња да носилац остаје важећи за наведене категорије
• Али не подразумевани пренос свих података о дозволи сваки пут када се запослени пријави у систем или почне смену

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

4. Осигуравачи: захтеви за штету нису дозвола за сталну видљивост

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

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

Будућа МВД треба да третира осигураваче као засебну категорију верификатора са засебним наменама:

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

То нису исте сврхе. Према принципима заштите података ЕУ, лични подаци морају бити прикупљени за наведене сврхе и ограничени на оно што је неопходно и пропорционално тој сврхи. Смернице W3C-а за ВЦ технички достижу исти закључак: верификатори треба да захтевају само оно што је строго неопходно.

Легитимни, догађај-специфични примери:

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

Подразумевано не дозвољено:

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

Возачки акредитив није претплата на надзор. И не би требало тихо да то постане.

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

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

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

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

Будућа МВД никада не би требало да допусти образац у коме корисник верује да открива податке компанији за изнајмљивање, али у стварности их открива невидљивом верификационом брокеру, процесору аналитике и ланцу продаваца захтева.

ETSI помаже овде. Његов модел сертификата ослоњених страна новчаника укључује URI-је за подршку, намену, URI-је регистра и метаподатке надзорног органа. То је тип машински читљиве инфраструктуре потребне да корисници разумеју ко је заправо на другом крају захтева и куда треба ићи када желе брисање или исправку.

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

Већина расправа о селективном откривању података завршава прерано. Фокусирају се на оно шта је откривено. Недовољно се фокусирају на то колико дуго остаје после тога.

Тренутне смернице се већ усклађују:

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

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

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

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

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

Када бих морао да сведем цео овај чланак на једно правило имплементације, то би bilo ово:

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

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

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

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

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

Будућа МВД не би требало да пита да ли подаци могу бити откривени. Треба да пита:

• Ко пита?
• У коју сврху?
• Под чијим овлашћењем?
• У ком контексту?
• С каквим последицама задржавања?

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

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