What should an Irish wallet demo prove?
A good demonstration should leave you with evidence you can describe and questions you can act on. Use this checklist when a supplier says it has tested a gateway or verifier with Ireland’s Government Digital Wallet.
Start with a simple distinction
“It worked in a test” is a useful statement about a particular setup. “It is ready for our customers” requires additional evidence about availability, security, privacy, support and your own service. This checklist is for evaluating a demonstration, not certifying a product.
1. Name the environment
Ask the presenter to identify the wallet, version, device, credential type and verifier configuration. Record the demonstration date and whether it uses a sandbox, official pilot or production service. Establish whether the data is synthetic, belongs to a consenting participant or has another approved basis for use.
Do not ask the presenter to reveal identity documents, private keys, access tokens or another person's information. A demonstration should be explainable using appropriately limited evidence. If a screen contains personal information, agree what can be recorded before taking a screenshot.
2. Follow the customer's journey
Begin at the page a real customer would see. Ask why the check is needed, which information is requested and what the customer is told before proceeding. Observe the transition from your service to the wallet and back. Check whether the requesting organisation is understandable at each step.
Where supported, ask to see both a desktop-to-phone flow and a same-phone flow. A QR code that works beautifully on a presentation screen may not solve the experience of someone opening the service on their only phone. Ask what is available today and record any unsupported journey as a gap.
3. Compare the request with the result
Write down the intended business question before the demonstration. Then compare it with the attributes requested and returned. If the purpose is an age-threshold decision, ask whether the service receives only the threshold result or additional identity details. Establish what is kept after the interaction and why.
Ireland's official test verifier illustrates different verification scenarios. It is a useful public reference for discussing the interaction. It does not establish that a supplier's separate product follows the same data path or has the same conditions of use.
4. Make “verified” specific
Ask the presenter to describe the checks behind a positive result in ordinary language. Which issuer is trusted? Which credential and presentation checks were made? How was the response connected to this request? What result would your application receive if any required check could not be completed?
Ask which part is demonstrated by the running software and which part is a statement about intended behaviour. If detailed security evidence requires a separate review, record that honestly. A product walkthrough is not an independent penetration test, certification audit or legal opinion.
5. Show the unhappy paths
| Scenario | What to observe |
|---|---|
| The user cancels | Clear return to the service without a misleading success |
| The request expires | A safe retry that preserves appropriate progress |
| The credential is unsupported | An understandable explanation and an alternative |
| A dependency is unavailable | A controlled failure with an operational owner |
| The user has no compatible wallet | A usable route that does not leave them stranded |
Agree these tests with the supplier in its approved demonstration environment. If they cannot be shown during the call, ask for a follow-up rather than inventing a conclusion. The omission may reflect time, environment limitations or unfinished work; the evidence should distinguish those possibilities.
6. List the gap to production
Ask which credentials, wallet versions and customers the supplier will support under contract. Discuss hosting, data processing, registration dependencies, service levels, incident reporting and change management. Find out which responsibilities remain with your organisation and who will support a customer when the flow fails.
Keep an explicit list of items not yet complete. A planned capability, an integration being tested and a contracted production capability belong in different columns. This is particularly important while Ireland's official programme describes testing and development.
Leave with a one-page record
- Observed: the exact journey completed during the demonstration.
- Supplier-reported: capabilities discussed but not shown.
- Unresolved: evidence, support or implementation questions still open.
- Next action: an owner, deliverable and review date for each material gap.
Summarise the result without promoting it into a stronger claim. For example: “The supplier demonstrated a test age-threshold presentation on the named wallet and device. We have not yet assessed production support or security evidence.” This is more useful to the next decision-maker than “wallet integration complete”.
If the evidence supports further work, use our pilot plan to define a bounded evaluation. If you are still clarifying the product's role, read wallets, gateways and verifiers first. A constructive supplier conversation does not require an endorsement, a paid partnership or a promise to publish.
In this topic: EUDI Wallet readiness
What should an Irish relying party prepare now?
View all 12 pages in this topic
- EU country tracker
- Country evidence methodology
- Wallet gateways and verifiers
- Irish wallet demo checklist
- Readiness for Irish organisations
- Issuer, wallet and relying-party roles
- Relying-party registration
- PID, EAA and QEAA credentials
- Protocols and formats
- Credential verification flow
- Conformance and certification
- Verifier UX and fallback
Keep up with the Irish evidence
Independent briefings on wallets, identity verification and age assurance.
Join the business briefing