Integración del emisor
Una integración de emisor convierte evidencia institucional autoritativa en una credencial que puede custodiarse, presentarse y verificarse de forma independiente. El emisor sigue siendo responsable de la verdad, alcance, gobierno y ciclo de vida de los claims que firma.
UbID coordina proofing, política, definición de credenciales, firma, entrega, estado y evidencia, manteniendo estas responsabilidades gobernables de forma independiente.
Establecer la autoridad emisora
Antes de implementar un flujo, la organización debe documentar:
- base jurídica o institucional para emitir el claim;
- población y jurisdicción cubiertas;
- sistemas o evidencias considerados autoritativos;
- assurance requerido antes de la emisión;
- quién puede aprobar, suspender, revocar, reemplazar o renovar una credencial;
- procedimientos de retención y derechos asociados;
- contextos de uso previstos.
Una organización técnicamente capaz no está automáticamente autorizada para emitir cualquier tipo de claim.
Definir la credencial
| Área | Preguntas que deben resolverse |
|---|---|
| Identidad | ¿Quiénes son emisor, sujeto y titular previsto? |
| Semántica | ¿Qué significa cada claim y qué fuente lo establece? |
| Minimización | ¿Qué claims son necesarios, opcionales o prohibidos? |
| Schema | ¿Cómo se validan campos, formatos y versiones? |
| Assurance | ¿Qué evidencia y nivel de revisión respaldan la emisión? |
| Vinculación | ¿Cómo se asocia la credencial con el titular o Wallet previstos? |
| Ciclo de vida | ¿Cuándo expira, se renueva, suspende, revoca o reemplaza? |
| Estado | ¿Cómo determina el verificador su aceptabilidad vigente? |
| Privacidad | ¿Qué disclosures se esperan y qué correlaciones deben limitarse? |
| Gobierno | ¿Quién responde por cambios, incidentes, soporte y comunicación? |
Los schemas aportan consistencia, pero no prueban que el claim de origen sea verdadero. Evidencia, autoridad y política siguen siendo esenciales.
Flujo de emisión
Un flujo representativo contiene:
- Inicio — un proceso autorizado inicia una transacción para una credencial definida.
- Recopilación de evidencia — se obtiene la evidencia mínima desde fuentes aprobadas.
- Proofing y validación — se evalúa evidencia de identidad, documentos, institución u otra categoría.
- Evaluación de política — se comprueban autoridad, elegibilidad, assurance, schema, duplicados y ciclo de vida.
- Vinculación con titular o Wallet — el destinatario demuestra la relación exigida por el perfil.
- Aprobación — una persona o política autorizada concede la emisión.
- Firma — un servicio criptográfico controlado firma los claims aprobados con una versión identificable de clave.
- Entrega — la credencial se entrega mediante la interacción aprobada con el titular.
- Registro y estado — se crean referencias coherentes de ciclo de vida y estado.
- Evidencia — se conserva un registro auditable sin material secreto innecesario.
Las etapas pueden ser síncronas o asíncronas. Un resultado satisfactorio de proofing no debe convertirse automáticamente en firma sin una transición explícita de política.
Preparar, validar, aprobar y ejecutar
Las APIs del emisor deben separar intención y cambio autoritativo de estado:
- Prepare construye la solicitud y las referencias de soporte.
- Validate comprueba sintaxis, schema, evidencia, identidad, duplicados y política.
- Approve registra la autorización requerida.
- Execute crea y firma la credencial.
Esta estructura favorece segregación de funciones, revisión humana cuando corresponda, idempotencia y fallas explicables.
Responsabilidad de claves y firma
El emisor responde por el significado de la firma y el gobierno de su identidad de firma. Las aplicaciones deben solicitar una operación acotada a un servicio aprobado de claves, sin recibir material institucional privado.
El perfil de partner debe definir:
- identificador del emisor y relación de verificación;
- formato y algoritmos aprobados;
- activación, rotación, retiro y respuesta ante compromiso de claves;
- cómo resuelven los verificadores el material público;
- cómo se revisan credenciales históricas;
- qué evidencia vincula la credencial con la versión de clave.
Los identificadores productivos de claves, configuración interna de KMS y procedimientos operacionales de recuperación no son documentación pública.
Entrega al titular
La entrega debe confirmar:
- interacción prevista de Wallet o titular;
- autorización y vigencia de la transacción;
- prueba del control de clave requerido;
- estado one-time o resistente a replay;
- información clara sobre emisor y credencial;
- comportamiento de timeout, abandono y reintento;
- resultado final visible para el emisor sin exponer contenido de la Wallet.
La entrega satisfactoria no autoriza al emisor a monitorear todos los usos posteriores.
Estado, renovación y reemplazo
El emisor debe mantener un ciclo coherente:
- activa — utilizable actualmente según política;
- expirada — fuera del período de validez;
- suspendida — temporalmente no aceptable;
- revocada — ya no aceptable;
- superada — reemplazada por una credencial nueva;
- renovada — reemitida conforme a política.
Los estados exactos dependen del perfil. El estado público solo debe revelar lo requerido por el verificador y evitar motivos sensibles o historial del titular.
Un claim o perfil modificado normalmente debe producir un nuevo artefacto firmado y una transición coherente, no mutar una credencial firmada existente.
Resultados de error y revisión
La integración debe distinguir:
- input incompleto o inválido;
- configuración de credencial no soportada;
- evidencia insuficiente o indeterminada;
- incumplimiento de elegibilidad o política;
- fallo de holder binding;
- estado duplicado o conflictivo;
- transacción obsoleta, reutilizada o consumida;
- operación pendiente de revisión;
- dependencia de firma o entrega no disponible;
- credencial creada con resultado de entrega no resuelto.
Los errores deben permitir recuperación segura sin revelar reglas antiabuso, datos de otras personas ni topología interna.
Evidencia del emisor
El emisor puede conservar referencias a:
- definición de credencial y versión de schema;
- fuente y categoría de assurance;
- decisión de política y aprobador;
- resultado de holder binding;
- referencia de versión de clave de firma;
- resultado de emisión y entrega;
- eventos de estado y ciclo de vida;
- categoría de motivo para corrección, renovación, suspensión o revocación.
La retención debe estar vinculada a la finalidad y considerar la jurisdicción. La evidencia sin procesar no debe duplicarse solo porque se emitió una credencial.
Checklist de readiness del emisor
Antes de producción, confirmar que:
- autoridad emisora y propiedad de claims están documentadas;
- schema y semántica están aprobados;
- datos mínimos y divulgación están definidos;
- proofing y assurance son comprobables;
- ciclo de claves y discovery para verificadores están gobernados;
- holder binding y entrega resisten replay;
- estado, renovación, reemplazo y revocación son operacionales;
- superan pruebas positivas, negativas, duplicados, expiración y dependencias;
- existen responsables de soporte e incidentes;
- las afirmaciones públicas describen el alcance implementado.
Límite de la documentación pública
Esta página no publica schemas de clientes, mappings de sistemas fuente, metadatos productivos, contratos de endpoints, registros de clientes, configuración de firma, reglas de aprobación, umbrales antifraude ni credenciales operacionales. Estos detalles se entregan mediante onboarding controlado.
Consulta UbID Credential Cloud, OpenID para credenciales verificables y Metadatos públicos y discovery.