Metadatos públicos y discovery
Los participantes interoperables necesitan una forma aprobada de descubrir identificadores, material público de verificación, perfiles de credenciales soportados, capacidades de protocolo, schemas e información de estado. Los metadatos públicos reducen configuración manual, pero no conceden autorización ni establecen confianza por sí solos.
Categorías de metadatos
| Categoría | Finalidad pública | Limitación importante |
|---|---|---|
| Identificadores institucionales | Identificar emisor, verificador o controlador de servicio | Resolver no prueba autoridad para todo claim |
| Material de verificación | Publicar claves o certificados y relaciones previstas | Material privado y operaciones internas permanecen protegidos |
| Metadatos del emisor | Describir capacidades y perfiles de emisión | La disponibilidad puede variar por producto, tenant y onboarding |
| Metadatos de autorización | Describir servicios compatibles y funciones de seguridad | Discovery no registra clientes ni concede scopes |
| Configuraciones de credenciales | Identificar tipos, formatos, claims, display y requisitos de prueba | Los resúmenes públicos pueden omitir schemas y políticas específicas |
| Metadatos del verificador | Identificar solicitante y comportamiento de presentación | El titular todavía valida finalidad y contexto |
| Schemas y vocabularios | Definir estructura y semántica | Validez estructural no prueba verdad del claim |
| Información de estado | Admitir controles de expiración, suspensión, revocación o reemplazo | El estado público no debe revelar motivos sensibles ni historial |
| Referencias de marcos de confianza | Apuntar a gobierno, acreditación o federación | La confianza se valida contra política local |
| Capacidades del servicio | Describir estándares y versiones soportados | Publicitar no equivale a conformidad universal |
Secuencia de discovery
Un participante debe:
- obtener la ubicación de metadatos por una ruta bootstrap aprobada;
- recuperarlos mediante canal autenticado y con integridad;
- validar procedencia y controlador esperado;
- confirmar perfil y versión exactos;
- aplicar política local de confianza y algoritmos;
- cachear solo dentro de la ventana aprobada de vigencia;
- detectar cambios inesperados;
- fallar de forma segura cuando no pueda resolver metadatos obligatorios.
Los metadatos nunca deben aceptarse solo porque provengan de un redirect no confiable o estén incluidos en una transacción no verificada.
Claves públicas y material de verificación
El material puede exponerse mediante documentos DID, JWKS, certificados u otro perfil aprobado. Los consumidores deben verificar:
- relación entre emisor y controlador;
- identificador de clave y finalidad;
- algoritmo y tipo de clave permitidos;
- estado de activación, retiro o revocación;
- ruta de validación de certificado o DID;
- comportamiento de caché y rotación;
- requisitos de verificación histórica.
Una clave pública nunca debe acompañarse de exponente privado, secreto de recuperación, seed o credencial interna de gestión de claves.
Metadatos de capacidades de credenciales
Pueden ayudar a una Wallet o partner a comprender:
- identificador de configuración;
- formato y perfil;
- nombre visible e idiomas;
- nombres de claims y valores esperados;
- requisitos de prueba o holder binding;
- patrones de autorización y entrega;
- modelo de estado y validez;
- versión y deprecación.
La representación pública debe ser suficiente para discovery sin exponer mappings de clientes, lógica interna de validación ni reglas productivas de aprobación.
Schemas y semántica
Un schema debe ser inmutable o estar claramente versionado después de publicarse. Los cambios incompatibles exigen una nueva versión y plan de migración.
Un registro o referencia debe distinguir:
- restricciones estructurales;
- significado semántico;
- autoridad del emisor;
- clasificación de divulgación;
- sensibilidad de privacidad;
- ciclo de vida y compatibilidad.
No debe suponerse que dos campos de nombre parecido tienen el mismo significado entre tipos de credenciales o jurisdicciones.
Metadatos de estado
Los mecanismos de estado deben proporcionar la información mínima vigente para verificar. Un buen diseño evita publicar:
- motivos de revocación vinculados a una persona;
- inventarios completos de credenciales o titulares;
- identificadores estables de correlación;
- datos internos de casos o incidentes;
- operaciones administrativas.
El comportamiento durante un outage debe definirse por política, no improvisarse en runtime.
Procedencia e integridad
Los consumidores deben aplicar controles como:
- validación del origen HTTPS;
- validación DID o de certificados cuando corresponda;
- metadatos firmados si el perfil lo admite;
- relaciones fijadas de emisor o marco de confianza;
- validación de content type y schema;
- restricciones de redirects;
- expiración y refresh de caché;
- monitoreo de cambios inesperados de claves o capacidades.
Metadatos correctos sintácticamente, pero incompatibles con el perfil aprobado, deben tratarse como evento controlado de compatibilidad.
Versionado y cambios
Los metadatos públicos deben identificar versión, estado efectivo y deprecación cuando el perfil lo permita. Los partners deben recibir aviso anticipado de cambios que afecten:
- identificadores o schemas de credenciales;
- endpoints o autorización;
- algoritmos, claves o certificados;
- requisitos de prueba y holder binding;
- mecanismos de estado;
- claims requeridos o formatos de presentación;
- semántica de errores;
- expectativas de conformidad.
La rotación puede ser rutinaria, pero los consumidores necesitan solapamiento, refresh e historial correctos.
Privacidad y resistencia al abuso
Los metadatos públicos deben publicar capacidades, no secretos operacionales. Deben revisarse para evitar:
- datos personales y fuga entre tenants;
- hostnames internos o topología;
- endpoints administrativos;
- umbrales antiabuso;
- relaciones de clientes no publicadas;
- detalles operacionales de alto valor para atacantes;
- fingerprinting o enumeración excesiva.
Controles de tasa y monitoreo pueden proteger los servicios sin impedir interoperabilidad legítima.
Superficies públicas y de partners
La superficie pública puede describir identificadores estables, estándares, capacidades, material público y perfiles generales.
La superficie controlada de partners puede incluir además metadatos del entorno, schemas exactos, registro de clientes, configuraciones de prueba, pertenencia a marcos de confianza y notas de compatibilidad.
Límite de la documentación pública
Esta página no publica endpoints productivos, identificadores de clientes, redirect locations, inventarios de tenants, schemas privados, interfaces administrativas, health interno, capacidades no liberadas ni detalles de gestión criptográfica.
Consulta Identificadores descentralizados, OpenID para credenciales verificables y Onboarding de partners.