The four cases of the Test Reporting Tool. The bench calls the Todis public API and shows what it returns, nothing else.
Used in the instructions and the read-out. Never leaves this page.
Name or part of the name of the issuer, as it appears in the registries.
A session lives in memory and dies on every redeployment of the service: during an interoperability week it is shipped several times a day, and a session that became unknown minutes after its creation comes from that, not from the wallet. A result must be read within the 900 seconds following the creation; past that the session is purged and the result lost.
This bench is meant for wallet providers. It plays the four cases the Unfold Test Reporting Tool expects, one per button, and shows what the verifier did with your wallet's response.
This bench is an integrator like any other: it calls the Todis public API, POST /verify/sessions or POST /hosted/sessions depending on the chosen path, POST /verify/sessions/{id}/response-code when a deep link returns, then GET /verify/sessions/{id}, over the network, with the token of a dedicated account. It shares neither binary nor configuration with the verifier. Everything this page shows about a session comes from those responses: it adds no verification and completes no result.
Todis does not issue credentials. Your test wallet is provisioned by its provider.
The issuer that loaded the wallet must be in our trust registries. This is the most frequent cause of failure, and it teaches nothing about the wallet: a participant often loads theirs from a third-party issuer that is in no official list.
This name goes nowhere: it only feeds the instructions and the reminder next to each result. A result names the issuer of the document, never the wallet that presented it, and only the choice made in the chooser establishes which one played.
In the order of the Test Reporting Tool. Each button creates its own session and shows its QR code; the four can live at the same time. Under each QR code: what the request contains, the exact gesture to perform on the phone, what to expect, and the session identifier. The gesture matters as much as the QR code, it is what prevents a run played through the wrong button.
The matrix draws only what the API can produce, and nothing more. If the trust registries of this deployment do not cover a type, its buttons stay: the API refusal appears in the opened session, rather than in a cell the bench would have erased.
One row per credential type this deployment can request, one column per path Todis carries the request to a wallet over. Clicking a cell creates that session and opens it below, with the same read-out as the four cases. A dash means the protocol of the column does not carry that type; an empty circle, that the combination exists and this deployment does not produce it.
This choice only bears on the two OpenID4VP paths by reference. The hosted page already imposes the encrypted response, and the age verification profile request goes in the clear by its specification.
Diagnostics publish the presentation as the wallet sent it, and with it stable identifiers of the credential, which make two sessions linkable to each other. Do not present a real credential. The block lives for the lifetime of the session, on the API side, and this bench keeps nothing of it.
Rows come from the catalogue served to this page, columns from the request paths the API publishes at creation under transport.offered. The client_id scheme is set per deployment, not per session.
not applicable, the protocol of the column does not carry this type not offered, the API of this deployment cannot produce it