Infrastructure
Four moving parts, and one that has to outlive the contract
A resolver, a record store, an event store and a credential layer. The architectural question that matters is not throughput — it is whether an identifier issued today still resolves when the product reaches end of life in 2041.
- Resolver
- GS1 Digital Link
- Events
- Append-only
- Residency
- Selectable, EU available
Definition
What does Digital Product Passport infrastructure consist of?
A passport platform has four components: a resolver mapping GS1 Digital Link identifiers to role-scoped responses, a record store holding passport data, an append-only event store holding EPCIS 2.0 supply chain events, and a credential layer issuing and verifying W3C Verifiable Credentials. Integrations sit around those four.
The separation is not incidental. Reads follow public scans and writes follow machine-generated events, and the GS1 Digital Link resolver has to answer the first without waiting on the second.
Architecture
What each layer is responsible for
| Layer | Responsibility | Standard |
|---|---|---|
| Resolver | Turns an identifier into the response the caller is entitled to | GS1 Digital Link |
| Record store | Holds the current passport state and its access policy | CIRPASS-aligned model |
| Event store | Append-only history of what happened to each object | GS1 EPCIS 2.0 |
| Credential layer | Issues, verifies and revokes signed claims | W3C VC 2.0 · DID |
| Integration | Moves data in from ERP, PLM and partner systems | REST · webhooks |
Infrastructure
Go deeper
API and integration
How data reaches the platform from ERP, PLM and carbon accounting systems.
Verifiable ledger
Where anchoring and revocation registries are used, and where they deliberately are not.
Security
Access control, key custody, tenancy isolation and data residency.
Scalability
How resolver reads and event writes scale independently of one another.
Resolution on your domain
Identifiers resolving under your hostname, so a fifteen-year artefact is not tied to ours.
Data model
The CIRPASS-aligned field model that lets a delegated act arrive as a mapping.
Answers
Frequently asked questions
What are the moving parts of a passport platform?
Four. A resolver that turns a GS1 Digital Link identifier into the caller-appropriate response, a record store holding the passport data, an append-only event store holding EPCIS 2.0 events, and a credential layer that issues and verifies W3C Verifiable Credentials. Everything else is integration around those four.
Does this run on a blockchain?
Not for the passport record itself, which would be both slow and inappropriate for data that must sometimes be corrected or erased. A distributed ledger is used only where anchoring adds something a signature does not — notably tamper-evident timestamping and revocation registries that no single party should control.
Where is our data held?
Data residency is selectable per tenant, and EU-resident deployments keep passport records, events and credentials within the EU. This matters more than usual here, because passport data is regulated product data that a market surveillance authority may need to reach for the lifetime of the product.
What has to keep working for fifteen years?
The identifier must keep resolving, and the credentials must keep verifying. Both are addressed by design rather than by promise: identifiers follow GS1 Digital Link and can resolve on your own domain, and credentials verify against Decentralized Identifiers that do not depend on this platform continuing to exist.
How does load actually behave?
Read volume follows scans, which are bursty and public-facing, while write volume follows supply chain events, which are steady and machine-driven. Those are different workloads, so the resolver and the event store scale independently rather than sharing one bottleneck.
Next step
Bring your platform team
We will walk the architecture, the residency model and the exit path, and answer the question that actually decides it: what happens if you stop using us.