Et digitalt produktpass viser ikke det samme for alle. En kjøper ser de offentlige opplysningene. Et reparasjonsverksted eller en gjenvinningsbedrift ser mer. En markedstilsynsmyndighet ser alt. Dette er avklart, og de europeiske standardene fastsetter det nå uttrykkelig.
Det interessante spørsmålet er mer subtilt: Hvis noen får tilgang til beskyttede felt utover de offentlige opplysningene, kan vedkommende da bevise at nettopp disse feltene er ekte? Eller må vedkommende stole på at plattformen har plukket dem ut korrekt og videreformidlet dem uendret?
For de fleste plattformer er det ærlige svaret: tillit. Vi har bygget vår slik at svaret er «bevis» - ikke bare for de offentlige feltene, men for hvert felt som først blir lagt til ved offentliggjøringen. Hvorfor denne forskjellen teller, og hvorfor vi har valgt den mer ressurskrevende veien.
Alle oppfyller tilgangsreglene på samme måte
EN 18239, den europeiske standarden for tilgangsrettigheter, sikkerhet og konfidensialitet i DPP, krever tilgangskontroll for hvert enkelt dataelement: For hvert felt finnes det en regel for hvem som har lov til å se det. Dette er det riktige kravet, og det er ikke vanskelig å oppfylle. Hvilken status disse standardene egentlig har, har vi redegjort for under harmoniserte standarder.
Den vanlige måten å oppnå dette på er filtrering på serversiden. Serveren vet hvem som spør, sjekker hva denne personen har lov til å se, og leverer nøyaktig dette utdraget tilbake. Tilgangskontroll: ordnet. Standarden krever ikke mer enn det.
Det er imidlertid en hake ved dette som standarden ikke tar hensyn til: Utdraget kommer usignert. Leseren får en oversikt som er satt sammen spesielt for ham, og må stole på at serveren har valgt ut innholdet ærlig og ikke har endret noe underveis. For et offentlig informasjonsark er dette greit. For en verdi som en databehandler bruker som grunnlag for prisen på et brukt batteri, er det å be om stor tillit.
Der en enkelt signatur når sine grenser
Den åpenbare løsningen er å signere dataene. For begge ender av skalaen fungerer en vanlig signatur godt: signere den offentlige visningen, signere det fullstendige datasettet, og begge verifiseres mot en offentlig nøkkel uten at en server står i veien. Hvordan dette foregår i detalj, står beskrevet i Signaturer og sertifikater i DPP.
I midten bryter det sammen. En signatur på hele dokumentet dekker nøyaktig ett sett med felt, nemlig de som var til stede ved signeringen. Hvis man i tillegg gjør et beskyttet felt tilgjengelig for en autorisert leser, ligger dette feltet utenfor den signerte mengden og kommer udekket frem til vedkommende. Signerer man i stedet hele datasettet fra starten av, dekker signaturen riktignok alt, men da må man også vise alt til alle.
Trinnene i mellom faller dermed utenfor rammen: reparasjonsverkstedet, forsikringsselskapet, gjenvinningsbedriften. Hvis man ønsket å signere hver eneste mulige kombinasjon av «hvem ser hva» på forhånd, ville man trenge et eget signert dokument for hver kombinasjon, og antallet kombinasjoner eksploderer med hver nye tilgangsgruppe. Det er det ingen som gjør. Man faller tilbake på det usignerte serverfilteret, og det mellomliggende leddet baserer seg igjen på tillit.
Signere hvert felt for seg
Det finnes en bedre løsning, og det er den vi bygger plattformen på. I stedet for å signere det ferdige dokumentet som én blokk, angir utstederen hvert felt enkeltvis i én enkelt signeringsomgang (for de som kjenner standardene: W3C-spesifikasjonen ecdsa-sd-2023 for selektiv offentliggjøring).
Hver visning starter med den offentlige kjernen
Hver visning ### starterdermed med de samme offentlige feltene. Det en leser får se utover dette, legges til felt for felt, og hvert av disse feltene kan fortsatt spores tilbake til utstederens offentlige nøkkel - offline, uten ny signering og uten tillit til den instansen som har satt sammen visningen. Feltene uten krav mangler ganske enkelt. Ikke svartet ut, men ikke der i det hele tatt, og ingenting siver gjennom om dem.
Hvorfor «ubrutt» er hele poenget
Tenk deg en notarius som ikke bekrefter brevet i sin helhet, men hvert avsnitt for seg. Det offentlige brevet får alle. Den som har krav på mer, får de ekstra avsnittene i tillegg, og hvert av dem bærer fortsatt seglet til den samme notaren. Ved vanlig fremgangsmåte skriver plattformen av disse avsnittene for deg, og det du mottar, bærer bare plattformens ord.
Hvorfor «ubrutt» er så viktig, fortjener en setning til. Et intakt segl sier ikke at innholdet er sant. Det sier: Dette er nøyaktig det utstederen skrev, og siden den gang har ingen endret et tegn i det. Dermed faller alle som bare har videresendt dokumentet - mellomlagringen, nettet, arkivet, vi - utenfor tillitsspørsmålet. Hvem som ga deg passet, spiller ingen rolle lenger.
Og et segl er binært. Enten holder det, eller så holder det ikke; det finnes ikke noe halvveis brutt segl. Hvis det brytes, får du ikke vite hvilken setning som er endret, men bare at du ikke lenger kan stole på hele arket. Derfor er det ingen gradvis forskjell på om de ekstra feltene kommer frem til deg med eller uten segl: Uten segl er de ikke noe svakere dokumentert, de er ikke dokumentert i det hele tatt.
Begge metodene kan du se på
Dette kan alle sjekke selv. Transpareo Time Machine er vår åpenkildekode-app for visning av produktpass: Den blar gjennom versjonshistorikken til et pass og beregner samtidig hver signatur i brukerens nettleser, uten å spørre en av våre servere. To eksempelpass er offentlig tilgjengelige der. Passet til en T-skjorte har en signatur som dekker hele dokumentet, mens passet til et batteri har feltvis offentliggjøring.
Begge er åpne W3C-spesifikasjoner: eddsa-jcs-2022 for signaturen som dekker hele dokumentet, ecdsa-sd-2023 for feltvis offentliggjøring. Alle som ønsker det, kan implementere dem. Arbeidsinnsatsen er grunnen til at mange ikke vil gjøre det: Signaturen som dekker hele dokumentet er betydelig billigere å utvikle og drifte, og den som kun leverer offentlige data, klarer seg med den.
At Time Machine behersker begge metodene, er tilsiktet og vil forbli slik. Den tilhører ingen plattform. En kontrollør som kun aksepterer den dyrere metoden, ville være et verktøy for oss og for ingen andre.
Hvem får tilgang til de beskyttede feltene
Det er verdt å spørre seg hvem som i det hele tatt får tilgang til noe utover de offentlige dataene. Ikke den tilfeldige kjøperen - hun får det offentlige passet. Det er gjenvinningsbedriften som vurderer hva et brukt batteripakke er verdt, forsikringsselskapet som prissetter en risiko, gjenvinningsbedriften som sorterer kjemikalier, og myndigheten som bygger opp en sak. Det er disse leserne som tar beslutninger som har betydning for penger eller sikkerhet.
Og det er nettopp disse feltene som i den vanlige tilnærmingen forblir udekket. Den som har størst grunn til å ønske seg et kryptografisk bevis, får det nettopp ikke for de feltene som ligger til grunn for vedkommendes beslutning.
Vi mener at et kontrollmerke bør bety det samme for alle. «Kontrollert av Transpareo» betyr det samme på den utvidede visningen hos et verksted som på et offentlig sertifikat til en kjøper: Hvert felt som vises, stammer fra utstederen og har ikke blitt endret siden. Et sertifikat som kun gjelder for de offentlige feltene, er et halvt sertifikat.
Mer enn standarden krever
Vi sier det rett ut: Ingenting av dette er påkrevd. EN 18239 krever at tilgangen kontrolleres, og et filter på serversiden kontrollerer tilgangen på en feilfri måte. Å gjøre også de offentliggjorte feltene kryptografisk verifiserbare er noe vi gjør i tillegg, ikke et krav som regelverket stiller til oss.
Nettopp derfor er det verdt å få nedskrevet. Det ville være enkelt å oppfylle bokstaven i standarden, levere serverfilteret og erklære trinnet for fullført. Vi foretrekker at løftet gjelder overalt der seglet vises. For hele poenget med et signert pass er at ingen trenger å stole på plattformen. Å unntake det midterste trinnet som en unntaksregel, gjenoppretter nettopp den tilliten som signaturen skulle fjerne.
Det samme prinsippet gjør at et felt blir glemt
Å forholde seg til hvert felt for seg medfører en annen egenskap, og denne kreves faktisk av europeisk lovgivning. Personvernforordningen gir mennesker rett til å få slettet personopplysninger. Et datasett som er signert som én samlet enhet, kan ikke oppfylle dette kravet uten å ødelegge sin egen signatur.
Fordi hvert felt her står for seg selv, kan et enkelt felt fjernes, mens alt annet fortsatt kan verifiseres. Hvis personopplysninger ved en feiltakelse havner i et pass, kan de fjernes uten problemer, og passet forblir gyldig: ingen nyutstedelse, ingen ødelagt historikk. De regulatoriske feltene som loven krever at skal oppbevares, forblir på plass; det som kan slettes, kan slettes på forespørsel, selv flere år senere.
Likevel et helt vanlig pass
Ingenting av dette gjør passet til et spesialobjekt som bare våre verktøy kan åpne. Det forblir en Verifiable Credential i JSON-LD, formatet som verden av webstandarder beveger seg mot, og det samme formatet som FNs Transparency Protocol og resten av W3C-miljøet bruker.
Passet som en kjøper skanner i nettleseren, er dermed det samme objektet som en dataromspartner kan lese inn, og enhver standardkompatibel kontrollør kan verifisere det, ikke bare våre egne. Den ekstra sikkerheten koster ikke leseren noe og binder ingen til oss.
Hvorfor dette er teknisk krevende
Først og fremst, for at det ikke skal oppstå et feilaktig inntrykk: Vi har ikke oppfunnet prosedyren. ecdsa-sd-2023 er en offentlig W3C-spesifikasjon; kryptografien bak stammer ikke fra oss, og den som ønsker å implementere den, kan lese seg opp på den. Det er ikke vanskelig å komme på ideen. Det vanskelige er å bygge den slik at et pass fortsatt kan verifiseres om ti år. Der ligger arbeidet, og om det kan man si noe nyttig.
Forskjellen høres liten ut, men endrer grunnlaget: En vanlig signatur beregner ut fra dokumentets byte. Selektiv offentliggjøring beregnes ut fra utsagnene i dokumentet. Passet blir før signering omformet til en standardisert form, der hver opplysning foreligger som en egen, selvstendig setning. Først da er det mulig å utelate en setning uten å skade de øvrige.
Dermed arver man et problem som en byte-signatur ikke har: Den samme standardiserte formen må komme nøyaktig ut igjen om ti år. Ikke omtrentlig, men tegn for tegn, ellers passer ikke beviset lenger. Tre ting står i veien for dette, og alle tre er ubetydelige.
Tall mister sin type. Skriver man et tall som ren JSON, går det tapt underveis hvilken type tall det var. En verdi som 2,0 kommer tilbake som 2 etter en runde gjennom JSON. For et menneske er det det samme, for den standardiserte formen er det en annen setning, og kontrollen mislykkes.
Betegnelser er ikke det samme som betydning. For at den standardiserte formen skal oppstå, må hvert feltnavn kunne tilordnes en entydig betydning. Mangler en slik betydning, forsvinner feltet i stillhet under konverteringen. Det står da i passet, men dokumentasjonen dekker det ikke, og ingen legger merke til det.
Betydninger finnes vanligvis på nettet. Denne tilordningen finnes i et vokabular som de fleste verktøy henter inn fra nettet under valideringen. Den som gjør dette, gjør validerbarheten av passet sitt avhengig av at en fremmed adresse fortsatt svarer om ti år, og at den da er uendret.
Slik løste vi det
Vi ## harlukket de tre punktene ved roten, i stedet for å fange dem opp senere.
Typer. Hver verdi skrives med sin type, og publiseringen avbrytes så snart det i den standardiserte formen dukker opp så mye som ett tall uten type. Feilen oppdages dermed der den koster én linje, i stedet for å dukke opp år senere som en uforklarlig valideringsfeil.
Vokabularer. Hvert vokabular som et pass refererer til, finnes lokalt hos oss og hentes aldri fra nettet. En ukjent adresse fører til et brått avbrudd under signeringen, ikke et stille tilbakefall til et tomt resultat.
Identifikatorer. Hver node i dokumentet har en stabil identifikator, slik at den standardiserte formen forblir reproduserbar, i stedet for å tildele nye hjelpenavn ved hver gjennomgang.
Den mest krevende delen ligger i «Bring Your Own Key». For hver utstedelse trengs en ekstra, kortvarig nøkkel, som brukes til å signere de feltene som kan offentliggjøres, ett etter ett. Denne nøkkelen genereres og kasseres av utstederen selv. Hvis den lå hos oss, kunne vi finne på enkeltfelt i etterkant, og uavhengigheten til utstillerens signatur ville bare være en påstand. Vi sjekker den returnerte bekreftelsen mot den lagrede offentlige nøkkelen før vi stoler på den.
Hvert pass inneholder to slike bevis, ett fra utstederen og ett fra Transpareo, og hvert av dem blir utledet uavhengig av hverandre for en lesers syn. To signaturer, to uavhengige autoriteter, selv for et enkelt felt som blir offentliggjort.
For oss er denne innsatsen på rett sted. Vi har ikke lagt til verifiserbarheten i etterkant; plattformen er bygget opp rundt dette helt fra den første versjonen. Hvert pass signeres ved publisering og lenkes til forrige versjon. Det uforanderlige tiårsarkivet er opprettet og trer i kraft så snart passene er registrert i EU-DPP-registeret. Å signere hvert enkelt felt i stedet for hele blokken er en utvidelse av denne kjernen, ikke et pålegg på noe som aldri var ment for dette formålet.
Hvor vi står
Kort sagt er valget enkelt. Du kan offentliggjøre beskyttede felt og be leseren om å stole på filteret ditt - det oppfyller standarden. Eller du kan offentliggjøre dem og legge ved beviset samtidig - det oppfyller et høyere krav, som vi mener disse feltene fortjener.
Vi har valgt å legge ved beviset, for hver enkelt leser, fordi et segl bør bety én ting, uansett hvem som ser på det. For de som vil se hvordan det fungerer: De to demoene som er lenket til ovenfor, verifiseres direkte i nettleseren, offline, mot ingenting annet enn en offentlig nøkkel.