Den 29. april 2026 offentliggjorde EU-kommisjonen utkastet til gjennomføringsforordningen om DPP-registeret og åpnet samtidig en fire ukers høringsperiode. Frem til 27. mai 2026 kan alle personer og organisasjoner i EU og utenfor gi innspill via «Have Your Say»-portalen. Innspillene er offentlige, hvert innspill er signert med navn eller organisasjon, og de blir offisielt innarbeidet i den endelige versjonen av forordningen.
Vi har diskutert utkastet inngående her på bloggen. Dette innlegget er viet til spørsmålet om hva vi har skrevet tilbake til Kommisjonen.
Hvorfor vi har sendt inn fire separate innspill
Portalen tillater 4 000 tegn per innlegg. Vi kunne ha presset alle punktene inn i ett langt innlegg. Det ville vært mer uoversiktlig å lese og vanskeligere å sitere for kommisjonens ansatte, som i mai skal gå gjennom dusinvis av innspill. Fire separate innspill er hver for seg lette å finne i den offentlige listen, og hvert av dem kan besvares - eller avvises - isolert uten å påvirke de andre punktene.
Vi har sendt inn følgende fire temaer:
1. Definere minimumskrav for DPP-tjenesteleverandører
Utkastet til forordning fastsetter den desentraliserte modellen korrekt: DPP-dataene lagres hos den økonomiske aktøren eller hos dennes DPP-tjenesteleverandør; Kommisjonens register lagrer kun referansene. For DPP-tjenesteleverandører (art. 2 nr. 32 i ESPR) er det planlagt en offisiell liste over godkjente leverandører.
Det som mangler, er en presisering av hva en tjenesteleverandør faktisk må oppfylle for å komme inn på denne listen og forbli der. Antakelig vil de vesentlige forpliktelsene følge i en delegert rettsakt i henhold til artikkel 4 i ESPR-hovedforordningen. Registeret starter imidlertid før denne rettsakten er publisert.
Vårt forslag: Enten å fastsette minimumskriterier for tjenesteleverandører direkte i denne gjennomføringsforordningen, eller å angi en bindende frist for når den delegerte rettsakten skal legges frem. Blant de foreslåtte minimumskravene inngår:
- Tilgjengelighet av det offentlige DPP-lesegrensesnittet på minst 99,5 prosent per måned
- En servicenivåavtale om hvor raskt en ny DPP-versjon må være tilgjengelig i sikkerhetskopien (forslag: 24 timer eller i sanntid, der det er teknisk mulig)
- Obligatorisk kryptografisk verifisering av innkommende versjoner av tjenesteleverandøren
- Publisering av den økonomiske aktørens offentlige nøkler under en standardisert bane (RFC 8615, forslag
/.well-known/dpp-keys/) - Definert bytte- og insolvensprosess, slik at DPP-data på en ordnet måte kan migreres til en annen leverandør dersom en leverandør går konkurs
Disse forpliktelsene koster ikke en seriøs leverandør noe - han oppfyller dem uansett -, men forhindrer et kappløp mot bunnen blant lavpristilbydere, som til slutt undergraver listen.
2. Langsiktig verifiserbarhet av registrerte DPP-er
Artikkel 9(4) setter en øvre grense på 90 kalenderdager for tilgjengeligheten av registreringsbeviset. Innenfor denne fristen genererer registeret beviset på nytt på forespørsel. Dette er greit for den løpende driften, men passer ikke med livssyklusen til den underliggende DPP-forpliktelsen: Artikkel 10(3) fastsetter standard oppbevaringstid til 10 år fra registrering, mens sektorlovgivning kan kreve lengre tid.
En markedstilsynsmyndighet, en tollbetjent, en gjenvinningsaktør eller en forsker i 2032 bør kunne kontrollere at en DPP registrert i 2026 virkelig var registrert, uten å være avhengig av at den opprinnelige økonomiske aktøren fortsatt eksisterer og kan be om et nytt bevis.
Våre to forslag er enkle å gjennomføre:
- Eksplisitt presisere at bevisbytene som er kvalifisert forseglet av Kommisjonen, kan lagres midlertidig, arkiveres og videreformidles av den økonomiske aktøren eller tjenesteleverandøren. Den kvalifiserte forseglingen i henhold til artikkel 35(2) i eIDAS-forordningen gir presumpsjon om integritet og opprinnelse, uavhengig av hvor byteene befinner seg.
- Et offentlig, ikke-autentisert verifiseringsendepunkt i registeret, som leverer et signert svar knyttet til en registrerings-ID. I dag forutsetter enhver tredjepartsverifisering at den økonomiske aktøren tar initiativ - dette er feil form for et bevisdokument som må overleve utstederen.
I tillegg har vi foreslått å fastsette hashdannelsen deterministisk: SHA-256 som hashfunksjon, JSON Canonicalization Scheme (RFC 8785) som serialisering, utenfor signaturblokken. I W3C-økosystemet er dette kryptosuiten eddsa-jcs-2022, som Transpareo bruker til å signere direkte. Uten denne fastsettelsen av pinning ville to tjenesteleverandører serialisere den samme DPP-en til forskjellige hasjer, og hash-feltet i registreringsbeviset ville ikke være reproduserbart.
3. Artikkel 17 må ikke begrense tilgangen til offentlige DPP-data
Artikkel 17 nevner «massiv nedlasting av data» som et mulig misbruk av registeret. For de administrative metadataene som ligger i selve registeret (identiteter, logger, revisjonsspor), er dette riktig - de hører ikke hjemme i massenedlastinger.
De offentlige DPP-dataene hos produsenten eller tjenesteleverandøren er imidlertid nettopp det området som ESPR ønsker å gjøre bredt tilgjengelig. Gjenvinningsbedrifter som henter komposisjonsdata om produktflåter; forskning som kryssanalyserer bærekraftserklæringer; markedsovervåking som gjennomfører sammenlignende analyser - alt dette er former for «massiv data nedlasting» fra det offentlige DPP-laget, og alt er formålstjenlig 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 sektorspesifikke delegerte rettsakter når det gjelder DPP-data. Ellers står tjenesteleverandører ved oppstart overfor et valg: enten å begrense tilgangen for all sikkerhets skyld kraftig - og dermed ødelegge forbrukeropplevelsen - eller å la den være åpen og risikere å senere bli klassifisert som misbruk i henhold til artikkel 17.
4. Offentliggjøre OpenAPI-spesifikasjonen og sandkassen før oppstart
Artikkel 3(b) krever en API for registreringer. Artikkel 8(5) gjør den til den ene av de to kanalene for registrering. Forordningen sier imidlertid ingenting om når API-avtalen skal offentliggjøres.
De som automatiserer registreringsprosesser - alle tjenesteleverandører og alle aktører i næringslivet med et større utvalg - trenger API-spesifikasjonen i god tid før lansering for å kunne implementere den og teste den mot et reelt endepunkt. Å finne en spesifikasjon i uken før ikrafttredelsen overfører integrasjonsrisikoen til alle leverandører i økosystemet.
Vi har derfor foreslått:
- Å publisere en OpenAPI 3.1-spesifikasjon minst åtte uker før ikrafttredelsen - for en start 19. juli 2026 altså senest 24. mai 2026
- Et parallelt sandkasse-miljø der tjenesteleverandører og produsenter kan integrere og teste automatisk verifisering i henhold til artikkel 8(6)
- En versjonspolitikk med Semver og en varslingsfrist på minst 18 måneder
Ytterligere designforslag: Idempotensnøkler på registreringsanrop, batchregistrering for store kataloger, asynkron registrering med webhook-tilbakekalling og maskinlesbare feilkoder for feiltilfeller ved automatisk verifisering.
Hvorfor vi gjør dette
En høring er ikke et spill for å samle poeng. Hvis hvert innspill bidrar til å gjøre en enkelt setning i den endelige versjonen mer presis, har det oppfylt sitt formål. Kommisjonen leser faktisk disse innspillene - erfaringene fra selve ESPR-prosessen viser at faglig velbegrunnede innspill ofte setter sitt preg på de endelige tekstene.
Vi vil uansett søke om oppføring på listen over DPP-tjenesteleverandører så snart opptaksprosedyren blir offentliggjort. Det ligger derfor i vår direkte interesse at reglene vi konkurrerer under, er presise og definerer like konkurransevilkår. De fire innspillene er vår konkrete måte å sikre at listen ikke forfaller til et rent markedsføringsmerke.
Hvem som kan delta
Tilbakemeldingsperioden varer til 27. mai 2026. Innspill kan sendes inn på alle EUs offisielle språk, krever registrering på portalen og blir offentlig tilgjengelige. De som skal utstede eller verifisere DPP-er - produsenter, tjenesteleverandører, gjenvinningsbedrifter, myndigheter - bør i det minste lese om initiativet på Have Your Say. Selv et kort, faglig presist innspill bidrar.
Vårt verifiseringsverktøy Transpareo Time Machine løser for øvrig verifiseringsbehovet som ble nevnt under punkt 2 allerede i åpen kildekode-praksis: Den som ønsker å verifisere et Transpareo-DPP uavhengig, kan gjøre det med verktøyet allerede i dag, uten å måtte vente på et formelt etablert verifiseringspunkt i Kommisjonens register.