A AUGENMASS
← The audit EUDI WALLET HACKATHON 2026 · DEVELOPER TOOLS TRACK · COMMUNITY-PREIS
METHOD AND SOURCES

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.

01 · THE QUESTION

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.

LEAD 7
Soft over-asks
Registered scope exceeds the stated purpose. The headline.
RP 26
Relying parties
Inspected in this audit run.
CERT 93
Certificates on the board
Sampled at most 15 per relying party; every finding kept.
FULL 428
Certificates in the record
The full crawl, kept in the source dataset.
GAP 3
Coverage gaps
Listed, no published certificate. Not a pass.
FLAG 2
Category flags
Secondary heuristic. A lead, not the headline.
X 14
Revoked
Certificate revoked. No verdict computed.
SNAP 2026-07-07
Snapshot
Crawled 22:41 UTC, published as the dated snapshot 2026-07-08.

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.

02 · THE SIGNAL CLASSES

How a verdict is reached

Five classes, fixed by the interface contract. A relying party carries the worst class any of its certificates raised.

Soft over-ask signal_class = soft
The registered scope is wider than the declared purpose needs. This is the headline signal and the only over-ask class this audit produces. Example A relying party declares “Identity verification for login using EUDI Wallet PID” and is registered for attributes past what that purpose calls for.
Category mismatch signal_class = heuristic
The category of a requested credential does not match the category of the declared purpose. Labelled as a secondary heuristic, never the headline. Example A purpose categorised finance (“Assess eligibility for a consumer loan (KYC)”) paired with a requested credential from another category.
Coverage gap signal_class = coverage
Nothing could be weighed: the relying party is listed in the Catalog of Attestations but publishes no registration certificate, or the certificate is malformed. A gap is a gap, not a clean bill of health. Example A catalog entry with no published certificate, so no scope and no purpose exist to compare.
Beyond registration signal_class = hard
Attributes requested beyond what the registration certificate covers. The class exists in the contract, and this audit never produces it: the request is synthesised from the registered scope, so every requested key is in scope by construction and the count stays at zero. Example None here. Raising it needs a live presentation request, which registry-audit mode never makes.
No signal signal_class = none
Either the scope fits the declared purpose (proportionate), or no verdict could be computed at all: the purpose is not stated, or the certificate is revoked. Example A revoked certificate is left without a verdict rather than counted as clean.

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.
03 · THE MEASURE

The three rules

Every verdict is weighed against the legal basis for data minimisation.

eIDAS Regulation (EU) 2024/1183
Art. 5b(3)
Relying parties shall not request users to provide data other than that indicated for their intended use.

A relying party may ask only for what its stated use actually calls for.

GDPR (EU) 2016/679
Art. 5(1)(c)
Personal data shall be adequate, relevant and limited to what is necessary (data minimisation).

Whatever is collected has to stay limited to what the purpose needs.

EUDI ARF, registration certificate
RPRC_21
The wallet verifies requested attributes are within the registration certificate and notifies the user otherwise.

The wallet itself checks the request against the registration certificate and warns the user when it reaches past it.

Correction notice

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.

04 · THE RECORD

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.