Los cuatro casos del Test Reporting Tool. El banco llama a la API pública de Todis y muestra lo que devuelve, nada más.
Se usa en las consignas y en el parte. No sale de esta página.
Nombre o fragmento del nombre del emisor, tal como figura en los registros.
Una sesión vive en memoria y muere en cada redespliegue del servicio: durante una semana de interoperabilidad se entrega varias veces al día, y una sesión que pasa a ser desconocida minutos después de su creación viene de ahí, no de la cartera. Un resultado se lee dentro de los 900 segundos siguientes a la creación; pasado ese plazo la sesión se purga y el resultado se pierde.
Este banco está pensado para los proveedores de carteras. Juega los cuatro casos que espera el Test Reporting Tool de Unfold, uno por botón, y muestra lo que el verificador ha hecho con la respuesta de su cartera.
Este banco es un integrador como cualquier otro: llama a la API pública de Todis, POST /verify/sessions o POST /hosted/sessions según el camino elegido, POST /verify/sessions/{id}/response-code al volver de un enlace profundo, y después GET /verify/sessions/{id}, por la red, con el token de una cuenta dedicada. No comparte ni binario ni configuración con el verificador. Todo lo que esta página muestra de una sesión procede de esas respuestas: no añade ninguna verificación ni completa ningún resultado.
Todis no emite credenciales. Su cartera de pruebas la aprovisiona su proveedor.
El emisor que ha cargado la cartera debe estar en nuestros registros de anclas. Es la causa de fallo más frecuente, y no enseña nada sobre la cartera: un participante carga a menudo la suya desde un emisor externo que no está en ninguna lista oficial.
Este nombre no se envía a ninguna parte: solo alimenta las instrucciones y el recordatorio junto a cada resultado. Un resultado nombra al emisor del documento, nunca a la cartera que lo ha presentado, y solo la elección hecha en el selector establece cuál ha jugado.
En el orden del Test Reporting Tool. Cada botón crea su sesión y muestra su código QR; los cuatro pueden vivir a la vez. Bajo cada código QR: lo que contiene la solicitud, el gesto exacto que hay que hacer en el teléfono, lo esperado y el identificador de sesión. El gesto cuenta tanto como el código QR, es lo que evita una tirada jugada por el botón equivocado.
La matriz solo dibuja lo que la API sabe producir, y nada más. Si los registros de anclas de este despliegue no cubren un tipo, sus botones permanecen: es el rechazo de la API el que aparece en la sesión abierta, en lugar de una celda que el banco habría borrado.
Una fila por tipo de atestación que este despliegue sabe solicitar, una columna por vía por la que Todis lleva la solicitud a una cartera. Un clic en una celda crea esa sesión y la abre debajo, con el mismo registro que los cuatro casos. Un guion indica que el protocolo de la columna no lleva ese tipo; un círculo vacío, que la combinación existe y este despliegue no la produce.
Esta elección solo afecta a las dos vías de OpenID4VP por referencia. La página alojada ya impone la respuesta cifrada, y la solicitud del perfil de verificación de edad sale en claro por su especificación.
El diagnóstico publica la presentación tal como la cartera la ha enviado, y con ella identificadores estables de la credencial, que permiten vincular dos sesiones entre sí. No presente una credencial real. El bloque vive el tiempo de la sesión, del lado de la API, y este banco no conserva nada de él.
Las filas vienen del catálogo servido a esta página, las columnas de las vías que la API publica en la creación bajo transport.offered. El esquema de client_id se fija por despliegue, no por sesión.
no aplicable, el protocolo de la columna no lleva este tipo no ofrecido, la API de este despliegue no sabe producirlo