Паліцыя, стойкі арэнды, працадаўцы, страхавальнікі: чаму яны не павінны бачыць адны і тыя ж даныя

Найбольшай памылкай у праектаванні будучага Міжнароднага дазволу на кіраванне (МДК) было б стаўленне да кожнага верыфікатара аднолькава. Супрацоўнік паліцыі, стойка арэнды аўтамабіля, працадаўца і страхавальнік задаюць розныя пытанні — таму яны не павінны атрымліваць адзін і той жа адказ.

Адзін кіроўца. Адно базавае права на кіраванне. Адзін кашалёк. Але чатыры зусім розныя верыфікатары:

• Супрацоўнік паліцыі на дарозе
• Стойка арэнды аўтамабіля пры атрыманні
• Працадаўца, які правярае права на кіраванне аўтапаркам
• Страхавальнік, які разглядае патрабаванне

Калі будучы МДК паказвае адны і тыя ж даныя ўсім чатыром, сістэма ўжо зазнала няўдачу. Не таму, што ўліковы дакумент ненадзейны, а таму, што мадэль раскрыцця занадта простая.

Супольнасць стандартызацыі ўжо адыходзіць ад гэтай простай мадэлі. Праца W3C па верыфікуемых уліковых дакументах апісвае экасістэму вакол эмітэнтаў, уладальнікаў і верыфікатараў, выкарыстоўваючы працадаўцаў і вэб-сайты ў якасці прыкладаў верыфікатараў. Работа ЕС па мабільных пасведчаннях кіроўцы ўжо разглядае дарожныя праверкі і арэнду аўтамабіляў як асобныя сцэнарыі верыфікацыі, уключаючы аддаленую папярэднюю перадачу для арэнды і асабістыя праверкі для паліцыі. Архітэктура ўжо распрацавана для некалькіх тыпаў верыфікатараў. Памылкай было б праектаваць карыстальніцкі досвед так, нібы існуе толькі адзін тып.

Чаму фізічная картка прывучыла нас думаць няправільна

Фізічнае пасведчанне прывучыла нас да падыходу «паказаць усё». Вы аддаяце картку. Іншы чалавек бачыць тое, што на ёй напісана. Гэта і ёсць увесь зварот.

Гэты падыход прымальны ў папяровым свеце, таму што альтэрнатывы няма. У лічбавым свеце ён становіцца непрымальным.

Мадэль даных W3C VC 2.0 непасрэдна сцвярджае: пасведчанне кіроўцы можа ўтрымліваць нумар пасведчання асобы, рост, вагу, дату нараджэння і хатні адрас — але гэта ўсё роўна можа быць значна больш, чым неабходна для канкрэтнай здзелкі. Ключавыя палажэнні дзеючых стандартаў:

• Лепшая практыка W3C: падтрымліваць выбарачнае раскрыццё і запытваць толькі тое, што сапраўды неабходна
• Кіраўніцтва ЕС па абароне даных: апрацоўка павінна быць абмежавана канкрэтнымі мэтамі, а апрацоўваемыя даныя павінны быць неабходнымі і прапарцыянальнымі
• Першы прынцып будучага МДК: адзін уліковы дакумент не азначае аднолькавага права на праверку

Правільная мадэль — раскрыццё на аснове палітыкі

Калі вы хочаце сур’ёзнай архітэктуры, правільная мадэль бліжэй да кантролю доступу на аснове атрыбутаў, чым да прэзентацыі лічбавай карткі.

NIST SP 800-205 вызначае рашэнні аб кантролі доступу як ацэнку атрыбутаў, звязаных з суб’ектам, аб’ектам, запытанай аперацыяй і ўмовамі асяроддзя, адносна палітыкі. Гэта менавіта правільная структура для будучага МДК:

• Суб’ект: кіроўца
• Аб’ект: запытаныя палі даных
• Дзеянне: не «прагледзець пасведчанне» ў абстрактным сэнсе, а нешта канкрэтнае, напрыклад «пацвердзіць права кіравання транспартным сродкам катэгорыі B на дарозе» або «пацвердзіць права арэнды для браніравання»
• Асяроддзе: дарога, стойка арэнды, аддаленая папярэдняя праверка, падключэнне аўтапарка і разгляд патрабавання пасля страты — гэта розныя асяроддзі, і яны павінны прыводзіць да розных рашэнняў

NIST таксама адзначае, што сістэмы атрыбутаў патрабуюць дэталізацыі, кіравання і механізмаў скарачэння, групоўкі і мінімізацыі атрыбутаў.

Таму будучы МДК не павінен пытацца: Ці можа гэты верыфікатар прачытаць пасведчанне? Ён павінен пытацца: Якія заявы можа атрымаць гэты верыфікатар, для якога прызначанага выкарыстання, у якім асяроддзі і з якімі правіламі захоўвання?

Верыфікатар павінен ідэнтыфікаваць сябе, перш чым нешта запытваць

Будучы МДК не павінен пачынацца з таго, што кашалёк паказвае даныя. Ён павінен пачынацца з таго, што верыфікатар даказвае, хто ён ёсць.

Архітэктура EUDI дакладная ў гэтым пытанні. Давераныя бакі павінны:

• Рэгістраваць, якія атрыбуты яны намераны запытваць і з якой мэтай
• Атрымліваць сертыфікаты доступу
• Аўтэнтыфікавацца ў кашальку перад любым раскрыццём
• Правярацца адпаведна іх зарэгістраванай сферы дзейнасці, дзе даступная інфармацыя аб рэгістрацыі

Карыстальнік можа бачыць, хто пытаецца, што запытваецца і ці знаходзіцца запыт у межах зарэгістраванай сферы.

Бягучая работа ETSI па сертыфікатах кашалька і давераных бакоў робіць гэта больш канкрэтным. Сертыфікат рэгістрацыі давераных бакоў кашалька можа апісваць прызначанае выкарыстанне давераным бокам і атрыбуты, якія ён зарэгістраваў для запыту. Звязаны сертыфікат доступу існуе для таго, каб гарантаваць, што запыт паступае ад законнага, упаўнаважанага боку. ETSI таксама ўключае метаданыя давераных бакоў, такія як:

• Гандлёвая назва
• URI падтрымкі
• Прызначанае выкарыстанне
• Правы
• URI рэестра
• Інфармацыя аб кантралюючым органе

Другі прынцып будучага МДК: без ідэнтыфікацыі верыфікатара — без раскрыцця.

Чаму экраны згоды недастатковыя

Тут ёсць яшчэ адна памылка: атаясамліванне зацвярджэння карыстальніка з прававой законнасцю.

Архітэктура EUDI прама кажа, што зацвярджэнне карыстальніка на прэзентацыю атрыбутаў не павінна разглядацца як правамерная аснова для апрацоўкі персанальных даных давераным бокам. Давераны бок усё роўна павінен мець уласную правамерную аснову. EUDI таксама патрабуе зацвярджэння карыстальніка ва ўсіх варыянтах выкарыстання, уключаючы выпадкі, калі давераны бок можа быць часткай праваахоўных органаў або іншага дзяржаўнага органа.

Добры інтэрфейс кашалька можа дапамагчы, але сам па сабе не можа вырашыць праблему перавышэння паўнамоцтваў верыфікатара. Правіла павінна існаваць да інтэрфейсу.

Таму будучы МДК патрабуе абодвух:

• Крыптаграфічнай аўтэнтыфікацыі верыфікатара для пацверджання таго, хто пытаецца
• Абмежаванняў палітыкі на тое, што гэтая катэгорыя верыфікатараў можа запытваць

Без абодвух «выбар карыстальніка» становіцца спосабам перакладання правіламі правалу на індывіда.

1. Паліцыя: пацвердзіць права на кіраванне, а не ўсю асобу

Сцэнарый з паліцыяй на дарозе з’яўляецца найбольш сканцэнтраваным.

Кіраўніцтва ЕС па mDL апісвае гэта непасрэдна: паліцыя або іншыя службовыя асобы правяраюць пасведчанне пры неабходнасці, уключаючы тэрмін дзеяння пасведчання і правы на транспартны сродак. У карыстальніцкім шляху супрацоўнік правярае пасведчанне праз паток, ініцыяваны QR-кодам, Bluetooth, Wi-Fi Aware або NFC. Гэта сканцэнтраваная задача верыфікацыі:

• Ці з’яўляецца гэта асоба ўладальнікам?
• Ці сапраўдны ўліковы дакумент?
• Якія правы і абмежаванні на транспартны сродак прымяняюцца?

Дазволена па змаўчанні:

• Імя
• Партрэт
• Статус пасведчання
• Даты выдачы і заканчэння тэрміну дзеяння
• Катэгорыі
• Абмежаванні, звязаныя з кіраваннем
• Эмітэнт і юрысдыкцыя
• Вынік актуальнасці/статусу

Не дазволена па змаўчанні:

• Хатні адрас
• Унутраныя ідэнтыфікатары, непатрэбныя для выкарыстання на дарозе
• Несувязаныя атрыбуты з іншых пасведчанняў
• Гістарычныя журналы прэзентацый
• Камерцыйныя метаданыя

Кіраўніцтва па ўкараненні AAMVA ўзмацняе пункт аб партрэце: калі партрэт запытваецца і любы іншы элемент раскрываецца, партрэт трэба перадаць, каб верыфікатар мог звязаць даныя з асобай, якая іх прадстаўляе. Тое ж кіраўніцтва таксама кажа, што зацікаўленыя бакі не павінны адсочваць уладальнікаў mDL або выкарыстанне mDL, за выключэннем выпадкаў, прадугледжаных законам.

Выпадак з паліцыяй — не пра тое, каб дзяржава атрымала ўсё. Ён пра тое, каб дзяржава атрымала спецыфічныя для кіравання даныя, неабходныя для правапрымянення на дарозе. Гэта важнае адрозненне.

2. Стойкі арэнды: права, адпаведнасць асобы і нічога лішняга

Выпадак з арэндай больш дэталёвы, таму што насамрэч ёсць два моманты: аддаленая папярэдняя праверка перад прыездам і атрыманне аўтамабіля, калі чалавек або кіёск аддае ключы.

Кіраўніцтва ЕС па mDL ужо мадэлюе абодва выпадкі. Служба арэнды аўтамабіляў можа запытаць mDL разам з пацверджаннем асобы пры браніраванні, пацвердзіць пасведчанні, а пазней асабіста верыфікаваць кліента пры атрыманні аўтамабіля перад яго выдачай. Карыстальнікі могуць перадаваць свае mDL кампаніям па арэндзе аўтамабіляў асабіста або аддалена загадзя.

Стойка арэнды не займаецца расследаваннем інцыдэнтаў у першую чаргу. Ёй трэба прыняць рашэнне: Ці магу я здаць гэты аўтамабіль у арэнду гэтаму кліенту паводле гэтага браніравання і палітыкі?

Аддаленая папярэдняя праверка павінна ўключаць:

• Сувязь з асобай
• Партрэт або эквівалентны элемент прывязкі асобы
• Адпаведная катэгорыя транспартнага сродку
• Даты выдачы і заканчэння тэрміну дзеяння
• Бягучы тэрмін дзеяння
• Магчыма, парог узросту або ўзроставы дыяпазон

Атрыманне аўтамабіля павінна пацвердзіць:

• Уладальнік — гэта той жа чалавек, які прайшоў папярэднюю праверку
• Бягучы тэрмін дзеяння
• Адпаведныя правы

Не патрэбна па змаўчанні:

• Поўны хатні адрас, калі профіль браніравання ўжо ўтрымлівае кантактную інфармацыю
• Поўная дата нараджэння, калі дастаткова пацверджання ўзросту або ўзроставага дыяпазону
• Несувязаныя атрыбуты асобы
• Паўторная прэзентацыя поўнага ўліковага дакумента, калі ўжо існуе пасведчанне браніравання

Бягучая архітэктура mDL NIST паказвае, як давераны бок выкарыстоўвае DCQL для запыту толькі неабходных атрыбутаў, і прама кажа, што гэта падтрымлівае мінімізацыю даных і згоду ўладальніка шляхам структуравання запыту, а не стаўлення да ўліковага дакумента як да адзінага цэлага. AAMVA дадае, што праграма павінна выразна паказваць, якія даныя былі запытаны і ці намерваецца верыфікатар захоўваць інфармацыю.

3. Працадаўцы: катэгорыя верыфікатараў, а не доступ да поўнай асобы

Агляд W3C выкарыстоўвае лічбавую сістэму працадаўцы, якая правярае дыплом універсітэта, у якасці прыкладу верыфікатара. Гэта нагадвае нам, што верыфікацыя працадаўцам — гэта ўжо прызнаная мадэль у экасістэмах уліковых дакументаў.

Працадаўца або аператар аўтапарка можа законна мець патрэбу ведаць:

• Ці мае работнік у цяперашні час права кіраваць пэўнымі катэгорыямі транспартных сродкаў
• Ці існуюць ключавыя абмежаванні
• Ці застаецца права дзейным

Гэта рэальная бізнес-патрэба. Але яна аўтаматычна не апраўдвае пастаянны доступ да ўсяго пасведчання кіроўцы, поўных даных аб асобе або бесперапыннага патоку паўторных прэзентацый.

NIST папярэджвае, што частая перадача шматразовага ідэнтыфікатара і прывучванне карыстальнікаў да неаднаразовага прадстаўлення ўліковага дакумента з данымі асобы з’яўляецца непажаданым, і кажа, што штодзённая аўтэнтыфікацыя павінна абапірацца на тэхналогіі, распрацаваныя для аўтэнтыфікацыі, такія як ключы доступу. NIST аддае перавагу лакальнай аўтэнтыфікацыі на прыладзе перад серверным біяметрычным параўнаннем, таму што гэта лепш захоўвае прыватнасць.

Будучы МДК не павінен стаць прапускам для доступу на рабочае месца.

Для выкарыстання працадаўцам і аўтапаркам правільная мадэль звычайна ўключае:

• Праверку правоў, актуальных для пасады
• Магчыма, перыядычнае пасведчанне адпаведнасці
• Магчыма, заяву аб тым, што ўладальнік застаецца дзейным для пэўных катэгорый
• Але не перадачу па змаўчанні ўсіх даных пасведчання кожны раз, калі работнік уваходзіць у сістэму або пачынае змену

Адпаведнасць патрабаванням аўтапарка — гэта асобная катэгорыя давераных бакоў з асобным прызначаным выкарыстаннем і асобным профілем раскрыцця.

4. Страхавальнікі: патрабаванні — не дазвол на пастаяннае назіранне

Страхавы выпадак часта з’яўляецца рэальным. У матэрыялах ЕС па выкарыстанні mDL страхавальнікі з’яўляюцца ўскосна ў сцэнарыі арэнды: страхавыя кампаніі патрабуюць ад кампаній па арэндзе аўтамабіляў праверыць, ці мае асоба, якая арандуе аўтамабіль, права кіравання. Страхаванне ўжо ўплывае на паток верыфікацыі кіравання.

Але гэта не азначае, што страхавальнік павінен атрымліваць тыя ж даныя, што і паліцыя, або пастаяннае права доступу да ўліковага дакумента.

Будучы МДК павінен разглядаць страхавальнікаў як асобную катэгорыю верыфікатараў з асобнымі прызначанымі выкарыстаннямі:

• Андэрайтынг
• Верыфікацыя рызыкі арэнды
• Апрацоўка патрабаванняў пасля страты
• Разгляд махлярства

Гэта не адны і тыя ж мэты. Згодна з прынцыпамі абароны даных ЕС, персанальныя даныя павінны збірацца для канкрэтных мэт і абмяжоўвацца тым, што неабходна і прапарцыянальна гэтай мэце. Кіраўніцтва W3C па VC тэхнічна прыходзіць да таго ж высновы: верыфікатары павінны запытваць толькі тое, што сапраўды неабходна.

Законныя, падзеяспецыфічныя прыклады:

• Пацверджанне таго, што пасведчанне было дзейным у адпаведны момант
• Пацверджанне адпаведнага права на транспартны сродак
• Пацверджанне сувязі з асобай, дзе гэта неабходна для патрабавання
• Раскрыццё, спецыфічнае для патрабавання

Не дазволена па змаўчанні:

• Пастаянны доступ да базавага ўліковага дакумента
• Паўторная агульная верыфікацыя кожны раз, калі кліент узаемадзейнічае са страхавальнікам
• Выкарыстанне ўліковага дакумента кіроўцы ў якасці токена ўваходу
• Збор несувязаных атрыбутаў

Уліковы дакумент кіроўцы — гэта не падпіска на маніторынг. І ён не павінен ціха ёй станавіцца.

Чаму пасярэднікі павінны быць бачнымі

Рэальныя рынкі ўключаюць пасярэднікаў. Платформы арэнды, пастаўшчыкі аўтапаркаў, HR-сістэмы працадаўцаў і апрацоўшчыкі страхавых патрабаванняў часта дзейнічаюць праз трэція бакі.

Архітэктура EUDI вырашае гэта шляхам:

• Стаўлення да пасярэднікаў як да давераных бакоў
• Патрабавання іх рэгістрацыі
• Патрабавання рэгістрацыі атрыбутаў, запытаных для апасродкаванага давераного боку
• Паказу карыстальніку як пасярэдніка, так і канчатковага давераного боку
• Забароны пасярэднікам захоўваць даныя аб змесце здзелкі

Будучы МДК ніколі не павінен дапускаць мадэлі, пры якой карыстальнік лічыць, што раскрывае даныя кампаніі па арэндзе, але ў рэальнасці раскрывае іх нябачнаму брокеру верыфікацыі, апрацоўшчыку аналітыкі і ланцугу пастаўшчыкоў патрабаванняў.

ETSI дапамагае тут. Яго мадэль сертыфіката кашалька і давераных бакоў уключае URI падтрымкі, прызначанае выкарыстанне, URI рэестра і метаданыя кантралюючага органа. Гэта той тып машыначытэльнай інфраструктуры, які патрэбны карыстальнікам, каб зразумець, хто сапраўды знаходзіцца на іншым канцы запыту і куды звярнуцца, калі яны хочуць выдалення або выпраўлення.

Захоўванне з’яўляецца часткай кантролю доступу

Большасць абмеркаванняў выбарачнага раскрыцця заканчваюцца занадта рана. Яны засяроджваюцца на тым, што раскрываецца. Яны не надаюць дастатковай увагі таму, як доўга гэта застаецца пасля.

Бягучыя кіраўніцтвы ўжо збліжаюцца:

• AAMVA: кашалёк павінен выразна паведамляць уладальніку, якія даныя былі запытаны і ці намерваецца верыфікатар іх захоўваць; зацікаўленыя бакі не павінны адсочваць уладальнікаў або выкарыстанне mDL, за выключэннем выпадкаў, прадугледжаных законам
• W3C: праграмнае забеспячэнне ўладальніка павінна весці журналы інфармацыі, перададзенай верыфікатарам, каб можна было ідэнтыфікаваць залішнія запыты
• EUDI: карыстальнікі павінны мець магчымасць атрымліваць доступ да журналаў транзакцый, паведамляць аб падазроных запытах і запытваць выдаленне

Клас захоўвання павінен быць часткай самой палітыкі раскрыцця:

• Паліцыя на дарозе: без захоўвання па змаўчанні, акрамя законнага аперацыйнага запісу
• Папярэдняя праверка арэнды: запіс транзакцыі, звязаны з браніраваннем, а не шматразовая копія асобы
• Адпаведнасць патрабаванням аўтапарка працадаўцы: запіс адпаведнасці або вынік пасведчання, а не неапрацаваныя даныя ўліковага дакумента
• Патрабаванне страхавальніка: запіс патрабавання, абмежаваны патрабаваннем, а не пастаянны доступ

Будучы МДК, які ігнаруе захоўванне, з’яўляецца толькі часткова захавальнікам прыватнасці.

Што кашалёк павінен насамрэч вырашаць

Калі б мне трэба было звесці ўвесь гэты артыкул да аднаго правіла ўкаранення, яно было б такім:

Кашалёк не павінен адказваць на пытанне «Ці магу я прадставіць гэты ўліковы дакумент?» Ён павінен адказваць на пытанне «Ці магу я прадставіць гэты набор заяў гэтаму аўтэнтыфікаванаму верыфікатару, для гэтага прызначанага выкарыстання, у гэтым кантэксце, у рамках гэтага класа захоўвання?»

Гэта рашэнне павінна кіравацца па меншай меры наступнымі ўваходнымі данымі:

• Ідэнтычнасць верыфікатара
• Катэгорыя верыфікатара
• Прызначанае выкарыстанне
• Зарэгістраваная сфера атрыбутаў
• Палітыка раскрыцця ад эмітэнта, калі яна прысутнічае
• Асяроддзе (дарога, атрыманне аўтамабіля, аддаленае, аўтапарк, патрабаванне)
• Зацвярджэнне ўладальніка
• Прымяняльная палітыка захоўвання

Стандарты ўжо ўтрымліваюць вялікую частку механізмаў для гэтага: выбарачнае раскрыццё, аўтэнтыфікацыю давераных бакоў, зарэгістраванае прызначанае выкарыстанне, сертыфікаты доступу, ацэнку палітыкі раскрыцця і запыты, абмежаваныя мэтай. Чаго яшчэ не хапае — гэта дысцыпліны разглядаць гэтыя элементы як адну цэласную архітэктуру раскрыцця.

Асноўны аргумент

Будучы МДК не павінен пытацца, ці можна раскрыць даныя. Ён павінен пытацца:

• Хто пытаецца?
• З якой мэтай?
• Пад якімі паўнамоцтвамі?
• У якім кантэксце?
• З якімі наступствамі захоўвання?

Паліцыя, стойкі арэнды, працадаўцы і страхавальнікі — гэта не чатыры лагатыпы на іншым канцы запыту. Гэта чатыры розныя мадэлі рызыкі, чатыры розныя прававыя кантэксты, чатыры розныя прычыны задаваць пытанні — і яны павінны прыводзіць да чатырох розных набораў раскрыцця.

Гэта не непатрэбная складанасць. Вось як выглядае сучасны ўліковы дакумент кіроўцы, калі ён перастае разглядаць кожнага верыфікатара аднолькава.