CIRPASS-2 — EU pilot for the Digital Product Passport
EU pilot (DIGITAL-2021-TRUST-01 · GA 101083432) preparing the deployment of the DPP from 2023, defining a reference architecture, vocabularies and prototypes in electronics, batteries and textiles.
Context
CIRPASS-2 is the institutional pilot project of the European Union to define the technical reference architecture of the DPP. It is not a binding rule (it has no CELEX) and it does not impose obligations on industry: it is a pilot funded by the European Commission that brings together an international consortium (31 organisations · 12 countries) and publishes technical reference deliverables. The MVP Spec §7.4 #11 lists it explicitly as a key glossary term for its role as the technical reference for the DPP architecture.
Project identification
European programme: DIGITAL-2021-TRUST-01 (Digital Europe programme). Grant Agreement: 101083432. Start: 1 October 2022. Initial duration: 18 months (initial CIRPASS · D3.2). CIRPASS-2 continuation until 2026. Lead beneficiary of deliverable D3.2: ERCIM/W3C. Principal authors of D3.2: Rigo Wenning (ERCIM/W3C), Panagiotis Papadakos (ERCIM), Carolynn Bernier (CEA). Official citation D3.2: Wenning R., Papadakos P., Bernier C. (2024), DPP System Architecture (V1.9), CIRPASS Consortium, https://doi.org/10.5281/zenodo.12206138.
Mission and scope
«Preparing the ground for the gradual piloting and deployment of DPPs from 2023 onwards, focusing on developing a roadmap for prototypes in three value chains: electronics, batteries and textiles.»
View verbatim quote in English
“Preparing the ground for the gradual piloting and deployment of DPPs from 2023 onwards, focusing on developing a roadmap for prototypes in three value chains: electronics, batteries and textiles.”
Legal nature
CIRPASS-2 is a pilot project funded by the European Commission, not a normative act. It has no CELEX in EUR-Lex because it is not a binding rule. The standard legal notice of D3.2 (page 4) specifies: «Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Health and Digital Executive Agency (HaDEA). Neither the European Union nor the granting authority can be held responsible for them».
Reference architecture · D3.2 (May 2024)
The deliverable D3.2 «DPP System Architecture»
version 1.9 (May 2024) describes two parallel but interoperable architectures for the provision of the DPP: (i) an architecture based on HTTP URIs (traditional web, Universal Resource Identifiers resolvable via DNS) and (ii) an architecture based on Decentralized Identifiers (DIDs · W3C model of decentralised identifiers with Verifiable Credentials). Both are presented from a structural point of view and from a data-flow point of view, and are validated against the requirements of the DPP system.
Basic design principles
The DPP system is decentralised by mandate of recital 32 ESPR. The data are kept and managed by their creator (or its designate) and are not aggregated in a single centralised location. It maximises robustness, resilience and security of data provision and allows responsibility to be located in the relevant stakeholders while distributing the load.
The information system is rooted in the Product-ID (Section 2.2.2 D3.2). In a circular economy, the tangible good is at the centre of interest. The Data Carrier is the immutable link between the physical world and its informational twin.
The information system must be instantly extensible without additional deployment requirements. This leads to the conclusion that the DPP must be a knowledge graph (Section 2.2.3 D3.2) where information is stored in the form of semantic triples {Subject, Predicate, Object}.
Use of standardised technology. The architecture allows the use of a wide variety of open-source tools and modules. The essential criteria are the use of URIs and a graph data model.
Main components of the HTTP architecture
Actor responsible for placing the product on the market and issuing the DPP. Generates the Product UID, assembles the DPP information and registers it with the authorities.
Unique product identifier generated by the REO (compatible with GS1 GTIN, GLN, proprietary identifiers). It is the root of the DPP.
Physical medium that links product and information (QR, 2D barcode, NFC, RFID). It is the immutable link between the physical world and the digital twin.
Service that transforms a UID into a consumable URI. There is a REO Resolver (managed by the economic operator) and a Default EU Resolver (managed by the Commission as a fallback).
Component that decides access rights to the DPP according to the role of the requester (consumer, recycler, surveillance authority, customs).
Distributed repositories where the actual DPP data reside. An interoperability layer built with linked data.
Main components of the DID architecture
W3C decentralised identifier that does not depend on DNS. There is an Actor DID (economic operator) and a Product DID (specific product).
JSON document associated with the DID that contains cryptographic keys and service endpoints.
Verifiable claims issued by third parties about the product (certification, laboratory test, declaration of conformity). W3C VC Data Model.
Applications the REO uses to issue the DPP (minting App + DID & VC Issuer Wallet) and to manage VCs (DPP App + DID & VC Issuer Wallet).
Registry where the DID Documents associated with the DIDs are stored.
Pilot value-chain coverage
CIRPASS-2 develops DPP prototypes in three selected value chains: electronics (consumer electronic products), batteries (aligned with the Battery Regulation Reg. (EU) 2023/1542, which already imposes a mandatory DPP) and textiles (anticipation of the ESPR textile delegated act foreseen in COM(2025) 187). The consortium includes 31 organisations from 12 countries: ERCIM/W3C (FR), CEA (FR), Fraunhofer (DE), Wuppertal Institut (DE), Chalmers University (SE), VDE (DE), Politecnico di Milano (IT), TU Delft (NL), GS1 in Europe (BE), Textile Exchange (US), Responsible Business Alliance (US), among others.
Applied case
A textile brand preparing its DPP for the ESPR textile delegated act foreseen in the Working Plan COM(2025) 187 can use the CIRPASS-2 D3.2 reference architecture as a technical guide to make implementation decisions before the publication of the delegated act and of the CEN/CENELEC/JTC 24 standards.
Architecture decision · HTTP URIs vs DIDs. The brand evaluates the two parallel architectures that CIRPASS-2 D3.2 proposes. The HTTP URIs architecture relies on standard web infrastructure (DNS, HTTPS) and is the more mature option for immediate implementation. The DID architecture relies on W3C decentralised infrastructure and is the more future-proof option for integration with Verifiable Credentials. Both are interoperable according to CIRPASS-2.
Implement the REO role. The brand takes on the Responsible Economic Operator role defined in D3.2. It generates Product UIDs aligned with GS1 (GTIN for model level + serialisation for item level via GS1 Digital Link), operates its own REO Resolver that resolves a UID to the DPP URI, assembles the DPP information following the JRC 145830 methodology and registers the DPP with the central EU-Registry via API when it is available.
Implement the Data Carrier. The brand places a QR code on the physical labelling of each garment (compatible with GS1 Digital Link), optionally an NFC tag for premium collections or accessibility. The QR resolves to the DPP via the REO Resolver following the HTTP DFD flow
«From Data Carrier to a Usable URI»
(Figure 8 D3.2).Implement the PDP · Policy Decision Point. The brand defines access rights by role: the public consumer sees composition, origin, care and durability; the surveillance authority accesses the technical documentation via an authenticated reserved channel; the recycler accesses substances of concern for treatment; the repairer accesses repair instructions. The PDP arbitrates each request according to the identified role.
Integrate Verifiable Credentials. The brand uses the W3C VC Data Model to incorporate verifiable claims issued by third parties (GOTS certification, OEKO-TEX test, CSDDD declaration) that are incorporated into the DPP as cryptographically verifiable evidence. It follows the VC Issuance pattern documented in Section 4.3.1 D3.2.
Common mistakes
CIRPASS-2 is NOT a binding rule: it is an institutional pilot project.
CIRPASS-2 has no CELEX in EUR-Lex because it is not a normative act. It is a pilot project funded by the European Commission under the Digital Europe programme (DIGITAL-2021-TRUST-01, Grant Agreement 101083432). The consortium deliverables (D2.1, D3.2) are voluntary technical references that orient the development of the EU-Registry and of the ESPR sectoral delegated acts. The binding rule for the DPP is Reg. (EU) 2024/1781 ESPR.
CIRPASS-2 does NOT replace the EU-Registry of Art. 12a ESPR: it methodologically anticipates it.
The central EU-Registry that will index resolvers and Product IDs on the internal market is the exclusive competence of the European Commission under Art. 12a ESPR. CIRPASS-2 D3.2 describes the EU-Registry as a reference architectural component (Section 3.1.5), but it neither establishes nor operates it. The Commission will deploy it according to the deadlines and specifications of the ESPR itself and of the corresponding implementing acts.
The two D3.2 architectures (HTTP URIs and DIDs) are NOT mutually exclusive alternatives: they are interoperable.
D3.2 v1.9 (Section 5.2) confirms that the two architectures are parallel but interoperable. An implementation can start with HTTP URIs (mature, familiar web infrastructure) and migrate progressively to DIDs (W3C, future-proof, cryptographically verifiable) without breaking compatibility with the DPP ecosystem. The architecture choice is a technical decision for each REO according to its needs, not a regulatory obligation.
CIRPASS-2 is NOT the same as JRC 145830: they are complementary pieces.
JRC 145830 sets the methodology for defining the DPP data requirements (which data to include and why · the what · steps A/B/C/D). CIRPASS-2 proposes the reference architecture of the DPP system (how to store and exchange those data · the how). They are complementary pieces of the same EU institutional ecosystem: one orients the content of the DPP, the other orients the technical infrastructure to serve it. JRC 145830 itself cites CIRPASS in its references (Section 1.1).
CIRPASS-2 does NOT impose proprietary technology: the architecture is open-standards.
The Scope and limitations note of D3.2 v1.9 (Section 1.1) specifies: «if specific solutions are mentioned in this deliverable, this should not exclude the use of alternative solutions». The CIRPASS-2 architecture relies on open standards (W3C, GS1, IETF) and allows multiple concrete implementations. The essential criteria are the use of URIs and a graph data model (linked data), not specific commercial products.
Frequently asked questions
What is CIRPASS-2?
A pilot project funded by the European Union (DIGITAL-2021-TRUST-01 programme · Grant Agreement 101083432) that prepares the technical deployment of the Digital Product Passport. It brings together a consortium of 31 organisations from 12 countries and publishes technical deliverables on the architecture of the DPP system (D3.2 v1.9 · May 2024), legal mapping (D2.1 · July 2023) and user stories. It develops prototypes in three value chains: electronics, batteries and textiles.
Is CIRPASS-2 binding for textile brands?
No. CIRPASS-2 is a pilot project funded by the European Commission, not a normative act. It has no CELEX in EUR-Lex. The consortium deliverables (D2.1, D3.2) are voluntary technical references. The binding rule for the DPP is Reg. (EU) 2024/1781 ESPR and the sectoral delegated acts published on the basis of the ESPR.
What architecture does CIRPASS-2 D3.2 propose?
Two parallel but interoperable architectures. (i) An architecture based on HTTP URIs (standard web, Universal Resource Identifiers resolvable via DNS, the mature option for immediate implementation). (ii) An architecture based on Decentralized Identifiers (DIDs · W3C model of decentralised identifiers with Verifiable Credentials, the future-proof option). Both are validated against 10 user stories and are interoperable.
Who is the REO in the CIRPASS-2 architecture?
REO (Responsible Economic Operator) is the actor responsible for placing the product on the market and issuing the DPP. It generates the Product UID, operates its own Resolver, assembles the DPP information, registers the DPP with the central EU-Registry and assumes operational responsibility for the long-term availability of the DPP (including cessation of activity via a certified independent third-party DPP service provider that acts as an Archive).
How does CIRPASS-2 relate to JRC 145830?
They are complementary pieces of the institutional DPP ecosystem. JRC 145830 sets the methodology for defining the DPP data requirements (which data to include and why). CIRPASS-2 proposes the reference architecture of the DPP system (how to store and exchange those data). JRC 145830 itself cites CIRPASS in its references (Section 1.1) as a complementary methodological input.
Does CIRPASS-2 cover the textile sector specifically?
Yes. CIRPASS-2 develops DPP prototypes in three selected value chains: electronics, batteries and textiles. The textile chain anticipates the requirements of the ESPR textile delegated act foreseen in the Working Plan COM(2025) 187 final. The CIRPASS-2 consortium includes textile-specialised organisations such as Textile Exchange and Responsible Business Alliance.
Fuentes oficiales
- Wenning R., Papadakos P., Bernier C. · CIRPASS Consortium · Zenodomayo 2024Technical deliverable of EU pilot project
- CIRPASS Consortiumjulio 2023Technical deliverable · legal mapping
- CIRPASS Consortium · co-funded by the European UnionvigenteProject website · public deliverables
- European Parliament and Council · OJEU OJ L, 28 Jun 202413 jun 2024Binding reference regulation
- European Parliament and Council · OJEU12 jul 2023Binding precursor regulation
