Digitaalinen tuotepassi ei näytä kaikille samoja tietoja. Ostaja näkee julkiset tiedot. Korjaamo tai kierrättäjä näkee enemmän. Markkinavalvontaviranomainen näkee kaiken. Tämä on selvitetty, ja eurooppalaisissa standardeissa se on nykyään nimenomaisesti määritelty.
Mielenkiintoisempi kysymys on hieman hienovaraisempi: jos jollekin paljastetaan julkisten tietojen lisäksi suojattuja kenttiä, voiko hän todistaa, että juuri nämä kentät ovat aitoja? Vai onko hänen luotettava siihen, että alusta on valinnut ne oikein ja välittänyt ne muuttamattomina eteenpäin?
Useimpien alustojen kohdalla rehellinen vastaus on: luottamus. Olemme rakentaneet alustamme niin, että vastaus on todiste - ei vain julkisten kenttien osalta, vaan jokaisen kentän osalta, joka lisätään vasta tietojen paljastamisen yhteydessä. Miksi tällä erolla on merkitystä ja miksi olemme valinneet tämän työläämmän tien.
Kaikki täyttävät pääsyoikeussäännön samalla tavalla
EN 18239, eurooppalainen standardi, ## jokakoskee pääsyoikeuksia, turvallisuutta ja luottamuksellisuutta DPP:ssä, vaatii pääsynhallintaa kunkin tietokentän osalta: jokaiselle kentälle on sääntö, joka määrittää, kuka sen saa nähdä. Tämä on oikea vaatimus, eikä sitä ole vaikea täyttää. Olemme eritellyt näiden standardien aseman kohdassa yhdenmukaistetut standardit.
Tavallinen tapa toteuttaa tämä on palvelinpuoleinen suodatus. Palvelin tietää, kuka pyytää tietoa, tarkistaa, mitä kyseinen henkilö saa nähdä, ja palauttaa juuri tämän osan. Käyttöoikeuksien hallinta: hoidettu. Standardi ei vaadi enempää.
Tässä on kuitenkin yksi ongelma, jota standardi ei ota huomioon: Ote saapuu allekirjoittamattomana. Lukija saa hänelle kootun näkymän ja joutuu luottamaan siihen, että palvelin on valinnut sisällön rehellisesti eikä ole muuttanut sitä siirron aikana. Julkisen tiedotteen kohdalla tämä on hyväksyttävää. Mutta kun kyseessä on arvo, johon tietojen käsittelijä perustaa esimerkiksi käytetyn pariston hinnan, se vaatii paljon luottamusta.
Missä yksittäinen allekirjoitus saavuttaa rajansa
Ilmeisin ratkaisu on allekirjoittaa tiedot. Tavallinen allekirjoitus toimii hyvin asteikon molemmissa päissä: julkinen näkymä allekirjoitetaan, täydellinen tietojoukko allekirjoitetaan, ja molemmat tarkistetaan julkisen avaimen avulla ilman, että välissä on palvelinta. Miten tämä tapahtuu yksityiskohtaisesti, on kuvattu artikkelissa Allekirjoitukset ja varmenteet DPP:ssä.
Keskivaiheilla järjestelmä pettää. Koko asiakirjan kattava allekirjoitus kattaa täsmälleen yhden kenttäjoukon, nimittäin ne kentät, jotka olivat olemassa allekirjoitushetkellä. Jos valtuutetulle lukijalle avataan lisäksi suojattu kenttä, tämä kenttä jää allekirjoitetun joukon ulkopuolelle ja saapuu hänelle suojaamattomana. Jos sen sijaan allekirjoitetaan alusta alkaen koko tietojoukko, allekirjoitus kattaa kyllä kaiken, mutta silloin jouduttaisiin näyttämään kaikki kaikille.
Välissä olevat tahot jäävät siten järjestelmän ulkopuolelle: korjaamo, vakuutusyhtiö, kierrättäjä. Jos haluttaisiin allekirjoittaa etukäteen jokainen mahdollinen ”kuka näkee mitä” -yhdistelmä, jokaiselle yhdistelmälle tarvittaisiin oma allekirjoitettu asiakirja, ja yhdistelmien määrä kasvaa räjähdysmäisesti jokaisen uuden käyttöoikeusryhmän myötä. Kukaan ei tee niin. Turvaudutaan allekirjoittamattomaan palvelinsuodattimeen, ja välivaihe perustuu jälleen luottamukseen.
Jokaisen kentän allekirjoittaminen erikseen
On olemassa parempi ratkaisu, ja rakennamme alustamme sen pohjalta. Sen sijaan, että valmis asiakirja allekirjoitettaisiin yhtenä kokonaisuutena, allekirjoittaja määrittelee jokaisen kentän erikseen yhdellä allekirjoituskierroksella (standardeihin perehtyneille: W3C-todistus ecdsa-sd-2023 valikoivaa paljastamista varten).
Jokainen näkymä alkaa julkisesta ytimestä
Jokainen näkymä alkaa siis samoista julkisista kentistä. Se, mitä lukija näkee tämän lisäksi, lisätään kenttä kerrallaan, ja jokainen näistä kentistä johtaa edelleen laatijan julkiseen avaimeen - offline-tilassa, ilman uutta allekirjoitusta ja ilman luottamusta näkymän kokoajaan. Kentät, joihin ei ole oikeutta, puuttuvat yksinkertaisesti. Niitä ei ole peitetty, vaan niitä ei ole lainkaan, eikä niistä vuoda mitään tietoa.
Esimerkki: korjaamo
Esimerkki havainnollistaa, miltä tämä käytännössä tuntuu. Korjaamo on ilmoittanut akkua koskevan oikeutetun edun, joka on yksi akkuasetuksessa nimenomaisesti mainituista käyttöoikeustasoista. Sen korjaamojärjestelmä kirjautuu API-avaimellaan rajapintaamme ja hakee passin.
Vastauksena saadaan sama julkinen passi, jonka myös ostaja näkee, mutta jossa on tarkalleen yksi kenttä lisää: purkuohjeet, jotka paljastetaan vain oikeutetuille lukijoille. Ei toista asiakirjaa, ei erikoisversiota, vaan sama passi, jossa on yksi kenttä lisää.
Ennen kuin yritys luottaa tähän kenttään, sen ohjelmisto tarkistaa mukana toimitetun todistuksen vertaamalla sitä myöntäjän julkiseen avaimeen. Jos tarkistus onnistuu, myös lisäkentän osalta, yritys tietää: nämä ohjeet ovat merkki merkiltä valmistajalta, eikä kukaan meistä tai ketään väliportaan toimijoista ole muuttanut niitä millään tavalla. Jos tarkistus ei onnistu, se tietää tämän yhtä varmasti ja hylkää näkymän kokonaan.
Oma osuutemme tässä on tarkoituksellisesti pieni. Se, että se saa juuri ne kentät, joihin sillä on oikeus, on edelleen pääsynhallintamme tehtävä; jokainen palvelinsuodatin hoitaa tämän samalla tavalla. Uutta on seuraava vaihe: hän tarkistaa itse, onko saapuva sisältö aitoa, kysymättä meiltä.
Miksi ”rikkomattomuus” on koko asian ydin
Kuvitellaan notaaria, joka ei todista kirjettä kokonaisuudessaan, vaan jokaisen kappaleen erikseen. Julkisen kirjeen saa jokainen. Se, jolla on oikeus saada enemmän, saa lisäkappaleet, ja jokaisessa niistä on edelleen saman notaarin sinetti.
Miksi ”ehjä” on tässä niin tärkeää, ansaitsee vielä yhden lauseen. Ehjä sinetti ei tarkoita, että sisältö on totta. Se kertoo: juuri tämän lähettäjä on kirjoittanut, eikä kukaan ole sen jälkeen muuttanut siitä mitään. Näin ollen luottamuskysymyksen ulkopuolelle jää jokainen, joka on vain välittänyt asiakirjan eteenpäin - välimuisti, verkko, arkisto, me. Sillä ei ole enää merkitystä, kuka passin sinulle antoi.
Ja sinetti on binäärinen. Se joko pysyy ehjänä tai ei, puoliksi rikkoutunutta sinettiä ei ole olemassa. Jos se rikkoutuu, et saa tietää, mikä lause on muutettu, vaan vain sen, ettet voi enää luottaa koko asiakirjaan. Siksi ei ole asteittaista eroa siinä, saapuvatko lisäkentät sinetillä varustettuina vai ilman: Ilman sinettiä ne eivät ole vain hieman heikommin vahvistettuja, vaan ne eivät ole lainkaan vahvistettuja.
Molemmat menetelmät tarkasteltavina
Kuka tahansa voi tarkistaa tämän itse. Transpareo Time Machine on avoimen lähdekoodin sovelluksemme tuotepassien ### tarkasteluun: Se selaa passin versiohistoriaa ja laskee samalla jokaisen allekirjoituksen katsojan selaimessa ilman, että se kysyy tietoja palvelimeltamme. Siinä on julkisesti saatavilla kaksi esimerkkipassia. T-paidan passissa on koko asiakirjaa koskeva allekirjoitus, pariston passissa kenttäkohtainen julkistaminen.
Molemmat ovat avoimia W3C-spesifikaatioita: eddsa-jcs-2022 koko asiakirjan kattavalle allekirjoitukselle, ecdsa-sd-2023 kenttäkohtaiselle tietojen julkistamiselle. Kuka tahansa voi toteuttaa ne, jos haluaa. Työmäärä on syy siihen, miksi monet eivät tule tekemään niin: koko asiakirjan kattava allekirjoitus on huomattavasti edullisempi rakentaa ja ylläpitää, ja se riittää niille, jotka toimittavat vain julkisia tietoja.
Se, että Time Machine hallitsee molemmat menetelmät, on tarkoituksellista ja pysyykin niin. Se ei kuulu millekään alustalle. Tarkastaja, joka hyväksyisi vain kalliimman menetelmän, olisi työkalu meille eikä kenellekään muulle.
Kenelle suojatut kentät paljastetaan
On syytä kysyä, kenelle julkisten tietojen lisäksi ylipäätään paljastetaan mitään. Ei satunnaiselle ostajalle - hän saa julkisen passin. Ne ovat kierrättäjä, joka arvioi käytetyn akkupaketin arvon; vakuuttaja, joka hinnoittelee riskin; kierrättäjä, joka lajittelee kemikaaleja; viranomainen, joka rakentaa tapausta. Nämä ovat lukijoita, joiden päätökset liittyvät rahaan tai turvallisuuteen.
Ja juuri nämä kentät jäävät tavanomaisessa lähestymistavassa paljastamatta. Juuri ne, joilla olisi eniten syytä haluta kryptografista todistusta, eivät saa sitä juuri niistä kentistä, jotka vaikuttavat heidän päätökseensä.
Mielestämme varmennusmerkin tulisi tarkoittaa samaa kaikille. ”Transpareon tarkastama” tarkoittaa korjaamon laajennetussa näkymässä samaa kuin ostajan julkisessa passissa: jokainen näkyvä kenttä on peräisin myöntäjältä, eikä siihen ole sen jälkeen koskettu. Sertifikaatti, joka koskee vain julkisia kenttiä, on puolittaista.
Enemmän kuin standardi vaatii
Sanomme tämän suoraan: mitään tästä ei ole määrätty. EN 18239 -standardi vaatii, että pääsyä hallitaan, ja palvelinpuolen suodatin hallitsee pääsyä moitteettomasti. Myös julkisten kenttien tekeminen kryptografisesti todennettaviksi on jotain, mitä teemme ylimääräisenä palveluna - se ei ole pakollinen vaatimus, jota sääntely meiltä edellyttää.
Juuri siksi se on mainitsemisen arvoista. Allekirjoitetun passin koko tarkoitus on, ettei kenenkään tarvitse luottaa alustaan. Keskitason poikkeuksen poistaminen palauttaa juuri sen luottamuksen, jonka allekirjoituksen oli tarkoitus poistaa.
Sama periaate saa kentän unohtumaan
Jokaisen kentän erikseen määritteleminen tuo mukanaan toisen ominaisuuden, ja tätä eurooppalainen lainsäädäntö itse asiassa vaatii. Yleinen tietosuoja-asetus antaa ihmisille oikeuden saada henkilötiedot poistettua. Yhtenä kokonaisuutena allekirjoitettu tietue ei voi täyttää tätä vaatimusta tuhoamatta omaa allekirjoitustaan.
Koska tässä jokainen kenttä on erillinen, yksittäinen kenttä voidaan poistaa, kun taas kaikki muu pysyy edelleen todennettavissa. Jos henkilötietoja päätyy vahingossa passiin, ne voidaan poistaa siististi, ja passi pysyy voimassa: ei uutta myöntämistä, ei katkenneita tietoja. Lain mukaan säilytettävät pakolliset kentät jäävät paikalleen; poistettavat tiedot voidaan poistaa pyynnöstä, jopa vuosia myöhemmin.
Silti täysin tavallinen passi
Mikään näistä seikoista ei tee passista erityistä objektia, jonka vain omat työkalumme pystyvät avaamaan. Se pysyy verifioitavana tunnistetietona (Verifiable Credential) JSON-LD-muodossa, johon web-standardien maailma on siirtymässä, ja samaa muotoa käyttävät myös YK:n läpinäkyvyysprotokolla (UN Transparency Protocol) ja muu W3C-ympäristö.
Passi, jonka ostaja skannaa selaimessaan, on siis sama objekti, jonka datahuoneen kumppani voi lukea, ja kuka tahansa standardien mukainen tarkastaja voi tarkistaa sen, ei vain meidän omamme. Lisäturvallisuus ei maksa lukijalle mitään eikä sido ketään meihin.
Miksi tämä on teknisesti vaikeaa
Ensinnäkin, jotta ei syntyisi väärää käsitystä: emme ole keksineet tätä menetelmää. ecdsa-sd-2023 on julkinen W3C-spesifikaatio, sen taustalla oleva salaustekniikka ei ole meidän kehittämä, ja kuka tahansa, joka haluaa toteuttaa sen, voi lukea siitä lisää. Idean keksiminen ei ole vaikeaa. Vaikeaa on rakentaa se niin, että salasana toimii vielä kymmenen vuoden kuluttua. Siinä piilee työn ydin, ja siitä voidaan sanoa jotain hyödyllistä.
Ero kuulostaa pieneltä, mutta se muuttaa perustan: tavallinen allekirjoitus laskee dokumentin tavujen perusteella. Valikoiva paljastaminen laskee asiakirjan väittämien perusteella. Passi muokataan ennen allekirjoittamista standardoituun muotoon, jossa jokainen tieto esiintyy erillisenä, itsenäisenä lauseena. Vasta tämän ansiosta yksi lause voidaan jättää pois vahingoittamatta muita.
Tämän myötä syntyy ongelma, jota tavallisella tavu-allekirjoituksella ei ole: sama standardoitu muoto on saatava täsmälleen takaisin kymmenen vuoden kuluttua. Ei suunnilleen, vaan merkki merkiltä, muuten todiste ei enää täsmää. Kolme asiaa estää tämän, ja kaikki kolme ovat huomaamattomia.
Luvut menettävät tyyppinsä. Jos luku kirjoitetaan pelkkänä JSON-muodossa, sentyyppi katoaa matkan varrella. Arvo kuten 2,0 palautuu JSON-kierroksen jälkeen muodossa 2. Ihmiselle se on sama asia, mutta standardoidussa muodossa se on eri lause, ja tarkistus epäonnistuu.
Nimet eivät vielä tarkoita mitään. Jotta standardoitu muoto syntyisi, jokaisen kentän nimen on viitattava yksiselitteiseen merkitykseen. Jos jokin puuttuu, kenttä katoaa muunnoksessa huomaamatta. Se on silloin passissa, mutta todistus ei kata sitä, eikä kukaan huomaa sitä.
Merkitykset löytyvät yleensä verkosta. Tämä vastaavuus on sanastossa, jonka useimmat työkalut lataavat verkosta tarkistuksen yhteydessä. Kuka näin tekee, asettaa passinsa tarkistettavuuden riippuvaiseksi siitä, että vieras osoite vastaa vielä kymmenen vuoden kuluttua, ja vieläpä muuttumattomana.
Kuinka ratkaisimme asian
Suljimme nämä kolme kohtaa jo alkulähteellä sen sijaan, että olisimme korjanneet ne myöhemmin.
Tyyppien määrittely. Jokainen arvo kirjoitetaan tyyppinsä mukaisesti, ja julkaisu keskeytyy heti, kun standardoidussa muodossa esiintyy edes yksi tyypittömä luku. Virhe havaitaan siis heti, kun se aiheuttaa yhden rivin menetyksen, eikä vasta vuosia myöhemmin selittämättömänä tarkastusvirheenä.
Sanastot. Jokainen sanasto, johon passi viittaa, on meillä paikallisesti saatavilla eikä sitä koskaan haeta verkosta. Tuntematon osoite aiheuttaa allekirjoituksen keskeytyksen, eikä se johda hiljaiseen paluuseen tyhjään tulokseen.
Tunnisteet. Jokaisella dokumentin solmulla on vakaa tunniste, jotta standardoitu muoto pysyy toistettavissa sen sijaan, että jokaisella kierroksella annettaisiin uusia apunimiä.
Herkin osa liittyy Bring Your Own Key -periaatteeseen. Jokaista myöntämistä varten tarvitaan ylimääräinen, lyhytaikainen avain, jolla julkistettavat kentät allekirjoitetaan yksitellen. Myöntäjä luo ja hävittää tämän avaimen itse. Jos avain olisi meillä, voisimme keksiä yksittäisiä kenttiä jälkikäteen, ja julkaisijan allekirjoituksen riippumattomuus olisi enää vain väitettä. Tarkistamme palautetun todistuksen tallennetun julkisen avaimen avulla, ennen kuin luotamme siihen.
Jokaisessa passissa on kaksi tällaista todistetta, yksi myöntäjältä ja yksi Transpareolta, ja kumpikin niistä johdetaan lukijan näkökulmasta riippumattomasti. Kaksi allekirjoitusta, kaksi toisistaan riippumatonta auktoriteettia, jopa yksittäisen julkistettavan kentän osalta.
Meille tämä vaiva on perusteltua. Emme ole lisänneet todennettavuutta jälkikäteen; alusta on rakennettu sen ympärille jo ensimmäisestä versiosta lähtien. Jokainen passi allekirjoitetaan julkaisun yhteydessä ja ketjutetaan edelliseen versioon. Muuttumaton kymmenen vuoden arkisto on luotu ja se astuu voimaan heti, kun passit on rekisteröity EU-DPP-rekisteriin rekisteröidään. Kunkin kentän allekirjoittaminen koko lohkon sijaan on tämän ytimen laajennus, ei lisäys johonkin, jota ei ole koskaan tarkoitettu tähän tarkoitukseen.
Missä olemme
Olemme päättäneet käyttää todistetta jokaisen lukijan hyväksi, koska sinetin tulisi tarkoittaa yhtä ja samaa asiaa riippumatta siitä, kuka sitä tarkastelee. Jos haluat nähdä, miten se toimii: edellä linkitetyt kaksi esittelyä tarkistavat itsensä suoraan selaimessa ilman palvelinkyselyä.
Kysymyksiä tästä artikkelista
Määrääkö jokin standardi kenttäkohtaisen allekirjoituksen?
Ei. Standardi EN 18239 edellyttää, että pääsyä hallitaan kunkin tietokentän osalta, ja palvelinpuolen suodatin täyttää tämän vaatimuksen täysin. Se, että julkistetuista kentistä tehdään tarkistettavia, on meidän päätöksemme, eikä mikään sääntelyn vaatima rasti. Pidämme tätä työtä perusteltuna, koska allekirjoitetun passin koko tarkoitus on se, ettei kenenkään tarvitse luottaa alustaan - välitason poistaminen palauttaa juuri tämän luottamuksen. Näiden standardien asemasta kerrotaan tark emmin artikkelissamme yhdenmukaistetuista standardeista.
Mitä konkreettista eroa on palvelinsuodattimeen verrattuna?
Kyse ei ole siitä, kuka mitäkin näkee, vaan siitä, mitä perille saapuu. Molemmat menetelmät näyttävät lukijalle tarkalleen ne kentät, joihin hänellä on oikeus. Palvelinsuodattimessa otos saapuu allekirjoittamattomana, joten lukijan on luotettava siihen, että palvelin on valittu rehellisesti eikä siihen ole tehty muutoksia siirron aikana. Kenttäkohtaisissa todisteissa sama otos saapuu todisteen kera, joka voidaan jäljittää offline-tilassa myöntäjän julkiseen avaimeen ilman, että kenenkään tarvitsee kysyä meiltä. Julkisen tiedotteen kannalta ero on akateeminen, mutta kun kyse on arvosta, johon kierrättäjä perustaa käytetyn pariston hinnan, se on ratkaiseva tekijä.
Tarvitsevatko lukijat tätä varten erityisohjelmistoa?
Ei. Passi pysyy JSON-LD-muotoisena todennettavissa olevana todistuksena (Verifiable Credential), ja sen todentamisperusteena on julkinen W3C-salausjärjestelmä ecdsa-sd-2023, joten kuka tahansa standardin mukainen tarkastaja voi tarkistaa sen. Avoimen lähdekoodin näyttösovelluksemme, Transpareo Time Machine, laskee jokaisen allekirjoituksen lukijan selaimessa kysymättä sitä meiltä palvelimelta, ja se hallitsee tarkoituksellisesti myös koko asiakirjan kattavan yksinkertaisen allekirjoituksen. Tarkastaja, joka hyväksyisi vain meidän menetelmämme, olisi työkalu meille eikä kenellekään muulle.
Kenelle suojatut kentät ylipäätään paljastetaan?
Ei satunnaiselle ostajalle - hän saa yleisen passin. Kyseessä ovat korjaamo, jolla on ilmoitettu oikeutettu intressi, kunnostusyritys, joka arvioi käytetyn akkupaketin arvon, kierrättäjä, joka lajittelee kemikaalit, vakuutusyhtiö, joka hinnoittelee riskin, sekä viranomainen, joka laatii tapauskansion - toimijat, joiden päätökset liittyvät rahaan tai turvallisuuteen. EU:n akkuasetus nimenomaan määrittelee nämä vaiheet. Samalla nämä ovat juuri ne toimijat, jotka tavanomaisessa lähestymistavassa eivät saa todisteita juuri niiltä aloilta, joihin heidän päätöksensä perustuvat.
Julkaisemme vain julkisia tietoja. Tarvitsemmeko sitä?
Luultavasti ei, ja sanomme sen myös suoraan. Koko asiakirjan kattava allekirjoitus, Cryptosuite eddsa-jcs-2022, kattaa passin, jonka kaikki kentät ovat julkisia, ja sen rakentaminen ja ylläpito on huomattavasti edullisempaa. Kenttäkohtainen julkistaminen kannattaa heti, kun mukaan tulee toinen kohderyhmä, kuten korjausverkosto, kierrättäjä tai viranomainen, jolle muuten luovuttaisit allekirjoittamattomia otteita. Molemmat menetelmät ovat avoimia W3C-spesifikaatioita, ja molemmat ovat nykyään käytössä Time Machinessa, T-paidan passissa ja akun passissa.
Voidaanko henkilötiedot poistaa myöhemmin ilman, että passi mitätöidään?
Kyllä, ja tämä osa onkin Euroopan unionin lainsäädännön vaatimus. Yleinen tietosuoja-asetus antaa ihmisille oikeuden saada henkilötiedot poistettua, eikä lohkona allekirjoitettua tietuetta voida poistaa ilman, että sen oma allekirjoitus tuhoutuu. Koska tässä jokainen kenttä on määritelty erikseen, yksittäinen kenttä voidaan poistaa, kun taas kaikki muu pysyy edelleen todennettavissa - ei uutta myöntämistä, ei katkenneita versiohistorioita. Sääntelyn edellyttämät kentät, joiden säilyttämistä laki vaatii, jäävät paikalleen.
Kuka hallitsee allekirjoitusavainta?
Jokaiseen passiin liittyy kaksi todistusta, joista toinen voi olla sinun. Jokainen myöntäjä tarvitsee lisäksi lyhytaikaisen avaimen, joka allekirjoittaa julkistettavat kentät yksitellen; myöntäjä itse luo ja hävittää tämän avaimen, sillä jos se olisi meillä, voisimme keksiä yksittäisiä kenttiä jälkikäteen, ja myöntäjän allekirjoituksen riippumattomuus olisi enää vain väitettä. Tarkistamme palautetun todistuksen tallennetun julkisen avaimen avulla, ennen kuin luotamme siihen. Jokaisessa passissa on siis kaksi todistusta kahdelta riippumattomalta viranomaiselta, sekä yksittäisen julkistettavan kentän että koko tietueen osalta.
Onko passi vielä voimassa kymmenen vuoden kuluttua?
Juuri siinä piilee työmäärä. Valikoiva julkistaminen perustuu asiakirjan sisältöön sen tavujen sijaan, joten sama standardoitu muoto on tuotettava merkki merkiltä uudelleen vuosikymmen myöhemmin. Kolme asiaa rikkoo tämän järjestelmän, ja olemme ratkaisseet ne kaikki juuritasolla - jokainen arvo kirjoitetaan tyyppinsä mukaisesti, ja julkaisu keskeytyy, jos löytyy tyypitön luku; jokainen sanasto on saatavilla paikallisesti eikä sitä koskaan haeta verkosta, ja jokaisella solmulla on vakaa tunniste, jotta standardoitu muoto pysyy toistettavissa. Muuttumaton kymmenvuotinen arkisto on perustettu ja se astuu voimaan heti, kun passit on rekisteröity EU:n rekisteriin, joka on ollut toiminnassa 20. heinäkuuta 2026 lähtien täytäntöönpanoasetuksen (EU) 2026/1778 nojalla. Lisätietoja aiheesta löytyy rekisteriasetusta koskevasta analyysistämme.
