Registration data wants a reference to the DPP service provider; we carry only a back-up URL

[LKSNDRTMLKV]

Two instruments require a reference to the digital product passport service provider as registration data. RegistrationPayload carries only a back-up URL, which is a different thing.

The act distinguishes them

Commission Implementing Regulation (EU) 2026/1778 Art. 8 separates the two in consecutive paragraphs:

Art. 8(7)(e) — on submission the Commission confirms "where relevant, the link to the back-up hosted by a digital product passport service provider".

Art. 8(9)(c) — the Commission shall store as part of the registration data "where relevant, reference to the digital product passport service provider".

One is a location; the other identifies the party. Both are listed, separately.

And so does the ESPR

Regulation (EU) 2024/1781 Annex III, point (l), verbatim:

"(l) the reference of the digital product passport service provider hosting the back-up copy of the digital product passport."

That is an Annex III passport data point in its own right, alongside the unique product identifier, the operator identifiers of points (g), (h) and (k), and the facility identifiers of point (i).

The role it names is defined at Art. 2(32):

"'digital product passport service provider' means a natural or legal person that is an independent third-party authorised by the economic operator which places the product on the market … and that processes the digital product passport data for that product for the purpose of making such data available…"

So the reference identifies a party under a legal role, not a host.

Current state

crates/dpp-registry/src/payload.rs:

/// Public URL of a back-up of this passport, hosted independently of the
/// issuing node. Verified by the registry where one is declared.
pub backup_url: Option<String>,

Validated for https:// and nothing else. There is no field for the provider's identity anywhere in RegistrationPayload, and identifiers.rs enumerates only the Annex III identifier classes it already covers.

A URL does not answer Art. 8(9)(c). Two providers can serve from the same domain; one provider can serve from many. And where the back-up URL is absent but a provider is engaged, there is nothing at all.

Same shape as an open issue

This is the Annex III operator-identifier finding again: an enumeration that stops one point short of what the annex lists. That one is about point (k); this is about point (l).

Suggested fix

A provider reference field on RegistrationPayload, and a decision on what identifies a provider. Worth settling deliberately rather than defaulting to a string:

• Art. 2(32) imposes no identifier scheme on the role.
• Annex III's own standards clause names the ISO/IEC 15459 conformity requirement for the data carrier, the unique product identifier, the operator identifiers of points (g), (h) and (k), and the facility identifiers of point (i) — point (l) is not in that list, so no scheme is mandated for it.
• LegalEntityIdentifier already models an EUID-or-other discriminant and is the obvious precedent if a structured form is wanted.

⚠️ One thing to know before designing: Art. 3(f) of 2026/1778 says the registry holds "a list of verified digital product passport service providers", but that Regulation lays down verification processes for economic operators (Art. 4) and value chain actors (Art. 5) only — nothing for service providers. The criteria are empowered by ESPR Art. 11, penultimate subparagraph, as a delegated act that has not been adopted. So there is no registry-issued provider identifier to reuse yet, and a design that assumes one would be inventing it.

[LKSNDRTMLKV]

Correction: the ⚠️ note at the end of this issue is wrong

Found while implementing it, and confirmed against the Official Journal text.

What this issue says:

⚠️ One thing to know before designing: Art. 3(f) of 2026/1778 says the registry
holds "a list of verified digital product passport service providers", but
that Regulation lays down verification processes for economic operators
(Art. 4) and value chain actors (Art. 5) only — nothing for service providers.
The criteria are empowered by ESPR Art. 11, penultimate subparagraph, as a
delegated act that has not been adopted.

IR (EU) 2026/1778 recital 4, verbatim:

"To ensure accountability, each economic operator and value chain actor (such
as digital product passport service provider, repairer, refurbisher,
remanufacturer, recycler) should be identified through a verification process."

A digital product passport service provider is a value chain actor for this
Regulation. Art. 5 therefore applies to it: a legal person obtains verified
status by proving identity and establishment with a qualified electronic seal or
a qualified electronic attestation of attributes. Art. 3(f)'s list is the output
of that process, not a placeholder for one.

There is no unadopted delegated act standing in the way.

How it happened: the note was written from a reading of Arts. 3–5 that never
reached recital 4, where the definition of the actor class lives. The recital is
what connects the role named in Art. 3(f) to the process in Art. 5, and nothing
in the articles themselves says so.

What survives

The design conclusion, on a better footing. Art. 5 produces a status evidenced
by a seal, not a namespace — it names the evidence and assigns no identifier.
So Annex III(l) still mandates no scheme, resting on the fact that actually
carries it: point (l) is absent from Annex III's second-paragraph ISO/IEC 15459
clause, which covers the data carrier, point (b), points (g)/(h)/(k) and point
(i).

And something neither reading had

Art. 5(4) caps verified status at the expiry of the electronic identification
means or three years from verification, whichever comes first. A provider
reference records who was named at the time; it is not a standing assertion that
they are verified now. That is recorded on both types in #303.