2026-06-17 · 8 min read · All articles

How dpp.gs Aligns With the New EU DPP Standards (EN 18216–18223)

For two years the Digital Product Passport was defined only by regulation — the ESPR said a passport must exist, but not what shape it should take on the wire. That gap closed in May 2026, when CEN/CENELEC technical committee JTC 24 published the first European DPP standards: the EN 18216–18223 series. This post maps dpp.gs to each one, plainly, so you can see exactly where the platform conforms today.

The EN 18216–18223 series at a glance

JTC 24 split the problem into layers. Each standard governs one concern, and a conformant passport has to answer all of them:

1. Identity and carriers: GS1 Digital Link (EN 18219 / EN 18220)

Everything starts with the identifier. dpp.gs never invents a proprietary product ID — it uses the GTIN you already own, expressed as a GS1 Digital Link. That single decision satisfies two standards at once: the identifier layer (EN 18219) and the data carrier layer (EN 18220), because a Digital Link is designed to live inside both a consumer QR code and a GS1 DataMatrix. The same code that a shopper scans in a shop is the code a customs scanner reads at the border. There is no second identity system to reconcile.

2. Retrieval and search: one URL, many formats (EN 18216 / EN 18222)

EN 18216 is about how a passport is fetched, and EN 18222 about how passports are found and how their lifecycle is queried. dpp.gs answers both from the same place:

• Retrieve — GET /dpp/v1/passports/{GTIN} returns the full passport as JSON-LD (or plain JSON). The public viewer URL does the same via content negotiation: ask for application/ld+json and you get data, not a web page.
• Search — GET /dpp/v1/passports?sector=textile&operator=… lets any authorised system discover passports by product identifier, economic operator, commodity (HS) code, sector or registration status, with paging.
• Lifecycle — GET /dpp/v1/passports/{GTIN}/lifecycle reports the registration state and key dates, so a downstream system knows whether a passport is active, pending or withdrawn.

Write operations (create, update, retire) stay behind authenticated tenant APIs — the public surface is read and search only, which is exactly the asymmetry the standards assume.

3. A semantic data model, not a form dump (EN 18223)

Interoperability fails the moment two systems disagree on what a field means. EN 18223 pushes toward linked data, and dpp.gs serves every passport as JSON-LD: a schema.org Product graph, extended with the GS1 vocabulary and a dpp: namespace for passport-specific aspects (materials, substances of concern, sector data). The @context is structured so it can later be re-pointed at the CIRPASS cross-sector ontology without changing the data shape. Materials, substances and recycled content are modelled as shared building blocks reused by every one of the 14 product categories — so a recycler's tool reads "cobalt, 12%, SVHC: no" the same way whether the product is a battery or a toy.

4. Trust: signed Verifiable Credentials (prEN 18246)

The draft authentication standard asks a hard question: how does a recycler, a customs officer or a consumer know a passport is genuine and unaltered? dpp.gs answers it with open cryptography rather than a ledger. Any passport can be issued as a W3C Verifiable Credential, signed with an Ed25519 key as a compact vc+jwt (the VC-JOSE-COSE representation). Anyone can fetch the issuer's public key from /.well-known/jwks.json and verify the signature offline — proving both who issued the passport and that not one byte has changed. No blockchain, no central trust broker, no vendor dependency. (See why we chose open standards over blockchain.)

5. Registry readiness (ESPR Art. 12–13)

Alongside the EN series, the ESPR mandates a central EU DPP Registry that records a small set of mandatory identifiers for each passport. dpp.gs already captures those fields for every product and holds them ready to push the moment the Commission's registry endpoint goes live. When that day comes, registration is a configuration switch, not a migration.

What this means for you

If you issue passports on dpp.gs, you are not betting on a proprietary format that the standards might later contradict. You are issuing GS1 Digital Link identifiers, JSON-LD data, QR + DataMatrix carriers and optionally signed credentials — the exact ingredients the European standards are converging on. As the EN series and the EU Registry firm up, your passports move with them instead of needing to be re-issued.

Related reading: GS1 Digital Link explained · Open standards, not blockchain · Who sees what in a passport