A draft law is on the table, and anyone may write in. That is how the EU Commission works: drafts like the one for the regulation on the DPP register are laid open for four weeks, and whoever wants to speaks up through the “Have Your Say” portal, by name, visible to all. The submissions officially flow into the final version.
We did that, four times, on the four points a manufacturer would hit first in daily work. We discussed the draft of 29 April 2026 in detail here on the blog; the feedback window runs until 27 May 2026. This post explains what we wrote to the Commission and why.
Why four separate submissions
The portal accepts 4,000 characters per contribution. We could have pressed all the points into one long contribution. For the Commission staff working through dozens of contributions in May, that would have been harder to read and harder to cite. Four individual submissions are each findable in their own right in the public list, and each can be answered or rejected on its own without touching the other points.
We submitted the following four topics:
1. Define what a service provider has to deliver at the least
The draft settles the split correctly: the passport data stays with the company or with its service provider, the Commission’s register stores only the references. For service providers (Article 2 No. 32 of the ESPR) an official list of authorised providers is foreseen.
What is missing is a definition of what a service provider actually has to deliver in order to get onto this list and stay on it. The actual obligations will probably follow in a separate legal act under Article 4 of the ESPR. The register starts, however, before that act is published.
Our proposal: either write minimum obligations for service providers directly into this regulation, or name a binding deadline by which the act will be supplied. The proposed minimum obligations include:
- The public read interface for passports is reachable at least 99.5 per cent of the month
- A firm commitment on how quickly a new passport version has to arrive in the back-up copy (proposal: 24 hours or at once where technically possible)
- The service provider checks the signature of every incoming version
- The company’s public keys sit under a uniform path (per RFC 8615, proposal
/.well-known/dpp-keys/) - A defined process for switching and insolvency, so that the passport data moves in an orderly way to another provider if one fails
These obligations cost a serious provider nothing, it meets them anyway. They do prevent a race to the bottom between cut-price providers that would ultimately hollow out the list.
2. A proof that lasts ten years
Article 9(4) caps the availability of the proof of registration at 90 calendar days. Within that period the register reissues the proof on request. That is fine for ongoing operation, but it does not match the lifetime of the duty behind it: Article 10(3) sets retention at ten 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 check that a passport registered in 2026 really was registered, without having to rely on the original company still existing and being able to request a fresh proof.
Our two proposals are cheap to implement:
- State explicitly that the proof sealed by the Commission may be kept, archived and passed on by the company or by the service provider. The qualified seal under Article 35(2) of the eIDAS Regulation proves authenticity and origin no matter where the file is held.
- A public checking address at the register that returns a signed answer for a registration number without a login. Today every check by a third party presupposes that the company itself takes action. That is the wrong form for a document of proof that has to outlive its issuer.
In addition, we proposed to define the computation of the fingerprint unambiguously: one fixed method and one fixed way of writing the data (our proposal: SHA-256 and JSON canonicalisation per RFC 8785). Without that definition, two service providers would compute different fingerprints for the same passport, and the fingerprint in the proof of registration could not be recomputed.
3. Article 17 must not restrict access to public passport data
Article 17 names “massive data download” as a possible misuse of the register. For the administrative data held in the register itself (identities, logs, audit trails) that is right, those do not belong in mass downloads.
The public passport data held by the manufacturer or service provider, however, is exactly what the ESPR wants to make broadly accessible. Recyclers pulling material data across whole product fleets; research analysing sustainability claims across the board; market surveillance running comparisons: all of these are mass downloads against the public passport data, and all of them intended uses the regulation was written for.
Our proposal is a clarifying sentence in Article 17 that limits the scope to register data and refers, for passport data, to the respective sector regulations. Otherwise service providers face a choice at the start: either throttle public access hard to be safe, and ruin the consumer experience, or leave it open and risk being classified later as misuse within the meaning of Article 17.
4. Publish the interface description and a test environment before the launch
Article 3(b) requires an interface for registrations. Article 8(5) makes it one of the two ways to register. The regulation says nothing, however, about when that interface will be described.
Anyone automating registrations, every service provider and every company with a larger catalogue, needs the description well before the launch in order to build and test against a real counterpart. Finding a description in the week before entry into force shifts the risk onto every provider.
We therefore proposed:
- Publishing a complete interface description (OpenAPI 3.1) at least eight weeks before entry into force, for a launch on 19 July 2026 that is by 24 May 2026
- A test environment alongside it, against which service providers and manufacturers can build and try out the automatic check under Article 8(6)
- Fixed rules for versions of the interface and a deprecation period of at least 18 months
Further suggestions: protection against duplicate entries on repeated calls, bulk registration for large catalogues, registration with a callback instead of waiting, and machine-readable error codes for the cases where the automatic check fails.
Why we do this
A consultation is not a game for collecting points. The Commission really does read these contributions. The experience from the ESPR process itself shows that well-founded submissions often leave traces in the final texts.
If every submission manages to make a single sentence in the final version more precise, it has fulfilled its purpose.
We are applying anyway for admission to the list of service providers, as soon as the procedure is published. It is therefore in our own interest that the rules under which we compete are precise and describe a fair playing field. The four contributions are our concrete way of ensuring that the list does not degenerate into a mere label.
Who wants to take part
The 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 check passports, manufacturers, service providers, recyclers, authorities, should read over the initiative on Have Your Say at least once. Even a short, precise submission carries weight.
Our checking tool Transpareo Time Machine, by the way, already meets the need described under point 2 today: anyone who wants to check a Transpareo passport independently can do so with the open-source tool in the browser, without waiting for a checking address in the Commission’s register.
