La versión Egeek.Sifen 0.4.0 consolidó el contrato catalogado y los eventos stateless. El siguiente paso no consiste en ampliar el protocolo fiscal a cualquier costo, sino en reforzar la base existente y facilitar una integración segura para quienes consumen el proyecto como servicio HTTP.
La hoja de ruta se divide en dos incrementos: 0.4.1, centrado en correcciones y hardening compatible, y 0.5.0, orientado a separar la superficie HTTP reutilizable del ejecutable WebApi de referencia.
0.4.1: robustez sin romper compatibilidad
El objetivo de 0.4.1 es conservar los contratos públicos de 0.4.0 y mejorar su comportamiento operativo. La primera corrección ya preparada centraliza la interpretación de los ambientes SIFEN: test y pruebas representan el mismo ambiente, al igual que production y produccion. Esto elimina diferencias accidentales entre generación, firma, transporte, consultas, eventos y configuración de la WebApi.
El resto del patch se concentrará en:
- sanitizar errores técnicos sin perder los códigos y mensajes funcionales de SIFEN;
- mantener correlación segura entre las respuestas públicas y el diagnóstico estructurado;
- hacer más clara la postura de seguridad de la WebApi de referencia y controlar la exposición de OpenAPI;
- incorporar validación opcional de cadena X.509;
- configurar explícitamente el ciclo de vida de conexiones HTTP con mTLS;
- ampliar las regresiones adversariales de XMLDSig y comprobar la integridad de los XSD;
- reforzar el pipeline ante dependencias vulnerables, secretos y artefactos de release.
Estos cambios serán compatibles: la validación de cadena dependerá de una activación explícita y el patch no impondrá autenticación, persistencia, scheduler ni reintentos automáticos.
0.5.0: autenticación componible sin fork
Actualmente, quien modifica directamente el Program.cs de la WebApi de referencia debe reconciliar sus cambios cada vez que actualiza el proyecto. La propuesta para 0.5.0 es extraer una superficie reutilizable en un paquete Egeek.Sifen.WebApi.Hosting.
Ese paquete reunirá controllers, contratos HTTP, serialización, middleware y extensiones de composición. El consumidor conservará su propio host ASP.NET Core y podrá registrar el esquema de seguridad que corresponda a su infraestructura: JWT Bearer, API key, mTLS entrante u otro mecanismo estándar.
La idea central es sencilla: Egeek.Sifen no administrará usuarios ni emitirá tokens. El host consumidor decidirá cómo autenticar y autorizar, aplicará sus policies a los endpoints SIFEN y actualizará las capacidades mediante paquetes NuGet, sin copiar controllers ni mantener una bifurcación del repositorio.
También se prevé un guard para el host de referencia: si un despliegue declara protección integrada pero no configura correctamente un esquema de autenticación, el inicio deberá fallar antes de exponer endpoints. Health y OpenAPI tendrán políticas explícitas para evitar exposiciones accidentales.
Lo que seguirá siendo parte del diseño
- un núcleo open source reutilizable y stateless;
- separación entre generación, firma y transmisión;
- credenciales y persistencia bajo control del consumidor;
- autenticación fuera de Domain, Application e Infrastructure;
- pruebas de paquetes y de un host consumidor limpio antes de publicar.
La secuencia será deliberada: primero completar y validar 0.4.1; después cerrar el contrato público del nuevo paquete de hosting y avanzar con 0.5.0. Las decisiones definitivas se incorporarán con pruebas, documentación de migración y una matriz clara de compatibilidad entre paquetes.
Mientras tanto, la versión estable actual y sus notas están disponibles en la release oficial de Egeek.Sifen 0.4.0.