Den 29. april 2026 offentliggjorde Europa-Kommissionen udkastet til gennemførelsesforordningen om DPP-registret og samtidig åbnet en fire ugers høringsperiode. Indtil den 27. maj 2026 kan enhver person og organisation i EU og uden for EU afgive feedback via »Have Your Say«-portalen. Indlæggene er offentlige, hvert indlæg er underskrevet med navn eller organisationsnavn, og de indgår officielt i den endelige udgave af forordningen.
Vi har drøftet udkastet indgående her på bloggen. Dette indlæg er viet til spørgsmålet om, hvad vi har skrevet tilbage til Kommissionen.
Hvorfor vi har indsendt fire separate indlæg
Portalen accepterer 4 000 tegn pr. indlæg. Vi kunne have presset alle punkterne sammen i ét langt indlæg. Det ville have været mere besværligt at læse og sværere at citere for Kommissionens medarbejdere, der i maj skal gennemgå snesevis af indlæg. Fire separate indlæg kan hver for sig findes på den offentlige liste, og hvert indlæg kan besvares - eller afvises - isoleret uden at påvirke de øvrige punkter.
Vi har indsendt følgende fire emner:
1. Fastlægge minimumskrav til DPP-tjenesteudbydere
Udkastet til forordning fastlægger korrekt den decentraliserede model: DPP-dataene opbevares hos den økonomiske aktør eller hos dennes DPP-tjenesteudbyder, mens Kommissionens register kun gemmer henvisningerne. For DPP-tjenesteudbydere (artikel 2, nr. 32, i ESPR) er der planlagt en officiel liste over godkendte udbydere.
Det, der mangler, er en fastlæggelse af, hvad en tjenesteudbyder rent faktisk skal opfylde for at komme med på denne liste og forblive der. De væsentlige forpligtelser vil formodentlig følge i en delegeret retsakt i henhold til artikel 4 i ESPR-hovedforordningen. Registret træder imidlertid i kraft, inden denne retsakt offentliggøres.
Vores forslag: Enten fastsættes der direkte i denne gennemførelsesforordning minimumskriterier for tjenesteudbydere, eller også angives der en bindende frist for, hvornår den delegerede retsakt skal forelægges. Blandt de foreslåede minimumskrav er:
- Tilgængelighed af den offentlige DPP-læsegrænseflade på mindst 99,5 procent pr. måned
- En serviceniveauaftale om, hvor hurtigt en ny DPP-version skal være tilgængelig i sikkerhedskopien (forslag: 24 timer eller i realtid, hvor det er teknisk muligt)
- Obligatorisk kryptografisk verifikation af indgående versioner foretaget af tjenesteudbyderen
- Offentliggørelse af den økonomiske aktørs offentlige nøgler under en standardiseret sti (RFC 8615, forslag
/.well-known/dpp-keys/) - En fastlagt proces for udskiftning og insolvens, så DPP-dataene kan overføres ordentligt til en anden udbyder, hvis en udbyder går konkurs
Disse forpligtelser koster ikke en seriøs udbyder noget - han opfylder dem alligevel - men forhindrer et kapløb mod bunden blandt billige udbydere, som i sidste ende undergraver listen.
2. Langsigtet verificerbarhed af registrerede DPP’er
Artikel 9, stk. 4, begrænser tilgængeligheden af registreringsbeviset til 90 kalenderdage. Inden for denne frist genudsteder registret beviset på anmodning. Det er fint nok i den daglige drift, men passer ikke til livscyklussen for den underliggende DPP-forpligtelse: Artikel 10, stk. 3, fastsætter standardopbevaringsperioden til 10 år fra registreringen, og sektorspecifik lovgivning kan kræve en længere periode.
En markedstilsynsmyndighed, en toldbetjent, en genvindingsvirksomhed eller en forsker i 2032 bør kunne kontrollere, at en DPP, der blev registreret i 2026, virkelig var registreret, uden at være afhængig af, at den oprindelige erhvervsaktør stadig eksisterer og kan anmode om et nyt bevis.
Vores to forslag er enkle at gennemføre:
- Det skal udtrykkeligt præciseres, at de bevisbytes, der er kvalificeret forseglet af Kommissionen, må cachelagres, arkiveres og videredistribueres af den økonomiske aktør eller tjenesteudbyderen. Den kvalificerede forsegling i henhold til artikel 35, stk. 2, i eIDAS-forordningen medfører formodning om integritet og oprindelse, uanset hvor byterne befinder sig.
- Et offentligt, ikke-autentificeret verifikationsendepunkt i registret, der leverer et signeret svar på et registrerings-ID. I dag forudsætter enhver tredjepartskontrol, at den økonomiske aktør tager initiativ - det er den forkerte form for et bevisdokument, der skal overleve udstederen.
Derudover har vi foreslået at fastlægge hash-dannelsen deterministisk: SHA-256 som hashfunktion, JSON Canonicalization Scheme (RFC 8785) som serialisering, uden for signaturblokken. I W3C-økosystemet er dette kryptosuiten eddsa-jcs-2022, som Transpareo bruger til direkte signering. Uden denne fastlæggelse af pinning ville to tjenesteudbydere serialisere den samme DPP til forskellige hashes, og hash-feltet i registreringsbeviset ville ikke være reproducerbart.
3. Artikel 17 må ikke begrænse adgangen til offentlige DPP-data
Artikel 17 nævner »massiv dataoverførsel« som et muligt misbrug af registret. For de administrative metadata, der findes i selve registret (identiteter, logfiler, revisionsspor), er dette korrekt - de hører ikke hjemme i massedownloads.
De offentlige DPP-data hos producenten eller tjenesteudbyderen er imidlertid netop det område, som ESPR ønsker at gøre bredt tilgængeligt. Genanvendere, der indhenter kompositoriske data om produktflåder; forskning, der tværgående analyserer bæredygtighedserklæringer; markedsovervågning, der udfører sammenlignende analyser - alt dette er former for »massive data download« fra det offentlige DPP-lag, og det er alt sammen formålstjenlig anvendelse, som forordningen er udformet med henblik på.
Vores forslag er en præciserende sætning i artikel 17, der begrænser anvendelsesområdet til registerdata og henviser til de respektive sektorspecifikke delegerede retsakter for DPP-data. Ellers står tjenesteudbydere ved opstarten over for et valg: enten at begrænse den offentlige adgang aggressivt af sikkerhedshensyn - og dermed ødelægge forbrugeroplevelsen - eller at lade den være åben og risikere senere at blive klassificeret som misbrug i henhold til artikel 17.
4. Offentliggør OpenAPI-specifikationen og sandkassen inden lanceringen
Artikel 3, litra b), kræver en API til registreringer. Artikel 8, stk. 5, gør den til den ene af de to kanaler for registrering. Forordningen siger imidlertid intet om, hvornår API-aftalen skal offentliggøres.
Enhver, der automatiserer registreringsworkflows - alle tjenesteudbydere og alle erhvervsaktører med et større katalog - har brug for API-specifikationen i god tid før lanceringen for at kunne implementere den og teste den mod et reelt slutpunkt. Hvis en specifikation først bliver tilgængelig i ugen før ikrafttrædelsen, overføres integrationsrisikoen til alle udbydere i økosystemet.
Vi har derfor foreslået:
- At offentliggøre en OpenAPI 3.1-specifikation mindst otte uger før ikrafttrædelsen - for en start den 19. juli 2026 altså senest den 24. maj 2026
- Etablering af et sandkasse-miljø, hvor tjenesteudbydere og producenter parallelt kan integrere og teste artikel 8, stk. 6, om automatisk verifikation
- En versionspolitik med Semver og en udløbsfrist på mindst 18 måneder
Yderligere designforslag: Idempotensnøgler ved registreringskald, batchregistrering for store kataloger, asynkron registrering med webhook-callback og maskinlæsbare fejlkoder for fejltilfælde ved den automatiske verifikation.
Hvorfor vi gør dette
En høring er ikke et spil, hvor man samler point. Hvis hvert enkelt indlæg bidrager til at gøre en enkelt sætning i den endelige udgave mere præcis, har det opfyldt sit formål. Kommissionen læser faktisk disse bidrag - erfaringerne fra selve ESPR-processen viser, at teknisk velunderbyggede bidrag ofte sætter deres præg på de endelige tekster.
Vi ansøger i øvrigt om optagelse på listen over DPP-tjenesteudbydere, så snart optagelsesproceduren offentliggøres. Det er derfor i vores direkte interesse, at de regler, vi skal konkurrere under, er præcise og definerer lige vilkår. De fire bidrag er vores konkrete måde at sikre, at listen ikke forvandles til et rent marketingmærke.
Hvem der vil deltage
Feedback-perioden løber indtil den 27. maj 2026. Indlæg kan afgives på ethvert af EU’s officielle sprog, kræver registrering på portalen og bliver offentligt synlige. Alle, der skal udstede eller verificere DPP’er - producenter, tjenesteudbydere, genvindingsvirksomheder, myndigheder - bør i det mindste én gang læse om initiativet på Have Your Say. Selv et kort, fagligt præcist indlæg tæller.
Vores verifikationsværktøj Transpareo Time Machine løser for øvrigt det verifikationsbehov, der blev nævnt under punkt 2, allerede i praksis med åben kildekode: Den, der ønsker at verificere et Transpareo-DPP uafhængigt, kan allerede i dag gøre det med værktøjet uden at skulle vente på et formelt etableret verifikationsendepunkt i Kommissionens register.