DIGITAL IDENTITY /
A wallet check inside the conversation.
The krnali eudi message verifier plugin connects a single-use message link to an EUDI test-wallet presentation. The source is public. The next acceptance step is a successful presentation from an installed phone wallet.
The problem we are testing
A conversation sometimes needs a small, specific check. A staff member has a name they expect and wants the other person to confirm it from a credential in their wallet. Asking for a photograph of a document brings much more information into the conversation than that check needs.
Our first request asks for given name and family name. The person reviews those attributes in their wallet, chooses whether to share them, and the result comes back to the operator who created the request.
The link is the handoff. The credential presentation and its validation are the check. Putting a URL in a message is only useful here if the system behind it actually verifies what comes back.
How the flow works
- Create a request. Give it a customer label, an optional expected name and a case reference. Start with copy-link; messaging adapters need their own provider configuration.
- Open the wallet. The recipient opens the link on their phone, or scans its wallet QR from another screen. The link can be started once and expires.
- Approve the presentation. The wallet shows the requester and the two requested name attributes. The holder can approve or decline.
- Read the result. The verifier validates the presentation. The console shows the returned name and whether it matches the expected name, then clears the claim values after their retention period.
What is connected today
The hosted application creates real OpenID4VP requests through the official EUDI reference verifier. It uses signed test credentials issued through the EUDI sandbox. The wallet will identify the requester as Web Verifier (PROD), because that service performs the verification.
That identity is disclosed in the app. A krnali-named requester needs its own relying-party registration. The current hosted registration covers our name check; the over-18 option stays disabled until the requested age attributes are covered.
This is an external sandbox data flow. The test presentation goes to the EUDI service and its result returns to our application. Use fictional test identities. The customer-hosted data boundary of krnali Ops is a separate product promise.
Using an iPhone
The setup page now includes a Trinsic-distributed EUDI reference wallet for TestFlight. Its documented issuance route is Add my Digital ID → issuer.eudiw.dev → PID Combined → FormEU. Choose fictional details and finish issuance.
Compatibility remains unconfirmed. Trinsic configures its build to trust its certificates. Getting a FormEU credential does not establish that this build accepts our exact verifier request. We need to complete that presentation before recommending it as a tested combination. The provider's instructions and the official iOS build alternative are linked from the setup page.
What we have proved, and what comes next
Automated checks have exercised signed request creation, QR generation, rejection of an invalid credential, and a real decline returning to the console. The Go race tests, static checks and public repository CI have passed.
The remaining acceptance test is a holder-approved presentation from a phone containing an issuer-signed PID. We then need to repeat it with a wrong expected name and check the actual mismatch result. That rehearsal comes before a demonstration video.
A successful credential check also does not prove that the wallet holder controls the chat account that received the link. A forwarded link remains usable by its first recipient. Expected-name comparison adds a check; it does not bind the wallet to a messaging account.
Read it, run it, test it
The public repository includes the Go service, browser UI, messaging adapters, tests, container builds and a README with the current limits. It runs as a standalone HTTP service. The live mode requires configured trust material and operator authentication; the separate local demo uses clearly labelled synthetic outcomes.
Start with the README or the phone setup guide. The hosted console requires an authorised operator sign-in. The setup guide and source can be read without that access.