Imagine a textile manufacturer in Bangladesh producing garments for a French brand, sold in Germany, recycled in Poland. The garment carries a Digital Product Passport. Four countries, four regulatory contexts, likely three or four different software systems, and one data carrier that must make all of it work seamlessly.
That is the interoperability problem. It is not abstract — it is the difference between a DPP that functions as a compliance checkbox and one that actually enables the circular economy the regulation is meant to create. The EU Commission's own impact assessments acknowledge that without interoperability, the DPP risks becoming a collection of siloed, incompatible data islands that fail to serve repair technicians, recyclers, customs authorities, or downstream manufacturers.
Digital product passport interoperability sits at the intersection of four technical domains: data standards, identity systems, trust frameworks, and infrastructure protocols. This piece examines each and explains why the choices made now — often before formal delegated act requirements are finalised — will determine whether cross-border DPP exchange actually works in practice.
Why interoperability is the problem nobody wants to solve first
Interoperability is genuinely hard. It requires agreement across competitors, across national authorities, across existing legacy systems, and across technical communities that rarely communicate with each other. It also produces no immediate competitive advantage — a brand cannot market "our DPP is interoperable" to consumers. The incentive to delay is strong.
The ESPR regulation tries to force the issue by requiring that DPP data be accessible to multiple actor types: consumers, repair services, recyclers, customs authorities, and market surveillance bodies. Each of these actors uses different systems. A customs declaration system in Poland is not going to query a brand's proprietary DPP platform via a bespoke API integration. It needs a standardised protocol.
The ESPR regulation delegates the technical specifications to implementing acts, most of which are still being developed. This creates a genuine tension: brands need to build DPP infrastructure now (particularly in batteries, where the Battery Passport regulation has hard deadlines), but the final interoperability specifications are not yet locked. Building for flexibility, rather than optimising for a single approach, is the pragmatic response.
EPCIS 2.0: the supply chain traceability backbone
GS1's Electronic Product Code Information Services standard — EPCIS — is the most mature interoperability protocol in the DPP ecosystem. Version 2.0, released in 2022, introduced JSON-LD serialisation alongside the older XML format, making it compatible with modern web infrastructure and semantic web tooling.
EPCIS describes events: a product was commissioned at a factory, it was shipped to a distribution centre, it passed a customs inspection, it was sold at retail. Each event carries a timestamp, a location (expressed as a GS1 Global Location Number), and references to the product identifiers involved. The result is a timestamped, auditable chain of custody that spans an entire supply chain without requiring a single centralised database.
For DPP purposes, EPCIS 2.0 solves the traceability layer. It answers questions like: where was this battery cell manufactured? Which production lot does this garment belong to? When was this electronic device exported from the EU? The connection to GS1 Digital Link is direct — the GTIN and serial number carried in the Digital Link URI are the same identifiers used in EPCIS event records, creating a coherent identity chain from physical label to event history.
Several EU member state pilot projects have used EPCIS 2.0 as the backbone for DPP data exchange — notably in the fashion and textile sector, where GS1 and the Textile Exchange have collaborated on interoperability specifications. The standard is not without limitations: EPCIS describes events, not product attributes. Material composition, repairability scores, carbon footprint data — these require a separate data model layered on top of the event chain.
W3C Verifiable Credentials: trust without a central authority
One of the genuinely difficult problems in cross-border DPP exchange is trust. If a recycler in Poland queries a DPP system run by a brand headquartered in Vietnam, how does the Polish recycler know the data is authentic and has not been tampered with?
W3C Verifiable Credentials (VCs) provide a cryptographic answer. A VC is a structured data object — typically JSON-LD — signed with a cryptographic key held by the issuer. Anyone with the issuer's public key can verify the signature without contacting the issuer. This means a sustainability claim (this battery contains 30% recycled materials) can be independently verified by any downstream actor without relying on the brand's server being available or trustworthy.
The DPP application of VCs is being developed by several consortia, including the European Blockchain Partnership and the Catena-X automotive network. The model works as follows: a manufacturer issues a VC attesting to certain product properties. A third-party auditor issues another VC attesting that those claims were independently verified. A customs authority can verify both VCs cryptographically without querying either the manufacturer or the auditor — both could be offline.
This architecture matters for the DPP's long-term credibility. Self-reported sustainability data without verifiable credentials is essentially unaudited. As market surveillance bodies gain experience with DPP enforcement, the expectation of cryptographic attestation for key claims will increase. Building VC support into DPP infrastructure early is considerably easier than retrofitting it after launch.
W3C DID (Decentralised Identifiers) is the companion standard — it provides the identity layer that VCs need to identify issuers. A manufacturer's DID is a persistent, globally unique identifier that resolves to the cryptographic keys needed to verify their VCs, without depending on any centralised registry. Both standards are published by the W3C and are genuinely open.
EU Data Spaces and GAIA-X: the infrastructure layer
The European Commission's Data Strategy includes a programme of sector-specific data spaces — governed data sharing environments built on common technical standards. Several are directly relevant to DPP interoperability.
The Manufacturing Data Space, the Mobility Data Space, and the Green Deal Data Space are the three most immediately relevant. Each is being developed under the GAIA-X umbrella — a European initiative to create a federated, interoperable data infrastructure that competes with hyperscaler cloud platforms while maintaining EU data sovereignty.
GAIA-X defines a technical framework for data spaces: participants self-describe their data offerings using standardised catalogues, data exchange is governed by policy-enforced contracts, and provenance is tracked cryptographically. The Catena-X automotive network is the most mature implementation — it already handles supply chain data exchange among hundreds of automotive manufacturers and suppliers using GAIA-X principles.
For DPP interoperability, data spaces offer a compelling model. Rather than every brand operating a private DPP repository that each supply chain partner must separately integrate with, brands publish DPP data into a sector data space. Authorised participants — recyclers, repair services, customs authorities — query the data space rather than individual brand endpoints. Data sovereignty is maintained: the brand controls what data is shared with whom, governed by enforceable contracts.
The practical limitation is that most sector data spaces relevant to DPP are still in early development. Catena-X is operational for automotive. Textile data spaces are in pilot. Battery data spaces are being designed in parallel with the Battery Passport regulation's technical specifications. Brands cannot yet fully rely on data space infrastructure — but designing DPP systems that can integrate with data spaces when they mature is a reasonable architectural goal.
JSON-LD and the semantic web foundation
JSON-LD (JSON for Linked Data) is the serialisation format that underlies both W3C Verifiable Credentials and EPCIS 2.0's modern profile. Understanding why it matters for interoperability requires a brief detour into what makes data actually interoperable versus merely exchangeable.
Two systems can exchange data without understanding each other. An XML file from system A can be parsed by system B if both agree on the schema. But if the schema changes, or if a third system C with a different schema needs to join the exchange, the rigid agreement breaks down. JSON-LD addresses this by making data self-describing: each field references a vocabulary term from a public ontology (typically Schema.org, GS1's Web Vocabulary, or a sector-specific ontology). Any system that understands those ontologies can interpret the data without prior bilateral agreement on schema.
For DPP data, this means a recycler's system can ingest a DPP from any manufacturer — regardless of whose platform generated it — as long as both use JSON-LD with shared vocabulary terms for material composition, carbon footprint, repairability index, and so on. The EU's working groups on DPP data models are converging on JSON-LD as the interchange format, with the Battery Passport regulation's technical annex serving as an early reference implementation.
Schema.org's Product and ItemList types provide a starting vocabulary. GS1's Web Vocabulary extends this for supply chain contexts. The European Commission's DPP technical working groups are developing additional vocabulary terms for sustainability attributes that are not yet covered by existing ontologies.
Cross-border compliance: what interoperability actually unlocks
The practical case for investing in interoperability is clearest when you map the actors who need to access DPP data and what they actually need from it.
Customs authorities need to verify that a product imported into the EU carries a valid DPP — and that the DPP data matches customs declarations for materials and origin. Without interoperability between customs systems and DPP registries, this check requires human intervention for every shipment. With a standardised protocol, it can be automated.
Repair services need access to repair manuals, spare parts lists, and disassembly instructions — data that is typically held by the manufacturer and currently provided only through proprietary service portals. A standardised DPP data model with authenticated access for registered repair providers would transform this. EPCIS provides the identity chain; Verifiable Credentials provide the access control.
Recyclers need material composition data at the item level to optimise sorting and material recovery. Bulk data exports to sector-level data spaces, aggregated from DPP records, would enable automated material flow management at a scale that is impossible with current fragmented data. This is explicitly the goal of the ESPR's circular economy provisions.
Building for these use cases from the start — rather than treating the DPP as a consumer-facing compliance checkbox — requires the kind of architectural thinking that the DPP creation guide addresses in detail. The requirements checklist includes interoperability standards as a mandatory consideration alongside data carrier and data model choices.
Frequently asked questions
What does "DPP interoperability" mean in practice?
DPP interoperability means that a Digital Product Passport created by one manufacturer using one platform can be correctly read, interpreted, and acted upon by a different organisation using different software — without prior bilateral integration. This requires shared data standards (like JSON-LD with common vocabularies), shared identity frameworks (like GS1 Digital Link for product identifiers), and shared trust mechanisms (like W3C Verifiable Credentials for data authenticity).
Is EPCIS 2.0 mandatory for Digital Product Passports?
EPCIS 2.0 is not currently mandated by EU regulation as the DPP standard, but it is widely recommended and used in pilot programmes. Its JSON-LD serialisation is compatible with the data format directions being taken by EU technical working groups. For supply chain traceability use cases — particularly in batteries, textiles, and electronics — EPCIS 2.0 is the most mature and widely supported option available.
What is GAIA-X and how does it relate to DPP compliance?
GAIA-X is a European initiative to create federated, interoperable data infrastructure. For DPP compliance, GAIA-X provides the governance framework for sector-specific data spaces — shared environments where DPP data can be exchanged between supply chain participants under defined rules. Catena-X (automotive) is the most mature example. Textile and battery data spaces are in development. Brands that design DPP systems to integrate with data spaces will have a significant compliance advantage as this infrastructure matures.
Do W3C Verifiable Credentials replace traditional compliance certificates?
Not immediately. W3C Verifiable Credentials are a technical standard for cryptographically signed data objects — they can represent the same information as a traditional certificate, but in a machine-readable format that can be verified without contacting the issuer. EU regulators are actively evaluating VCs for DPP attestation of sustainability claims. In time, VCs are likely to supplement or replace paper-based and proprietary digital certificates for certain regulated claims, but the transition will be gradual.
Why is JSON-LD preferred over plain JSON for DPP data?
Plain JSON is flexible but ambiguous — a field labelled "weight" in one system may mean net weight, gross weight, or shipping weight, and another system cannot determine which without prior agreement. JSON-LD adds a context that maps each field to a shared vocabulary term with a precise, public definition. Any system that understands the vocabulary can correctly interpret the data without bilateral schema agreement. This is what makes true interoperability possible across unrelated systems and organisations.
What does "DPP interoperability" mean in practice?
DPP interoperability means that a Digital Product Passport created by one manufacturer using one platform can be correctly read, interpreted, and acted upon by a different organisation using different software — without prior bilateral integration. This requires shared data standards (like JSON-LD with common vocabularies), shared identity frameworks (like GS1 Digital Link for product identifiers), and shared trust mechanisms (like W3C Verifiable Credentials for data authenticity).
Is EPCIS 2.0 mandatory for Digital Product Passports?
EPCIS 2.0 is not currently mandated by EU regulation as the DPP standard, but it is widely recommended and used in pilot programmes. Its JSON-LD serialisation is compatible with the data format directions being taken by EU technical working groups. For supply chain traceability use cases — particularly in batteries, textiles, and electronics — EPCIS 2.0 is the most mature and widely supported option available.
What is GAIA-X and how does it relate to DPP compliance?
GAIA-X is a European initiative to create federated, interoperable data infrastructure. For DPP compliance, GAIA-X provides the governance framework for sector-specific data spaces — shared environments where DPP data can be exchanged between supply chain participants under defined rules. Catena-X (automotive) is the most mature example. Textile and battery data spaces are in development. Brands that design DPP systems to integrate with data spaces will have a significant compliance advantage as this infrastructure matures.
Do W3C Verifiable Credentials replace traditional compliance certificates?
Not immediately. W3C Verifiable Credentials are a technical standard for cryptographically signed data objects — they can represent the same information as a traditional certificate, but in a machine-readable format that can be verified without contacting the issuer. EU regulators are actively evaluating VCs for DPP attestation of sustainability claims. In time, VCs are likely to supplement or replace paper-based and proprietary digital certificates for certain regulated claims, but the transition will be gradual.
Why is JSON-LD preferred over plain JSON for DPP data?
Plain JSON is flexible but ambiguous — a field labelled "weight" in one system may mean net weight, gross weight, or shipping weight, and another system cannot determine which without prior agreement. JSON-LD adds a context that maps each field to a shared vocabulary term with a precise, public definition. Any system that understands the vocabulary can correctly interpret the data without bilateral schema agreement. This is what makes true interoperability possible across unrelated systems and organisations.
Digital product passport interoperability is not a single technology decision — it is a stack of decisions across data formats, identity systems, trust frameworks, and infrastructure. The encouraging news is that the standards landscape has matured considerably in the past three years. EPCIS 2.0, W3C VCs, JSON-LD, and GS1 Digital Link are all stable, open standards with real implementations. The data space infrastructure is emerging more slowly, but the direction is clear.
For brands building DPP systems now, the actionable principle is: use open standards at every layer, and design for multiple consumers from the start. The GS1 Digital Link specification is the right starting point for the identity and carrier layer. From there, our platform handles the resolver architecture and data endpoint management needed to serve the different actor types your DPP will eventually need to reach.