DPP Knowledge Base 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.
In short
- The DPP Service Validator checks DPP services – the systems that hold and serve passports – not single passports.
- Every listed service is checked every day against the service criteria of the open repository dpp-criteria.
- It checks transport security, the lifecycle API of EN 18222, and that nobody can create or change a passport without authorisation.
- Results are public, with every finding and the exact version of the criteria used.
- Any operator can add their own service with a pull request. It is free and open source.
Why check services, not just passports
An economic operator rarely runs its own passport infrastructure. It hands its passports to a DPP service provider – and has to trust that the service speaks the standard API, uses current transport security and does not let strangers change a passport.
A single passport cannot show that. Whether unknown passports are answered correctly, whether old TLS versions are refused, whether a write without credentials is rejected – that is a property of the service. The validator checks exactly these properties, the same way for every service, and publishes the result.
What is checked
| Area | Examples |
|---|---|
| Transport (EN 18216) | HTTPS with a valid certificate, TLS 1.2 or higher, HTTP/2, no older HTTP versions |
| Lifecycle API (EN 18222) | the read methods ReadDPPById, ReadDPPByProductId and ReadDPPIdsByProductIds, the v1/ version prefix, status codes, 404 for unknown passports, the representation flag |
| Protection | creating or changing a passport without credentials is refused, and the test passport is unchanged afterwards |
Each run records which commit of dpp-criteria it used, and each criterion links to its description at that commit. A result can therefore always be traced back to the exact rule it was checked against.
How a service gets listed
A service is listed only by its operator, or with the operator’s consent. The operator opens a pull request to dpp-criteria with a short entry: name, operator, API address, a contact address and a test passport that stays online while the service is listed.
What the daily run sends is deliberately small: about 30 requests and TLS handshakes, one after another. It reads the test passport and an identifier that does not exist, sends one plain HTTP request to check the redirect to HTTPS, and tries to create and change a passport without credentials – requests that must be refused. No DELETE is ever sent, and the body of the change attempt is empty.
Before opening the pull request, an operator can run the same check locally against its own service, read-only:
docker run --rm -v "$PWD/local:/app/local" oydeu/dpp-validator:latest run --service local/service.yaml --output local/result.json --read-only
Reading the results
Results follow the same logic as the DPP Linter: every criterion ends as passed, warning, failed or skipped with a reason. Only criteria with the status active count in “N of M automated checks passed”. A feature a service declares as not implemented is skipped as not implemented and never counts against it.
What the results do not say
The results state how many automated checks a service passed on a given day. They are not a certification and do not establish a presumption of conformity. Checks that need credentials, such as writing a passport, and ratings over several days are not part of the daily run yet.
So far the OwnYourData DPP Service is the only listed service. The criteria are written for any service that follows the standards – the more services take part, the more useful the comparison becomes.
See the current results
The results page shows every listed service, the criteria version it was checked against and each finding.
Further reading
- How to add a DPP service to the daily checksstep by step, including what the run sends
- dpp-validatorsource code, local runs and result format
- dpp-criteriathe criteria and the list of services
Related articles
The DPP criteria catalogue: requirements you can check
How the open repository dpp-criteria turns the ESPR and the harmonised standards into machine-checkable criteria – what a criterion contains, which tool checks it, where each requirement comes from, and how anyone can contribute.
DPP Linter: check any passport against the standards
Enter the link from a product's QR code and see, criterion by criterion, whether its passport can be read, follows the EN 18223 data model, uses valid identifiers and can be checked for integrity. Free, open source, no account.
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.