¿Qué parte de la orquestación de verificación debe gestionar tu aplicación?
Un equipo B2B pequeño integra un onboarding de identidad alojado y descubre que su manejador mezcla tres cosas: lo que dijo el proveedor, cómo llegó ese mensaje y si el negocio debe permitir que el usuario actúe. Cuando un callback dice Approved, el manejador concede acceso de vendedor en el mismo paso. Este artículo propone una pequeña tabla de decisión que separa esas responsabilidades y la contrasta con el fixture sintético probado. Tu decisión es si ese límite, en el que tu aplicación es dueña del permiso de negocio, encaja con tu tarea de onboarding lo bastante como para probar una integración en sandbox.
curl https://gridzen.ai/console/api/quickstart/trial \
-H 'Content-Type: application/json' \
-d '{"task": "identity_onboarding", "scenario": "success"}'El problema: un estado, tres preguntas
Un estado como Approved responde a una pregunta limitada sobre la evidencia del proveedor. No dice si el mensaje es auténtico, si pertenece a este tenant y sujeto, ni si está dentro de su plazo. Dice todavía menos sobre si tus reglas permiten la acción ahora. Según la guía Bring Your Own Provider, el cliente conserva su relación con el proveedor y autoriza un alcance de integración definido. GridZen usa un adaptador y una ruta aprobados para normalizar la evidencia. La alfa actual no acepta claves arbitrarias de proveedor en el navegador ni en el cuerpo de la solicitud. Tener una API pública o una cuenta disponible no prueba que se tenga permiso para vender los datos resultantes.
Tabla de decisión propuesta
Esta tabla es un diseño de aplicación propuesto, no un comportamiento implementado. Evidencia del proveedor. La gestiona el proveedor, bajo tu propia cuenta y contrato. Tú compruebas que el producto, el país, el evento y los identificadores permitidos coinciden con el alcance que registraste. Entrega. La gestiona la capa de orquestación. En la ruta de producción de GridZen, esto incluye verificar notificaciones firmadas, volver a consultar las decisiones autoritativas, controlar los plazos y deduplicar eventos. Permiso de negocio. Lo gestiona tu aplicación. Necesita una política explícita, una versión de política, la vinculación a tenant y sujeto, y una decisión tomada con evidencia vigente. La regla que se deriva: ninguna fila puede ascenderse sola a la siguiente. Approved no es un permiso incondicional, y la acción de cliente de extremo a extremo en vivo sigue sin verificarse.
Escenario hipotético y salidas esperadas del fixture
Hipotéticamente, un equipo incorpora vendedores y ejecuta en local el fixture descargable con SQLite. Todos los identificadores deben empezar por fixture-. Crear: la llamada devuelve mode synthetic_fixture, state simulated, session fixture-session y un hosted_link en example.invalid. También devuelve link_executable false y next send_real_provider_link_only_after_authorization. Un evento fixture-approved con policy true: la sesión devuelve status approved, deadline 60, permission_granted true, grant_count 1, live_permission_changed false, policy_version 1 y allow_action true. Reenviar el mismo evento: la salida es idéntica y grant_count sigue en 1. Una corrección posterior a Declined: status pasa a declined y permission_granted pasa a false. grant_count sigue en 1 como historial. En otra sesión que sigue pendiente después de su plazo, recover con now 61 devuelve status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh y provider_polled false. Los campos de permiso son registros locales del fixture, no un permiso de negocio real.
Manejo de fallos que conserva tu aplicación
El fixture devuelve errores explícitos en lugar de adivinar. Un evento para una sesión desconocida devuelve BINDING_MISMATCH. Leer una sesión desconocida devuelve SESSION_NOT_FOUND. Cualquier source distinto de fixture_callback, o cualquier mode distinto de synthetic_fixture, lanza PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. El fixture solo acepta callbacks sintéticos y nunca verifica firmas reales. Las llamadas decide y revise_policy exigen una versión de política entera explícita y un booleano explícito. Una versión obsoleta lanza STALE_POLICY_VERSION. Decidir sin evidencia aprobada vigente dentro del plazo lanza CURRENT_EVIDENCE_AND_EXPLICIT_APPROVAL_REQUIRED. La llamada handoff devuelve verified false y next_action read_current_evidence_and_policy_before_explicit_decision. Recover hace expirar la sesión en local; no consulta al proveedor. Refrescar desde el proveedor es tarea de tu ruta autorizada.
Qué está implementado y qué no
Implementado en el fixture: persistencia en SQLite, vinculación a tenant y sujeto, deduplicación de eventos, revocación mediante Declined, expiración local y comprobación de políticas versionadas. Evidenciado en la prueba real de identidad alojada de GridZen: creación real de sesiones, notificaciones firmadas, lecturas autoritativas y expiración. Esa prueba es para empresas elegibles de EE. UU. y GB que acepten un anexo de Didit separado. Está limitada a 2 solicitudes por dominio empresarial verificado y 10 solicitudes compartidas de por vida, y a módulos gratuitos confirmados, sin cobros a clientes. Sin verificar: un usuario real recién aprobado y cualquier acción de negocio del cliente. Ten en cuenta también que la prueba HTTP anónima de tres escenarios es un artefacto distinto del ejemplo descargable de cuatro ramas. Antes de cualquier uso en vivo, la guía exige aprobar la retención, el borrado, el registro de accesos, la titularidad de la política y la recuperación operativa.
Lista de aceptación
- Registra el producto del proveedor, el país, el evento, los identificadores permitidos, el titular de la cuenta, el manejo de credenciales y el alcance de la evidencia posterior. - Confirma que se permite el procesamiento en servidor en nombre del cliente. - Ejecuta el fixture y comprueba que coincide con las salidas anteriores, incluido grant_count 1 en el duplicado y provider_polled false. - Prueba las rutas de fallo: entradas faltantes, errores upstream, ID desconocidos y política obsoleta. - Revisa las trazas en busca de identificadores en bruto. - Mantén el permiso de negocio en tus propias reglas, con decisiones explícitas y versionadas. - Decide si una solicitud de sandbox guardada encaja con tu tarea. Solo entonces plantéate una prueba real.
Ejecutar el ejemplo sintético comprobado
Descargue y extraiga https://gridzen.ai/downloads/verification-delivery.zip, entre en verification_delivery y ejecute con Python 3.10+. El ejemplo local no hace llamadas de red. Use una base nueva para otra prueba de identidad.
python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqliteFuentes y alcance
https://gridzen.ai/guides/bring-your-own-provider/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.
Probar por separado tres resultados del sandbox Crear una cuenta para continuar la integración
Una descarga no demuestra una ejecución correcta. Los ejemplos locales y el sandbox en línea se prueban por separado.