Tras el lanzamiento de la primera versión del validador y tras moldear el diseño del mismo se observaron oportunidades para simplificar su integración en múltiples plataformas de la manera más sencilla posible. En este artículo se analizan varias propuestas de cambio para lograrlo.
Integrar validador y firmador en un solo proyecto
Actualmente el validador es un proyecto independiente del firmador. Sin embargo, si para la versión 3.0 del firmador se pretende publicar como binario compilado con la misma tecnología de GraalVM CE, entonces puede generarse una única aplicación donde el validador sea un parámetro por línea de comandos.
El firmador, aparte de la interfaz gráfica, probablemente terminará siendo una aplicación por línea de comandos de manera preferente, a diferencia de lo planeado inicialmente de compilarse como librería. Si mereciera la pena compilarlo como librería sería algo con menor prioridad, ya que requiere más tiempo y mantenimiento, además de la complejidad de mantener una ABI y API estables.
Al enfocar el firmador en la línea de comandos, el validador puede agregarse a la lista de parámetros para devolver el XML tal y como hace ahora. Debido al gran tamaño de los ejecutables de GraalVM CE y donde es probable disponer de un firmador y validador en un solo ambiente, se ahorra espacio en servidores donde se fueran a utilizar ambos.
Utilizar JavaScript del lado cliente para visualizar el reporte XML
En la versión 1.0 del validador se agregó código PHP para generar (X)HTML a partir del XML mediante una plantilla XSLT. Sin embargo, esto requiere más dependencias o implementar soluciones específicas para cada lenguaje de servidor, si bien tiene la ventaja de no requerir JavaScript en el navegador.
En el caso del firmador, existe una demostración para firma mediante sitio web que tiene un código para invocar el firmador del lado cliente mediante Java Web Start (JNLP), que terminará siendo reemplazado por una solución ejecutable liviana o preinstalada. El mecanismo de comunicación ya era genérico y no requería mayor procesado en el servidor que no fuera subir el fichero a un manejador con los parámetros que requiriera el gestor de contenidos.
En el mismo caso que en en el sistema de firma web, el validador podría mostrar el resultado de validación de documentos sin requerir PHP, pudiendo utilizarse de manera más genérica incluso en gestores de contenidos o gestores documentales que utilizan otros lenguajes (Java, Python, etc.). Esto se logra fácilmente mediante la API XSLTProcessor() de JavaScript en el navegador.
Mantener módulos para gestores de contenidos populares
Para integrar validación de documentos en los gestores de contenidos y gestores documentales, se agregaría lo mínimo necesario en cada integración y delegando en lo posible por JavaScript para reutilizar código.
Debido a que el validador es un ejecutable nativo y específico de cada plataforma y ejecutándose en el servidor, el módulo se encargaría de descargar el componente precompilado para facilitar la configuración y mantener las actualizaciones de seguridad del binario nativo. En el caso de plataformas como PHP y otros se requerirá que el servidor permita ejecutar comandos nativos mediante exec() o similar.
Algunos ejemplos de gestores de contenidos y gestores documentales populares donde algunas de las integraciones que se podrían considerar abarcarían versiones soportadas de WordPress, Drupal, Joomla, Odoo, Alfresco, AtoM, entre otros.
Conclusión
Con el diseño planteado en conjunto con los cambios a futuro del firmador se logra reducir la duplicidad y mantenimiento y enfocarse más en las interfaces e integraciones, pudiendo abarcar más diversidad de plataformas con los mismos recursos disponibles. 2024 será el año donde se comience a consolidar este nuevo diseño y se espera disponer de primeros prototipos funcionales, aunque todavía no se espera que se lancen versiones formales de esta nueva arquitectura en ese mismo año, podrían existir versiones para uso interno de algunas integraciones tempranas.
Muchas gracias por el esfuerzo, realmente ayuda a generar la marca de agua en los pdfs.
Me gustaria pedir una funcionalidad que no tiene el actual. Soporte a la firma desde el telefono. Si no tengo la tarjeta fisica no puedo usarlo desde la computadora.
Gracias, por restricciones del controlador de tarjetas y por la falta de documentación para poder utilizar las tarjetas por NFC desconozco si es viable, había pensado en utilizar emulación de arquitectura utilizando QEMU para emular x66_64 en aarch64 para cargar la librería de Linux en Android pero por otro lado creo que Android no permite fácilmente acceder por NFC sin root, si bien existen proyectos para usar un dispositivo Android como lector NFC genérico sin root (vsmartcard), pero requiere bastante trabajo investigar cómo funciona todo y si podría utilizarse el middleware PKCS#11 desde el mismo. En cuanto a algo similar en iOS es todavía más improbable.
Lo que puede hacer por ahora es utilizar la aplicación GAUDI Móvil. No obstante, esta aplicación requiere solicitar un certificado específico para cada dispositivo (cuesta 5000 colones) y se pierde si lo reinicia a estado de fábrica, pero al menos le permite utilizarlo en esos casos. La versión para Android requiere una versión relativamente reciente para funcionar (creo que no especifican cuál, pero Android 10 no está soportada). Desconozco los requerimientos para la versión de iOS.
Saludos.
Gracias por la respuesta.
El problema es que GAUDI Movil no genera marca de agua y muchas personas rechazan el documento por no ver la marca. Firmador fue la alternativa que habia encontrado para generar la marca a la hora de firmar.
Es correcto, los servicios de firma de GAUDI no tienen esa representación visual. Aunque no deberían rechazarle el documento, a veces es más complicado tener que pelear caso por caso.
La única solución técnicamente viable a corto plazo para firmar desde el celular es tener la tarjeta conectada en una computadora remota (en casa, por ejemplo), aunque el acceso debería hacerse lo suficientemente seguro para que nadie más pueda entrar y firmar, o en caso de mecanismo de acceder a la tarjeta, dónde almacenar el PIN o transmitirlo de manera segura.
Un acceso de control remoto completo de la vista de escritorio de la computadora remota con la tarjeta conectada no requiere desarrollo adicional pero es más incómodo de manejar desde el teléfono. Una herramienta a medida para acceso remoto podría ser más conveniente para estos casos de uso, sobre todo para ajustar la representación visual desde una pantalla pequeña que fuera fácil de utilizar.
Estoy preparando un prototipo para hacer esta selección de ubicación en la vista previa de páginas de documento PDF desde una interfaz web pero todavía queda bastante para tener algo usable. El propósito inicial era poder utilizar un firmador web de escritorio de tamaño mínimo apenas para solicitar el PIN pero tal vez pueda aprovecharse para estos casos en una interfaz para teléfonos celulares y tablets. Saludos.