What is a Digital Product Passport?

Key insight: A Digital Product Passport (DPP) is a machine-readable digital twin of a physical product — a standards-conformant record that travels with the product, updates through its lifecycle, and can be validated automatically by any conforming system.

1. The DPP as a machine-readable record

A DPP is not a PDF, a web page, or a label. It is a structured, machine-readable data object that conforms to a published data model and is addressed through a unique identifier carried on the product. Where a paper label is a snapshot frozen at manufacture, a DPP is a living record that accumulates events — manufacturing, shipment, repair, resale, recycling — over the product's entire life.

"Machine-readable" has a precise meaning here. A DPP is served as JSON-LD (JSON for Linked Data): ordinary JSON whose keys are mapped, via a @context, to globally unique IRIs. That mapping is what turns "recycledContent": 0.42 from a string that only your system understands into a statement that any conforming system can interpret. The same passport is served as HTML to a human browser and as JSON-LD to software, using content negotiation on the same URL.

Five properties distinguish a DPP from ordinary product information:

A useful mental model: a DPP is a digital twin. The identifier is the twin's address, the data model is its anatomy, and the data carrier (QR, NFC, RFID) is the physical handle that connects a scan to the digital record.

2. The information a DPP carries

The ESPR does not define one flat list; it organises passport data into groups. Across product categories the recurring groups are:

• Identity & specification — identifiers, model, technical parameters.
• Material composition — substances, percentages, certifications.
• Origin & provenance — where materials and products came from.
• Environmental impact — carbon, water, energy across the lifecycle.
• Compliance & certification — standards met, certificates held.
• Usage & maintenance — repairs, servicing, modifications.
• End-of-life — recycling, repair, disposal guidance.

Each group maps onto fields in the data model — and, in the EU system, onto specific classes and properties in the eudpp core ontology. That mapping is not arbitrary:

When a delegated act requires a "recycled content" field, that field is expressed as a typed property in the ontology, then constrained by a JSON Schema or SHACL shape. That is the chain from regulation → model → machine-readable field.

{
  "@context": "https://w3id.org/eudpp",
  "@id": "https://example.com/product/gtin-09506000134352/serial-AX7",
  "@type": "Product",
  "recycledContent": { "@value": 0.42, "unitCode": "P1" }
}

3. What makes it digital: identifier, carrier, and resolver

Three components make a passport reachable in the physical world:

1. Unique identifier — a globally unique, persistent key (in EN 18219: the UPI/UOI/UFI). Without it, two "battery model X" records would collide.
2. Data carrier — the physical encoding (QR, Data Matrix, NFC, RFID) that holds or points to the identifier, typically as a GS1 Digital Link URI.
3. Resolver — the service that turns a scan into the location of the passport data and redirects the requester.

A concrete GS1 Digital Link URI makes this tangible:

https://id.gs1.org/01/09506000134352/21/AX7
              └─ GTIN (product class) ─┘  └─ serial (unit) ─┘

The resolution flow, step by step:

1. A consumer scans the QR → the scanner reads the GS1 Digital Link URI above.
2. The scanner (or its app) calls the resolver with that URI.
3. The resolver looks up the identifier in the EU DPP Registry and finds the passport's hosting location.
4. The resolver redirects to the repository that hosts the passport.
5. The repository returns the JSON-LD passport; the client validates and renders it.

scan → GS1 Digital Link URI → resolver → registry lookup → repository → JSON-LD passport

This separation — identifier, carrier, resolver, repository — is what keeps the physical and digital worlds decoupled. The same identifier can be served by different carriers and hosted by different providers, as long as the resolution contract is honoured.

4. Where DPPs fit in the EU regulatory system

The DPP is not a standalone gadget; it is the information instrument of the Ecodesign for Sustainable Products Regulation (ESPR) and, for batteries, the Batteries Regulation (2023/1542). It is the mechanism through which product sustainability, circularity, and compliance information is made accessible.

Two facts matter for implementers:

• The DPP is decentralised: the passport data lives with the economic operator or their service provider, while a central Registry stores only identifiers and registration metadata. There is no giant EU database of all products.
• The DPP is standards-based: the technical infrastructure (identifiers, carriers, APIs, exchange, storage, interoperability) is specified by the EN 182xx family — EN 18219 for identifiers, EN 18220 for carriers, EN 18222 for APIs and searchability, EN 18221 for storage, EN 18216 for exchange, and EN 18223 for interoperability. The data model is aligned to the CIRPASS-2 eudpp ontology.

This means "building a DPP" is mostly a matter of conforming to those standards — which is exactly what the rest of this certification walks through.

5. Why it matters: compliance, circularity, and trust

For an implementer, the DPP matters because it is the interface between regulation and data:

• Compliance — regulators and market surveillance read the passport to verify conformity.
• Circularity — recyclers, repairers, and resellers read material, composition, and repair data to keep products in use.
• Trust — signed, integrity-protected data prevents greenwashing by making claims checkable.

The recurring theme: a DPP's value is not that information is available, but that it is machine-checkable. A claim of "42% recycled content" only matters because software can read the field, validate its type, and verify its signature — automatically, at scale, across borders.

Key points

• A DPP is a machine-readable, standards-conformant digital twin of a product, not a document.
• Its five defining properties: lifecycle coverage, machine-readability, updateability, verifiability, access control.
• Data is served as JSON-LD (with HTML via content negotiation) and mapped to the eudpp ontology.
• Three physical/digital components make it reachable: identifier, data carrier, resolver.
• In the EU it is decentralized (Registry = identifiers only) and standards-based (EN 182xx + eudpp ontology).
• Its value is machine-checkability — the basis for compliance, circularity, and trust.

Key takeaway: A DPP is the machine-readable contract between a physical product and the sustainability economy. Everything else in this certification is about conforming to the identifier, carrier, data-model, and API standards that make that contract work.