Integración del verificador
Una integración de verificador formula una pregunta de confianza, solicita evidencia proporcional, valida la respuesta y devuelve un resultado explicable de política a la institución usuaria. No debe recopilar un perfil completo solo porque técnicamente haya más datos disponibles.
Definir la finalidad
El verificador debe documentar:
- transacción y parte usuaria;
- decisión que necesita evidencia;
- tipos de credenciales y emisores aceptables;
- claims mínimos o afirmaciones derivadas;
- requisitos de assurance, vigencia y holder binding;
- comportamiento de estado y dependencias;
- requisitos de retención y comprobantes;
- vías de revisión humana o apelación;
- responsable de la decisión institucional final.
La solicitud debe ser explicable para el titular y proporcional a la finalidad.
Diseñar la solicitud
Una solicitud puede definir:
- formatos y perfiles aceptables;
- emisores o marcos de confianza;
- claims obligatorios y opcionales;
- credenciales alternativas o combinaciones de evidencia;
- vigencia, audiencia y vinculación transaccional;
- relación con el titular o key binding;
- finalidad e información de la parte usuaria;
- protección y expiración de la respuesta;
- expectativas de autorización y experiencia de usuario.
Una consulta conforme con estándares todavía puede ser excesiva. La revisión de política y privacidad continúa siendo necesaria.
Pipeline de verificación
Un verificador representativo realiza:
- Integridad de la solicitud — confirma vigencia, autenticidad y asociación con la parte correcta.
- Parsing de la respuesta — rechaza estructuras malformadas, ambiguas o no soportadas.
- Validación de formato — aplica el perfil exacto aprobado.
- Resolución del emisor — resuelve emisor y material de verificación por rutas aprobadas.
- Validación de firma o prueba — comprueba integridad con algoritmos y relaciones de clave permitidos.
- Ciclo de vida — verifica validez, estado, reemplazo y condiciones actuales.
- Contexto de presentación — valida nonce, audiencia, state, tiempo y replay.
- Relación con el titular — verifica la vinculación exigida por el perfil.
- Conformidad de divulgación — confirma claims obligatorios y evita tratar datos no relacionados como necesarios.
- Política de confianza y assurance — evalúa alcance del emisor, tipo, assurance, jurisdicción y reglas de transacción.
- Generación de resultado — produce un resultado explicable y referencia de evidencia.
- Decisión de la parte usuaria — permite aplicar reglas de negocio, legales, seguridad o acceso fuera del protocolo.
Verificación no es un único booleano
| Resultado | Significado |
|---|---|
| Verificada y conforme | Se aprobaron las condiciones técnicas y de confianza exigidas |
| Válida pero insuficiente | El artefacto es auténtico, pero no satisface la política |
| Falla de ciclo de vida | Expirada, suspendida, revocada o reemplazada |
| Fuente no confiable | Emisor o tipo fuera del alcance aprobado |
| Falla de contexto | Obsoleta, reproducida, dirigida incorrectamente o sin vínculo transaccional |
| Falla de relación con titular | No se demostró la vinculación requerida |
| No soportada | Formato, algoritmo, schema o perfil no aceptado |
| Indeterminada | Dependencia autoritativa no disponible o inconclusa |
| Revisión requerida | La política dirige el resultado a un proceso humano autorizado |
La parte usuaria no debe reinterpretar un resultado indeterminado o no soportado como verificación satisfactoria.
Política de confianza
El verificador debe conocer no solo quién emitió la credencial, sino si ese emisor es confiable para el tipo y finalidad. La confianza puede limitarse por:
- jurisdicción y sector;
- definición de credencial;
- nivel de assurance;
- algoritmo y tipo de clave;
- mecanismo de estado;
- modelo de holder binding;
- riesgo transaccional;
- validez y vigencia;
- certificación o pertenencia a un marco cuando exista evidencia independiente.
Los registros de confianza y versiones de política son activos controlados. Su representación pública no debe revelar lógica de aceptación de clientes ni relaciones privadas.
Verificación con privacidad
El verificador debe minimizar:
- claims solicitados;
- frecuencia de presentación e identificadores de correlación;
- material de credenciales retenido;
- documentos de origen y evidencia de proofing;
- logs con datos personales;
- distribución de comprobantes.
Cuando sea posible, la aplicación usuaria debe recibir solo los claims y el resultado de política necesarios, no el artefacto completo de presentación.
Comprobantes y evidencia
Un comprobante puede identificar:
- solicitud y transacción;
- verificador y parte usuaria;
- finalidad declarada;
- tipo de credencial y referencia del emisor;
- controles realizados y versión de política;
- nombres de claims divulgados o resultado minimizado;
- estado y resultados de dependencias;
- categoría final y timestamp.
No debe convertirse en un dossier reutilizable. La retención y el acceso deben estar vinculados a la finalidad.
Dependencias y fallas
El perfil debe definir si falla de forma cerrada, reintenta o dirige a revisión cuando:
- no se resuelven metadatos del emisor;
- una clave falta, está retirada o no aprobada;
- no puede comprobarse el estado;
- la presentación está incompleta u obsoleta;
- relojes, cachés o versiones discrepan;
- un registro externo de confianza no está disponible;
- el formato es válido sintácticamente pero está fuera del perfil fijado.
No se admite downgrade silencioso de un control obligatorio a uno más débil.
Expectativas de pruebas
Las pruebas deben incluir:
- firmas válidas e inválidas;
- emisor o tipo incorrecto;
- credenciales expiradas, revocadas, suspendidas y reemplazadas;
- algoritmos no soportados y disclosures malformadas;
- audiencia, nonce, state o transacción incorrectos;
- respuestas reproducidas y duplicadas;
- holder binding ausente;
- claims excesivos o inesperados;
- rotación de metadatos y refresh de caché;
- indisponibilidad de dependencias y resultados indeterminados;
- migración de versiones de política.
Checklist de readiness del verificador
Antes de producción, confirmar que:
- pregunta de confianza y responsable de decisión son explícitos;
- las solicitudes recopilan solo evidencia necesaria;
- alcances de confianza están gobernados;
- algoritmos, formatos, estado y holder binding están fijados;
- los resultados son explicables más allá de válido/inválido;
- están definidos fail-closed y revisión;
- comprobantes están minimizados y retenidos adecuadamente;
- superan pruebas negativas y replay;
- cambios de política y metadatos se monitorean;
- existen responsables de soporte, incidentes y apelación.
Límite de la documentación pública
Esta página no expone metadatos productivos, definiciones de solicitudes de clientes, trust lists privadas, umbrales de aceptación, reglas de fraude, código de política, registros de clientes, schemas de comprobantes ni procedimientos de excepción.
Consulta Verificación y política, Confianza y política y OpenID para credenciales verificables.