EUDI infrastructure
Wallet-relying party access certificate (WRPAC)
A wallet relying party access certificate, or WRPAC, is the certificate that proves to an EU Digital Identity Wallet that you are a registered relying party. Without one the wallet refuses your request outright, before any data is shared and before the user is even asked.
Also called: WRPAC, access certificate, relying party access certificate, reader authentication
At a glance
- Full name
- Wallet-relying party access certificate
- Proves
- That the requester is a registered relying party
- Travels in
- The x5c header of the signed OpenID4VP request object
- Bound to
- A DNS name that must match the client_id (x509_san_dns)
- Without one
- The wallet refuses before any data is released, in every environment
- Tessio status
- Applied 5 August 2026, not yet held
What it actually does
A wallet does not hand data to whoever asks for it. Before it shows the user a consent screen, it authenticates the requester, a step the specifications call reader authentication. Your presentation request is signed, the signing chain travels with it in the x5c header of the request object, and the wallet checks that chain against a published list of access certificate providers it trusts.
The certificate also pins the request to a hostname. The client_id you send takes the form x509_san_dns:yourhost, and that host has to appear in the certificate as a subject alternative name. So the certificate does not only say "a registered relying party is asking", it says "this specific host is asking". That is what stops someone lifting your request and replaying it from their own domain.
What happens without one
Nothing degrades gracefully, which is the useful thing to know. We ran this against the EU reference wallet on 5 August 2026. It fetched our signed request, parsed it, reached its reader-authentication decision and refused, logging InvalidJarJwt with the cause "Untrusted x5c". What the user saw was: "Presentation blocked. This presentation request has been blocked because the relying party could not be verified by your Wallet."
It is worth being precise about the consequence, because it is usually described as a production concern. It is not. No data is released, so no check can complete against a real wallet in any environment, including testing. We recorded it as a production-only gate ourselves at first, and that was wrong.
Who issues one
Access certificates come from providers that the wallet ecosystem publishes as a signed, machine readable list, which is how a wallet decides whose certificates to trust. When we read the list the EU reference wallet is configured with, on 5 August 2026, it carried seven pilot providers, identified by country: EU, CZ, EE, LU, NL, PT and UT. UT is Utopia, the Commission's fictional test member state, which is the pilot lane.
The practical consequence matters more than the list itself. You do not have to wait for your own country's register to open before you can develop, because a pilot certificate from the Commission's test provider is already trusted by the reference wallet today. Sweden, for one, was not on that list.
Where the process actually is
There is no published self-serve route to request one. When we went looking in August 2026, what existed was the Commission's wallet support mailbox and the team that operates the age-verification issuer. We applied on 5 August 2026 and do not hold a certificate yet.
Secondary sources report that the implementing regulation on registering wallet relying parties applies from 24 December 2026, which would put national registers in place around then. We have not confirmed that against the primary text, and dates in this area have moved before, so treat it as a lead rather than something to plan a launch around.
Check one yourself
Reading about it only gets you so far. These are free validators in Tessio Labs, no signup, and nothing you paste is stored.
Why it matters
If you're comparing age verification vendors for the EU wallet, this is the question to put to all of them: do you hold an access certificate, and who issued it. Every relying party in Europe is behind this same gate, incumbents included, so a vendor claiming live production wallet verification today is worth a second look.
It doesn't block your integration work, though. The certificate changes which key signs the request, not the shape of what you build, so the integration you write against a sandbox now is the one you go live with.
Frequently asked
Is a WRPAC the same as my TLS certificate?
No, and you need both. Your TLS certificate proves your server to a browser and comes from a public web CA. An access certificate proves you to a wallet and comes from a provider the wallet ecosystem trusts. Different chain, different issuer, different question being answered.
Can I build and test without one?
Against a sandbox, yes, and that's most of the integration work. Against a real wallet, no. The wallet refuses the request before any data is released, so there is no partial or degraded mode to test in.
Do I need my own certificate, or does my verification vendor cover me?
Technically the certificate binds to the host that sends the request, so with a hosted verifier that's your provider's host and their certificate. Whether the regulation also expects you to be registered as a relying party in your own right is a separate question, it may differ by member state, and it's one for your counsel rather than for a glossary.
Why does the wallet check this at all?
Because the alternative is a wallet that releases identity data to anyone who asks nicely. Reader authentication is what makes "the user consented" mean something: the consent screen can name a party that has been registered and can be held to it.
Primary sources
- The WRPAC provider list the EU reference wallet reads
- Regulation (EU) 2024/1183, the EUDI framework
- OpenID for Verifiable Presentations 1.0
- EU Digital Identity Wallet reference implementation
This is a plain language explanation, not legal advice. Specifications and dates in this area move, so check anything you are going to rely on against the primary sources.
Keep reading
Age verification API
Or skip the theory and build against it
Tessio proves someone is over 18 from their EU Digital Identity Wallet and stores no personal data. Access is invite only while we onboard design partners. Tell us what you're building.