On 29 April 2026 the European Commission published the draft implementing regulation for the DPP register and opened a four-week feedback window in parallel. Until 27 May 2026 every person and every organisation in the EU and beyond can give feedback via the “Have Your Say” portal. The submissions are public, each is signed with a name or organisation, and they officially flow into the final version of the regulation.
We discussed the draft in detail here on the blog. This post is devoted to the question of what we wrote back to the Commission.
Why we made four separate submissions
The portal accepts 4,000 characters per contribution. We could have pressed all the points into one long contribution. That would have been more unpleasant to read and harder to cite for Commission staff working through dozens of contributions in May. Four individual submissions are each findable in their own right in the public list, and each can be answered - or rejected - in isolation without affecting the other points.
We submitted the following four topics:
1. Define minimum requirements for DPP service providers
The draft regulation correctly lays down the decentralised model: the DPP data lives with the economic operator or with its DPP service provider, the Commission register stores only the references. For DPP service providers (Art. 2 No. 32 of the ESPR) an official list of authorised providers is foreseen.
What is missing is a determination of what a service provider actually has to deliver in order to land on this list and stay on it. The substantial obligations probably follow in a delegated act under Article 4 of the ESPR parent regulation. The register starts, however, before this act is published.
Our proposal: either write minimum criteria for service providers directly into this implementing regulation, or name a binding deadline by which the delegated act will be supplied. The proposed minimum requirements include:
- availability of the public DPP read interface of at least 99.5 per cent per month
- a service-level agreement on how quickly a new DPP version must arrive in the back-up copy (proposal: 24 hours or in real time where technically possible)
- mandatory cryptographic verification of incoming versions by the service provider
- publication of the economic operator’s public keys under a standardised path (RFC 8615, proposal
/.well-known/dpp-keys/) - a defined switching and insolvency process, so that DPP data migrates in an orderly way to another provider if one provider fails
These obligations cost a serious provider nothing - it meets them anyway - but they prevent a race to the bottom between cut-price providers that would ultimately undermine the list.
2. Long-term verifiability of registered DPPs
Article 9(4) caps the availability of the proof of registration at 90 calendar days. Within this period the register regenerates the proof on request. That is fine for ongoing operation, but it does not fit the lifecycle of the underlying DPP obligation: Article 10(3) sets the standard retention at 10 years from registration, and sector law can require longer.
A market-surveillance authority, a customs officer, a recycler or a researcher in the year 2032 should be able to verify that a DPP registered in 2026 really was registered, without having to rely on the original economic operator still existing and being able to request a fresh proof.
Our two proposals are cheap to implement:
- explicitly clarify that the proof bytes sealed in qualified form by the Commission may be cached, archived and redistributed by the economic operator or by the service provider. The qualified seal under Article 35(2) of the eIDAS Regulation carries the presumption of integrity and origin regardless of where the bytes are held.
- a public, unauthenticated verification endpoint at the register that returns a signed response for a registration ID. Today every third-party check presupposes that the economic operator becomes active - which is the wrong form for an evidentiary document that has to outlive its issuer.
In addition, we proposed to fix the hash construction deterministically: SHA-256 as the hash function, the JSON Canonicalization Scheme (RFC 8785) as the serialisation, outside the signature block. In the W3C ecosystem this family is called eddsa-jcs-2022; Transpareo pins the closely related variant eddsa-jcs-sha256 (SHA-256 over JCS). Without this pinning specification, two service providers would serialise the same DPP to different hashes, and the hash field in the proof of registration would not be reproducible.
3. Article 17 must not restrict access to public DPP data
Article 17 names “massive data download” as a possible misuse of the register. For the administrative metadata held in the register itself (identities, logs, audit trails) this is right - those do not belong in mass downloads.
The public DPP data held by the manufacturer or service provider, however, is exactly the surface that the ESPR wants to make broadly accessible. Recyclers pulling compositional data across product fleets; research analysing sustainability claims across the board; market surveillance running comparative analyses - all of these are forms of “massive data download” against the public DPP layer and all of them intended uses for which the regulation was written.
Our proposal is a clarifying sentence in Article 17 that limits the scope to register data and refers, for DPP data, to the respective sector-specific delegated acts. Otherwise service providers face a choice at the start: either aggressively rate-limit public access to be safe - and ruin the consumer experience - or leave it open and risk being later classified as misuse within the meaning of Article 17.
4. Publish the OpenAPI specification and a sandbox before the launch
Article 3(b) requires an API for registrations. Article 8(5) makes it one of the two channels for registration. The regulation says nothing, however, about when the API contract is published.
Anyone automating registration workflows - every service provider and every economic operator with a larger catalogue - needs the API specification well before the launch in order to implement and test against a real endpoint. Finding a specification in the week before entry into force shifts the integration risk onto every provider in the ecosystem.
We therefore proposed:
- publishing an OpenAPI 3.1 specification at least eight weeks before entry into force - for a 19 July 2026 launch, that is by 24 May 2026
- a sandbox environment in parallel, against which service providers and manufacturers can integrate and test Article 8(6) auto-verification
- a versioning policy with Semver and a deprecation period of at least 18 months
Additional design suggestions: idempotency keys on registration calls, batch registration for large catalogues, asynchronous registration with a webhook callback, and machine-readable error codes for the error cases of the automatic verification.
Why we do this
A consultation is not a game for collecting points. If every submission manages to make a single sentence in the final version more precise, it has fulfilled its purpose. The Commission really does read these contributions - the experience from the ESPR process itself shows that technically well-founded submissions often leave traces in the final texts.
We are applying anyway for admission to the list of DPP service providers, as soon as the admission procedure is published. It is therefore in our direct interest that the rules under which we compete are precise and define a fair playing field. The four contributions are our concrete way of ensuring that the list does not degenerate into a mere marketing label.
Who wants to take part
The feedback window runs until 27 May 2026. Contributions are possible in every official EU language, require registration with the portal and are publicly visible. Anyone who will issue or verify DPPs - manufacturers, service providers, recyclers, authorities - should read over the initiative on Have Your Say at least once. Even a short, technically precise submission carries weight.
Our verification tool Transpareo Time Machine, by the way, already solves the verification need outlined under point 2 in open-source practice: anyone who wants to verify a Transpareo DPP independently can do so with the tool today, without waiting for a formally established verification endpoint in the Commission register.