DPP Knowledge Base DPP Service: an open implementation of the EN 18222 passport API
The open-source service that stores, versions and serves Digital Product Passports through the standard lifecycle API – with signed writes, content binding, role-based access and an access log. Use our public instance or run your own.
In short
- The DPP Service implements the passport lifecycle API of EN 18222:2026, with passports in the data model of EN 18223:2026.
- Reading is public; writing needs a short-lived token signed with the writer’s own
did:oyd– no client secrets, no accounts. - It binds each passport’s content to its identifier, delivers controlled data per role and logs every read of it.
- Passports live in the service’s own database or at a custodian chosen by the operator.
- OwnYourData runs a public instance at
dpp-service.ownyourdata.eu. The code is open source under Apache 2.0 – anyone can run their own.
What a DPP service does
A Digital Product Passport has to be created, corrected, kept available for years, read by anyone who scans the product, and ended when the product reaches the end of its life. EN 18222:2026 defines the API for this lifecycle: which methods exist, how they are called and what they answer. A DPP service is the system that offers this API.
The DPP Service of OwnYourData is one complete, open implementation of it. It is the service the DPP Manager talks to – but any client that speaks the standard API can use it, and any organisation can run its own copy.
The API
| Group | Methods |
|---|---|
| Lifecycle | create, read by passport or product identifier, update (as a JSON merge patch), delete, read the version valid at a given date, look up passport identifiers for a list of products |
| Fine-granular | read or update a single data element or collection |
| Registry | register a passport with the EU registry |
| Beyond the standard | change of custodian, the mandate for the custodian, access policies, access grants, the access log, and a discovery document at /.well-known/dpp-service |
The whole contract is published as an OpenAPI description and rendered at /api-docs.
Writing: signed, not shared secrets
The public instance accepts a write only with a bearer token the writer issues itself: a JSON Web Token, valid for at most 15 minutes, signed with the document key of the writer’s did:oyd. There is no account to create and no client secret that could leak.
The service resolves the DID, checks the signature, and remembers who created each passport. Only the DID that created a passport may change it. Reading needs no token at all.
What the service adds to a passport
Content binding. After a write, the hash of the published content is recorded in the passport’s own DID document. Anyone can check later that what they receive is what the operator published – see Public availability.
Role-based access. The operator can classify each attribute as public, for readers with a legitimate interest, or for authorities only. The service then gives each reader exactly the parts it may read, and logs every read of controlled data – see Role-based access to passport data.
Versions and end of life. Every change is kept: the version valid at any past date can be read back. When a passport is ended, the service stops serving it and keeps the final state as history.
Where the passports are kept
The service can work in two ways:
- Stand-alone, with passports in its own PostgreSQL database. Nothing else is needed; the stand-alone guide sets it up, also as a container.
- With a custodian. The passport is kept by a separate hosting service, under a mandate the operator signs: one statement naming one passport, one storage place and a lifetime. The custodian also serves the public part on the link printed on the product. Moving to another custodian changes neither the passport identifier nor the printed link.
The public instance uses the second way. Its custodian is the data intermediary of DID FlexCo, an organisation separate from OwnYourData, so that the party serving the API and the party holding the data are not the same.
The public instance
| What | Where |
|---|---|
| Base address | https://dpp-service.ownyourdata.eu/dpp/v1 |
| API description | /api-docs |
| Discovery | /.well-known/dpp-service – the service’s DID, the token audience and the issuers it trusts for authorities |
| Daily checks | DPP Service Validator results |
The instance is checked every day by the DPP Service Validator – the same checks any other listed service goes through.
Run your own
The code is published at github.com/OwnYourData/dpp-service-public under the Apache 2.0 licence. A stand-alone instance needs Ruby or Docker and a PostgreSQL server:
bundle install
bin/rails db:create db:migrate db:seed
bin/rails server
A fresh stand-alone instance starts in a permissive mode for trying things out, in which token signatures are not checked. For production, switch on signature checking as the public instance does.
The public repository is a snapshot of the development repository, refreshed from time to time. Questions and suggestions are welcome as issues.
Try the API
The public instance is open for reading – no account. The interactive API description lists every method with its parameters.
Further reading
- Running the service stand-alonesetup with your own PostgreSQL database
- The DPP Service on the command lineone passport created, corrected, moved and ended, as curl calls
- Identifiers in the DPP ecosystemwhich identifier is which
- OYD DID methodthe self-certifying identifiers the service uses
Related articles
Public availability: from QR code to passport
How anyone gets from the code on a product to its passport – without an account or an app – why the link on the product never has to change, and how a reader can check that the data is genuine.
Role-based access to passport data
Not every field of a passport is for everyone. How the DPP Service classifies passport data, who may read what, how access is granted and revoked, and how every access is logged.
DPP Service Validator: daily, public checks of DPP services
Every listed DPP service is checked every day against open criteria – transport security, the EN 18222 API and protection against unauthorised changes – and the results are published for everyone to see.