Accesoweb

Alberto comienza diciendo que:

una funcionalidad importante de nuestra Web está desarrollada con un applet que debe ser invocado mediante javascript (...) para leer el almacén de certificados digitales del navegador cliente y realizar una operación de firma electrónica. Este es el resumen de nuestra operación:

• Al cargar la página cargamos el applet.
• Mediante javascript leemos datos de un formulario HTML y los pasamos como parámetros de entrada a un método del applet.
• El método del applet nos da como resultado una cadena de texto que almacenamos en un campo del formulario HTML.

Esta operación no puede realizarse en el servidor ya que se necesita acceder al almacén de certificados digitales del cliente y a ese almacén sólo se puede acceder mediante un componente en el cliente (applet, OCX, javascript, etc).

Hemos visto que las pautas de accesibilidad especifican cómo hacer que un applet o un javascript sean accesibles. Esto no nos supone ningún problema (pautas 6.5,8.1 y 9.3).

Pero el problema lo tenemos con la pauta 6.3: 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.

A lo que Alejandro Cuesta responde, a mi entender, dando en el clavo, ya que explica que en vuestra aplicación estáis incorporando parte de la lógica de la aplicación (código) en la interfaz (la web) a través de tecnologías como Java (applet) y Javascript. Esta dependencia hace la web inaccesible de por sí a todo aquel que no disponga de java o/y javascript. Esto es debido a que vuestra web se ha transformado, de alguna forma, en una aplicación. Al perder la condición de web, las WCAG ya no tienen sentido, ya que no estamos hablando de la web universal definida por la W3C. Para resolverlo, sugiere dos posibilidades:

1. Si queréis que TODO EL MUNDO pueda acceder a vuestra web, me temo que el problema es difícil de resolver sin realizar modificaciones en la aplicación. Deberíais separar la interfaz de la lógica perfectamente. Normalmente todo tiene una solución más sencilla de lo que parece, es cuestión de darle vueltas y proporcionar mecanismos alternativos: solicitar manualmente la inclusión de algunos datos, o separar en varias etapas diversos procesos para aquellos usuarios que no dispongan de las tecnologías requeridas.
2. Si no podéis separar la lógica implementada en el applet y en javascript, debéis asumir que no podéis llegar a todo el mundo, y por tanto las WCAG no tienen sentido. Solo podéis optar a hacerla lo más accesible posible para las personas que disponen de las tecnologías requeridas.

Insisto, yo creo que Alejandro Cuesta da en el clavo. Sin embargo, Javier Echeverría responde a Alejandro que:

Este es un tema en el que la tecnología Web está todavía un poco verde. Como bien dice Alberto, es imposible acceder al almacén de certificados de cliente sin utilizar una aplicación (en Web un applet o un ActiveX), y esto es necesario para la firma electrónica, en la que se necesita el acceso a un certificado digital para firmar con la clave privada del mismo. Esto es imposible hacerlo con HTML, evidentemente. Aquí aparece una controversia, y es que desde las Administraciones Públicas se quiere a la vez avanzar en trámitación electrónica basada en firma electrónica con certificados digitales, y a la vez en la accesibilidad a los contenidos Web. El objetivo será entonces tratar de hacer accesibles todos los contenidos, quedando fuera la tramitación para aquellos dispositivos y navegadores que no lo posibilitan.

Ante lo cual, yo planteo que (...) se considera una aplicación web a determinado contenido que puede ser usado a través de la Web. Cualquier contenido vía web es contenido web, sea el de una aplicación accesible vía web o el de una simple página web de información. Por tanto, las Directrices de Accesibilidad del Contenido Web (WCAG) sí que se aplican a esas aplicaciones. Esto yo creo que es así, a no ser que pensemos en aplicaciones de aspecto win32, como dice un amigo.

Javier Echeverría responde reforzando lo que anteriormente había expuesto y afirma categórico que el problema de la firma digital accesible está en el estado de la tecnología Web hoy, en 2005. Para explicar por qué no es posible acceder a certificados digitales sin javacript o applets de Java -que parece ser el quid de la cuestión-, Echeverría explica los pasos que aparecen en la administración electrónica:

1. Coger los datos HTML que ha introducido un usuario, incluyendo, por ejemplo, los ficheros que adjunta en un formulario.
2. Hacer un hash (tipo MD5 o SHA-1) de todo eso.
3. Encriptar este hash con la clave privada del cliente. Esto significa que debemos consultar al almacén de certificados del cliente, hacerle escoger con cuál quiere firmar, y utilizar la clave privada almacenada en el certificado escogida para encriptar de forma simétrica ese hash.
4. 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.

Salvo que tenga un grave error de concept, todos los pasos a) b) c) y d) deben realizarse con TECNOLOGIAS DE CLIENTE, es decir, en el cliente. No se puede hacer viajar la clave privada al servidor (apañados iríamos, ya que la base de la firma digital es que la clave privada no se mueva de su sitio si no quiere el dueño Desconozco si habrá un super-innovador proyecto que arregle esto, y además al final depende del API que te dé la plataforma de autenticación y firma (en Andalucía usamos @Firma), el caso es que aquí es 100% obligatorio el uso de lógica en el cliente.

Hablando con otros compañeros de trabajo, pensamos que la administración electrónica con firma digital sería posible de la siguiente forma. Imaginemos que queremos realizar el pago del IVA

1. La Agencia Tributaria -organismo de la administración pública- genera un par de claves, una pública y una privada, con un certificado firmado con su propio CA. Te dan las dos claves y una copia de la clave pública del CA, y ellos se quedan con una copia de la clave pública tuya.
2. En el programa añades su certificado -clave pública de CA- de CA y tu certificado firmado con tu clave privada.
3. Así, compruebas que efectivamente te conectas a la Agencia Tributaria y por otro lado ellos comprueban que eres tú quien se conecta.
4. Además, se podría poner un sistema de usuario y contraseña.
5. Si la información la rellenas en línea a través de un formulario, no puedes guardar de una forma sencilla los datos que rellenas pero ellos podrían enviarte:
   • Un PDF firmado electrónicamente por ellos con tus datos rellenos a una dirección de correo electrónico, con el correo electrónico firmado también.
   • Un PDF impreso, sellado por ellos y enviado por correo postal certificado a tu domicilio.
   • Ambos documentos

No sé si esta explicación ya la había imaginado Javier Echeverría en otro mensaje que:

no todos los browsers (corregidme si me equivoco) tienen implementado un almacén de certificados digitales. Accesos equivalentes: haberlos haylos, como as meigas, pero dudo que manteniendo la validez legal del proceso. Es evidente que no hace falta un certificado digital para autenticarse en un sistema (llevamos toda la vida usando usuario y contraseña en los bancos), ni un certificado digital para firmar algo (en el banco hacemos la transferencia metiendo una clave y el dinero va). La autenticación con usuarios y contraseñas es perfectamente accesible, pero me temo que no asumible en Administración Electrónica como legal. ¡El DNI electrónico no es más que un soporte para el certificado digital! De ahí que pueda haber un pequeño imposible que no creo que sea culpa de ninguno de los dos mundos...

Digo que no lo sé porque no sé por qué no es asumible por la administración electrónica como algo legal un proceso como el que narrábamos. Por otro lado, no conozco en Internet Explorer pero en Mozilla, Firefox, Opera, Galeon, Epiphany o Lynx sí que se pueden administrar certificados digitales. Por tanto, ¿cuál es el pequeño imposible?

A todo esto, Juan L. Lara planteaba otra cuestión interesante, que es la sensibilización de la sociedad para lograr efectivamente la accesibilidad en la web:

Es necesario que haya una voluntad política real de poner el tema de la accesibilidad web en la agenda pública, que los medios colaboren y se cree esa conciencia colectiva que respalde los cambios y dote de fuerza y legitimación a la regulación comunitaria, nacional, regional o del rango que sea. Sin ello, seguirá siendo la lucha de unos pocos (cada vez más afortunadamente).

Sin duda parece que en esta lista y en otras iniciativas que parten del Sidar estamos en ello.