Gestión del Ciclo de Vida y Seguridad Esta sección aborda los casos de uso administrativos y de seguridad que son fundamentales para garantizar la integridad, confiabilidad y sostenibilidad a largo plazo del ecosistema de la licencia de conducir digital. Estos procesos son gestionados por personal técnico y de seguridad de la  OGTIC y del INTRANT . Caso de Uso 1: Gestión del Esquema de la Credencial (Schema) Este caso de uso se activa cuando los requisitos de negocio o legales de la licencia de conducir cambian (ej. se añade un campo nuevo como "Donante de Órganos"). Actor : Administrador de Credenciales (INTRANT), con aprobación de OGTIC. Trigger : Decisión administrativa o cambio en la normativa de tránsito. Mecanismo Técnico : Definición de la Nueva Versión : Se crea una nueva versión del esquema JSON que define la estructura de la VC. Se le asigna un nuevo identificador de versión o URI. JSON // old_schema_uri: "https://intrant.gob.do/schemas/licencia/v1.0" // new_schema_uri: "https://intrant.gob.do/schemas/licencia/v1.1" Actualización del Portal de Emisión : El administrador actualiza la configuración en el portal Inji-Certify a través de una interfaz administrativa segura. Llamada API (Interna) : Se podría ejecutar una llamada PUT a un endpoint administrativo. Endpoint : https://admin.inji-certify.intrant.gob.do/api/v1/schemas/driving-license Body (JSON) : JSON { "schemaUri": "https://intrant.gob.do/schemas/licencia/v1.1", "schemaDefinition": { ... nuevo esquema JSON ... }, "isActive": true } Plan de Transición : Nuevas Emisiones : Todas las licencias emitidas o renovadas a partir de este punto utilizarán el nuevo esquema v1.1. Credenciales Antiguas : Las licencias existentes (v1.0) siguen siendo válidas hasta su fecha de expiración o hasta que sean renovadas. Las aplicaciones de los verificadores deben estar programadas para entender y validar ambas versiones del esquema. Impacto en el Ecosistema : Requiere coordinación para que las aplicaciones de verificadores se actualicen y puedan interpretar correctamente tanto el esquema antiguo como el nuevo. Caso de Uso 2: Gestión de Claves Criptográficas del Emisor (INTRANT) Este es uno de los procesos más críticos para la seguridad y confianza de todo el sistema. Actor : Oficial de Seguridad (OGTIC/INTRANT). Trigger : Rotación Programada : Política de seguridad que exige cambiar las claves cada 1-2 años. Compromiso de Clave : Sospecha o confirmación de que la clave privada ha sido expuesta. Mecanismo Técnico (Rotación Programada) : Generación de Nueva Clave : Se genera un nuevo par de claves (privada/pública) dentro del HSM . La nueva clave privada nunca sale del HSM. Actualización del Documento DID : Se debe actualizar el documento DID del emisor ( did:web:intrant.gob.do ) para reflejar este cambio. El did.json se modifica para: Añadir la nueva clave pública en la sección verificationMethod . Mantener la clave antigua en la misma sección, pero marcándola como histórica o expirada si es posible. Actualizar las secciones assertionMethod y authentication para que apunten a la nueva clave. Llamada API (para publicar el did.json en el servidor web): PUT /var/www/html/.well-known/did.json (Ejemplo de despliegue en servidor web) Activación de la Nueva Clave : El portal Inji-Certify se configura para usar la nueva clave ( key-2 ) para firmar todas las nuevas credenciales. Mecanismo Técnico (Compromiso de Clave de Emergencia) : Revocación Inmediata : El Documento DID se actualiza inmediatamente para eliminar la clave comprometida de assertionMethod . Esto invalida su uso para nuevas firmas. Plan de Re-emisión : Se debe notificar a todos los ciudadanos que necesitan solicitar una re-emisión de su licencia, ya que las antiguas, aunque no expiradas, podrían no ser confiables. Actualización de Verificadores : Las aplicaciones de los verificadores deben forzar una actualización de la caché de la clave del INTRANT para asegurarse de que ya no confían en la clave comprometida. Impacto : Una rotación bien planificada es transparente para los usuarios. Un compromiso de clave es un incidente de seguridad grave que requiere una comunicación pública clara y una acción rápida de re-emisión. Caso de Uso 3: Mantenimiento de la Lista de Estado de Credenciales Garantiza que el mecanismo de revocación funcione de manera eficiente y escalable. Actor : Administrador del Sistema (OGTIC). Trigger : La lista de estado actual (bitmap) se está llenando o ha alcanzado un tamaño que afecta el rendimiento. Mecanismo Técnico : Creación de una Nueva Lista : Se genera una nueva lista de estado vacía. Llamada API (Interna) : POST https://api.intrant.gob.do/v1/statuslists Respuesta : Devuelve el ID y la URL de la nueva lista (ej. .../status/2 ). Configuración del Emisor : El portal Inji-Certify se configura para que todas las nuevas credenciales emitidas apunten a esta nueva lista en su propiedad credentialStatus . Archivado de la Lista Antigua : La lista antigua ( .../status/1 ) se mantiene activa y disponible para que las credenciales ya emitidas que apuntan a ella puedan seguir siendo verificadas, pero ya no se le añaden nuevas revocaciones. Impacto : Es una tarea de mantenimiento rutinario y transparente para los usuarios finales, pero crucial para el rendimiento y la escalabilidad del sistema de revocación. Caso de Uso 4: Monitoreo, Auditoría y Alertas del Sistema Es el proceso continuo de vigilancia para asegurar la salud y seguridad del ecosistema. Actor : Administrador del Sistema y Oficial de Seguridad (OGTIC). Trigger : Continuo (24/7). Mecanismo Técnico : Recolección de Logs : Todos los componentes (servidores de API, HSM, portal de emisión, base de datos) envían sus logs a un sistema SIEM centralizado. Los logs deben incluir: Intentos de acceso (exitosos y fallidos). Cada emisión de credencial (quién la autorizó, a quién, cuándo). Cada verificación de estado de revocación. Errores del sistema y métricas de rendimiento (latencia, tasa de errores). Creación de Paneles (Dashboards) : Se configuran paneles en el SIEM o en herramientas como Grafana para visualizar en tiempo real: Disponibilidad (Uptime) de las APIs críticas. Número de credenciales emitidas por día/hora. Latencia promedio de las verificaciones. Mapa de geolocalización de las solicitudes de verificación. Configuración de Alertas : Se definen reglas para generar alertas automáticas (vía email, Slack, PagerDuty) ante eventos anómalos. Ejemplos de Alertas de Seguridad : Múltiples intentos de inicio de sesión fallidos para un administrador. Emisión de credenciales fuera del horario laboral normal. Una tasa de error del 5% o más en la API de verificación. Un intento de acceso al HSM desde una IP no autorizada. Impacto : Permite la detección proactiva de problemas de rendimiento y brechas de seguridad, reduciendo el tiempo de respuesta ante incidentes. Genera un registro de auditoría inmutable crucial para investigaciones forenses.