En las listas de AccesoWeb de SIDAR mantuvimos en 2005 una interesante discusión sobre la compatibilidad entre los puntos de verificación de accesibilidad de WAI y la firma electrónica, que requiere realizar procesos en cliente con tecnologías obviamente ejecutadas en cliente (Javascript + Applet Java o Active X). En tres años ha habido realmente poca evolución a este respecto, y considero que la discusión se puede mantener vigente.
Sobre la firma electrónica
No confundamos firma electrónica con autenticación con certificado. Podemos acceder (login) a una aplicación web con nuestro certificado, y que sea accesible. En lo que se refiere a la firma electrónica en una aplicación web, hay sin embargo una serie de conceptos claros. El proceso técnico es más o menos como el que sigue (ahorrando varios pasos para no hacer un post tipo Biblia):
- El usuario introduce los datos que debe firmar. Esto puede ser de muchas formas; rellenar un formulario HTML, adjuntar un fichero, etc.
- El navegador del usuario debe generar un resumen (digest) con un algoritmo hash (tipo MD5 o SHA-1) de la información a firmar.
- El navegador debe utilizar la clave privada del certificado digital del cliente para encriptar esta información. Esta encriptación es simétrica; lo que se encripta con la clave privada podrá ser desencriptada con la clave pública, y sólo con esta. Para realizar esta operación, el navegador debe consultar de alguna forma el almacén de certificados del cliente, hacerle escoger el certificado con el que quiere firmar, y utilizar la clave privada almacenada en el certificado escogido para encriptar ese hash. Ya tenemos la firma: es el hash encriptado.
- El navegador envía al servidor de firma todos los datos necesarios: el hash encriptado y la clave pública del certificado digital del cliente. Ahora éste lo almacena con el formato que se considere más oportuno. En cualquier momento se puede verificar la validez de esa firma con una sencilla operación: desencriptando la firma con la clave pública del certificado, y comparándola con el resultado de realizar el hash Almacenar el documento original con su firma (el hash encriptado). De esta forma, si algún día se quiere comprobar que lo que introdujo el usuario (el documento original) no ha sido modificado maliciosamente (lo que le confiere validez legal), se puede realizar una sencilla operación de comprobación de firma, consistente en desencriptar la firma con la clave pública del certificado digital, obteniendo el hash, y aplicando el algoritmo de hash sobre el documento original. Si ambos hash coinciden, la firma es válida.
El problema es que los pasos 2 y 3 deben realizarse en cliente, es decir, en el navegador. Esto se totalmente necesario y obligatorio; precisamente, uno de los puntos clave para mantener la seguridad del proceso se basa en que la clave privada del certificado del cliente nunca sale de la máquina del cliente. Hay un número finito de tecnologías para ejecutar esto en un navegador web: lo más normal son applets Java (como el conocido OpenOCES, que utilizamos en Viafirma y que usan otras plataformas como la de Safelayer) o clientes Active X, invocados desde Javascript. De hecho, éste es uno de los puntos claves para que un trámite telemático sea lo más universal y usable posible: la calidad del componente cliente. Por ejemplo, la semana pasada tardé dos horas, experimentos en 3 máquinas diferentes (ya varios navegadores en cada una, aunque con Opera o Safari no llegas muy lejos) y un buen número de reinstalaciones de componentes para conseguir cambiar a mi mujer de médico de cabecera, debido a la infame calidad de los applets Java de firma de la plataforma @Firma. Si a mí me costó tanto, no quiero imaginar qué le ocurrirá a un usuario de a pie. El mayor problema es que funciona muy mal con el JRE Java 6, pero debería tenerse en cuenta que, salvo que se configure de forma diferente, el JRE se autoactualiza automáticamente, con lo que a estas alturas hasta el panadero de la esquina tiene instalado Java 6 en su máquina.
Sobre la accesibilidad web
En lo que se refiere a la accesibilidad web, las pautas WAI te exigen que para acceder a tu contenido web no sea imprescindible el uso de applets o javascript. En concreto, la pauta 6.3 dice que “Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible”.
Según esta pauta entendemos que no podemos tener una calificación AA de accesibilidad si utilizamos javascript y applets, ya que deberíamos tener una página alternativa. El problema es que no podemos tener una página alternativa ya que la operación que realizamos no se puede realizar de otra forma de forma legal.
Sobre las Administraciones Públicas
Por último, las Administraciones Públicas exigen por regla general que sus portales web, incluyendo sus oficinas virtuales, alcancen un nivel AA de accesibilidad, esto es, cumplan todos los puntos de verificación de prioridad 1 y 2.
Pero también exigen que para que una operación telemática sea legal, se haga utilizando firma electrónica que, como hemos visto, tiene problemas insalvables de accesibilidad porque hoy por hoy no es posible firmar sin ejecutar lógica de cliente que no todos los navegadores o dispositivos de usuario tienen por qué soportar. Por ello, la alternativa legal que podemos dar a nuestra web con firma electrónica es que el usuario se vaya a la institución físicamente.
¿No es un contrasentido? Se piden dos cosas incompatibles entre sí.
Una conclusión: quedarse en medio.
Bajo mi punto de vista, no debemos olvidar que las pautas WAI se refieren al acceso al contenido. Una Oficina Virtual está mucho más cerca de una aplicación web que de un portal, por lo que debe plantearse si las pautas aplican con la misma restrictividad. En todo caso, siempre se puede tratar de que toda la web sea accesible realmente, y sacar la zona dotada de firma electrónica de la declaración de accesibilidad. Y esperar a que la tecnología avance para superar estos escollos.
