Atenea tech ha desarrollado un módulo de Drupal para la autenticación de usuarios con certificados electrónicos utilizando el sistema verificación de identidad de Tractis. El plugin da la posibilidad de añadir login con certificados (DNI electrónico, catcert y otros) en cualquier sitio web desarrollado con Drupal.
¿Y por qué dejar a un tercero la tarea de verificación e identificación cuando la podemos hacer nosotros?
Vamos, no tengo nada en contra de Tractis, pero quién garantiza que la información que devuelve Tractis procede del certificado que se está verificando en sus servidores. Parece buena idea para ahorrarse el plug-in Java que hay que desarrollar para poder hacer la validación desde un servidor web, pero creo que si se requiere la seguridad que proporcionan los certificados entonces merece la pena hacerlo.
Para muestra los bancos que permiten log-in vía DNIe... todos utilizan sus propias aplicaciones (por la cuenta que les trae). Hace tiempo estuve pensando en esta forma de log-in para un CMS PHP cualquiera, pero el hecho de tener que depender de Java me quita bastante porque implica un requisito más de cara al usuario... a ver cuándo es el día que el propio navegador proporciona los elementos necesarios y así se pueda hacer sin aplicaciones extra.
Las cuestiones que planteas son muy relevantes y me gustaría aportar nuestra visión del tema desde Tractis.
FILOSOFÍA DE DESARROLLO
=======================
Detrás de estos desarrollos hay un, podríamos llamarlo, "trasfondo filosófico" basado en el pensamiento de Lawrence Lessig. Para las personas interesadas en el tema pero que no hayan leído sus libros, el propio Lessig resume muy bien su pensamiento en este artículo cortito "Code is Law. On Liberty on Cyberspace (Harvard Magazine Jan-Feb 2000)" [1]. Se trata de un texto que hemos comentado mucho internamente y utilizado de base para los desarrollos de verificación de identidad. En resumen, Lessig dice que:
1. El código es la ley. El código informático puede regular la conducta en Internet tanto o más que el código legal.
2. Sin embargo este "Código" puede cambiar y, de hecho, está cambiando por la presión de empresas y gobiernos. No hay nada más peligroso que creer que el código es inmutable.
3. Ya que el código está cambiando, lo correcto es involucrarse y participar en el desarrollo del nuevo código para tener voz sobre como se van a producir estos cambios y no cerrar los ojos y clamar que el cambio es imposible.
Curiosamente, mucha gente cita a Lessig pero se queda en el punto 1. Afirman que el código es la ley e inmutable y que, por tanto, cualquier intento de identificación en internet está abocado al fracaso. Digo "curiosamente" porque es justo lo contrario de lo que dice Lessig.
Ya que el cambio se está produciendo [2], queremos adelantarnos y hacerlo bien y, con vuestra ayuda, explicar al mercado por qué esta es la manera correcta de hacerlo y porqué el nuevo código debe respetar estos valores:
* Opcionalidad: Nada de DNIe obligatorio o, si no, no inicias sesión, no comentas en un blog, etc...
* Transparencia: En todo momento, el usuario sabe quien (sitio web) te pide que verifiques tu identidad y qué datos va a consultar.
* Independencia: La verificación de identidad es realizada por un tercero independiente, no por el dueño del sitio web ni por el que se autentica.
* Universalidad: Acceso universal: cualquier persona debe ser capaz de utilizar el sistema. Para ello es necesario proporcionar alta usabilidad (nada de sistemas solo para techies) y soportar múltiples sistemas operativos (Windows, Linux/Unix, Mac OSX), navegadores (Firefox, IE, Safari, Opera) y certificados.
* Granularidad: Nada de "one-card-shows-all". Por un lado, el dueño del sitio web debe poder configurar qué atributos de la identidad desea verificar y cuales no (p.ej: necesito conocer la edad pero no la nacionalidad, etc.) y, por otro, el usuario debe poder revelar solo la información necesaria.
RESPUESTA A TUS COMENTARIOS
===========================
* "¿Y por qué dejar a un tercero la tarea de verificación e identificación cuando la podemos hacer nosotros?"
Hay varias razones para preferir que la verificación de identidad la realice un tercero. Por un lado, independencia: la verificación la realiza un tercero independiente al sitio web y el usuario (imagina a David Bravo comentando en el blog de la SGAE). Por otro lado, granularidad: dado que el dueño del sitio web puede configurar qué atributos desea verificar y cuales no, el usuario tiene la tranquilidad de que no está entregando todos los datos contenidos en su DNIe (o el certificado que sea) a todos los sitios web que se lo solicitan.
Finalmente, no todo el mundo dispone de los recursos, conocimientos o tiempo necesario para desarrollar un sistema de verificación de identidad capaz de validar certificados de distintos países (en la actualidad, 46 perfiles de certificados de 23 Autoridades de Certificación en 10 países distintos [3]) y de validar los distintos atributos de cada perfil de certificado (en la actualidad, 8 atributos: "Fecha de nacimiento", "CIF", "DNI", "Emisor del certificado", "Nombre completo", "Asociación Profesional", "Dirección" y "Titulo" ), máxime cuando hay que hacer un mapeo distinto para cada perfil ya que cada Autoridad coloca estos atributos en distintos sitios del certificado.
* "quién garantiza que la información que devuelve Tractis procede del certificado que se está verificando en sus servidores."
Si lo que te preocupa es que Tractis haga las cosas bien, esta es la eterna pregunta. Una pregunta que se puede hacer con respecto a un montón de servicios (¿quien garantiza que Visa o Paypal o Moneybookers hacen los pagos bien?, ¿que Gmail no lee tus correos?, etc...). La respuesta es que si utilizas un servicio es porque confías que ese servicio hace las cosas bien. Es un tema de confianza. Cada vez que validamos un certificado, la Autoridad de Certificación de que se trate (en el caso del DNIe, la Dirección General de la Policía) devuelve siempre una respuesta firmada electrónicamente sobre si el certificado es válido o ha sido revocado. En caso de que surja un conflicto, podríamos presentar estas evidencias irrefutables ante el juez. Sin embargo, hemos descartado proporcionar de entrada esta lista de respuestas al dueño del sitio web porque estaríamos dándole acceso todos los datos personales del usuario en vez de solo los que necesita y, por tanto, incumpliendo el principio de granularidad.
Si lo que te preocupa es comprobar la veracidad de los datos recibidos en tu sistema, la especificación de la integración de verificación de identidad de Tractis [4] establece la necesidad de que tu aplicación haga una petición a Tractis para contrastar los datos recibidos.
* "Para muestra los bancos que permiten log-in vía DNIe... todos utilizan sus propias aplicaciones (por la cuenta que les trae)."
Discrepo. El hecho de que los bancos estén utilizando sus propias aplicaciones es más un síntoma de los efectos de la crisis que de un deseo de hacer las cosas bien.
En la actualidad, la práctica totalidad de los bancos que ofrecen autenticación con DNIe [5] lo hacen de manera muy deficiente: solo para un sistema operativo (Windows), solo para un navegador (Internet Explorer), solo para un certificado (DNIe) y solo para un propósito (autenticación). Al limitar tanto el alcance del desarrollo es posible (utilizando un control Active X) ofrecer autenticación con DNIe de forma barata pero a costa de incumplir el principio de universalidad (¿qué pasa con el resto de sistemas operativos, navegadores, certificados y posibles usos?).
* "el hecho de tener que depender de Java me quita bastante porque implica un requisito más de cara al usuario... a ver cuándo es el día que el propio navegador proporciona los elementos necesarios y así se pueda hacer sin aplicaciones extra."
Coincido contigo: cualquier requisito extra de cara al usuario es indeseable.
Hay varias opciones, cada una con ventajas y desventajas. La primera es utilizar Active X (solo funciona en Windows e Internet Explorer, rompe el principio de universalidad). Otra es dejarlo en manos del navegador (ya es posible a día de hoy, pero la usabilidad deja mucho que desear -ejemplo [6]-, habría que formar al usuario -> pasaporte seguro a frustración, fracaso y baja utilización del sistema) y la tercera, la que hemos elegido, es un applet de Java (requiere JVM pero funciona en todas las plataformas y te permite controlar la usabilidad, mensajes al usuario, interface, proceso de autenticación/firma, etc). A día de hoy, si necesitas crear un servicio o aplicación que verifique la identidad real de tus usuarios utilizando certificados, creemos que Java es la mejor opción.
Espero haber podido arrojar algo de luz sobre cuales sobre las razones detrás de nuestras decisiones de desarrollo. Para nosotros, estos temas no son solo tecnología y empresa sino una oportunidad de participar en la definición del Internet del futuro. Creo que es muy importante que se empiece a hablar de estos temas y a darles la importancia que merecen y, por tanto, por nuestra parte, cualquier comentario, crítica o sugerencia es bienvenido.
Las cuestiones que planteas son muy relevantes y me gustaría aportar nuestra visión del tema desde Tractis.
FILOSOFÍA DE DESARROLLO
=======================
Detrás de estos desarrollos hay un, podríamos llamarlo, "trasfondo filosófico" basado en el pensamiento de Lawrence Lessig. Para las personas interesadas en el tema pero que no hayan leído sus libros, el propio Lessig resume muy bien su pensamiento en este artículo cortito "Code is Law. On Liberty on Cyberspace (Harvard Magazine Jan-Feb 2000)" [1]. Se trata de un texto que hemos comentado mucho internamente y utilizado de base para los desarrollos de verificación de identidad. En resumen, Lessig dice que:
1. El código es la ley. El código informático puede regular la conducta en Internet tanto o más que el código legal.
2. Sin embargo este "Código" puede cambiar y, de hecho, está cambiando por la presión de empresas y gobiernos. No hay nada más peligroso que creer que el código es inmutable.
3. Ya que el código está cambiando, lo correcto es involucrarse y participar en el desarrollo del nuevo código para tener voz sobre como se van a producir estos cambios y no cerrar los ojos y clamar que el cambio es imposible.
Curiosamente, mucha gente cita a Lessig pero se queda en el punto 1. Afirman que el código es una especie de ley inmutable y que, por tanto, cualquier intento de identificación en internet está abocado al fracaso. Digo "curiosamente" porque es justo lo contrario de lo que dice Lessig.
Ya que el cambio se está produciendo [2], queremos adelantarnos y hacerlo bien y, con vuestra ayuda, explicar al mercado por qué esta es la manera correcta de hacerlo y porqué el nuevo código debe respetar estos valores:
* Opcionalidad: Nada de DNIe obligatorio o, si no, no inicias sesión, no comentas en un blog, etc...
* Transparencia: En todo momento, el usuario sabe quien (sitio web) te pide que verifiques tu identidad y qué datos va a consultar.
* Independencia: La verificación de identidad es realizada por un tercero independiente, no por el dueño del sitio web ni por el que se autentica.
* Universalidad: Acceso universal: cualquier persona debe ser capaz de utilizar el sistema. Para ello es necesario proporcionar un elevado nivel de usabilidad (nada de sistemas solo para techies) y soportar múltiples sistemas operativos (Windows, Linux/Unix, Mac OSX), navegadores (Firefox, IE, Safari, Opera) y certificados.
* Granularidad: Nada de "one-card-shows-all". Por un lado, el dueño del sitio web debe poder configurar qué atributos de la identidad desea verificar y cuales no (p.ej: necesito conocer la edad pero no el nombre ni la nacionalidad) y, por otro, el usuario debe poder revelar solo la información necesaria.
RESPUESTA A TUS COMENTARIOS
===========================
* "¿Y por qué dejar a un tercero la tarea de verificación e identificación cuando la podemos hacer nosotros?"
Hay varias razones para preferir que la verificación de identidad la realice un tercero. Por un lado, independencia: si la verificación la realiza un tercero independiente al sitio web y el usuario, ninguno de los dos tiene que probar/convencer sobre el funcionamiento del sistema al otro (imagina a David Bravo comentando en el blog de la SGAE). Por otro lado, granularidad: dado que el dueño del sitio web puede configurar qué atributos desea verificar y cuales no, el usuario tiene la tranquilidad de que no está entregando todos los datos contenidos en su DNIe (o el certificado que sea) a todos los sitios web que se lo solicitan.
Finalmente, no todo el mundo dispone de los recursos, conocimientos o tiempo necesario para desarrollar un sistema de verificación de identidad capaz de validar certificados de distintos países (en la actualidad, 46 perfiles de certificados de 23 Autoridades de Certificación en 10 países distintos [3]) y de validar los distintos atributos de cada perfil de certificado (en la actualidad, 8 atributos: "Fecha de nacimiento", "CIF", "DNI", "Emisor del certificado", "Nombre completo", "Asociación Profesional", "Dirección" y "Titulo" ), máxime cuando hay que hacer un mapeo distinto para cada perfil ya que cada Autoridad coloca estos atributos en distintos sitios del certificado.
* "quién garantiza que la información que devuelve Tractis procede del certificado que se está verificando en sus servidores."
Si lo que te preocupa es que Tractis haga las cosas bien, esta es la eterna pregunta. Una pregunta que se puede hacer con respecto a un montón de servicios (¿quien garantiza que Visa o Paypal o Moneybookers hacen los pagos bien?, ¿que Gmail no lee tus correos?, etc...). La respuesta es que si utilizas un servicio es porque confías que ese servicio hace las cosas bien. Es un tema de confianza. Cada vez que validamos un certificado, la Autoridad de Certificación de que se trate (en el caso del DNIe, la Dirección General de la Policía) devuelve siempre una respuesta firmada electrónicamente sobre si el certificado es válido o ha sido revocado. En caso de que surja un conflicto, podríamos presentar estas evidencias irrefutables ante el juez. Sin embargo, hemos descartado proporcionar de entrada esta lista de respuestas al dueño del sitio web porque estaríamos dándole acceso todos los datos personales del usuario en vez de solo los que necesita y, por tanto, incumpliendo el principio de granularidad.
Si lo que te preocupa es comprobar la veracidad de los datos recibidos en tu sistema, la especificación de la integración de verificación de identidad de Tractis [4] establece la necesidad de que tu aplicación haga una petición a Tractis para contrastar los datos recibidos.
* "Para muestra los bancos que permiten log-in vía DNIe... todos utilizan sus propias aplicaciones (por la cuenta que les trae)."
Discrepo. El hecho de que los bancos estén utilizando sus propias aplicaciones es más un síntoma de los efectos de la crisis que de un deseo de hacer las cosas bien.
En la actualidad, la práctica totalidad de los bancos que ofrecen autenticación con DNIe [5] lo hacen de manera muy deficiente: solo para un sistema operativo (Windows), solo para un navegador (Internet Explorer), solo para un certificado (DNIe) y solo para un propósito (autenticación). Al limitar tanto el alcance del desarrollo es posible (utilizando un control Active X) ofrecer autenticación con DNIe de forma barata pero a costa de incumplir el principio de universalidad (¿qué pasa con el resto de sistemas operativos, navegadores, certificados y posibles usos?).
* "el hecho de tener que depender de Java me quita bastante porque implica un requisito más de cara al usuario... a ver cuándo es el día que el propio navegador proporciona los elementos necesarios y así se pueda hacer sin aplicaciones extra."
Coincido contigo: cualquier requisito extra de cara al usuario es indeseable.
Hay varias opciones, cada una con ventajas y desventajas. La primera es utilizar Active X (solo funciona en Windows e Internet Explorer, rompe el principio de universalidad). Otra es dejarlo en manos del navegador (ya es posible a día de hoy, pero la usabilidad deja mucho que desear -ejemplo [6]-, habría que formar al usuario -> pasaporte seguro a frustración, fracaso y baja utilización del sistema) y la tercera, la que hemos elegido, es un applet de Java (requiere JVM pero funciona en todas las plataformas y te permite controlar la usabilidad, mensajes al usuario, interface, proceso de autenticación/firma, etc). A día de hoy, si necesitas crear un servicio o aplicación que verifique la identidad real de tus usuarios utilizando certificados, creemos que Java es la mejor opción.
Espero haber podido arrojar algo de luz sobre cuales sobre las razones detrás de nuestras decisiones de desarrollo. Para nosotros, estos temas no son solo tecnología y empresa sino una oportunidad de participar en la definición del Internet del futuro. Creo que es muy importante que se empiece a hablar de estos temas y a darles la importancia que merecen y, por tanto, por nuestra parte, cualquier comentario, crítica o sugerencia es bienvenido.
Comentarios
¿Y por qué dejar a un tercero la tarea de verificación e identificación cuando la podemos hacer nosotros?
Vamos, no tengo nada en contra de Tractis, pero quién garantiza que la información que devuelve Tractis procede del certificado que se está verificando en sus servidores. Parece buena idea para ahorrarse el plug-in Java que hay que desarrollar para poder hacer la validación desde un servidor web, pero creo que si se requiere la seguridad que proporcionan los certificados entonces merece la pena hacerlo.
Para muestra los bancos que permiten log-in vía DNIe... todos utilizan sus propias aplicaciones (por la cuenta que les trae). Hace tiempo estuve pensando en esta forma de log-in para un CMS PHP cualquiera, pero el hecho de tener que depender de Java me quita bastante porque implica un requisito más de cara al usuario... a ver cuándo es el día que el propio navegador proporciona los elementos necesarios y así se pueda hacer sin aplicaciones extra.
Para lo que estoy desarrollando no es interesante este módulo. Pero he de reconocer que me he alegrado mucho al leerlo.
Saludos
Llevo más de un año desarrollando con Drupal y cada día estoy más contento con la elección.
Hola wschutz,
Las cuestiones que planteas son muy relevantes y me gustaría aportar nuestra visión del tema desde Tractis.
FILOSOFÍA DE DESARROLLO
=======================
Detrás de estos desarrollos hay un, podríamos llamarlo, "trasfondo filosófico" basado en el pensamiento de Lawrence Lessig. Para las personas interesadas en el tema pero que no hayan leído sus libros, el propio Lessig resume muy bien su pensamiento en este artículo cortito "Code is Law. On Liberty on Cyberspace (Harvard Magazine Jan-Feb 2000)" [1]. Se trata de un texto que hemos comentado mucho internamente y utilizado de base para los desarrollos de verificación de identidad. En resumen, Lessig dice que:
1. El código es la ley. El código informático puede regular la conducta en Internet tanto o más que el código legal.
2. Sin embargo este "Código" puede cambiar y, de hecho, está cambiando por la presión de empresas y gobiernos. No hay nada más peligroso que creer que el código es inmutable.
3. Ya que el código está cambiando, lo correcto es involucrarse y participar en el desarrollo del nuevo código para tener voz sobre como se van a producir estos cambios y no cerrar los ojos y clamar que el cambio es imposible.
Curiosamente, mucha gente cita a Lessig pero se queda en el punto 1. Afirman que el código es la ley e inmutable y que, por tanto, cualquier intento de identificación en internet está abocado al fracaso. Digo "curiosamente" porque es justo lo contrario de lo que dice Lessig.
Ya que el cambio se está produciendo [2], queremos adelantarnos y hacerlo bien y, con vuestra ayuda, explicar al mercado por qué esta es la manera correcta de hacerlo y porqué el nuevo código debe respetar estos valores:
* Opcionalidad: Nada de DNIe obligatorio o, si no, no inicias sesión, no comentas en un blog, etc...
* Transparencia: En todo momento, el usuario sabe quien (sitio web) te pide que verifiques tu identidad y qué datos va a consultar.
* Independencia: La verificación de identidad es realizada por un tercero independiente, no por el dueño del sitio web ni por el que se autentica.
* Universalidad: Acceso universal: cualquier persona debe ser capaz de utilizar el sistema. Para ello es necesario proporcionar alta usabilidad (nada de sistemas solo para techies) y soportar múltiples sistemas operativos (Windows, Linux/Unix, Mac OSX), navegadores (Firefox, IE, Safari, Opera) y certificados.
* Granularidad: Nada de "one-card-shows-all". Por un lado, el dueño del sitio web debe poder configurar qué atributos de la identidad desea verificar y cuales no (p.ej: necesito conocer la edad pero no la nacionalidad, etc.) y, por otro, el usuario debe poder revelar solo la información necesaria.
RESPUESTA A TUS COMENTARIOS
===========================
* "¿Y por qué dejar a un tercero la tarea de verificación e identificación cuando la podemos hacer nosotros?"
Hay varias razones para preferir que la verificación de identidad la realice un tercero. Por un lado, independencia: la verificación la realiza un tercero independiente al sitio web y el usuario (imagina a David Bravo comentando en el blog de la SGAE). Por otro lado, granularidad: dado que el dueño del sitio web puede configurar qué atributos desea verificar y cuales no, el usuario tiene la tranquilidad de que no está entregando todos los datos contenidos en su DNIe (o el certificado que sea) a todos los sitios web que se lo solicitan.
Finalmente, no todo el mundo dispone de los recursos, conocimientos o tiempo necesario para desarrollar un sistema de verificación de identidad capaz de validar certificados de distintos países (en la actualidad, 46 perfiles de certificados de 23 Autoridades de Certificación en 10 países distintos [3]) y de validar los distintos atributos de cada perfil de certificado (en la actualidad, 8 atributos: "Fecha de nacimiento", "CIF", "DNI", "Emisor del certificado", "Nombre completo", "Asociación Profesional", "Dirección" y "Titulo" ), máxime cuando hay que hacer un mapeo distinto para cada perfil ya que cada Autoridad coloca estos atributos en distintos sitios del certificado.
* "quién garantiza que la información que devuelve Tractis procede del certificado que se está verificando en sus servidores."
Si lo que te preocupa es que Tractis haga las cosas bien, esta es la eterna pregunta. Una pregunta que se puede hacer con respecto a un montón de servicios (¿quien garantiza que Visa o Paypal o Moneybookers hacen los pagos bien?, ¿que Gmail no lee tus correos?, etc...). La respuesta es que si utilizas un servicio es porque confías que ese servicio hace las cosas bien. Es un tema de confianza. Cada vez que validamos un certificado, la Autoridad de Certificación de que se trate (en el caso del DNIe, la Dirección General de la Policía) devuelve siempre una respuesta firmada electrónicamente sobre si el certificado es válido o ha sido revocado. En caso de que surja un conflicto, podríamos presentar estas evidencias irrefutables ante el juez. Sin embargo, hemos descartado proporcionar de entrada esta lista de respuestas al dueño del sitio web porque estaríamos dándole acceso todos los datos personales del usuario en vez de solo los que necesita y, por tanto, incumpliendo el principio de granularidad.
Si lo que te preocupa es comprobar la veracidad de los datos recibidos en tu sistema, la especificación de la integración de verificación de identidad de Tractis [4] establece la necesidad de que tu aplicación haga una petición a Tractis para contrastar los datos recibidos.
* "Para muestra los bancos que permiten log-in vía DNIe... todos utilizan sus propias aplicaciones (por la cuenta que les trae)."
Discrepo. El hecho de que los bancos estén utilizando sus propias aplicaciones es más un síntoma de los efectos de la crisis que de un deseo de hacer las cosas bien.
En la actualidad, la práctica totalidad de los bancos que ofrecen autenticación con DNIe [5] lo hacen de manera muy deficiente: solo para un sistema operativo (Windows), solo para un navegador (Internet Explorer), solo para un certificado (DNIe) y solo para un propósito (autenticación). Al limitar tanto el alcance del desarrollo es posible (utilizando un control Active X) ofrecer autenticación con DNIe de forma barata pero a costa de incumplir el principio de universalidad (¿qué pasa con el resto de sistemas operativos, navegadores, certificados y posibles usos?).
* "el hecho de tener que depender de Java me quita bastante porque implica un requisito más de cara al usuario... a ver cuándo es el día que el propio navegador proporciona los elementos necesarios y así se pueda hacer sin aplicaciones extra."
Coincido contigo: cualquier requisito extra de cara al usuario es indeseable.
Hay varias opciones, cada una con ventajas y desventajas. La primera es utilizar Active X (solo funciona en Windows e Internet Explorer, rompe el principio de universalidad). Otra es dejarlo en manos del navegador (ya es posible a día de hoy, pero la usabilidad deja mucho que desear -ejemplo [6]-, habría que formar al usuario -> pasaporte seguro a frustración, fracaso y baja utilización del sistema) y la tercera, la que hemos elegido, es un applet de Java (requiere JVM pero funciona en todas las plataformas y te permite controlar la usabilidad, mensajes al usuario, interface, proceso de autenticación/firma, etc). A día de hoy, si necesitas crear un servicio o aplicación que verifique la identidad real de tus usuarios utilizando certificados, creemos que Java es la mejor opción.
Espero haber podido arrojar algo de luz sobre cuales sobre las razones detrás de nuestras decisiones de desarrollo. Para nosotros, estos temas no son solo tecnología y empresa sino una oportunidad de participar en la definición del Internet del futuro. Creo que es muy importante que se empiece a hablar de estos temas y a darles la importancia que merecen y, por tanto, por nuestra parte, cualquier comentario, crítica o sugerencia es bienvenido.
Enlaces:
[1] http://harvardmagazine.com/2000/01/code-is-law.html
[2] http://blog.negonation.com/es/tarjetas-inteligentes-en-europa-avalancha-de-e-id/
[3] https://www.tractis.com/accepted_certificates
[4] https://www.tractis.com/help/?p=3537&language=es#verify
[5] http://www.dnielectronico.es/servicios_disponibles/serv_disp_priv.html
[6] http://blog.negonation.com/es/wp-content/uploads/2009/07/dnie-firefox.png
Hola wschutz,
Las cuestiones que planteas son muy relevantes y me gustaría aportar nuestra visión del tema desde Tractis.
FILOSOFÍA DE DESARROLLO
=======================
Detrás de estos desarrollos hay un, podríamos llamarlo, "trasfondo filosófico" basado en el pensamiento de Lawrence Lessig. Para las personas interesadas en el tema pero que no hayan leído sus libros, el propio Lessig resume muy bien su pensamiento en este artículo cortito "Code is Law. On Liberty on Cyberspace (Harvard Magazine Jan-Feb 2000)" [1]. Se trata de un texto que hemos comentado mucho internamente y utilizado de base para los desarrollos de verificación de identidad. En resumen, Lessig dice que:
1. El código es la ley. El código informático puede regular la conducta en Internet tanto o más que el código legal.
2. Sin embargo este "Código" puede cambiar y, de hecho, está cambiando por la presión de empresas y gobiernos. No hay nada más peligroso que creer que el código es inmutable.
3. Ya que el código está cambiando, lo correcto es involucrarse y participar en el desarrollo del nuevo código para tener voz sobre como se van a producir estos cambios y no cerrar los ojos y clamar que el cambio es imposible.
Curiosamente, mucha gente cita a Lessig pero se queda en el punto 1. Afirman que el código es una especie de ley inmutable y que, por tanto, cualquier intento de identificación en internet está abocado al fracaso. Digo "curiosamente" porque es justo lo contrario de lo que dice Lessig.
Ya que el cambio se está produciendo [2], queremos adelantarnos y hacerlo bien y, con vuestra ayuda, explicar al mercado por qué esta es la manera correcta de hacerlo y porqué el nuevo código debe respetar estos valores:
* Opcionalidad: Nada de DNIe obligatorio o, si no, no inicias sesión, no comentas en un blog, etc...
* Transparencia: En todo momento, el usuario sabe quien (sitio web) te pide que verifiques tu identidad y qué datos va a consultar.
* Independencia: La verificación de identidad es realizada por un tercero independiente, no por el dueño del sitio web ni por el que se autentica.
* Universalidad: Acceso universal: cualquier persona debe ser capaz de utilizar el sistema. Para ello es necesario proporcionar un elevado nivel de usabilidad (nada de sistemas solo para techies) y soportar múltiples sistemas operativos (Windows, Linux/Unix, Mac OSX), navegadores (Firefox, IE, Safari, Opera) y certificados.
* Granularidad: Nada de "one-card-shows-all". Por un lado, el dueño del sitio web debe poder configurar qué atributos de la identidad desea verificar y cuales no (p.ej: necesito conocer la edad pero no el nombre ni la nacionalidad) y, por otro, el usuario debe poder revelar solo la información necesaria.
RESPUESTA A TUS COMENTARIOS
===========================
* "¿Y por qué dejar a un tercero la tarea de verificación e identificación cuando la podemos hacer nosotros?"
Hay varias razones para preferir que la verificación de identidad la realice un tercero. Por un lado, independencia: si la verificación la realiza un tercero independiente al sitio web y el usuario, ninguno de los dos tiene que probar/convencer sobre el funcionamiento del sistema al otro (imagina a David Bravo comentando en el blog de la SGAE). Por otro lado, granularidad: dado que el dueño del sitio web puede configurar qué atributos desea verificar y cuales no, el usuario tiene la tranquilidad de que no está entregando todos los datos contenidos en su DNIe (o el certificado que sea) a todos los sitios web que se lo solicitan.
Finalmente, no todo el mundo dispone de los recursos, conocimientos o tiempo necesario para desarrollar un sistema de verificación de identidad capaz de validar certificados de distintos países (en la actualidad, 46 perfiles de certificados de 23 Autoridades de Certificación en 10 países distintos [3]) y de validar los distintos atributos de cada perfil de certificado (en la actualidad, 8 atributos: "Fecha de nacimiento", "CIF", "DNI", "Emisor del certificado", "Nombre completo", "Asociación Profesional", "Dirección" y "Titulo" ), máxime cuando hay que hacer un mapeo distinto para cada perfil ya que cada Autoridad coloca estos atributos en distintos sitios del certificado.
* "quién garantiza que la información que devuelve Tractis procede del certificado que se está verificando en sus servidores."
Si lo que te preocupa es que Tractis haga las cosas bien, esta es la eterna pregunta. Una pregunta que se puede hacer con respecto a un montón de servicios (¿quien garantiza que Visa o Paypal o Moneybookers hacen los pagos bien?, ¿que Gmail no lee tus correos?, etc...). La respuesta es que si utilizas un servicio es porque confías que ese servicio hace las cosas bien. Es un tema de confianza. Cada vez que validamos un certificado, la Autoridad de Certificación de que se trate (en el caso del DNIe, la Dirección General de la Policía) devuelve siempre una respuesta firmada electrónicamente sobre si el certificado es válido o ha sido revocado. En caso de que surja un conflicto, podríamos presentar estas evidencias irrefutables ante el juez. Sin embargo, hemos descartado proporcionar de entrada esta lista de respuestas al dueño del sitio web porque estaríamos dándole acceso todos los datos personales del usuario en vez de solo los que necesita y, por tanto, incumpliendo el principio de granularidad.
Si lo que te preocupa es comprobar la veracidad de los datos recibidos en tu sistema, la especificación de la integración de verificación de identidad de Tractis [4] establece la necesidad de que tu aplicación haga una petición a Tractis para contrastar los datos recibidos.
* "Para muestra los bancos que permiten log-in vía DNIe... todos utilizan sus propias aplicaciones (por la cuenta que les trae)."
Discrepo. El hecho de que los bancos estén utilizando sus propias aplicaciones es más un síntoma de los efectos de la crisis que de un deseo de hacer las cosas bien.
En la actualidad, la práctica totalidad de los bancos que ofrecen autenticación con DNIe [5] lo hacen de manera muy deficiente: solo para un sistema operativo (Windows), solo para un navegador (Internet Explorer), solo para un certificado (DNIe) y solo para un propósito (autenticación). Al limitar tanto el alcance del desarrollo es posible (utilizando un control Active X) ofrecer autenticación con DNIe de forma barata pero a costa de incumplir el principio de universalidad (¿qué pasa con el resto de sistemas operativos, navegadores, certificados y posibles usos?).
* "el hecho de tener que depender de Java me quita bastante porque implica un requisito más de cara al usuario... a ver cuándo es el día que el propio navegador proporciona los elementos necesarios y así se pueda hacer sin aplicaciones extra."
Coincido contigo: cualquier requisito extra de cara al usuario es indeseable.
Hay varias opciones, cada una con ventajas y desventajas. La primera es utilizar Active X (solo funciona en Windows e Internet Explorer, rompe el principio de universalidad). Otra es dejarlo en manos del navegador (ya es posible a día de hoy, pero la usabilidad deja mucho que desear -ejemplo [6]-, habría que formar al usuario -> pasaporte seguro a frustración, fracaso y baja utilización del sistema) y la tercera, la que hemos elegido, es un applet de Java (requiere JVM pero funciona en todas las plataformas y te permite controlar la usabilidad, mensajes al usuario, interface, proceso de autenticación/firma, etc). A día de hoy, si necesitas crear un servicio o aplicación que verifique la identidad real de tus usuarios utilizando certificados, creemos que Java es la mejor opción.
Espero haber podido arrojar algo de luz sobre cuales sobre las razones detrás de nuestras decisiones de desarrollo. Para nosotros, estos temas no son solo tecnología y empresa sino una oportunidad de participar en la definición del Internet del futuro. Creo que es muy importante que se empiece a hablar de estos temas y a darles la importancia que merecen y, por tanto, por nuestra parte, cualquier comentario, crítica o sugerencia es bienvenido.
Enlaces:
[1] http://harvardmagazine.com/2000/01/code-is-law.html
[2] http://blog.negonation.com/es/tarjetas-inteligentes-en-europa-avalancha-de-e-id/
[3] https://www.tractis.com/accepted_certificates
[4] https://www.tractis.com/help/?p=3537&language=es#verify
[5] http://www.dnielectronico.es/servicios_disponibles/serv_disp_priv.html
[6] http://blog.negonation.com/es/wp-content/uploads/2009/07/dnie-firefox.png