· ReadyStack
Worked example
Real numbers from this tool, line by line.
Seven errors in one EUDI wallet request: that is what this linter returns for the failing sample it ships with, and if you are the identity engineer wiring wallet onboarding at a bank in the Netherlands or Germany, it is the same JSON you are writing this quarter.
An OpenID4VP presentation request is the document your verifier sends to a user's EU Digital Identity Wallet. It is plain JSON: a client_id that says who is asking, a response_mode that says how the answer comes back, a nonce that binds the answer to this question, and a dcql_query that names the attributes you want out of the user's PID. All four fields are now governed by something other than taste.
Regulation (EU) 2024/1183 entered into force on 2024-05-20. Implementing Regulation (EU) 2025/848, which creates the national registers of wallet relying parties, applies from 2026-12-24 — the same date by which every Member State must offer at least one wallet. From 2026-09-21 that is 94 days. Fewer than a third of Member States currently meet the readiness benchmark for that date, and that is what misleads teams: the deadline looks soft because the wallets are late, while the register your request must match is not.
Here are the seven errors the linter reports on the failing sample, each with the line that replaces it.
The client_id is "https://pay.shop-example.eu". A bare URL carries no registration entry. A wallet resolves the relying party from the prefix of client_id, so the value has to read "x509_san_dns:pay.shop-example.eu" or one of the other registered prefixes.
Two credential queries state no purpose. Regulation (EU) 2024/1183 Art. 5b(5) makes the relying party tell the user which attributes it needs and what for, and a DCQL entry without a purpose string leaves the wallet consent screen with nothing to show.
One credential query names no claims at all. A query with no claims array asks for every attribute in the credential. Your registration lists the attributes you may request; an open query does not match it.
The response_mode is "direct_post", which posts the vp_token in the clear. It has to be "direct_post.jwt" so the presentation is encrypted to your key.
There is no nonce, so a captured presentation can be replayed against your endpoint.
The registration window has passed: registration_valid_until is 2026-08-31, which is 21 days before 2026-09-21. That is the rule that makes this linter take a date rather than just a file.
Three more findings come back as warnings. The request asks for birth_date where the PID carries age_equal_or_over flags built for exactly that question. The request is neither signed nor fetched through a request_uri, so nothing ties it to the certificate behind the client_id. And one credential type, "com.example.loyalty.card", is not an EUDI-recognised identifier, so nothing in the trust list can ever satisfy that query.
Nine rules, ten findings, seven of them errors. The passing sample returns zero: the rules fire on the request, not on your formatting.
It reads the request document and nothing else. It does not fetch your request_uri, verify a JWT signature, call a national register, or judge whether your purpose string is truthful.
The free version finishes a whole job: one request file, all nine rules, each finding carrying its article. No key, no watermark, no answer held back. The full version changes the scope instead — every request file in the workspace in one pass, and a dated relying-party evidence report you export and keep. It is $29 once, and one hour of a European contract identity engineer costs more than that.
15 seconds — what it actually does
Questions people ask
What does this actually do?
It reads an OpenID4VP presentation request — the JSON your service sends to a user's EU Digital Identity Wallet — and applies nine rules to it: registered client_id prefix, a purpose on every credential query, named claims instead of whole credentials, age flags over date of birth, encrypted response mode, nonce, signed request, live registration window, and known credential types.
Who is it for?
Identity, payments and onboarding engineers at EU banks, marketplaces and public services that have to accept the wallet. If you are writing the verifier side of OpenID4VP against the EUDI Architecture and Reference Framework, and your relying-party registration is being prepared for the national register, this is your file.
Why will a free tool not do this?
A JSON schema validator says your request is valid JSON. A general linter has never read Implementing Regulation (EU) 2025/848. Chat assistants trained before the 2025 implementing acts still suggest presentation_definition with a bare URL client_id, which is exactly the pattern rule one rejects. The rules here carry the article they come from.
What is free and what is paid?
Free finishes a real job: lint one request file, in the editor or on the web page, and read all nine rules with the article behind each finding. The full version changes the scope — it scans every request file in the workspace in one pass and exports a dated relying-party evidence report you keep and hand on.
What would this cost done by hand?
One hour of a European contract identity engineer costs more than the full version does once. Reading Implementing Regulation (EU) 2025/848 and the Architecture and Reference Framework against one request set takes longer than an hour the first time, and the reading has to happen again each time the request changes.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. EUDI Wallet Request Lint (OpenID4VP) checks the file you open against 9 rules, each naming its legal or official basis, from a rule set dated 2026-09-21, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.