Technical
For solution providers, IT architects, developers, and startups building DPP solutions. This section covers identifiers, data carriers, resolvers, architecture, data structures, and interoperability.
With so much information available on Digital Product Passports (DPPs), finding the right information can be a challenge. CoE-DPP has brought together the key topics and linked them to content from official sources and trusted partners. Use the table of contents to quickly find the information you need.
If you can’t find what you’re looking for or you have other questions, please contact us at info@coe-dsc.nl. We’re happy to help you.
How do I build a DPP?
A DPP system consists of several technical building blocks. In CIRPASS 2 a set of architectural recommendations are made. The DPP solution must adhere to the standards set by CEN CENELEC JTC24.
The CIRPASS-2 Reference Architecture describes how these components fit together in a coherent system.
Product identifiers
For consumer products
The ESPR requires a unique product identifier for every product with a DPP. The identifier must be globally unique, following a predefined syntax, interoperable, accurately represent the object it refers to, open and transparent, and persistent. Multiple identification schemes exist — the key is choosing one that respects the 6 principles.
For raw materials, components, and semi-finished goods
These may use different identifier schemes depending on the industry context. The identifier must still be unique and resolvable.
For locations and facilities
Economic operators and facilities also need unique identifiers, particularly for traceability and supply chain mapping.
For events (tracking supply chain events)
Events in the value chain (production, transport, repair, recycling) may be tracked using event-based identifiers as part of traceability systems.
The CIRPASS Identification Schemes report provides a vendor-neutral evaluation framework comparing existing schemes on 10 criteria.
Data carriers
A data carrier is the physical encoding on a product that links to its DPP. Options may include (but will be defined by the delegated act for a specific product group):
| Carrier | Pros | Cons |
|---|---|---|
| QR code | Widely scannable by consumers, low cost | Limited data capacity, requires printing |
| DataMatrix | Small, high data density, durable | Less familiar to consumers |
| RFID/NFC | No line-of-sight needed, fast bulk scanning | Higher per-unit cost, requires reader |
The ESPR requires that the data carrier is physically present on the product, its packaging, or accompanying documentation. The choice depends on the product type, use case, and what the delegated act specifies.
Resolvers
A resolver translates a product identifier into a URL where the DPP data can be accessed. When a consumer scans a QR code, the resolver determines what information to show based on:
- Who is requesting it (consumer, authority, repairer)
- What type of information is relevant
- What language/locale to present
Resolvers can be operated by any party — they don’t need to be centralized. The key is that they follow a standardized protocol so that any scanner/client can find the DPP.
Data structure and machine readability
DPP data must be machine-readable. This means structured data formats rather than PDF documents. The DPP itself must be serialized in JSON for operational data exchange, as a JSON object. Key technical considerations:
- JSON-LD is the recommended approach for linked data, allowing semantic interoperability while still being resolvable as a JSON object;
- Vocabularies and ontologies define the meaning of data fields — see the Semantic Treehouse for existing DPP vocabularies;
- Data models per product group will be standardized through CEN/CLC/JTC 24 and delegated acts.
Access rights — who sees what?
The DPP system implements tiered access control 3 levels, each level with associated actors, and example data points (exact data points will be defined in industry delegated acts):
| Access level | Who | What data |
|---|---|---|
| Public | Anyone (consumers, public) | Environmental performance, basic product info, repair information |
| Authorities | Market surveillance, customs | Full compliance data, technical documentation |
| Value chain actors | Repairers, recyclers, distributors, refurbishers | Role-specific data (repair manuals, material composition, disassembly instructions, etc.) |
The technical mechanism for access control is part of the DPP system architecture. Authentication may involve credentials, tokens, or future integration with EU Digital Identity Wallets.
Verifiable Credentials and trust
The DPP ecosystem needs mechanisms to verify that:
- The DPP data is authentic (comes from the declared economic operator)
- The economic operator is who they claim to be
- Data hasn’t been tampered with
Technologies being explored include Verifiable Credentials, digital signatures, and blockchain-based approaches.
How do I avoid vendor lock-in?
Principles for interoperable, non-proprietary DPP solutions:
- Use open standards for identifiers, data formats, and protocols
- Ensure data portability — you must be able to export all your DPP data at any time
- Choose resolvers that follow open protocols — not proprietary redirect services
- Prefer open-source components where possible
- Verify against the reference architecture — does the solution align with the CIRPASS-2 D4.1 architecture?
The CIRPASS-2 Risks and Mitigations document specifically addresses lock-in risks and how to prevent them.
How do I know if a solution provider is compliant?
Currently, there is no formal certification for DPP service providers. The ESPR foresees rules for DPP Service Providers (DPPSPs) which are being developed. In the meantime, check whether a provider:
- Aligns with the CIRPASS-2 Reference Architecture
- Supports open data formats (not proprietary-only)
- Allows full data export
- Is tracking CEN/CLC/JTC 24 standard development
- Can demonstrate interoperability with other solutions
International standards beyond the EU
The EU DPP does not exist in isolation. Globally, complementary standards are emerging:
- UN Transparency Protocol (UNTP) — International traceability framework compatible with EU DPP
- Various national initiatives — covered in the CIRPASS-2 worldwide standardisation report
For companies with international supply chains, aligning with both EU DPP and UNTP can reduce duplication.
Examples and practical cases
- CIRPASS-2 Open Source DPP Catalogue — open-source tools and reference implementations
- GS1 DPP Demo Sandbox — interactive demo environment (one of multiple possible approaches)
Relevant sources for this section
DPP Powered by GS1 Standards — guideline for applying GS1 standards in DPP architecture. Portal to All GS1 Standards — GTIN, GLN, SSCC, GPC, DataMatrix, EPC/RFID, GDSN, EPCIS/CBV, and more.
Help us improve this page
The DPP landscape is evolving rapidly — regulations change, new standards emerge, and practical experience grows every day. If you notice something on this page that is incorrect, outdated, or incomplete, please let us know.
Your input helps us keep this knowledge hub accurate and useful for everyone in the DPP ecosystem.