How the
board is made
Every verdict on the board comes from one comparison, applied the same way to every row. This page states what was measured, how a verdict is reached, which rules it is measured against, and where the data can be downloaded and cited.
What we measured
Unit of analysis is the certificate. The board rolls up worst-signal-wins per relying party.
For every relying party in the public EUDI sandbox relying-party registry, Augenmaß reads the request scope the party is registered for, reads the purpose that same party declares, and marks each case where the registered scope is wider than the declared purpose needs.
These are the figures the board itself renders, read from the snapshot inlined in the page. The board shows the sampled view (93 certificates); the source dataset holds the full crawl (428 certificates across the same 26 relying parties), which is why the two certificate counts differ. Registry-audit mode makes no live wallet request.
How a verdict is reached
Five classes, fixed by the interface contract. A relying party carries the worst class any of its certificates raised.
Honest scope
- Coverage Relying parties visible through the Catalog of Attestations, enriched with their published registration certificates, plus local fixtures for deterministic demo coverage. This does not claim to cover every relying party in the registry.
- Sandbox The source is the public EUDI sandbox registry API, not a production deployment.
- Sampling High-volume relying parties are sampled at up to 15 certificates each, so a single tester cannot dominate the registry-wide totals. Every finding is kept in the sample; the full crawl stays in the source dataset.
- Fixtures A few rows are local fixtures that exist to keep the malformed, revoked and coverage-gap cases visible. They are labelled by provenance on the board and never presented as live registry findings.
- No live request Nothing is disclosed and no hard signal is raised, so “disclosed” is never presented as a finding.
The three rules
Every verdict is weighed against the legal basis for data minimisation.
A relying party may ask only for what its stated use actually calls for.
Whatever is collected has to stay limited to what the purpose needs.
The wallet itself checks the request against the registration certificate and warns the user when it reaches past it.
The archived snapshots of 2026-06-25 and 2026-07-08 carry the locator RPRC_07 in their legal_basis block; the intended locator is RPRC_21, the requirement that a Wallet Unit verifies requested attributes against the registration certificate.* Those files stay byte-identical to what was published, so existing citations keep resolving to the bytes they referenced, while the current audit.json and the generator that produces it are corrected.
Download the data
The full crawl behind the board, published as a citable dataset with a fixed date in its filename.
The JSON is the source of record: every relying party, every certificate, every verdict, with the crawl metadata that produced it. The CSV is the per-relying-party roll-up. Both are published from the Augenmaß repository under the Apache License 2.0, and both are left byte-identical once dated, so a citation stays stable. What is known to be wrong in a dated snapshot is recorded separately in CORRECTIONS.md.