Am 29. April 2026 hat die Europäische Kommission den Entwurf der Durchführungsverordnung zum DPP-Register veröffentlicht und parallel ein vierwöchiges Feedback-Fenster eröffnet. Bis zum 27. Mai 2026 kann jede Person und jede Organisation in der EU und darüber hinaus über das «Have Your Say»-Portal Rückmeldung geben. Die Eingaben sind öffentlich, jede ist mit Namen oder Organisation gezeichnet, und sie fliessen offiziell in die finale Fassung der Verordnung ein.
Wir haben den Entwurf hier im Blog ausführlich besprochen. Diesen Beitrag widmen wir der Frage, was wir der Kommission zurückgeschrieben haben.
Warum wir vier separate Eingaben gemacht haben
Das Portal akzeptiert pro Beitrag 4 000 Zeichen. Wir hätten alle Punkte in einen langen Beitrag pressen können. Das wäre für Kommissionsmitarbeiter, die im Mai dutzende Beiträge durcharbeiten, unangenehmer zu lesen und schwerer zu zitieren gewesen. Vier einzelne Eingaben sind in der öffentlichen Liste je für sich auffindbar, und jede lässt sich isoliert beantworten - oder ablehnen - ohne die anderen Punkte zu beeinflussen.
Folgende vier Themen haben wir eingereicht:
1. Mindestanforderungen für DPP-Diensteanbieter definieren
Der Verordnungsentwurf legt das dezentrale Modell korrekt fest: Die DPP-Daten leben beim Wirtschaftsakteur oder bei seinem DPP-Diensteanbieter, das Kommissionsregister speichert nur die Verweise. Für DPP-Diensteanbieter (Art. 2 Nr. 32 der ESPR) ist eine offizielle Liste der zugelassenen Anbieter vorgesehen.
Was fehlt, ist eine Festlegung, was ein Diensteanbieter eigentlich leisten muss, um in dieser Liste zu landen und dort zu bleiben. Vermutlich folgen die substanziellen Pflichten in einem delegierten Rechtsakt nach Artikel 4 der ESPR-Mutterverordnung. Das Register startet aber, bevor dieser Rechtsakt publiziert ist.
Unser Vorschlag: Entweder direkt in dieser Durchführungsverordnung Mindestkriterien für Diensteanbieter festschreiben, oder eine verbindliche Frist nennen, bis wann der delegierte Rechtsakt nachgereicht wird. Zu den vorgeschlagenen Mindestanforderungen gehören:
- Verfügbarkeit der öffentlichen DPP-Leseschnittstelle von mindestens 99,5 Prozent pro Monat
- Eine Service-Level-Vereinbarung, wie schnell eine neue DPP-Version in der Sicherheitskopie ankommen muss (Vorschlag: 24 Stunden oder in Echtzeit, wo technisch möglich)
- Verpflichtende kryptografische Verifizierung eingehender Versionen durch den Diensteanbieter
- Publikation der öffentlichen Schlüssel des Wirtschaftsakteurs unter einem standardisierten Pfad (RFC 8615, Vorschlag
/.well-known/dpp-keys/) - Definierter Wechsel- und Insolvenz-Prozess, damit DPP-Daten beim Ausfall eines Anbieters geordnet zu einem anderen Anbieter migrieren
Diese Pflichten kosten einen seriösen Anbieter nichts - er erfüllt sie ohnehin -, verhindern aber ein Rennen nach unten zwischen Billiganbietern, das die Liste am Ende untergräbt.
2. Langzeit-Verifizierbarkeit registrierter DPPs
Artikel 9(4) deckelt die Verfügbarkeit des Registrierungsnachweises auf 90 Kalendertage. Innerhalb dieser Frist regeneriert das Register den Nachweis auf Anfrage. Das ist für den laufenden Betrieb in Ordnung, passt aber nicht zum Lebenszyklus der dahinter stehenden DPP-Pflicht: Artikel 10(3) setzt die Standard-Aufbewahrung auf 10 Jahre ab Registrierung, Sektorrecht kann länger fordern.
Eine Marktüberwachungsbehörde, ein Zollbeamter, ein Recycler oder ein Forscher im Jahr 2032 sollte überprüfen können, dass ein 2026 registrierter DPP wirklich registriert war, ohne darauf angewiesen zu sein, dass der ursprüngliche Wirtschaftsakteur noch existiert und einen frischen Nachweis anfordern kann.
Unsere zwei Vorschläge sind günstig in der Umsetzung:
- Explizit klarstellen, dass die von der Kommission qualifiziert gesiegelten Nachweis-Bytes vom Wirtschaftsakteur oder vom Diensteanbieter zwischengespeichert, archiviert und weiterverteilt werden dürfen. Das qualifizierte Siegel nach Artikel 35(2) der eIDAS-Verordnung trägt die Integritäts- und Ursprungs-Vermutung unabhängig davon, wo die Bytes liegen.
- Einen öffentlichen, nicht authentifizierten Verifizierungs-Endpunkt am Register, der zu einer Registrierungs-ID eine signierte Antwort liefert. Heute setzt jede Drittprüfung voraus, dass der Wirtschaftsakteur aktiv wird - das ist die falsche Form für ein Beweis-Dokument, das den Aussteller überleben muss.
Zusätzlich haben wir vorgeschlagen, die Hash-Bildung deterministisch festzulegen: SHA-256 als Hash-Funktion, JSON Canonicalization Scheme (RFC 8785) als Serialisierung, ausserhalb des Signaturblocks. Im W3C-Ökosystem heisst diese Familie eddsa-jcs-2022; Transpareo pinnt die eng verwandte Variante eddsa-jcs-sha256 (SHA-256 über JCS). Ohne diese Pinning-Festlegung würden zwei Diensteanbieter denselben DPP zu unterschiedlichen Hashes serialisieren, und das Hash-Feld im Registrierungsnachweis wäre nicht reproduzierbar.
3. Artikel 17 darf den Zugriff auf öffentliche DPP-Daten nicht einschränken
Artikel 17 nennt «massive data download» als möglichen Missbrauch des Registers. Für die im Register selbst liegenden Verwaltungs-Metadaten (Identitäten, Logs, Auditspuren) ist das richtig - die gehören nicht in Massendownloads.
Die öffentlichen DPP-Daten beim Hersteller oder Diensteanbieter sind aber genau die Fläche, die die ESPR breit zugänglich machen will. Recycler, die kompositorische Daten über Produktflotten ziehen; Forschung, die Nachhaltigkeitsaussagen quer auswertet; Marktüberwachung, die Vergleichsanalysen fährt - das sind alles Formen von «massive data download» gegenüber der öffentlichen DPP-Schicht und alles bezweckte Nutzungen, für die die Verordnung geschrieben wurde.
Unser Vorschlag ist ein klarstellender Satz in Artikel 17, der den Geltungsbereich auf Register-Daten beschränkt und für DPP-Daten auf die jeweiligen sektorspezifischen delegierten Rechtsakte verweist. Sonst stehen Diensteanbieter beim Start vor einer Wahl: entweder den öffentlichen Zugriff sicherheitshalber aggressiv ratenlimitieren - und das Konsumenten-Erlebnis kaputtmachen - oder ihn offenlassen und riskieren, später als Missbrauch im Sinn von Artikel 17 eingestuft zu werden.
4. OpenAPI-Spezifikation und Sandbox vor dem Start veröffentlichen
Artikel 3(b) verlangt eine API für Registrierungen. Artikel 8(5) macht sie zum einen der beiden Kanäle für die Registrierung. Die Verordnung sagt aber nichts dazu, wann der API-Vertrag publiziert wird.
Wer Registrierungs-Workflows automatisiert - jeder Diensteanbieter und jeder Wirtschaftsakteur mit einem grösseren Katalog - braucht die API-Spezifikation deutlich vor dem Start, um zu implementieren und gegen einen echten Endpunkt zu testen. Eine Spezifikation in der Woche vor dem Inkrafttreten zu finden, verschiebt das Integrationsrisiko auf alle Anbieter im Ökosystem.
Wir haben deshalb vorgeschlagen:
- Eine OpenAPI-3.1-Spezifikation mindestens acht Wochen vor dem Inkrafttreten zu publizieren - für einen 19.-Juli-2026-Start also bis 24. Mai 2026
- Eine Sandbox-Umgebung parallel, gegen die Diensteanbieter und Hersteller integrieren und Artikel-8(6)-Auto-Verifikation testen können
- Eine Versionierungspolitik mit Semver, Abkündigungsfrist von mindestens 18 Monaten
Zusätzliche Design-Anregungen: Idempotency-Keys auf Registrierungs-Calls, Batch-Registrierung für grosse Kataloge, asynchrone Registrierung mit Webhook-Callback und maschinenlesbare Fehler-Codes für die Fehlerfälle der automatischen Verifikation.
Warum wir das machen
Eine Konsultation ist kein Spiel zum Punktesammeln. Wenn jede Eingabe es schafft, einen einzelnen Satz in der finalen Fassung präziser zu machen, hat sie ihren Zweck erfüllt. Die Kommission liest diese Beiträge tatsächlich - die Erfahrung aus dem ESPR-Prozess selbst zeigt, dass technisch fundierte Eingaben in den finalen Texten häufig Spuren hinterlassen.
Wir bewerben uns ohnehin um die Aufnahme in die Liste der DPP-Diensteanbieter, sobald das Aufnahmeverfahren publiziert ist. Es liegt also in unserem direkten Interesse, dass die Regeln, unter denen wir antreten, präzise sind und ein faires Spielfeld definieren. Die vier Beiträge sind unsere konkrete Form, dafür zu sorgen, dass die Liste nicht zum blossen Marketing-Etikett verkommt.
Wer mitmachen will
Das Feedback-Fenster läuft bis zum 27. Mai 2026. Beiträge sind in jeder Amtssprache der EU möglich, brauchen eine Anmeldung beim Portal und werden öffentlich sichtbar. Wer DPPs ausstellen oder verifizieren wird - Hersteller, Diensteanbieter, Recycler, Behörden -, sollte mindestens einmal über die Initiative auf Have Your Say drüberlesen. Auch eine kurze, fachlich präzise Eingabe trägt.
Unser Verifizierungs-Werkzeug Transpareo Time Machine löst übrigens den unter Punkt 2 angerissenen Verifizierungsbedarf bereits in der quelloffenen Praxis: Wer einen Transpareo-DPP unabhängig prüfen will, kann das mit dem Werkzeug heute schon tun, ohne auf einen formal etablierten Verifizierungs-Endpunkt im Kommissions-Register zu warten.