1. Koduleht
  2.  / 
  3. Blogi
  4.  / 
  5. Miks on plokiahel vabatahtlik tulevase rahvusvahelise juhiloa (RJL) jaoks
Miks on plokiahel vabatahtlik tulevase rahvusvahelise juhiloa (RJL) jaoks

Miks on plokiahel vabatahtlik tulevase rahvusvahelise juhiloa (RJL) jaoks

Tulevane rahvusvaheline juhiluba (RJL) vajab läbipaistvust, usaldusankruid ja avalikku vastutust. See, mida see vaikimisi ei vaja, on juhtide endi kandmine hajusregistrisse.

Iga tõsine arutelu digitaalse, piiriülese RJL-i üle jõuab lõpuks sama ettepanekuni: „Pane see lihtsalt plokiahelasse.” Ahvatlus on mõistetav. Plokiahelad pakuvad võltsimistõendeid, jagatud nähtavust ja ainult lisatavat ajalugu. Need on reaalsed omadused. Kuid piiriülese juhi isikusamasuse kontekstis rakendatakse neid väga sageli valele kihile.

See artikkel selgitab miks, tutvustab standardite tegelikku sisu ja esitab parema arhitektuurilise mustri.

Mida standardid tegelikult plokiahela kohta ütlevad

W3C kontrollitavate tõendite andmemudel täpsustab selgesõnaliselt, et kontrollitav andmeregister võib võtta mitmeid vorme, sealhulgas:

  • Usaldusväärsed andmebaasid
  • Detsentraliseeritud andmebaasid
  • Valitsuse isikusamasuse andmebaasid
  • Hajusregistrid

DID Core on sama selge: paljud DID-meetodid kasutavad hajusregistri tehnoloogiat, kuid mitte kõik. Teisisõnu lükkavad standardid juba tagasi idee, et plokiahel on digitaalsete tõendite kohustuslik alus.

See on õige lähtepunkt tulevase RJL-i jaoks. Kasulik küsimus ei ole „plokiahel või mitte plokiahel?” See on:

Milline kiht tegelikult vajab läbipaistvust ja milline kiht ei tohiks vaikimisi muutuda avalikuks infrastruktuuriks?

Plokiahel on omaduste kogum, mitte nõue

Esimene viga on käsitada „plokiahelat” ühe nõudena. See ei ole nii. See on võimalike omaduste kogum, sealhulgas:

  • Jagatud avalikustamine
  • Ainult lisatav ajalugu
  • Hajusoperatsioon
  • Kviitungite genereerimine
  • Vastupanu ühepoolsetele muutustele

Mõned neist on tulevase RJL-i jaoks kasulikud. Mõned on ebaolulised. Ja mõned on aktiivselt ohtlikud, kui neid rakendatakse inimeste tõendite subjektidele. W3C registrimudel lubab tahtlikult mitut rakendust, kuna erinevad ökosüsteemid vajavad erinevaid kompromisse.

Kolm probleemi, mida ei tohiks ühendada

Teine viga on kolme erineva probleemi koondamine ühte süsteemi. Tulevase RJL-i puhul peavad need eraldi püsima:

  1. Kus elab õiguslik tõde. Sõiduõigus kuulub autoritatiivsetesse riiklikesse juhilubade registritesse.
  2. Kuidas usaldusmaterjaali levitatakse. Väljastajate võtmed ja kontrollijate sertifikaadid kuuluvad kontrollitud usaldusregistritesse.
  3. Kuidas ökosüsteem muutusi auditeerib. See kuulub läbipaistvuskihti.

Reaalmaailma ökosüsteemid töötavad juba nii. AAMVA digitaalse usalduse teenus levitab väljastajate avalikke võtmeid allalaaditavas loendis enne, kui kontrollija üldse mobiilse juhiloaga (mDL) suhtleb. Euroopa Liidu mobiilse juhiloa käsiraamat täpsustab, et liikmesriigid teavitavad Euroopa Komisjoni volitatud mDL-i väljastajatest ja komisjon avaldab nende asutuste kontrollimisloendi. See on usalduse levitamine ilma plokiahelata.

Mida sertifikaatide läbipaistvus meile õpetab

Kõige tõhusam läbipaistvusmudel avalikus internetis ei ole tarbija plokiahel. See on sertifikaatide läbipaistvus (CT).

RFC 9162 kirjeldab CT-d protokollina TLS-serveri sertifikaatide avalikuks logimiseks, et igaüks saaks:

  • Auditeerida sertifitseerimisasutuste tegevust
  • Tuvastada probleemseid või valesti väljastatud sertifikaate
  • Auditeerida ise logisid

CT-st tulenev põhiline disainiõppetund: läbipaistvus on kõige väärtuslikum siis, kui see salvestab väljastaja käitumist ja usaldusmaterjaali — mitte lõppkasutaja tegevust.

Tulevase RJL-i puhul tähendab see selliste asjade logimist nagu:

  • Väljastajate võtmete väljastamine ja rotatsioon
  • Usaldusankrute avaldamine
  • Kontrollijate kategooriate registreerimine
  • Poliitika muutused
  • Vastavusdeklaratsioonid
  • Turvalisusega seotud sündmused

See ei tähenda avaliku või poolavaliku registri loomist omanike, tõendite identifikaatorite või esitlussündmuste kohta. See ei ole läbipaistvus. See on liigne andmete kogumine.

SCITT: miks läbipaistvus ei ole sama mis tõde

IETF SCITT arhitektuuriprojekt laiendab seda mõtteviisi. SCITT määratleb läbipaistvusteenuse, mis säilitab kontrollitava andmestruktuuri ja väljastab krüptograafilisi kviitungeid, tõendades allkirjastatud avalduste kaasamist. Läbipaistvusteenuse identiteet on jäädvustatud avaliku võtmega, mis on tugipooltele teada, ja usaldusankrud ning registreerimispoliitikad muudetakse ise läbipaistvaks.

See on võimas mudel RJL-i infrastruktuuri jaoks, kuna see muudab läbipaistvuse auditeeritavaks teenuseks usaldusmaterjaali ja poliitika ümber — mitte isiklike reisisündmuste ümber.

SCITT on selge ka läbipaistvuse piiride osas:

  • Registreeritud avaldus tõendab ainult seda, et väljastaja selle koostas ja registreeris — mitte seda, et avaldus on lõputult õige.
  • Hilisem allkirjastatud avaldus võib asendada varasema.
  • Läbipaistvus ei takista ebaausaid või kompromiteeritud väljastajaid; see vastutab nende eest.

Juhi isikusamasuse puhul on see eristus äärmiselt oluline: läbipaistvuslogi on tõendusmaterjal ja auditiajalugu, mitte kellegi sõiduõiguse autoritatiivne õiguslik seisund.

SCITT märgib ka, et läbipaistvusteenus saab kaitsta oma ainult lisatavat jada usaldusväärsete riistvara-, konsensusprotokollide ja krüptograafiliste tõendite kombinatsiooniga. Isegi läbipaistvuskiht ei nõua ühte konkreetset plokiahela disaini. Konsensus on üks võimalus, mitte ainus.

Tulevase RJL-i õige arhitektuuriline eraldamine

Tulevane RJL peaks jagama probleemid neljaks erinevaks kihiks:

  1. Autoritatiivsed andmed selle kohta, kellel on sõiduõigus (riiklikud litsentseerimisasutused)
  2. Usaldusregistrid väljastajate ja kontrollijate võtmetele
  3. Staatuse infrastruktuur värskuse ja tühistamise jaoks
  4. Vabatahtlik läbipaistvuskiht poliitikate, usaldusankrute, kviitungite ja vastavusdeklaratsioonide avalikuks auditeerimiseks
Läbipaistvus infrastruktuuri jaoks, mitte inimeste jaoks

Kui need kihid eraldada, muutub plokiahela küsimus palju teravamaks. See ei ole enam „kas tulevane RJL peaks olema plokiahelas?” See muutub:

Milline kiht, kui üldse, tegelikult kasu saab ainult lisatavast avalikust auditist?

Viis põhjust, miks ahelas olev juhi identiteet on vale vaikimisi

1. See loob kestvaid jälgimissignaale

EUDI privaatsustöö selgitab, et tõendite esitlused võivad sisaldada unikaalseid väärtusi, nagu:

  • Soolväärtused
  • Räsiväärtused
  • Tühistamisidentifikaatorid
  • Seadmega seotud avalikud võtmed
  • Allkirjad
  • Ajatemplid

Kuna need väärtused on sama tõendi puhul fikseeritud, võimaldavad need tugipooltele erinevate tehingute sidumist ja kasutaja käitumisprofiili koostamist. EUDI hoiatab selgesõnaliselt, et see rikub mõistlikku ootust, et eraldiseisvad digitaalrahakoti tegevused ei kombineerita.

Kui avaldate avalikus registris stabiilseid omaniku identifikaatoreid, stabiilseid tõendite identifikaatoreid, korduvkasutatavaid räsisid või individuaalselt jälgitavaid tühistamissündmusi, ei lahendate jälgimisprobleemi — te muudate selle püsivaks.

2. See paljastab tühistamis- ja värskussündmused

W3C bittide olekuloendi soovitus kirjeldab probleemi selgelt: kui tõendi ja URL-i vahel, kus selle olek avaldatakse, on üks-ühele vastavus, saab avaldaja ühendada omaniku, kontrollija ja kontrolli aja. Spetsifikatsioon kasutab juhiloa näidet, et illustreerida, miks asutust sisenedes väljastaja poolt jälgimine rikub tavalist privaatsusootust.

Parem vaikimisi, mida Bitstring Status List pakub:

  • Suured, tihendatavad olekuloendid, kus paljud tõendid jagavad ühte olekuressurssi
  • Vaikimisi loendi pikkus 131 072 kirjet
  • Tugipooled laadivad uued versioonid alla eraldi, ennast autentimata
  • Juhuslikud indeksid ja grupiprivaatsuse garantiid

See on vastupidine individualiseeritud, ahelas olevatele tühistamisjälgedele.

3. See ajab segamini tõendi staatuse õigusliku sõidustaatusega

Digitaalset tõendit saab tühistada, kuna selle allkirjamehhanismi on kahjustatud — isegi siis, kui reaalmaailma sõiduõigus jääb kehtivaks. Avalik tõendisündmuste register ei ole puhas asendus riikliku sõiduregistri autoritatiivsele seisundile.

SCITT kinnitab seda seisukohta: registreeritud avalduse võib hiljem asendada uus ja tugipooled otsustavad, mida usaldada, lähtudes poliitikast ja ajaloost. Logi ei ole püsiv tõde. See on tõendusmaterjal selle kohta, kes mida millal ja millise poliitika alusel ütles. Riiklik litsentseerimisasutus jääb õigusliku tõe algallikaks.

4. See sihib vale haldamisprobleemi

Piiriülene juhi isikusamasus ei ole peamiselt konsensusküsimus. See on haldamisküsimus:

  • Kes on lubatud väljastama?
  • Millised avalikud võtmed on praegused?
  • Millised kontrollijad on volitatud?
  • Millised andmepäringud vastavad nende deklareeritud eesmärgile?
  • Milline poliitikaversioon oli sel ajal jõus?

Reaalsed ökosüsteemid vastavad neile juba juhitud usaldusinfrastruktuuri kaudu, mitte detsentraliseeritud konsensuse kaudu:

  • AAMVA digitaalse usalduse teenus avaldab väljastavate asutuste avalikud võtmed allalaaditavas loendis.
  • Euroopa Liidu mobiilse juhiloa käsiraamat ütleb, et komisjon avaldab volitatud mDL-i väljastajate loendi.
  • ETSI rahakoti tugipoole sertifikaatide töö pakub masinloetavat kontrollija autentimist kavandatud kasutuse ja registreeritud soovitud atribuutidega.

See on selge avaliku usalduse haldamine — mitte detsentraliseeritud juhtimine.

5. See ei lahenda teeperve reaalsust

Paljud plokiahela ettepanekud eeldavad vaikimisi, et reaalajas võrgule juurdepääs on eelis. Juhi tõendite puhul — eriti teepervel või reisimise ajal — see sageli nii ei ole.

AAMVA rakendamisjuhend täpsustab, et:

  • Seadme toomine töötab ilma välise ühenduvuseta nii omaniku kui ka lugeja jaoks tehingu ajal.
  • ISO/IEC 18013-5 nõuab seadme toomise toetust.
  • Kontrollija juurdepääs väljastaja avalikele võtmetele ei pea toimuma tehingu ajal. Võtmeid saab eelnevalt alla laadida.

Kui kontrollija saab juba lokaalselt valideerida vahemällu salvestatud usaldusmaterjaali kasutades, ei ole reaalajas plokiahela sõltuvus hädavajalik. Parimal juhul on see rakendusvalik mõne taustasüsteemi auditifunktsiooni jaoks.

Mis peaks olema läbipaistev tulevases RJL-is

Tulevane RJL vajab kindlasti läbipaistvust — õiges kohas.

Tehke need vaikimisi läbipaistvaks:

  • Väljastajate avalikud võtmed ja võtmerotatsiooni sündmused
  • Usaldusankrud ja volitatud väljastajate loendid
  • Kontrollija juurdepääsusertifikaadid ja registreeritud eesmärgi metaandmed
  • Poliitika versioonid ja registreerimiseeskirjad
  • Vastavusdeklaratsioonid ja turvalisusega seotud tarkvara väljalaskeväited
  • Auditeeritavad kviitungid, mis tõendavad nende avalduste registreerimist

Ärge tehke neid vaikimisi avalikuks:

  • Omaniku identifikaatorid avalikus registris
  • Stabiilsed tõendite identifikaatorid, mida kontrollijate lõikes korduvkasutatakse
  • Esitluspõhised sündmused
  • Toored tühistamiskirjed, mis isoleerivad ühe isiku
  • Täielikud allkirjastatud avaldused, mis sisaldavad isikuandmeid, kui räsid või metaandmed piisaksid

SCITT hoiatab väljastajaid selgesõnaliselt üle vaatama privaatsete, konfidentsiaalsete või isikut tuvastava teabe kaasamist enne avalduste esitamist läbipaistvusteenusele. Samuti märgib see, et läbipaistvusteenused saavad säilitada ainult krüptograafilisi metaandmeid, nagu räsid — mitte täielikke allkirjastatud avaldusi.

Parem muster: läbipaistvus ökosüsteemi ümber, mitte läbi isiku

Tulevase RJL-i puhas arhitektuur näeb välja selline:

  • Autoritatiivne riiklik register — jääb sõiduõiguse õiguslikuks tõeallikaks.
  • Tõendite kiht — kannab masinloetavad sõiduõigused omaniku digitaalrahakotti.
  • Usaldusregistri kiht — levitab väljastajate võtmeid, kontrollijate sertifikaate ja volitatud väljastajate loendeid.
  • Staatuse kiht — kasutab lühiajalisi tõendeid või privaatsust säilitavaid olekuloendeid, mida eraldi värskendatakse.
  • Läbipaistvuskiht — võib või ei pruugi sisemiselt konsensust kasutada ja logib usaldusankrud, võtmemuutused, poliitika uuendused, kviitungid ning ökosüsteemi avaldused, mis saavad kasu ainult lisatavast avalikust auditist.

See arhitektuur hõivab plokiahela mõtlemise kasulikud osad — ainult lisatav auditeeritavus, avalik kontroll, võltsimistõendid, kviitungid — muutmata juhti süsteemi avalikuks subjektiks. See vastab ka sellele, mida standardid juba kirjeldavad: registrid võivad võtta erinevaid vorme, DID-id ei nõua hajusregistreid, usaldusregistrid on juba olemas ja privaatsust säilitavad staatuse mehhanismid on juba standardiseeritud.

Põhiargument

Tulevane RJL peaks võtma üle plokiahelast parima idee — avalik vastutus infrastruktuuri eest — ilma selle halvima vaikimisi omaduseta inimeste jaoks: kestvat, globaalselt nähtavat jälgimist.

Praktikas tähendab see:

  • Läbipaistvus väljastajatele, mitte omanike paljastamine
  • Auditeeritavad usaldusankrud, mitte avalikud reisiandmed
  • Kviitungid poliitikate ja registreerimiste jaoks, mitte tõendite kasutamise püsivad ajaskaalad
  • Ainult lisatav tõendusmaterjal ökosüsteemi haldamiseks, mitte ahelas olev juhi identiteet vaikimisi

See ei ole argument plokiahela vastu. See on argument plokiahela rakendamise vastu valele kihile.

Tulevane RJL võib hästi kasutada konsensusepõhiseid läbipaistvusteenuseid kusagil ökosüsteemis. Kuid kui disain algab juhi, tõendi või esitlusjälje kandmisega registrisse, on see juba valinud vale vaikimisi.

Taotle
Palun sisesta oma e-post allolevasse välja ja kliki "Tellimuse"
Tellige ja hankige täielikud juhised rahvusvahelise juhiloa hankimise ja kasutamise kohta, samuti nõuandeid välismaal asuvatele autojuhtidele