This service is listed as a Wallet Relying Party in the EU reference registry that ships with the European Digital Identity Wallet architecture (ARF 3.0). Below is the live registration record, the JAR-signing certificate we present to wallets, and a link that lets you verify the listing directly on the EU registry with no CodeB systems in the loop.
Server-side fetch of registry.serviceproviders.eudiw.dev/wrp, filtered to this tenant. Cached 5 minutes.
The registry issued a PKCS#12 to this tenant during Wallet Relying Party enrolment. Every OpenID for Verifiable Presentations JAR we sign against a wallet carries this certificate in its x5c header. The public half is below.
Prove the round-trip works with a credential we did not issue. Get a PID from dev.issuer.eudiw.dev using the EU Reference Wallet (Android / iOS), then run the interoperability self-test below. Our verifier accepts the third-party PID, decodes selective disclosures, verifies the KB-JWT holder binding, and shows a per-check HAIP report you can screenshot.
Same source: registry.serviceproviders.eudiw.dev/wrp. We hide test / demo / fake entries and dead-domain records (policyURI on an unreachable host) so the list reflects real, contactable Wallet Relying Parties only. Filter is a heuristic pass (tradeName / URL substrings) plus an explicit blacklist maintained by our operators.
Wallet Relying Party (WRP). The European Digital Identity Wallet architecture treats every verifier — the party that asks a wallet to present a credential — as a Wallet Relying Party. The EU Reference Wallet ships with an inbuilt list of registered Wallet Relying Parties and will show your users which entitlements each one has claimed before they consent to share attributes.
Trust anchor. The WRP entry above is what the EU Reference Wallet consults when it validates an OpenID for Verifiable Presentations request from this service. The signing certificate we display in the second card is the same certificate the wallet checks the JAR signature against. If either changes, wallets stop trusting the request. There is no shortcut, no self-declaration, and no honour system.
Verify without our help. Click Verify yourself on the EU registry to open registry.serviceproviders.eudiw.dev/wrp directly. The list is a base64-encoded JSON payload — the same one this page fetches on your behalf — and you can decode it locally with any base64 tool. The tenant tradeName, entitlements, supported formats and privacy policy URL should match what you see here.
Registered honestly. The entitlements list — Service_Provider, PID_Provider, Non_Q_EAA_Provider — matches what we actually ship: OID4VP verification, PID issuance, and non-qualified EAA issuance (EHIC, mVRC, mDL). We are not a qualified trust service provider; the entitlement URIs make that explicit. Supported credential formats dc+sd-jwt, mso_mdoc, jwt_vc are declared on the registry record; each one has a live issuer + verifier path in this deployment.
Independent proof surfaces. Alongside the reference registry entry, this deployment publishes an OpenID Federation entity statement at /.well-known/openid-federation, a DID document at /.well-known/did.json, an EU Trusted List at /.well-known/trust-list.xml, a Wallet Provider attestation at /.well-known/wallet-provider.jwt, and a machine-readable relying-party metadata document at /.well-known/eudi-relying-party.json. Third parties can pick whichever trust surface they prefer.
Why our peer list is shorter than the raw registry. The reference registry at registry.serviceproviders.eudiw.dev/wrp is a permissionless developer sandbox: any team can POST a registration and the entry persists until manually removed. To make the peer view useful we apply reachability and validity filters before rendering the table above: (a) entries whose policyURI uses an IANA-reserved documentation TLD (per RFC 2606 §3), (b) entries whose policyURI resolves to a loopback or private address, (c) entries with a missing or non-http(s) policyURI, (d) entries whose tradeName is empty, and (e) entries whose hostname does not respond. We deliberately do not enumerate the individual entries we filter — the raw registry is public and anyone can diff our peer list against the source themselves. The raw and filtered counts are both shown in the "Live proof" card above so the delta is visible, and both counts refresh whenever a WRP joins or leaves the registry.
Nothing on this page is a claim. Everything is either a live fetch from the EU reference registry, or a public field of the WRP certificate the registry issued. If the registry drops us or a certificate expires, the cards above turn empty automatically — there is nothing static or cached for us to bluff about.
Contact for verification. The tenant Data Protection Officer contact is published in the DPIA. The Records of Processing Activities are at /ropa.html. The Supervisory Authority listed in our registry record is the Information and Data Protection Commissioner of Malta.