viernes, 13 de abril de 2007

Accesibilidad, firma electrónica y DNIe en el ámbito de las Administraciones Públicas

Las aplicaciones Web de la Administración Pública española, desde el 1 de enero de 2006, deben cumplir los requisitos de accesibilidad W3C-WAI según la Ley 34/2002 [1] (aunque no se especifica el nivel mínimo de adecuación recomendado, el exigido en otros textos a nivel nacional [2] y desde la Unión Europea [3] es explícitamente la Doble A).

Por otro lado, la Administración Pública española debe ofrecer servicios de tramitación telemática [4], para los cuales se requiere firma electrónica, que permite identificar al firmante, verificar la integridad de su mensaje y asegurar su autoría, en caso de que éste decidiera negarla. [5]

La Ley distingue dos tipos de firma electrónica. La firma electrónica avanzada, que se define según la Ley 59/2003 [5] como:

"Art. 3.2 La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control."


y la firma electrónica reconocida, que se define según la Ley 59/2003 [5] como:

"[...] que se define siguiendo las pautas impuestas en la Directiva 1999/93/CE como la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma. A la firma electrónica reconocida le otorga la Ley la equivalencia funcional con la firma manuscrita respecto de los datos consignados en forma electrónica.

[...]

Con ello se aclara que no basta con la firma electrónica avanzada para la equiparación con la firma manuscrita; es preciso que la firma electrónica avanzada esté basada en un certificado reconocido y haya sido creada por un dispositivo seguro de creación."


Un dispositivo seguro de creación como el DNIe.


No pretendo aquí incluir un manual de firma electrónica, pero sí que es necesario decir que, en ambos casos, el funcionamiento de la firma electrónica está basado es una clave pública y una clave privada. La clave privada sólo está en poder del propietario, que debe conservarla de forma segura, y por tanto jamás debe abandonar la máquina del cliente (en realidad, en el caso de la firma reconocida, ésta nunca sale del chip de la smartcard o dispositivo). Por ello no podremos realizar nunca la firma electrónica en el servidor.


Y entonces llegamos a donde quería ir a parar, que la firma electrónica requiere lógica en cliente, por un lado la utilización de Javascript y por otro la necesidad de un ActiveX o un applet (las opciones más habituales), ya que, también por motivos de seguridad, mediante Javascript no tendrías nunca permisos para acceder, por ejemplo, al almacén de certificados.


El punto de verificación 6.3 de las Pautas de Accesibilidad de la WAI (que como hemos dicho deben acatar las aplicaciones de las Administraciones Públicas) dice así:



"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".



Dicho punto es de Prioridad 1, es decir, es necesario para alcanzar un nivel de adecuación Simple A, el menos exigente (recordemos que hemos dicho que el nivel mínimo recomendado era la Doble A, el siguiente nivel de adecuación y más exigente que la Simple A).


La WAI es realista, prevé que en aquellos casos en los cuales la tecnología del momento no alcanza para ofrecer la plena accesibilidad de un servicio, no habrá más solución que ofrecer una versión o un modo de interacción diferente. En este caso habría que ofrecer una alternativa accesible para los usuarios cuyo navegador no admite o no tiene activo el Javascript (según W3C el 10% de los usuarios navegan con el Javascript desactivado), así como para aquellos que no puedan ejecutar el ActiveX o el applet.


Podría pensarse en una alternativa como la que estamos habituados en los entornos de banca, después de informar al usuario de que su navegador no admite Javascript o no lo tiene activado, o que si bien admite Javascript no puede ejecutar los componentes cliente de firma electrónica (ActiveX o Applet) y que por tanto no podrá autenticarse o firmar con certificado digital, informarle como digo de que sí que podrá hacerlo mediante usuario y contraseña, reforzado por ejemplo con una tarjeta de coordenadas, incluso disponible en versión braille como la que ofrece Bankinter a sus clientes.


El problema es que, aunque esta solución podría valernos para la autenticación, en el caso de la firma electrónica, dentro de la Administración Pública no tendría validez legal, puesto que se exige que la firma electrónica ofrezca garantías de Autenticación, Integridad y No repudio, lo que le confiere validez legal. [5] .


Por tanto, nos encontramos con una paradoja: la Administración Pública debe ofrecer servicios de tramitación telemática que necesitan de firma electrónica, pero a su vez debe cumplir con las Pautas de Accesibilidad de la WAI. Y ambos son incompatibles hoy en día. Podrán hacerse accesibles todos los contenidos salvo aquellos que requieran firma electrónica.


A este respecto, la web del Ministerio de Fomento, en su apartado de Accesibilidad dice así:


“Todas las aplicaciones satisfacen todos los puntos de verificación de prioridad 1 y 2 definidos en las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0) por la Iniciativa de Accesibilidad Web (WAI) del World Wide Web Consortium (W3C). De acuerdo a lo anterior, ninguna de las aplicaciones necesita para alcanzar su funcionalidad completa el uso de javascript.

En el caso de que la complejidad de los formularios haya aconsejado mantener funcionalidades que hagan uso de javascript para mejorar su usabilidad, se ofrece una versión accesible AA alternativa y equivalente.

No obstante es necesario puntualizar lo siguiente: Por motivos de seguridad es necesario que las operaciones de firma se realicen en su navegador, por lo que éste debe capaz de ejecutar javascript y los componentes cliente de firma electrónica (ActiveX o Applet). Ésta es la única excepción a la norma y la única funcionalidad que emplee javascript que usted se encontrará si elige usar la versión accesible AA de las aplicaciones.”


Paradójico, como digo: podrás realizar todo el proceso pero no te servirá de nada, porque al final no podrás firmar, deberás cerrar el ordenador e irte a hacer cola a una ventanilla.


La tecnología Web debe avanzar, así que si os queréis forrar ya sabéis lo que tenéis que patentar: una forma de realizar firma electrónica accesible, sin necesidad de lógica en cliente. Hoy en día suena a ciencia ficción, ya veremos mañana.



NOTAS

[1] Ley 34/2002, en su Disposición Adicional Quinta.


Las Administraciones públicas adoptarán las medidas necesarias para que la información disponible en sus respectivas páginas de Internet pueda ser accesible a personas con discapacidad y de edad avanzada, de acuerdo con los criterios de accesibilidad al contenido generalmente reconocidos, antes del 31 de diciembre de 2005.

[2] Por ejemplo, en el marco concreto de los registros y las notificaciones telemáticas, los "Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades" (Criterios SNC)”. Indica en su apartado cinco específicamente la Doble A:

La Orden PRE/1551/2003, de 10 junio, por la que se desarrolla la Disposición final primera del Real Decreto 209/2003, de 21de febrero de 2003, que regula los registros y las notificaciones telemáticas, así como la utilización de medios telemáticos para la sustitución de certificados por los ciudadanos, establece que el registro telemático y el servicio de notificación telemática deberán cumplir los requerimientos en materia de accesibilidad establecidos por la Iniciativa para una Web Accesible (WAI) del Consorcio World Wide Web y en particular las especificaciones de la Recomendación de 5 de mayo de 1999 sobre Pautas de Accesibilidad del Contenido en la Web, versión 1.0, en su nivel AA.

[…]

5.2 Los servicios electrónicos puestos por la Administración a disposición del ciudadano deben ser visualizables, accesibles y funcionalmente operables desde diversos navegadores alternativos. En particular, se deben adaptar las aplicaciones web a los estándares del World Wide Web Consortium (W3C), evitar la utilización de extensiones propietarias de navegadores y verificar el sitio web, al menos, con http://validator.w3.org/. (Véase capítulo 'Software libre y de fuentes abiertas')


[3] Por ejemplo en la Resolución del Parlamento Europeo sobre la Comunicación de la Comisión “eEurope 2002: Accesibilidad de los sitios Web públicos y de su contenido (COM(2001) 529 – C5 – 0074/2002 – 2002/2032(COS) de abril de 2002,” en su punto 30:

Subraya que para que los sitios web sean accesibles es fundamental que satisfagan el nivel doble A y que se aplique en su totalidad la prioridad 2 de las Pautas WAI.

[4] El artículo 45 de la Ley 30/1992, impone a las Administraciones Públicas la obligación de impulsar el empleo y aplicación de técnicas electrónicas, informáticas y telemáticas en el desarrollo de su actividad y el ejercicio de sus competencias. Esta tarea de promoción recibió un nuevo impulso legislativo con la reforma operada por la Ley 24/2001.

[Más información]

[5] Ley 59/2003, de 19 de septiembre, de firma electrónica.

11 comentarios :
torresburriel dijo...

Jejejeje, mira que molan las cosas en negro sobre blanco :-)

Muy buen post.

Jesús dijo...

Pues lo cierto es que, como siempre, los propios navegadores terminarán dando solución a esto mediante la interpretación de nuevas etiquetas XHTML.

Hay empresas como la nuestra que en parte perderán un pelín de negocio (pero ganaremos en tranquilidad, ya que la distribución de componentes cliente para la ejecución dentro del navegador causa más dolores de cabeza e inversión de tiempo que beneficios, esa es la verdad).

Y en realidad es volver al pasado pero con etiquetas HTML en lugar de componentes Javascript del propio navegador: ya el infame Netscape 4 tenía funciones javascript del tipo "Crypto.signText()" nativas. Entiendo que la nueva especificación del W3C definirá nuevos tipos de botón, por ejemplo "signAndSubmit", para la firma de todo un formulario seguido del submit al servidor.

Como digo, pese a lo que pueda parecer como parte interesada, sinceramente creo que a las empresas de software especializadas en firma electrónica nos interesa tanto la estandarización como la universalización de estos componentes.

El negocio está en la parte servidor, y es un entorno 99% controlable. Las grandes consultoras así lo han entendido y sólo empresas innovadoras como la nuestra dan solución a aspectos como el envío de ficheros grandes desde el navegador, o a la firma electrónica/cifrado/etc, mediante agentes ActiveX y Applet especializados.

Pero es sólo mi opinión personal, claro.

Enhorabuena por el blog.

Roger Carhuatocto dijo...

Entiendo que la firma digital en trámites de las administración pública será incompatible con las normas WAI únicamente sobre el 10% de usuarios y que son aquellos que tienen el JavaScript desactivado o quizá no pueden usar ActiveX o Java Applets.
Al final las restricciones técnicas hacen que sea dificil cumplir las normas WAI. La Administracione Pública considera este 10% muy pequeño ya es dificil encontrar a un usuario que tenga DNIe, lo use para efectuar un trámite por internet y que tenga el JavaScript desactivado. La solución para la Administración Pública es formar y preparar a estos usuarios antes de liarse en implementar algún mecanismo técnico que permita firmar digitalmente sin usar JavaScript, Applet y/o ActiveX.

Esto nosotros lo estamos haciendo, formando e informando del proceso que deben seguir las personas para usar el DNIe.

A veces la solución a un problema técnico es uno no técnico.

Saludos.

-roger

Olga Carreras dijo...

El problema no es sólo los usuarios que no tengan javascript activado, sino los usuarios que usan user-agents que no admitan javascript, y estos suelen ser usuarios con discapacidad, decir que como son una minoría no es importante es discriminatorio.

Anónimo dijo...

Entrada sobre accesibilidad y firma electronica:
http://xnoccio.com/316-firma-electronica-y-accesibilidad-web/

Anónimo dijo...

Mayo 2008: Firma electrónica y accesibilidad web

Anónimo dijo...

Hola! Felicidades por ese estupendo post. Sólo una cosita, cambia ese paradógico por paradóJico. Un saludo

Olga Carreras dijo...

Ya está, gracias!

Santi dijo...

Olga, me ha gustado como planteas el tema: Es contradictorio disponer de un script generador de firma y cumplir con un mínimo nivel de accesibilidad (nivel A). Pero ¿dónde está el problema para la accesibilidad si se utiliza tarjeta inteligente o HSM? En estos casos, la lógica de la firma está dentro de la tarjeta/HSM, y la llamada a este HW puede realizarse por medios distintos a los scripts.

Anónimo dijo...

Hola Olga,

¿Hubo algún avance este tema? ¿existe hoy en día la firma electrónica accesible?

Olga Carreras dijo...

Actualmente están vigente las WCAG 2.0, sobre el uso de javascript en las WCAG 2.0 http://olgacarreras.blogspot.com.es/2011/01/respuesta-25-dudas-habituales-sobre.html#1904095

Publicar un comentario en la entrada