Чаму блокчэйн з'яўляецца неабавязковым для будучага Міжнароднага дазволу на кіраванне (МДК)

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

Кожная сур’ёзная размова пра лічбавы трансгранічны МДК у рэшце рэшт прыцягвае адну і тую ж прапанову: «Проста размесціце яго ў блокчэйне». Прывабнасць зразумелая. Блокчэйны прапануюць доказы фальсіфікацыі, агульную бачнасць і гісторыю толькі з дадаваннем. Гэта рэальныя ўласцівасці. Але ў кантэксце трансгранічнай ідэнтыфікацыі кіроўцы яны вельмі часта прымяняюцца да няправільнага ўзроўню.

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

Што стандарты насамрэч кажуць пра блокчэйн

Мадэль даных W3C Verifiable Credentials выразна сцвярджае, што рэестр праверных дадзеных можа мець мноства формаў, у тым ліку:

• Давераныя базы дадзеных
• Дэцэнтралізаваныя базы дадзеных
• Дзяржаўныя базы дадзеных ідэнтычнасці
• Размеркаваныя рэестры

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

Гэта правільная адпраўная кропка для будучага МДК. Карысным пытаннем з’яўляецца не «блокчэйн ці не блокчэйн?» Яно такое:

Які ўзровень насамрэч патрабуе празрыстасці, і які ўзровень абсалютна не павінен па змаўчанні станавіцца публічнай інфраструктурай?

Блокчэйн — гэта набор уласцівасцей, а не патрабаванне

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

• Агульная публікацыя
• Гісторыя толькі з дадаваннем
• Размеркаваная праца
• Генерацыя квітанцый
• Устойлівасць да аднабаковых змяненняў

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

Тры праблемы, якія не варта аб’ядноўваць

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

1. Дзе жыве прававая ісціна. Права на кіраванне транспартным сродкам належыць да аўтарытэтных нацыянальных рэестраў пасведчанняў.
2. Як распаўсюджваецца матэрыял даверу. Ключы эмітэнта і сертыфікаты верыфікатара належаць да кіраваных рэестраў даверу.
3. Як экасістэма правярае змяненні. Гэта адносіцца да ўзроўню празрыстасці.

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

Чаму вучыць нас Празрыстасць сертыфікатаў

Найбольш эфектыўная мадэль празрыстасці ў публічным інтэрнэце — гэта не карыстальніцкі блокчэйн. Гэта Празрыстасць сертыфікатаў (CT).

RFC 9162 апісвае CT як пратакол публічнага вядзення журнала сертыфікатаў TLS-сервераў, каб кожны мог:

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

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

Прымяняючы да будучага МДК, гэта азначае вядзенне журнала такіх рэчаў, як:

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

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

SCITT: чаму празрыстасць — гэта не тое ж самае, што ісціна

Праект архітэктуры IETF SCITT пашырае гэтую думку. SCITT вызначае службу Transparency Service, якая падтрымлівае праверную структуру дадзеных і выдае крыптаграфічныя квітанцыі, якія пацвярджаюць уключэнне падпісаных заяў. Ідэнтычнасць службы Transparency Service фіксуецца адкрытым ключом, вядомым пакладаючымся бакам, а самі якарныя элементы даверу і палітыкі рэгістрацыі зроблены празрыстымі.

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

SCITT таксама выразна вызначае межы празрыстасці:

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

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

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

Правільнае архітэктурнае раздзяленне для будучага МДК

Будучы МДК павінен раздзяліць задачы на чатыры асобныя ўзроўні:

1. Аўтарытэтныя запісы аб тых, хто мае права кіраваць (нацыянальныя органы ліцэнзавання)
2. Рэестры даверу для ключоў эмітэнта і верыфікатара
3. Інфраструктура статусу для актуальнасці і адкліканняў
4. Неабавязковы ўзровень празрыстасці для публічнага аўдыту палітык, якарных элементаў даверу, квітанцый і заяў аб адпаведнасці

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

Які ўзровень, калі такі ёсць, насамрэч атрымлівае выгаду ад публічнага аўдыту толькі з дадаваннем?

Пяць прычын, чаму ідэнтыфікацыя кіроўцы ў ланцужку з’яўляецца няправільным выбарам па змаўчанні

1. Яна стварае трывалыя сігналы адсочвання

Праца EUDI па прыватнасці тлумачыць, што прэзентацыі атэстацыі могуць змяшчаць унікальныя значэнні, напрыклад:

• Солі
• Хэш-значэнні
• Ідэнтыфікатары адкліканняў
• Адкрытыя ключы прывязкі прылады
• Подпісы
• Часовыя пазнакі

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

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

2. Яна раскрывае падзеі адкліканняў і актуальнасці

Рэкамендацыя W3C Bitstring Status List выразна апісвае праблему: калі існуе адпаведнасць адзін да аднаго паміж уліковымі дадзенымі і URL, дзе публікуецца іх статус, выдавец можа звязаць уладальніка, верыфікатара і час праверкі. Спецыфікацыя выкарыстоўвае прыклад пасведчання кіроўцы, каб праілюстраваць, чаму адсочванне эмітэнтам пры ўваходзе ва ўстанову парушае агульнае чаканне прыватнасці.

Лепшы выбар па змаўчанні, які прапануе Bitstring Status List:

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

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

3. Яна блытае статус уліковых дадзеных з прававым статусам кіравання

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

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

4. Яна накіравана на няправільную праблему кіравання

Трансгранічная ідэнтыфікацыя кіроўцы — гэта не ў першую чаргу праблема кансенсусу. Гэта праблема кіравання:

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

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

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

Гэта відавочнае публічнае адміністраванне даверу — а не дэцэнтралізаванае кіраванне.

5. Яна не вырашае рэальнасць на дарозе

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

Кіраўніцтва па рэалізацыі AAMVA ўдакладняе, што:

• Атрыманне дадзеных з прылады працуе без знешняга злучэння як для ўладальніка, так і для счытвальніка ў момант транзакцыі.
• ISO/IEC 18013-5 патрабуе падтрымкі атрымання дадзеных з прылады.
• Доступ верыфікатара да адкрытых ключоў эмітэнта не абавязкова павінен адбывацца ў момант транзакцыі. Ключы можна загрузіць загадзя.

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

Што павінна быць празрыстым у будучым МДК

Будучы МДК абсалютна патрабуе празрыстасці — у правільным месцы.

Зрабіце гэта празрыстым па змаўчанні:

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

Не рабіце гэта публічным па змаўчанні:

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

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

Лепшы шаблон: Празрыстасць вакол экасістэмы, а не праз асобу

Чыстая архітэктура для будучага МДК выглядае наступным чынам:

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

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

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

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

На практыцы гэта азначае:

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

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

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