From product data to a verified passport in three steps.
OpenDPP is engineered for Digital Product Passport validation aligned with the decentralised DPP model, standard GS1 resolution, and asymmetric eIDAS cryptography — without the operational overhead. Map your product data once; we handle the signing, hosting, and verification.
Three steps from SKU to signed, scannable passport
No standards team or custom build required — the regulation's requirements become a guided workflow.
Import product data
No-code or CSV. Map your SKUs, materials, and footprint once — reuse forever. Product metadata stays in your OpenDPP workspace — the EU registry (ESPR Art. 13) indexes identifiers only; it does not host product data.
Sign & publish
An eIDAS advanced electronic seal is applied automatically and the passport is published behind a GS1 Digital Link. Elliptic-curve ECDSA keys rotate with a single click; private keys never leave the tenant database.
Verify anywhere
Scan a QR → public passport. The resolver content-negotiates HTML or JSON-LD, and buyers, auditors, and recyclers verify the advanced electronic seal in seconds, offline or in the Seal Audit portal.
The architecture that makes it work
Standards-native by design — content negotiation, GS1 resolution, eIDAS advanced electronic seals, JSON-LD product data, and a tenant-node model aligned with the decentralised DPP architecture.
Tenant node, decentralised model
Your data lives in your OpenDPP workspace, not in a central EU registry — the Commission index (ESPR Art. 13) maps identifiers to passport URIs only.
GS1 Digital Link resolver
One scan resolves a GTIN or GRAI (AI 01/8003), validates the mod-10 checksum, and reads the AI 21 serial — then queries the node.
eIDAS advanced electronic seals
FprEN 18246 (final draft) ESDCs: each JSON-LD payload is signed with the tenant's private key, held in encrypted vault custody (AES-256-GCM, per-tenant, in Postgres), for tamper-evident proof.
W3C JSON-LD & AAS
Content negotiation returns human-readable HTML or machine-readable JSON-LD, plus Asset Administration Shell (AAS v3.0/3.1) submodels.
Aligned with the decentralised DPP model
Under the ESPR (Art. 10 / CIRPASS) and CEN/CENELEC specifications, the European Commission does not host your company's product, material, or chemical data. Doing so would violate intellectual-property protections and create centralised single points of failure.
Instead, the EU Commission registry (ESPR Art. 13) operates merely as an index — mapping a Unique Product Identifier (UPI) to the exact URI of the corresponding passport. OpenDPP runs as a high-performance passport repository and GS1 Digital Link resolver aligned with this decentralised model: product metadata resides in your tenant-isolated workspace on the EU-hosted OpenDPP node (your product data stays on the OpenDPP node, not in the registry, which indexes identifiers only). OpenDPP is registry-ready: it already projects each passport into the exact Art. 13 pointer record and validates it against the CIRPASS-2 reference registry (a non-normative EU-funded reference) — battery registration in the Commission registry is not yet possible, and no operator-facing machine API is documented.
GS1 Digital Link resolution gateway
To connect physical products with their digital passports, OpenDPP leverages standard GS1 Digital Link URIs. When a QR code printed on a product or returnable asset is scanned, the resolution gateway (matching GET /:ai(01|8003)/*) intercepts the request. It extracts the GS1 Application Identifier, parses the GTIN or GRAI, verifies its Modulo-10 checksum, and reads subsequent key-value attributes such as the unique Serial Number (AI 21). The node then resolves against Postgres JSONB metadata and returns the content-negotiated HTML or JSON-LD representation.
- Identifier parsing. AI 01 (GTIN) and AI 8003 (GRAI) are recognised, mod-10 validated, and routed to the right passport or per-unit view.
- Per-unit serialisation. An AI 21 serial redirects to the public unit page: the unit's identity, status and lifecycle lineage are public, while its telemetry (state of health, cycle counts) is released only to authorised legitimate-interest viewers and authorities, per Annex XIII of the Battery Regulation.
- Content negotiation. The same URL serves a human-readable page or a machine-readable JSON-LD document depending on the request's Accept header.
Asymmetric eIDAS advanced electronic seals, keys encrypted in your vault
To help prevent fraud and support non-repudiation, the final-draft standard FprEN 18246 (at formal vote) sets out that passports are encapsulated within Electronically Signed Data Constructs (ESDC). OpenDPP applies a per-tenant eIDAS advanced electronic seal with software custody inside the tenant database space — brands rotate elliptic-curve ECDSA keys with a single click, and private keys are stored AES-256-GCM-encrypted, never leaving the tenant node in plaintext.
When a passport is sealed and published, the node signs the complete JSON-LD payload using the tenant's private key and writes the signature directly to PostgreSQL. Auditors then verify the seal's authenticity in the Seal Audit validator portal — a public check that the passport genuinely came from the declared operator and has not been altered.
A passport is not a one-time filing. It is a living, signed record that must stay accurate and reachable long after the product has left your warehouse — which is why key custody and persistence sit at the centre of the design.
— How we frame the obligation for stakeholdersAAS metamodels and signed supply-chain lineage
For industrial twin interoperability, OpenDPP supports the Asset Administration Shell (AAS v3.0/3.1) specification, dynamically converting PostgreSQL JSONB rows into standard compliance submodels. To avoid hardcoding attributes, a semantic concept registry maps local object fields to global IEC and eCl@ss IRDI dictionaries at runtime — so enterprise clients can query passports using industrial-standard terms or ingest raw AAS JSON Environment payloads directly.
OpenDPP parses physical supply-chain transactions wrapped inside signed, VC-shaped UNTP credentials following the UN Transparency Protocol (UNTP / EPCIS 2.0). As trace events are registered, the node resolves the graph recursively with a cycle-resistant depth-first walker to build a lineage Directed Acyclic Graph (DAG) — a machine-readable upstream pedigree your own due-diligence workflows can consume. Separately, OpenDPP issues each product passport as a conformant UNTP DigitalProductPassport credential — an enveloping vc+jwt (W3C VC-JOSE-COSE) and an embedded W3C Data Integrity proof (ecdsa-jcs-2019) — that validates against the official UNTP schema.
- AAS v3.0/3.1 submodels. JSONB rows are projected into standard compliance submodels on demand, with ingestion of raw AAS Environment payloads.
- Semantic concept registry. Local fields map to IEC and eCl@ss IRDI dictionaries at runtime — no hardcoded standard attributes.
- UNTP / EPCIS 2.0 lineage. Signed trace events compile into a cycle-resistant lineage DAG — a machine-readable upstream pedigree of your supply chain.
- Conformant UNTP DPP credentials. Each passport is also issued as a conformant UNTP DigitalProductPassport credential — an enveloping vc+jwt (W3C VC-JOSE-COSE) and an embedded W3C Data Integrity proof (ecdsa-jcs-2019), with resolvable did:web issuer keys and W3C Bitstring Status List revocation.
See the architecture issue a passport in real time.
Watch your team go from product data to a sealed, verification-ready Digital Product Passport.
Book a demoOpenDPP publishes Digital Product Passports (DPPs) in three steps: (1) model product data as W3C-standard JSON-LD via the no-code uploader or API, (2) apply an eIDAS advanced electronic seal whose verification algorithm, certificate chain and samples are all published, so a third party can check integrity without calling OpenDPP, and (3) publish GS1 Digital Link QR codes that resolve to the passport for any party.
How OpenDPP Publishes a Digital Product Passport · Last reviewed