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 fastslår 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 riktig og videreformidlet dem uendret?
Tenk deg en notarius som ikke bekrefter brevet i sin helhet, men hvert avsnitt for seg. Det offentlige brevet får alle. De som har rett til mer, får de ekstra avsnittene i tillegg, og hvert av dem bærer fortsatt seglet til den samme notariusen. Slik har vi bygget plattformen vår. Hos de fleste plattformer er det ærlige svaret på spørsmålet ovenfor: tillit. Hos oss er svaret: bevis, for hvert felt som først legges til ved offentliggjøringen. Denne artikkelen forklarer hvorfor denne forskjellen er viktig, 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 at tilgangen styres felt for felt: 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 i vårt innlegg om harmoniserte standarder.
Den vanlige måten å oppnå dette på er et filter på serveren. Serveren vet hvem som spør, sjekker hva denne personen har lov til å se, og leverer nøyaktig dette utdraget tilbake. Standarden krever ikke mer enn det. Leseren må stole på at serveren har valgt ut innholdet på en ærlig måte og ikke har endret noe underveis. For et offentlig informasjonsark er dette greit. For en verdi som en gjenvinningsbedrift bruker som grunnlag for prisen på et brukt batteri, er det mye tillit å stille.
Det er imidlertid en hake som standarden ikke tar hensyn til: Utdraget kommer uten segl.
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. Hvordan dette foregår i detalj, står beskrevet i «Signaturer og sertifikater» i DPP. I midten bryter det sammen. En signatur over hele dokumentet dekker nøyaktig de feltene som var til stede ved signeringen. Hvis man i tillegg åpner et beskyttet felt for en autorisert leser, ligger dette feltet utenfor den signerte mengden og kommer udekket frem til ham. Ingen signerer alle mulige kombinasjoner av «hvem ser hva» på forhånd, for antallet kombinasjoner eksploderer. Man faller tilbake på filteret uten segl, og det midterste trinnet baserer seg igjen på tillit.
Signere hvert felt enkeltvis
Det finnes en bedre konstruksjon, og det er den vi bygger plattformen på. I stedet for å signere det ferdige dokumentet som én samlet enhet, fastsetter produsenten hvert felt enkeltvis i én enkelt gjennomgang (for de som kjenner standardene: W3C-prosedyren ecdsa-sd-2023).
Hver visning starter dermed 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 produsentens 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.
En gjennomgang: reparasjonsverkstedet
Et reparasjonsverksted har meldt en berettiget interesse for et batteri, et av tilgangsnivåene som batteriforordningen uttrykkelig forutsetter. Verkstedssystemet logger seg på grensesnittet vårt med sin nøkkel og henter passet. Svaret er det samme offentlige passet som kjøperen også ser, men med nøyaktig ett felt til: demonteringsveiledningen, som kun blir vist til berettigede lesere. Ikke noe annet dokument, ingen spesialutgave.
Før bedriften stoler på dette feltet, sjekker programvaren den medfølgende signaturen mot produsentens offentlige nøkkel. Hvis signaturkontrollen går gjennom, også for det ekstra feltet, vet bedriften: Denne veiledningen stammer tegn for tegn fra produsenten, og ingen underveis har endret noe i den. Hvis den ikke stemmer, legger han hele visningen til side. At han mottar nøyaktig de feltene han har rett til, er fortsatt oppgaven til vår tilgangskontroll. Det nye er trinnet etterpå: Han sjekker selv om det han mottar er ekte, uten å spørre oss.
Hvorfor «ubrutt» er hele poenget
Et intakt segl sier ikke at innholdet er sant. Det sier: Dette er nøyaktig det produsenten har skrevet, og siden den gang har ingen endret et eneste tegn. Dermed faller alle som bare har videresendt dokumentet utenfor tillitsspørsmålet: mellomlagringen, nettverket, arkivet, oss.
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 som heter et halvveis brutt segl. 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 slett ikke dokumentert.
Begge metodene for visning
Dette kan alle sjekke selv. Transpareo Time Machine er vår åpne kildekode-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. Passet til en T-skjorte har en signatur som dekker hele dokumentet, mens passet til et batteri har feltvis godkjenning.
Begge er åpne W3C-standarder, og alle kan implementere dem. Signaturen som dekker hele dokumentet er betydelig billigere å utvikle og drifte, og for de som kun leverer offentlige data, er dette tilstrekkelig. Det er med vilje at Transpareo Time Machine støtter begge metodene: Passet forblir et vanlig standardformat som kan kontrolleres av ethvert egnet verktøy, ikke bare vårt.
Hvem har nytte av dette, og hva krever standarden?
Hvem får i det hele tatt tilgang til noe utover de offentlige dataene? Ikke den tilfeldige kjøperen. 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. Lesere hvis beslutninger avhenger av penger eller sikkerhet. Og i den vanlige tilnærmingen er det nettopp disse leserne som ikke får et sertifikat for feltene som deres beslutning bygger på. Vi mener at et sertifikat bør bety det samme for alle: Hvert felt som vises, stammer fra produsenten og har ikke blitt rørt siden. Et segl som kun gjelder for de offentlige feltene, er et halvt segl.
Vi sier det rett ut: Ingenting av dette er påbudt. EN 18239 krever at tilgangen kontrolleres, og et filter på serveren gjør dette feilfritt. At vi i tillegg gjør de offentliggjorte feltene verifiserbare, er fordi hele poenget med et signert pass er at ingen trenger å stole på plattformen. Å unntaksbehandle det midterste nivået gjenoppretter nettopp den tilliten som signaturen skulle fjerne.
Det samme prinsippet gjør at et felt kan glemmes
Å fastsette hvert ## feltfor 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 blokk, 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 resten fortsatt er gyldig. Hvis personopplysninger ved en feiltakelse havner i et pass, kan de fjernes uten problemer, og passet forblir gyldig: ingen nyutstedelse, ingen ødelagt historikk. Feltene som loven krever at skal oppbevares, forblir på plass; det som kan slettes, kan slettes på forespørsel, selv flere år senere.
Hvorfor dette er vanskelig, og hvordan vi har løst det
Vi har ikke oppfunnet denne prosessen; det er en offentlig W3C-standard. Det er ikke vanskelig å komme på ideen. Det vanskelige er å bygge den slik at et pass fortsatt kan valideres om ti år. En vanlig signatur beregnes ut fra dokumentets byte. Feltbasert signatur beregnes ut fra de enkelte opplysningene, og for dette formålet blir passet før signering omformet til en fast skrivemåte, der hver opplysning står som en egen setning. Denne formateringen må om ti år komme ut tegn for tegn, ellers vil ingen signatur lenger stemme. Tre ubetydelige ting står i veien for dette, og vi har løst alle tre ved roten.
Tall mister sin type. En verdi som 2,0 kommer tilbake som 2 etter en runde gjennom et vanlig dataformat. For et menneske er det det samme, for den faste skrivemåten er det en annen setning. Hos oss lagres hver verdi med sin type, og publiseringen avbrytes så snart det dukker opp bare ett tall uten type.
Betegnelser er ikke det samme som betydning. Hvert feltnavn må kunne spores tilbake til en entydig betydning i en ordbok, ellers forsvinner feltet stille og rolig under konverteringen, og seglet dekker det ikke. Hos oss ligger hver ordbok lokalt og hentes aldri fra nettet; et ukjent feltnavn stopper signeringen, i stedet for å levere et tomt resultat uten videre.
Oppføringer trenger faste navn. Hver oppføring i dokumentet har hos oss en fast identifikator, slik at skrivemåten forblir den samme ved hver gjennomgang, i stedet for å tildele nye hjelpenavn hver gang.
Den mest følsomme delen ligger i produsentens egen nøkkel. 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 produsenten selv. Hvis den lå hos oss, kunne vi finne på enkeltfelt i etterkant. Hvert pass har to slike segl, ett fra produsenten og ett fra Transpareo, også for et enkelt felt som offentliggjøres.
For oss er denne innsatsen vel anvendt. Med Transpareo Proofchain blir hvert pass signert ved publisering og koblet til forrige versjon, og Transpareo Vault - det uforanderlige tiårsarkivet - trer i kraft så snart passene er registrert i EU-registeret. Å signere hvert felt i stedet for hele blokken er en utvidelse av denne kjernen, ikke et tillegg.
Hvor vi står
Vi har valgt å gi bevis for hver leser, fordi et segl skal bety én ting, uansett hvem som ser på det. For de som vil se hvordan det fungerer: De to eksempelpassene som er lenket til ovenfor, kan verifiseres direkte i nettleseren, uten å spørre en server.
Spørsmål om dette innlegget
Foreskriver en standard signaturen felt for felt?
Nei. EN 18239, den europeiske standarden for tilgangsrettigheter i DPP, krever at tilgangen styres felt for felt, og et filter på serveren oppfyller dette fullt ut. Å gjøre de offentliggjorte feltene verifiserbare utover dette er vårt eget valg, og ikke et krav som reguleringen stiller til noen. Vi anser innsatsen som berettiget, fordi hele poenget med et signert pass er at ingen trenger å stole på plattformen. Hvilken status disse standardene egentlig har, fremgår av vårt innlegg om harmoniserte standarder.
Vi publiserer kun offentlige data. Trenger vi det?
Sannsynligvis ikke, og det sier vi også rett ut. En signatur som gjelder hele dokumentet dekker et pass der alle feltene er offentlige, og den er betydelig billigere å utvikle og drifte. Feltvis godkjenning lønner seg så snart en ny målgruppe kommer til, for eksempel et reparasjonsnettverk, en gjenvinningsbedrift eller en myndighet som du ellers ville ha gitt utdrag uten segl. Begge metodene er åpne W3C-standarder (ecdsa-sd-2023 for feltvis signatur), ethvert verktøy som støtter standarden kan verifisere dem, og begge kjører i dag i Transpareo Time Machine, på passet til en T-skjorte og på passet til et batteri.
Kan personopplysninger slettes senere uten at passet blir ugyldig?
Ja, og dette kravet er faktisk fastsatt i europeisk lovgivning. Personvernforordningen gir enkeltpersoner rett til å få slettet personopplysninger, og en datasett som er signert som en blokk kan ikke etterkomme dette kravet uten å ødelegge sin egen signatur. Siden hvert felt her er fastsatt for seg, kan et enkelt felt fjernes, mens alt annet fortsatt er gyldig, uten at det må utstedes på nytt og uten at versjonshistorikken blir ødelagt. Feltene som loven krever at skal bevares, forblir på plass.
Hvem har signaturnøkkelen?
Hvert pass har to segl, og ett av dem kan være ditt. Hver utstedelse krever i tillegg en kortvarig nøkkel som signerer de feltene som kan offentliggjøres, ett etter ett; denne genereres og kasseres av produsenten selv, for hvis den lå hos oss, kunne vi finne på enkelte felter i etterkant. Vi sjekker det returnerte seglet mot den lagrede offentlige nøkkelen før vi stoler på det. Hvert pass har dermed to segl fra to uavhengige instanser, både for hvert enkelt felt som offentliggjøres og for hele datasettet.
Vil et pass fortsatt være gyldig om ti år?
Det er nettopp der arbeidet ligger. Den feltbaserte signaturen beregnes ut fra de enkelte opplysningene i et dokument, ikke ut fra bytene, så den samme faste skrivemåten må kunne gjenskapes tegn for tegn et tiår senere. Tre ting bryter dette prinsippet, og vi har løst alle tre ved kilden. Hver verdi lagres sammen med sin type, alle ordbøker ligger hos oss og hentes aldri fra nettet, og hver oppføring har en fast identifikator. Det uforanderlige tiårsarkivet er opprettet og trer i kraft så snart passene er registrert i EU-registeret. Mer om dette i vår analyse av registerforordningen.
