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 tenant node — the future EU registry (ESPR Art. 13) is designed to index identifiers only, 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 tenant node, not in a central EU registry — the future Commission index (ESPR Art. 13) is designed to map 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 future EU Commission registry (ESPR Art. 13) is designed to operate 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 securely in your tenant node, preserving data sovereignty (your product data stays in your tenant node; the registry is intended to index 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) — live Commission API integration is still pending.
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.
For deforestation (EUDR) and forced-labour (UFLPA) due diligence, 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) — audited in real time for geographic blacklist matches and polygon overlaps. 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 for EUDR and UFLPA due diligence.
- 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 so any verifier can check integrity offline, 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