Registered Wallet Relying Party on the European Digital Identity Wallet reference registry
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.
Registration status across registries
A Wallet Relying Party can register on any number of EUDIW Registrars — each Registrar publishes its own trust anchor + issues its own certificates. We hold registrations independently on each. If your wallet ships one anchor bundle and not the other, this table tells you which side of the trust boundary we are visible on today.
Data sources: registry.serviceproviders.eudiw.dev/wrp and sandbox.eudi-wallet.org/api/wrps. Match is a case-insensitive substring lookup on our tradeName ("aloaha" / "codeb") — if either registry lists us under a different name, edit _ourNameHints in this page.
Live proof from the EU reference registry
Server-side fetch of registry.serviceproviders.eudiw.dev/wrp, filtered to this tenant. Cached 5 minutes.
Registry-issued JAR-signing certificate
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.
Verify with an EU-issued PID
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.
What a successful presentation looks like
Screenshot from the EU Reference Wallet immediately after presenting a PID (SD-JWT VC) to this verifier. The green verified badge next to CodeB / Aloaha Limited is drawn by the wallet from the tradeName + certificate the EU registry holds against our entry — a substring of the family name is redacted for privacy.
phone.codeb.io tenant.Other verified Wallet Relying Parties on the same registry
Two live sources, merged: registry.serviceproviders.eudiw.dev/wrp (EU reference registry — unmarked rows) and sandbox.eudi-wallet.org/api/wrps (German national Sandbox Registrar — rows tagged DE registrar). 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.
What this actually means
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, (e) entries whose hostname does not respond, and (f) entries with no declared providesAttestations (nothing to actually verify against). 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.
For journalists, auditors, DPOs
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.