Confianza y política
La política de confianza convierte evidencia criptográfica en una decisión contextual. Una firma válida confirma integridad bajo una clave; la política determina si ese emisor, clave, credencial, disclosure, relación con el titular y transacción son aceptables para la finalidad declarada.
Capas de política
| Capa | Responsabilidad de ejemplo |
|---|---|
| Política de participantes | Qué emisores, Wallets, verificadores o partes usuarias son reconocidos |
| Política de credenciales | Qué tipos, schemas, perfiles y significados de claims se aceptan |
| Política criptográfica | Formatos, algoritmos, tipos de clave, relaciones y deprecaciones permitidos |
| Política de ciclo de vida | Validez, estado, suspensión, revocación, reemplazo y dependencias |
| Política de presentación | Claims exigidos, alternativas, minimización, audiencia, nonce y holder binding |
| Política de assurance | Proofing, fuentes de evidencia, nivel de revisión y riesgo requeridos |
| Política jurisdiccional | Finalidad, base jurídica, biometría, retención, transferencias y derechos |
| Política de negocio | Elegibilidad, acceso, seguridad, fraude, sanciones, clínica o sector |
| Política operacional | Timeout, reintentos, revisión, outages, monitoreo, evidencia e incidentes |
Estas capas deben versionarse independientemente cuando tengan propietarios y ciclos de cambio distintos.
La confianza está acotada
Un emisor solo debe ser confiable para los claims y contextos que está autorizado a respaldar. La confianza puede limitarse por:
- tipo de credencial;
- población de sujetos;
- jurisdicción;
- sector o dominio profesional;
- nivel de assurance;
- período de validez;
- perfil de algoritmo y clave;
- finalidad del verificador o parte usuaria;
- pertenencia a un marco gobernado independientemente.
Un emisor confiable de afiliación laboral no lo es automáticamente para identidad civil, títulos académicos, licencias médicas o elegibilidad financiera.
Fuentes de confianza
La política puede apoyarse en fuentes gobernadas, como:
- allow-lists institucionales explícitas;
- registros de confianza o metadatos de federación;
- relaciones contractuales con partners;
- evidencia de certificación o acreditación;
- gobierno de dominios y DID;
- infraestructura de clave pública aprobada;
- registros sectoriales o gubernamentales;
- registros de excepciones aprobados manualmente.
La existencia de un identificador o clave pública no es suficiente. Deben establecerse procedencia y autorización.
Política de credenciales y schemas
La política debe fijar la definición aceptada y la semántica de claims. Debe rechazar schemas ambiguos o modificados silenciosamente aunque sigan siendo técnicamente parseables.
Un perfil debe definir:
- modelos de emisor y sujeto;
- claims obligatorios y opcionales;
- formatos de valores y vocabularios;
- reglas de disclosure;
- modelo de holder binding;
- mecanismo de estado;
- validez y renovación;
- categoría de evidencia y assurance;
- compatibilidad de versiones.
Validar el schema confirma estructura, no verdad ni autorización.
Política de algoritmos y claves
La política criptográfica solo debe permitir combinaciones revisadas de:
- formato de credencial;
- algoritmo de firma o prueba;
- tipo y tamaño de clave;
- relación de verificación;
- estado y ciclo de vida de la clave;
- ruta de validación de certificado, DID o registro;
- prueba del titular y key binding;
- cifrado de respuesta cuando corresponda.
Combinaciones inesperadas, deprecadas, débiles o no soportadas deben fallar de manera segura. La agilidad no consiste en aceptar toda opción anunciada.
Política de estado y vigencia
Una credencial puede ser auténtica y no aceptable por estar expirada, suspendida, revocada, reemplazada o fuera de contexto.
La política debe definir:
- si la comprobación de estado es obligatoria;
- antigüedad aceptable de caché y comportamiento de dependencias;
- manejo de expiración y tolerancia de reloj;
- uso histórico de credenciales superadas;
- qué resultados se dirigen a revisión;
- efecto de una indisponibilidad de estado según el riesgo.
Un verificador nunca debe omitir silenciosamente una comprobación obligatoria y afirmar verificación completa.
Assurance y riesgo
La misma credencial puede ser suficiente para una transacción e insuficiente para otra. La política puede combinar:
- autoridad del emisor;
- assurance de proofing o evidencia;
- holder binding;
- assurance de dispositivo y sesión;
- antigüedad de la credencial;
- valor o impacto de la transacción;
- indicadores contextuales de riesgo;
- revisión humana obligatoria.
Las etiquetas de assurance deben estar respaldadas por controles y evidencia explícitos, no solo lenguaje comercial.
Resultados de política
Un motor de políticas debe devolver una categoría explicable, no solo un booleano. Puede incluir:
- satisfecha;
- evidencia insuficiente;
- emisor o perfil no confiable;
- falla de ciclo de vida;
- falla de contexto o holder binding;
- algoritmo o formato no soportado;
- dependencia no disponible;
- revisión requerida;
- error de configuración de política.
El resultado debe identificar versión y categoría de razón sin exponer lógica sensible de fraude ni detalles internos.
Ciclo de gobierno de la política
La política debe pasar por:
- propuesta y asignación de responsable;
- revisión de arquitectura, seguridad, privacidad, legal o negocio;
- definición de vectores de prueba y casos negativos;
- aprobación controlada;
- activación gradual;
- observación en producción;
- revisión periódica;
- migración o retiro.
Todo cambio material debe identificar credenciales, partners, titulares, decisiones históricas, metadatos, pruebas y condiciones de rollback afectados.
Pruebas de política
Las pruebas deben incluir:
- emisores aprobados y no aprobados;
- fechas límite y cambios de estado;
- claves rotadas y retiradas;
- disclosures malformadas o excesivas;
- prueba del titular ausente;
- presentaciones reproducidas o con audiencia incorrecta;
- algoritmos y versiones no soportados;
- outage del registro de confianza;
- rutas de revisión y excepción;
- migración desde la versión anterior.
Límite de la documentación pública
Esta página describe la arquitectura de políticas. Registros productivos de confianza, reglas de aceptación de clientes, indicadores de fraude, allow-lists de algoritmos, código fuente de políticas, umbrales, registros de excepciones y overrides de emergencia permanecen controlados.
Consulta Verificación y política, Metadatos públicos y discovery y Estado de contenido y capacidades.