Digital Product Passport
Welcome to the Digital Product Passport page. The Digital Product Passport (DPP) is a crucial enabler of the transition to a circular economy. Providing valuable information about a product’s design, material composition, and environmental impact supports the development of more sustainable business models and value chains while also reducing waste and increasing the efficiency of logistics and accounting functions when recycling materials and components.
We are still working on the project and some information may change in the near future.
For more information and updates, please visit DPP Page.
Summary
Chapter 1
Introduction to DPP
Chapter 2
Regulation and benefits
Chapter 3
Technical features
Chapter 4
Collaborative designs
1 - Introduction to Digital Product Passport
A DPP as represented by a machine-readable data carrier (such as a QR code), contains a unique identifier for a product, as well as linked data references not only to attributes such as its design and constituent materials, but also process details spanning across the product’s life-cycle – from manufacturing and usage to disposal and recycling.
The wide adoption of a DPP standard has the potential to facilitate fine-grained transitions to a circular economy, from the local to the global. A circular economy aims to keep materials in use for as long as possible, minimising the entropy created by production processes: an externality known as waste and pollution. Products must be designed with their end-of-life in mind, and materials must be recovered, reused, or recycled to minimise the entropy of production processes.
DPPs can provide valuable information to enable this transition by facilitating the tracking of materials and products throughout their life cycle. Initiatives willing to produce open hardware can use this information to optimise recycling processes, reduce waste, and support the development of new business models and value chains.
For example, by providing information about the materials and components used in a product, a DPP can facilitate identifying and separating these materials for recycling. It can also provide information about the materials’ quality, lifetime and condition, enabling more effective recycling processes
2 - Regulation and benefits
The EU Regulation
At the heart of the European Commission’s European Green Deal strategy[EC1], the Ecodesign for Sustainable Products Regulation (ESPR) [EC2] defines DPPs as the technical keystone for achieving its aims. DPPs are designed for all participants along a value chain, from designers, manufacturers, distributors and end-users to repairers, re-manufacturers and recyclers, to cooperatively access information that is valuable in their work to improve environmental performance, prolong product lifetime, reduce energy use and waste disposal while boosting efficiency and increasing the use of secondary raw materials.
Benefits
Over a product’s complete life-cycle, from design and production to its usage, disuse and recycling, a DPP is a means to:
- increase a product’s sustainability by addressing consumers’ needs more effectively for longer, with less primary resources and energy required and less waste disposed of throughout the product’s life-cycle
- achieve an increasingly circular economy by enabling the identification of opportunities to reuse, repurpose and recycle a product’s components and wastes, as well as minimising energy consumption throughout its life-cycle
- provide sufficient product locality information to assess manufacture, repair, and reuse transport and distribution energy use across the product life-cycle
- provide sufficient insights to producers to assess mass production models against less resource & waste-intensive business models (e.g. service-oriented sustainable models).
To achieve this, the ESPR and its Annexes outline required information parameters linked to a DPP data carrier as appropriate.
3 - Technical features
A Data Carrier, machine readable that contains:
- Product Identifier Code
- Location Reference to Linked Data
- Verifiable cryptographic authenticity & integrity data
Linked Data, including:
- Identifier codes for source, components & materials
- Identifier codes for manufacturers & manufacturing facilites
- (Dis)assembly instructions
- Safety & use instructions & more …
- Voluntary sharing of further data encouraged
Above: DPP main features
Graph Data and “Resource-Event-Agent” accounting model
In our research and development, we use a Resource-Event-Agent (REA) accounting model to create a product’s DPP. According to this model, a resource undergoes transforming events operated by agents. An example of a model could be the following: a designer (agent) produces (event) a design (resource), and a manufacturer (agent) uses (event) the design (resource) to produce (event) a bike (resource).
The REA accounting model structure allows for graph data representation. We implement this structure utilising a graph database and the Graph Query Language (GQL) to access it.
When looking at concrete implementations of a DPP, we introduce the following two concepts:
- To trace a resource: “follow the completed path backwards from its current point to where it began”—for example, tracing a bike from its current state through the production process back to the constituent components/materials.
- To track a resource: “follow the emerging path forwards from your starting point to wherever the thing is”—for example, tracking a bike’s reparations and owner changes after being sold.
In our research and development activity, we focused primarily on tracing for the DPP, because tracing contains each event that contributed to the manifestation of a resource, along with events of intermediate resources together with each agent involved.
For example, a bike’s trace starts with the bike and goes back along the assembly phase, listing the parts used. It proceeds following the trace of the parts bought by a workshop from different resellers, which in turn had bought batches from other manufacturers, and so on. Such a DPP allows the tracing of a resource from its current known manifestation back to its origins, potentially as deep as accounting for all the different raw materials used.
Tracing captures the provenance of the resource – the chain of relations between resources, events and agents and their properties that constitutes a given manifestation of the resource.
An example of tracing back a resource is the following:
Above: trace (fragment) of “fancy collaborative bike” (in red). Squares represent events, circles resources and triangles agents. The graph represents Processes (group of events) using diamond glyphs.
- What was also produced by the manufacturers that made the bike parts?
- What was made with the same raw materials used to make the bike parts?
We consider these questions less relevant for our present open hardware DPP use case but may revise this assumption in future research.
DPP Verification Methods
Proper means to verify the authenticity of a DPP are essential because one needs to export DPP linked data references into a data carrier (for instance, a RFID tag or QR code) and rely on a verification method to assess the integrity of the data carrier. The data carrier can hold only a limited amount of data constrained by the physical data carrier format, and so contains linked data references to provide further details for verification online.
An offline verification method can cryptographically verify the direct data and references contained within the data carrier.
An online verification method can verify both the data carrier content as well as all details of the referenced linked data available online. This link is necessary when importing the data into another federated system or visualising details for closer inspection.
In the case of Open Source Hardware DPPs, it is crucial to have some information about Agents involved in a product life cycle to further serve the implementation of economic models. In some situations, the Agents should also produce valid signatures to attest liabilities and warranties related to the production of an object. But then strong privacy concerns arise in terms of protecting the personal details of people contributing their work to a design, product, or service.
This configuration calls for developing an advanced cryptographic model that can solve these requirements and serve to authenticate data carrier linked data references to federated graph data storage. We have already created the cryptographic primitives for such a model in REFLOW crypto.
The building blocks are two:
- BLS signatures because of the possibility to aggregate them to pack multiple signatures into a single seal; this way, one can export it at a reasonable size for non-interactive verification.
- Zero-Knowledge Proofs because they preserve agents’ privacy while proving they are known members of a production lab, which may give access to further details about the production process.
,,
4- DPP and collaborative designs
Proof for the collaboration and reputation
In OSH development multiple parties can be involved in producing a particular resource, a condition common to most supply chains. Parties should be able to work together with limited trust and visibility of each other’s actions. Each party then certifies and assume liabilities for its part of the flow (corresponding to a sub-graph of the entire trace graph in our data representation), and each party can see and verify the other parties’ actions.
We use graph (see Chapter 3) as an example, where agent Designer creates a design, releases it licensed as an OSH design; agent service_prov2 then uses (“cite” in Valueflows) this design and uses (“consumes”) two other resources (magic bike mirror and aluminium bike frame) to produce a bike (fancy collaborative bike). Let’s imagine a customer wants to buy a bike designed by a local designer. The DPP can show this, but why would the customer trust it? A service provider may falsify a DPP, claiming they used an OSH design from a local designer.
A way to guarantee the authenticity of such claims is the use of cryptographic signatures. In this example, first, Designer1 generates (and thus signs) the design’s DPP (represented by the sub-graph on the right side of the picture). Once the bike is built from the design, service_prov2 generates (and thus signs) the manifested bike’s DPP (which includes citing the design of the local designer).
As shown in figure, the bike’s DPP contains the DPP for the bike’s design, as the design is embedded within the bike’s trace graph.
This configuration implies that when service_prov2 generates the bike’s DPP, the sub-graph describing the design is identical to the subgraph signed by Designer1; otherwise, Designer1’s design use cannot be verified.
A requirement for the DPP then becomes the following: any DPP generated at time t needs to include any DPP generated at an earlier time ti. In other words, each DPPt is a subgraph of DPPti if t ≤ ti.
Interfacer platform, Tech demo February 2023 – Adding contributors to project by Jaromil (Dyne.org)
Assembly Documentation Fab City OS
Ingest for Trace & DPP Modelling
DPP data modeling visualization status
Please see embedded interactive trace
Digital Product Passport Git Repositories
and Zenflows Manual to contribute.
Powered by Oxjno