Et lovforslag ligger på bordet, og alle kan komme med innspill. Slik jobber EU-kommisjonen: Forslag som dette om forordningen om DPP-registeret legges ut til offentlig høring i fire uker, og den som ønsker det, kan si sin mening via portalen «Have Your Say» - med navn, synlig for alle. Innspillene blir offisielt innarbeidet i den endelige versjonen.
Vi har gjort dette fire ganger, knyttet til de fire punktene som en produsent først ville støte på i hverdagen. Utkastet fra 29. april 2026 har vi diskutert inngående her i bloggen; fristen for tilbakemeldinger løper frem til 27. mai 2026. Dette innlegget forklarer hva vi har skrevet til Kommisjonen og hvorfor.
Hvorfor fire separate innspill
Portalen tillater 4 000 tegn per innlegg. Vi kunne ha presset alle punktene inn i ett langt innlegg. For kommisjonens ansatte, som i mai skal gå gjennom dusinvis av innlegg, ville det vært vanskeligere å lese og vanskeligere å sitere. Fire separate innspill er hver for seg lette å finne i den offentlige listen, og hvert av dem kan besvares eller avvises for seg selv, uten at det påvirker de andre punktene.
Vi har sendt inn følgende fire temaer:
1. Fastslå hva en tjenesteleverandør som et minimum må yte
Utkastet fastsetter fordelingen riktig: Passdataene forblir hos selskapet eller dets tjenesteleverandør, mens kommisjonens register kun lagrer henvisningene. For tjenesteleverandører (artikkel 2 nr. 32 i ESPR) er det planlagt en offisiell liste over godkjente leverandører.
Det som mangler, er en fastsettelse av hva en tjenesteleverandør faktisk må oppfylle for å komme inn på denne listen og forbli der. Antakelig vil de egentlige forpliktelsene følge i en egen rettsakt i henhold til artikkel 4 i ESPR. Registeret starter imidlertid før denne rettsakten er offentliggjort.
Vårt forslag: Enten fastsette minimumsforpliktelser for tjenesteleverandører direkte i denne forordningen, eller angi en bindende frist for når lovgivningen skal legges frem. Blant de foreslåtte minimumsforpliktelsene inngår:
- Det offentlige lesegrensesnittet for pass skal være tilgjengelig minst 99,5 prosent av måneden
- En fast forpliktelse til hvor raskt en ny passversjon må være tilgjengelig i sikkerhetskopien (forslag: 24 timer eller umiddelbart, der det er teknisk mulig)
- Tjenesteleverandøren skal kontrollere signaturen på hver innkommende versjon
- Selskapets offentlige nøkler skal ligge under en enhetlig sti (i henhold til RFC 8615, forslag
/.well-known/dpp-keys/) - En fastsatt prosedyre for bytte og insolvens, slik at passdataene flyttes på en ordnet måte til en annen leverandør dersom en leverandør svikter
Disse forpliktelsene koster ikke noe for en seriøs leverandør, da vedkommende oppfyller dem uansett. De forhindrer imidlertid et kappløp mot bunnen blant lavpristilbydere, noe som til slutt vil devaluere listen.
2. Et bevis som gjelder i ti år
Artikkel 9(4) begrenser tilgjengeligheten av registreringsbeviset til 90 kalenderdager. Innenfor denne fristen utsteder registeret et nytt bevis på forespørsel. For den løpende driften er dette greit, men det stemmer ikke overens med gyldighetsperioden for forpliktelsen som ligger til grunn: Artikkel 10(3) fastsetter oppbevaringstiden til ti år fra registreringstidspunktet, mens bransjelovgivning kan kreve lengre oppbevaringstid.
En markedstilsynsmyndighet, en tollbetjent, en gjenvinningsaktør eller en forsker i 2032 bør kunne kontrollere at et pass registrert i 2026 virkelig var registrert, uten å være avhengig av at det opprinnelige selskapet fortsatt eksisterer og kan be om et nytt bevis.
Våre to forslag er enkle å gjennomføre:
- Uttrykkelig presisere at beviset som er forseglet av Kommisjonen, kan oppbevares, arkiveres og videreformidles av selskapet eller tjenesteleverandøren. Det kvalifiserte seglet i henhold til artikkel 35(2) i eIDAS-forordningen bekrefter ektheten og opprinnelsen, uansett hvor filen befinner seg.
- En offentlig verifiseringsadresse i registeret som gir et signert svar uten at man må logge seg på med et registreringsnummer. I dag forutsetter enhver verifisering av tredjepart at bedriften selv tar initiativet. Dette er feil form for et bevisdokument som må overleve utstederen.
I tillegg har vi foreslått å fastsette beregningen av fingeravtrykket entydig: en fast prosedyre og en fast skrivemåte for dataene (vårt forslag: SHA-256 og JSON-kanonisering i henhold til RFC 8785). Uten denne fastsettelsen ville to tjenesteleverandører beregne forskjellige fingeravtrykk for det samme passet, og fingeravtrykket i registreringsbeviset ville ikke kunne etterberegnes.
3. Artikkel 17 må ikke begrense tilgangen til offentlige passdata
Artikkel 17 nevner «massiv nedlasting av data» som et mulig misbruk av registeret. For administrasjonsdataene i selve registeret (identiteter, logger, revisjonsspor) er dette riktig; disse hører ikke hjemme i massenedlastinger.
De offentlige passdataene hos produsenten eller tjenesteleverandøren er imidlertid nettopp det som ESPR ønsker å gjøre bredt tilgjengelig. Gjenvinningsbedrifter som henter materialdata om hele produktflåter; forskning som kryssanalyserer bærekraftsopplysninger; markedsovervåking som gjennomfører sammenligninger: Alt dette er massenedlastinger av de offentlige passdataene, og alt er tiltenkt bruk som forordningen ble utformet for.
Vårt forslag er en presiserende setning i artikkel 17 som begrenser anvendelsesområdet til registerdata og henviser til de respektive bransjeforordningene når det gjelder passdata. Ellers står tjenesteleverandører overfor et valg ved oppstart: enten å begrense den offentlige tilgangen kraftig av sikkerhetshensyn, og dermed ødelegge opplevelsen for forbrukerne, eller å la den være åpen og risikere å senere bli klassifisert som misbruk i henhold til artikkel 17.
4. Offentliggjøre grensesnittbeskrivelse og testmiljø før oppstart
Artikkel 3(b) krever et grensesnitt for registreringer. Artikkel 8(5) gjør dette til en av de to måtene å registrere på. Forordningen sier imidlertid ingenting om når dette grensesnittet skal beskrives.
De som automatiserer registreringer - alle tjenesteleverandører og alle bedrifter med et større katalog - trenger beskrivelsen i god tid før oppstart for å kunne utvikle systemet og teste det mot en ekte motpart. Å måtte finne en beskrivelse i uken før ikrafttredelsen overfører risikoen til alle leverandører.
Vi har derfor foreslått følgende:
- Å publisere en fullstendig beskrivelse av grensesnittet (OpenAPI 3.1) minst åtte uker før ikrafttredelsen, altså senest 24. mai 2026 for en oppstart 19. juli 2026
- Et testmiljø parallelt med dette, der tjenesteleverandører og produsenter kan utvikle løsninger og prøve ut den automatiske kontrollen i henhold til artikkel 8(6)
- Faste regler for versjoner av grensesnittet og en varslingsfrist på minst 18 måneder
Ytterligere forslag: Beskyttelse mot dupliserte oppføringer ved gjentatte forespørsler, samleoppføring for store kataloger, registrering med tilbakemelding i stedet for ventetid, og maskinlesbare feilkoder for de tilfellene der den automatiske kontrollen mislykkes.
Hvorfor vi gjør dette
En høring er ikke et spill for å samle poeng. Kommisjonen leser faktisk disse innspillene. Erfaringene fra selve ESPR-prosessen viser at faglig underbygde innspill ofte setter spor i de endelige tekstene.
Hvis hvert innspill klarer å gjøre en enkelt setning i den endelige versjonen mer presis, har det oppfylt sitt formål.
Vi søker uansett om å bli oppført på listen over tjenesteleverandører så snart prosedyren blir offentliggjort. Det er derfor i vår egen interesse at reglene vi konkurrerer under, er nøyaktige og sikrer like vilkår. De fire innspillene er vår konkrete måte å sikre at listen ikke blir redusert til et rent merkelapp.
For deg som vil delta
Fristen går ut 27. mai 2026. Innspill kan leveres på alle EUs offisielle språk, krever registrering på portalen og blir offentlig tilgjengelige. De som skal utstede eller kontrollere pass - produsenter, tjenesteleverandører, gjenvinningsbedrifter og myndigheter - bør i det minste lese om initiativet på Have Your Say. Selv et kort, faglig korrekt innspill bidrar.
Vårt kontrollverktøy Transpareo Time Machine oppfyller for øvrig allerede i dag behovet beskrevet under punkt 2: Den som ønsker å kontrollere et Transpareo-pass uavhengig, kan gjøre det med det åpne kildekodeverktøyet i nettleseren, uten å måtte vente på en kontrolladresse i Kommisjonens register.
