Les quatre cas du Test Reporting Tool. Le banc appelle l'API publique de Todis et affiche ce qu'elle rend, rien d'autre.
Repris dans les consignes et le relevé. Ne quitte pas cette page.
Nom ou fragment de nom de l'émetteur, tel qu'il figure dans les registres.
Une session vit en mémoire et meurt à tout redéploiement du service : pendant une semaine d'interopérabilité, il est livré plusieurs fois par jour, et une session devenue inconnue quelques minutes après sa création vient de là, pas du portefeuille. Un résultat se lit dans les 900 secondes qui suivent la création ; au delà la session est purgée et le résultat perdu.
Ce banc s'adresse aux fournisseurs de portefeuilles. Il joue les quatre cas qu'attend le Test Reporting Tool d'Unfold, un par bouton, et montre ce que le vérifieur a fait de la réponse de votre portefeuille.
Ce banc est un intégrateur comme un autre : il appelle l'API publique de Todis, POST /verify/sessions ou POST /hosted/sessions selon le chemin choisi, POST /verify/sessions/{id}/response-code au retour d'un lien profond, puis GET /verify/sessions/{id}, par le réseau, avec le jeton d'un compte dédié. Il ne partage ni binaire ni configuration avec le vérifieur. Tout ce que cette page affiche d'une session vient de ces réponses : elle n'ajoute aucune vérification et ne complète aucun résultat.
Todis n'émet pas d'attestation. Votre portefeuille de test est approvisionné par son fournisseur.
L'émetteur qui a chargé le portefeuille doit être dans nos registres d'ancres. C'est la cause d'échec la plus fréquente, et elle n'apprend rien sur le portefeuille : un participant charge souvent le sien depuis un émetteur tiers qui n'est dans aucune liste officielle.
Ce nom ne part nulle part : il ne sert qu'aux consignes et au rappel à côté de chaque résultat. Un résultat nomme l'émetteur du document, jamais le portefeuille qui l'a présenté, et seul le choix fait dans le sélecteur établit lequel a joué.
Dans l'ordre du Test Reporting Tool. Chaque bouton crée sa session et affiche son QR code ; les quatre peuvent vivre en même temps. Sous chaque QR code : ce que la requête contient, le geste exact à faire sur le téléphone, l'attendu et l'identifiant de session. Le geste compte autant que le QR code, c'est lui qui évite un tir joué par le mauvais bouton.
La matrice ne dessine que ce que l'API sait produire, et rien de plus. Si les registres d'ancres de ce déploiement ne couvrent pas un type, ses boutons restent : c'est le refus de l'API qui s'affiche dans la session ouverte, plutôt qu'une cellule que le banc aurait effacée.
Une ligne par type d'attestation que ce déploiement sait demander, une colonne par chemin par lequel Todis porte la requête à un portefeuille. Un clic sur une cellule crée cette session et l'ouvre dessous, avec le même relevé que les quatre cas. Un tiret dit que le protocole de la colonne ne porte pas ce type ; un cercle vide, que la combinaison existe et que ce déploiement ne la produit pas.
Ce choix ne porte que sur les deux chemins d'OpenID4VP par référence. La page hébergée impose déjà la réponse chiffrée, et la requête du profil de vérification d'âge part en clair par sa spécification.
Le diagnostic publie la présentation telle que le portefeuille l'a envoyée, et avec elle des identifiants stables du credential, qui permettent de relier deux sessions entre elles. Ne présentez pas un credential réel. Le bloc vit le temps de la session, côté API, et ce banc n'en conserve rien.
Les lignes viennent du catalogue servi à cette page, les colonnes des chemins que l'API publie à la création sous transport.offered. Le schéma de client_id est fixé par déploiement, pas par session.
non applicable, le protocole de la colonne ne porte pas ce type non offert, l'API de ce déploiement ne sait pas le produire