Xnoccio.com

• Se posibilita una verdadera firma electrónica reconocida desde dispositivos móviles: la firma electrónica es avanzada (se realiza localmente en el dispositivo móvil siempre bajo el control exclusivo del usuario), y además se basa en un dispositivo seguro de creación de firma como es el DNIe.
• Se abre una nueva vía para el uso del DNIe, en smartphones y tablets. El comportamiento del usuario en internet está cambiando radicalmente a la vez que cambia el mercado de smartphones / tablets; las conexiones móviles a Internet ya superan a las de ADSL, y todos empezamos a acostumbrarnos a utilizar estos dispositivos para navegar, mirar el correo electrónico, interaccionar en redes sociales, fotografía, banca electrónica… ¿por qué no Administración Electrónica móvil (m-government) o servicios con firma electrónica móvil, con plena validez legal?
• Ya hay más de 25 millones de DNI electrónicos en España, si bien probablemente el porcentaje de usuarios del mismo que conozcan cómo usarlo o simplemente su PIN sea demasiado bajo.
• Probablemente, simplemente la posibilidad de utilizarlo en smartphones y tablets despierte el interés en el DNIe por parte de usuarios de smartphones que no están interesados en utilizar la versión de escritorio.
• Se abren nuevas vías de interés en aplicaciones móviles. No hace mucho Tuenti apostó por el uso del DNI electrónico como mecanismo para garantizar la identidad, edad, etc., de sus usuarios;  ¿por qué no poder usarlo en smartphones para poder acreditar esta misma información?
• Y sobre todo, porque estamos convencidos de que para el usuario final, es más usable el DNIe en su tablet o smartphone, que en escritorio.

¿En qué nos basamos para asegurar eso?

• No hacen falta drivers. Basta con insertar el lector en el dispositivo, y utilizar una aplicación nativa iOS (o Android en el futuro) que embeba la librería desarrollada por Viafirma. Esta librería implementa los drivers APDU del DNIe, y además sirve de interfaz visual para la previsualización de los datos públicos del DNI, la inserción de password, etc.
• Esto hace que el comportamiento sea totalmente plug & play.
• El escenario de ejecución es plenamente controlable. Al ejecutarse en un dispositivo móvil, y estando conectado el lector en un único puerto, las posibilidades de que otras aplicaciones, servicios o dispositivos puedan interferir en la comunicación DNIe / lector / dispositivo son inexistentes. Por ello, los servicios de lectura, autenticación y firma electrónica con el DNI electrónico funcionarían siempre del mismo modo.
• El lector es inalámbrico, y de dimensiones muy reducidas (ver foto del inicio), además de tener un look & feel agradable. La estética es una parte clave en la usabilidad, por cuanto genera una primera impresión de satisfacción en el usuario.
• No hacen falta applets. La aplicación móvil hace de driver de lector, driver de DNIe y de applet. Se eliminan los riesgos de actualizaciones de la JVM, las matrices de compatibilidad de sistemas operativos / JVM / navegador, etc.
• Se puede incorporar lógica de autenticación y firma electrónica reconocida con DNIe en aplicaciones web o nativas.

Quizás pequemos de optimismo, pero creemos que la utilización de esta tecnología puede ayudar enormemente al impulso del uso del DNI electrónico en España, facilitando el uso de la tecnología y acercándolo al nuevo modelo de comportamiento del usuario con las redes basado en tablets y smartphones.

Por último, os dejamos un vídeo donde se observa cómo se insertan dos DNI electrónico en un mismo iPhone.

¿Cuántas ideas de negocio se os ocurren basadas en esta posibilidad?

A pesar de la ola de calor que está azotando España estos días, nos hemos animado y hemos decidido volver a presentaros novedades sobre el sistema de monitorización de firma electrónica más completo del mercado.

Siguiendo la linea de nuestros post de descripción informativa sobre Viafirma Manager,  lanzamos la tercera parte de la saga, en donde abordaremos como tratar las fuentes de validación y como configurar las autoridades de sellado de tiempo (TSA).

Fuentes de Validación

Viafirma Platform soporta la gestión de los servicios de validación de las distintas Autoridades de Certificación, configuradas en su interfaz de administración Viafirma Manager:

• Permite una gestión de las Autoridades de Certificación y Autoridades de Validación que se deseen soportar, a nivel sistema y a nivel aplicación concreta.

• Para facilitar la tarea a los Administradores del sistema, se utiliza por defecto el mecanismo de validación que venga informado en la estructura X509.v3 del certificado digital en cuestión.

• Se permite especificar para cada Autoridad de Certificación un servicio específico de validación, si no se desea utilizar el informado por defecto en el certificado digital.

• Se permite especificar más de un servicio y Autoridad de Validación por Autoridad de Certificación, y un orden de prioridad a seguir en el caso de que uno de ellos esté caído. Por ejemplo, “verifica primero vía OCSP y si no hay respuesta, por CRL’s”. Incluso pudiendo escoger si, en el caso de que todos los servicios den un error de respuesta, se pueda o no continuar la operación sin haber garantizado el estado de revocación del certificado.

Además, se permite gestionar qué autoridades de certificación están habilitadas para cada aplicación concreta (por ejemplo, “la aplicación X admite sólo DNIe”) e incluso se permite dar de alta Autoridades de Certificación no reconocidas (por ejemplo, una interna creada con un software de PKI) y sus Autoridades de Validación correspondientes, siguiendo las mismas normas y opciones que con las Autoridades de Certificación reconocidas.

Configuración de autoridades de sellado de tiempo (TSA)

Viafirma Platform soporta la interacción con cualquier TSA (Timestamping Authority) que cumpla el estándar RFC 3161, necesario en formatos de firma (cualquiera de firma longeva) que recojan dentro de las evidencias de firma sellos de tiempo. Este soporte de sellados de tiempo puede ser utilizado con cualquier tipo de formato que admita la inclusión de los timestamping, modalidad de firma, operación en cliente, servidor, etc.
En primer lugar, se procede a configurar en la interfaz de administración Viafirma Manager los distintos servicios de TSA que tenemos disponibles a nivel plataforma. Esta configuración es muy sencilla, ya que esencialmente lo único que necesitaremos es la URL del servicio de TSA.

Posteriormente, la plataforma permite asociar a una aplicación:

•    La autoridad o autoridades de sellado de tiempo (TSA) que se utilizarán en cada caso.

•   El orden de invocación de las TSA. Ello permite, por ejemplo, que si un servicio de TSA no esté disponible, se utilice el siguiente configurado y asociado a la aplicación.

Por último, el sistema almacena para cada operación datos como la TSA que finalmente se utilizó en una operación de firma, el tiempo de respuesta de la misma, etc.

En el siguiente post hablaremos sobre los Roles de Acceso y Auditoría, pero mientras tanto, nos gustaría escuchar cualquier comentario, duda o aclaración que pudiera haber.

Hace ya casi un año que anunciábamos el comienzo del proyecto etítulo. Etítulo es un proyecto que permite la puesta en marcha del primer título electrónico universitario en el mundo. Se trata de una versión electrónica del Título Universitario Oficial que, entre otros objetivos, permitirá acabar con la suplantación profesional. El etítulo, incorpora todos los procedimientos telemáticos para implementar el título oficial universitario en formato electrónico con todas las prestaciones legales que son inherentes al título convencional en papel.

A día de hoy, nos complace contemplar como un proyecto que nació en Viavansi gracias a Firmaprofesional, y que poco a poco ha ido aprendiendo gatear hasta coger impulso para dar sus primeros pasos. Entre los logros tecnológicos alcanzados en el proyecto, destacamos el motor de autenticación y firma electrónica utilizado: Viafirma Platform.

En la lista de universidades adheridas publicada por Signe podemos contar hasta 11 de ellas, entre las que se encuentran la Universidad de Cádiz, la Universidad de Sevilla o la Universidad de Zaragoza. A esta lista tenemos que sumarle aquellas que también utilizan el software de autenticación y firma electrónica de viafirma como la Universidad de Málaga y la Universidad de Extremadura, (la ya mencionada Universidad de Cádiz, además de pertenecer al proyecto, también utiliza el software para otras gestiones) con lo que nos encontramos que, en poco menos de un año, son 13 las universidades que incorporan a sus servicios telemáticos la autenticación y firma electrónica de viafirma.

Las principales funcionalidades que el egresado a etítulo podrá realizar son:

• Obtener cuantas copias digitales auténticas de su título.
• Testimoniar, de forma indubitada, su condición de titulado ante empresas, organismos, autoridades y empleadores.
• Colegiarse sin necesidad de desplazamientos.
• Acceder a oposiciones.
• Acceder a estudios de Máster.
• Acreditar ante portales de empleo, la autenticidad de su titulación.

Se puede acceder a a los servicios de solicitud on-line en www.etitulo.es.

Durante varias semanas hemos estado informándonos y llevando a cabo los trámites adecuados para proceder a tramitar los retrasos en el pago de facturas acumuladas por la administración. Al surgirnos dudas y conversaciones con varias personas al respecto, hemos pensado en transmitiros toda la información que conocemos a través de este post que esperamos os sea de utilidad.

El pasado mes de febrero el Gobierno puso en marcha el denominado “Plan Proveedores”, mecanismo ágil de pago y cancelación de deudas pendientes con proveedores de Entidades Locales y de Comunidades Autónomas. A través de este mecanismo se ofrece una solución de medio y largo plazo a las Administraciones territoriales para que puedan hacer frente a estos pagos con la debida condicionalidad fiscal y financiera que garantice la sostenibilidad de sus finanzas.

La condición que debe cumplir el proveedor para tener derecho al cobro de sus facturas es que se trate de obligaciones pendientes de pago generadas por obras, servicios o suministros realizados antes del 1 de enero de 2012 y que, además, se trate de contratos incluidos en el ámbito de lo recogido en la Ley de Contratos del Sector Público.

El mecanismo de financiación: normativa, procedimiento, aceptación y tramitación del pago y demás podéis encontrarlo en este enlace.

Centrándonos en el plazo actual referente a los contratistas de las comunidades autónomas que es del 02 al 22 de Mayo, os explicaremos resumidamente los pasos que tenéis que llevar a cabo:

1. Nos dirigimos al portal de la agencia tributaria (http://www.agenciatributaria.es/) y en concreto pulsamos sobre el banner de pago a proveedores.

2. Accedemos dentro de Opciones del Contratista a Consulta de facturas y tramitación. Para acceder a este apartado necesitamos tener instalado en nuestro navegador un certificado electrónico o disponer de un DNIe.

Si no sabes como obtener tu certificado electrónico sigue este enlace http://developers.viafirma.com/como-obtener-mi-certificado-digital y para instalarlo consulta nuestras faq http://developers.viafirma.com/preguntas-frecuentes-relacionadas-con-la-firma-electronica

3. Una vez seleccionemos el certificado que contendrá un NIF concreto nos aparecerá un listado de facturas relacionadas con el mismo y que estarán en estado “Pendiente de aceptación”. Lo primero que tendremos que hacer es revisar estas facturas y aceptarlas en el caso de que sean correctas.
Para acceder a aceptar o modificar las facturas, pulsamos sobre la factura concreta (en la columna ente principal). Nos aparecerá en la parte superior un apartado “Acciones” donde podremos observar las opciones disponibles.
Este trámite se puede hacer de forma masiva por el total de las facturas del listado, sin necesidad de ir una por una, accediendo al apartado: Tramitación masiva (por lotes) de Aceptación Voluntad de Acogerse al procedimiento.

4. Una vez pulsemos sobre la opción “Aceptar”, nos solicitará una cuenta bancaria donde realizar el pago y pulsamos sobre el botón “Firmar y Enviar”. Y a continuación revisamos los datos y de nuevo “Firmar y Enviar”. Nos aparecerá el detalle de la factura y la confirmación de que la aceptación se ha llevado a cabo además de un código seguro de verificación (CVS) que nos permitirá acceder al recibo de presentación.

Podéis consultar también para más detalles  el tutorial publicado por al agencia tributaria al respecto.

Cada una de las comunidades debe tener además un modo de consultar estas facturas e información relacionada. Si todo es correcto, deberían coincidir con las consultadas a través de la agencia tributaria, en nuestro caso se trata de la junta de Andalucía y estas facturas se pueden consultar de manera on-line: https://www.juntadeandalucia.es/haciendayadministracionpublica/ov/admon_publica/proveedores.htm.

Los proveedores podrán solicitar a través de este enlace la emisión de certificaciones individuales de reconocimiento de obligaciones pendientes de pago, con respecto a aquellas facturas que no figuren en la relación certificada.

Espero que os haya servido de ayuda, por lo menos esa ha sido la intención .

Hace ya casi dos años que publicamos Viafirma Mobile para iOS, nuestro cliente nativo de Viafirma Platform para poder realizar autenticación fuerte y firma electrónica avanzada con certificados digitales en formato software (PKCS#12). Esta aplicación hace las funciones de “applet de firma” en un entorno como iOS, donde no se dispone de máquina virtual de Java; por ello, interactúa con los certificados instalados localmente en el dispositivo móvil para poder realizar las operaciones criptográficas necesarias.

Para instalar los certificados, debemos utilizar la capacidad de compartir ficheros con aplicaciones de iOS a través de iTunes, cargando nuestro certificado en formato PKCS#12 (y protegido con PIN) a la aplicación Viafirma instalado en nuestro iPhone, iPad, iPod Touch, etc. Así, Viafirma Mobile puede desplegar dichos certificados en el keystore local de la aplicación.

Algunos clientes nos han preguntado por qué no usamos el sistema de profiles disponible en iOS a nivel de dispositivo, en lugar de usar el repositorio local de la aplicación. Por ejemplo, disponiendo del certificado en formato PKCS#12 en el iPhone o iPad (adjunto en un email por ejemplo), se puede instalar sobre el dispositivo y queda visible en los Profiles (Ajustes -> General -> Perfiles). De hecho, si hacemos esto, podemos tener autenticación con certificado en cualquier aplicación que tenga configurada la autenticación con certificado sobre SSL; al navegar por la aplicación con Safari, el dispositivo iOS nos pide que escojamos qué certificado queremos utilizar (ver figura adjunta). Si existe esto, ¿por qué no interactuamos con los profiles del dispositivo en lugar de utilizar el keystore local? Se debe poder, ya que tanto Safari (para autenticar) como Mail (para firmar un email) pueden utilizar el certificado almacenado en el Profile…

La respuesta es fácil: porque no se puede, desgraciadamente. Apple restringe a las aplicaciones no firmadas por ellos el acceso a los servicios de keychain que no sean locales de la aplicación. Esto puede ser consultado en Apple Developers.

Y más concretamente, este párrafo que acaba con toda esperanza, de momento:

Keychain Access ControlsiOS: The iOS gives an application access to only its own keychain items. The keychain access controls discussed in this section do not apply to iOS.

Eso deja como opción inicial en iOS el uso del keychain local de la aplicación, siguiendo los dictados del Apple. En todo caso, tal y como publicamos hace unos días, para alcanzar un nivel de firma electrónica reconocida en dispositivos móviles, en Viafirma hemos desarrollado el conector nativo con DNI electrónico en dispositivos iOS. Ello permite interactuar con el DNI electrónico para realizar autenticación y firma electrónica reconocida directamente en los dispositivos móviles, lo cual además mejora enormemente la experiencia de usuario en comparación con las alternativas tradicionales de lectores + drivers en PC’s, Mac, etc. Esta librería es susceptible de poder ser embebida en otras plataformas y desarrollos de terceros como @Firma, etc., de forma que se podría conseguir que cualquier ciudadano pudiese interactuar con la eAdministración en sus smartphones y tablets, con la plena validez legal que otorga la firma electrónica reconocida según la Ley de Firma Electrónica española, y con una mejor experiencia de usuario.

Aunque ya llevábamos dando pistas durante las últimas semanas, en Viafirma tenemos el placer de anunciaros que hemos finalizado, tras muchos meses de trabajo, el soporte integral del DNI electrónico en smartphones iPhone y tablets iPad, con capacidad tanto de autenticación como firma electrónica reconocida en estos dispositivos móviles. Para ello hemos tenido que aunar en una sola aplicación móvil Objective C el driver del DNIe (utilizando los comandos APDU, establecimiento del canal seguro, encriptación, etc.) y el cliente de firma electrónica.

Sinceramente consideramos que esto es un verdadero bombazo y una revolución en el sector de la firma electrónica. Todos nos estaremos dando cuenta del incremento exponencial de uso de smartphones y tablets en la vida cotidiana tanto personal como profesional, y pensamos que la firma electrónica no debería quedarse atrás, como está ocurriendo en la realidad. Dejando al margen los usuarios de las soluciones integradas con Viafirma Platform, pocos usuarios pueden autenticarse y firmar electrónicamente sin encontrar problemas en Linux, Mac OS X (a título personal me toca usar máquinas virtuales Windows), o con iPhone, iPad, Android, BlackBerry o Windows Phone… sin tener que mandarle el certificado a ninguna plataforma centralizada para que firme por él un servidor.

Creemos que incluir el soporte del DNIe en iPhone y iPad ahora, y Android próximamente, ayudará no sólo a potenciar la firma electrónica, sino también a fomentar de forma efectiva el uso del DNIe. Sinceramente la experiencia de usuario y la usabilidad del DNIe es mucho mejor en el iPhone y iPad que en un ordenador convencional, al menos en mi caso personal como usuario, y consideramos que ésta era precisamente una de las debilidades del modelo actual. Usar el DNIe en nuestro smartphone o tablet es tan fácil como conectar el lector, insertar la tarjeta y meter el PIN cuando se nos pida.

Os adelantamos algunas características de este logro:

• Se utiliza un lector que se inserta en el puerto dock del iPhone / iPad. Este lector ha sido desarrollado conjuntamente con un fabricante que ha procedido a adquirir las diversas certificaciones de seguridad (FIPS, etc.), y tendrá un coste bastante reducido (aunque es pronto para asegurarlo, un orden de magnitud razonable podrían ser 29 €). Habíamos experimentado previamente con algunos lectores Bluetooth compatibles con BlackBerry y algún Android, pero su precio (200 – 300 €) nos hicieron pensar en una inviabilidad realista del proyecto.
• El lector es realmente móvil: de reducidas dimensiones y con una estética muy agradable. Es un periférico más de tu smartphone o tablet. El lector ya ha sido reconocido por Apple y es compatible (y probado) en iOS 4, iOS 5.0 y 5.1.
• Hemos trabajado con prototipos conjuntamente con nuestro fabricante, pero el lector podría estar disponible en un plazo de uno a dos meses.
• La firma se hace 100% localmente en el móvil o tablet. Aunque esto es obvio, porque resulta imposible sacar la clave privada fuera del DNIe, hemos considerado oportuno este hecho. Para ello nos hemos apoyado en la tecnología de firma avanzada móvil Viafirma ya existente desde 2010 para plataformas iOS, Android, BlackBerry y Windows Phone.
• Se alcanza el nivel de firma electrónica reconocida móvil, al utilizarse un dispositivo seguro de creación de firma.
• El sistema es 100% plug & play. No hay que instalar nada en el móvil, aparte de la última versión de la aplicación móvil Viafirma. Esta aplicación se encarga de todas las operaciones criptográticas, haciendo tanto de driver, como de “applet” de firma electrónica reconocida que se ejecuta localmente en el dispositivo.
• Disponemos de varios lectores y podemos realizar demostraciones in-situ desde ya mismo. ¡Podéis usar vuestros propios DNI electrónicos para comprobar el funcionamiento!
• Cualquier aplicación integrada con Viafirma Platform, ya sea aplicación web o aplicación nativa móvil, dispondrá de soporte de DNIe en iPhone y iPad sin necesidad de realizar ningún desarrollo adicional. Resulta muy sencillo incluir funcionalidades de autenticación y firma electrónica con DNIe en iPhone / iPad en tu aplicación web o iOS.
• Nuestro desarrollo será publicado con la mayor brevedad como actualización de nuestro cliente móvil iOS Viafirma, que ya permite realizar firma electrónica avanzada y local en cualquier aplicación integrada con Viafirma Platform.
• Toda la lógica está en la aplicación nativa, que interactúa con nuestra plataforma para realizar las operaciones de validación, verificación, timestamping, custodia… por ello, de momento sólo funcionaría con soluciones integradas con nuestra plataforma Viafirma Platform. Sin embargo, es técnicamente posible construir bridges / clientes nativos para otras soluciones como @Firma (aFirma), etc. Las instituciones que pudieran estar interesadas en disponer de esta funcionalidad pueden contactarnos sin ningún compromiso.
• Hemos realizado el desarrollo para el DNIe, pero es técnicamente posible extender el uso a otro tipo de tarjetas criptográficas / smartcards.

En nuestro canal Youtube hemos publicado algunos vídeos de firma electrónica en iPad y iPhone con nuestros DNIe, y pretendemos seguir publicando más en los próximos días y semanas. En este caso, hemos grabado un caso de uso consistente en una petición de firma para dos firmantes en nuestra plataforma de portafirmas Viafirma Inbox. Los firmantes proceden a firmar con su DNIe en un iPad y un iPhone. Veamos ambos vídeos (os recomendamos que los pongáis a pantalla completa para ver algo):

También queremos anunciaros que el lector que estamos usando será a medio plazo compatible con dispositivos Android de versiones 3.1 o superiores, ya que dispondrá de un puerto miniUSB que podrá conectarse al host USB del smartphone o tablet Android. Así, podremos también hacer firma electrónica reconocida móvil con smartcards y DNIe en dispositivos Android. Os mantendremos informados.

Con el objetivo de habilitar diversos mecanismos de acceso a la información publicada a través de la Interfaz de Interoperabilidad de Contenidos Web (iCMS), además del end-point opensearch que conforma la propia interfaz de iCMS, se han implementado mecanismos de integración con servidores semánticos (en este post nos centraremos en Virtuoso) . Entre otras características, estos sistemas permiten la utilización del lenguaje estándar SPARQL para la consulta de los datos almacenados.

Entre las funcionalidades de iCMS encontramos la gestión de eventos asociados a las colecciones de datos (al iniciar y al modificar las colecciones), permitiendo vincular scripts (en la versión actual de iCMS se da soporte a la inyección de scripts Groovy, aunque en el Roadmap de la solución se encuentra el soporte para otras tecnologías, como pueden ser Python o Ruby) a dichos eventos.

El mecanismo de integración entre iCMS y Virtuoso se apoya en esta funcionalidad, es decir, se trata de un script Groovy que incluye toda la lógica necesaria para conectar con virtuoso, crear los grafos, obtener los recursos/datos (desde los back-ends a través de los drivers iCMS) cuya modificación ha lanzado el evento y finalmente actualizar la información en Virtuoso.

La actualización de los datos en Virtuoso se realiza mediante la ejecución de sentencias INSERT/DELETE de SPARQL a través de los servicios desplegados por Virtuoso.

En la parametrización de las colecciones de datos, cuyo contenido va a ser volcado en Virtuoso, es preciso establecer la configuración del evento que dispara el script Groovy que incluye la lógica de integración con el servidor semántico. Esta configuración sigue el siguiente modelo:

    event {
       my_event_script {
           path = "/opt/icms/data/scripts/groovy_virtuoso.groovy"
           urlSubscription = "http://localhost:8080/icms"
           collections = "<nombre_coleccion>"
           parameters {
              virtuoso_url = "jdbc:virtuoso://localhost:1111"
              virtuoso_usr = "icms_virt"
              virtuoso_psw = "icms_virt"
              virtuoso_graph = "<http://nombre_grafo>"
           }
      }
    }

La configuración anterior le indica a iCMS que cuando haya algún cambio en los recursos de la colección definida (“nombre_colección” en el ejemplo) se ejecute el script groovy_virtuoso.groovy con los parámetros dados. Dicho script contiene toda la lógica necesaria para rellenar Virtuoso con los nuevos cambios.

En el siguiente gráfico se muestra a alto el proceso de integración entre iCMS y el servidor semántico Virtuoso:

En  octubre de 2007, en una de las conferencias de la SunLight Foundation se discutía sobre el modelo a seguir por los Organismos Públicos para realizar la apertura de datos almacenados electrónicamente. En este evento tienen su origen un conjunto de principios básicos a tener en cuenta en diseño de cualquier iniciativa de apertura de datos (que hoy día son incluidos en la Ley de Transparencia de diversos Organismos Públicos):

• Completeness. Los Datos deben ser lo más completos que sea posible.
• Primacy. Deben ser obtenidos en su origen, evitando la transformaciones intermedias.
• Timeliness. Publicados en tiempo real, o actualizados siempre sea posible.
• Ease of Physical and Electronic Access. Fácilmente accessibles.
• Machine readability. Procesables electrónicamente.
• Non-discrimination. Accesibles sin discriminación (disponibles para todos).
• Use of Commonly Owned Standards. Publicados en formatos no proprietarios.
• Licensing. Datos libres (el licenciamiento utilizado debe facilitar el acceso libre a los mismos).
• Permanence. Se debe garantizar la permanencia en el tiempo de los conjuntos de datos publicados.
• Usage Costs. Sin coste.

Es esta ocasión nos centraremos en los tres primeros enunciados (datos completos, obtenidos directamente desde la fuente y actualizados), pues representan (al menos, desde mi punto de vista) algunos de los aspectos más destacables de la Interfaz de Interoperabilidad de Contenidos Web (iCMS), esto es, la posibilidad de publicar conjuntos de datos obteniéndolos directamente desde su fuente, sin necesidad de recurrir a procesos de consolidación de los datos en repositorios centralizados (por ejemplo, mediante ETLs). De esta forma, siempre que se cumplan determinadas condiciones (que son establecidas en el proceso de configuración del conjunto de datos), los datos son ofrecidos completamente actualizados. Obviamente, para ofrecer esta posibilidad, ha sido necesario recurrir a mecanismos de caché e indexación con el objetivo de que el acceso a los datos no penalice el rendimiento de los back-ends (sistemas donde son generados/almacenados los datos).

Hace unas semanas, tuve la suerte de asistir como oyente al evento Gobierno Abierto: “Reto y Oportunidad” , donde en una de las mesas redondas uno de los ponentes presentaba un concepto que enmarca claramente las características descritas anteriormente: Real-Time Open Data.

Todo esto es posible gracias al sistema de notificaciones implementado en iCMS. En primer lugar, los back-ends notifican al servidor iCMS (a través de los drivers iCMS) los cambios que se producen en los datos,  con el objetivo de las actualizaciones sean indexadas. Por otro lado,  una vez indexados los cambios, el servidor iCMS procede a notificar dicho cambio a todos los sistemas suscritos al conjunto de datos en el que se ha producido el evento. Este proceso es descrito en el siguiente diagrama:

En el siguiente gráfico se presenta a muy alto nivel el rol que desempeña iCMS dentro de una iniciativa de apertura de datos:

En futuras entradas, se detallará el resto de capacidades/funcionalidades de iCMS, así como los procesos de integración con CKAN y Virtuoso.

Ha llegado la hora de tomar medidas drásticas y reforzar el equipo Viafirma/Viavansi con verdaderos expertos que ayuden a los desarrolladores en su día a día.

El objetivo:

• Fomentar el trabajo en equipo
• Ayudar al desarrollador a encontrar errores
• Disminuir la interrupción a compañeros
• Hacer que todos los desarrolladores se sientan escuchados cuando se enfrentan a un problema
• Acelerar la curva de aprendizaje
• Ser capaces de desarrollar mejor sofware.

Y como no podía ser de otra forma, como medida drástica hemos decidido incorporar a la plantilla un equipo multidisciplinar de patitos de goma!.

En esta foto podemos ver al equimo multidisciplinar al completo:

Y aqui a uno de sus integrantes ayudando en las tareas de desarrollo:

Cito textualmente:

Algúnas referencas de expertos en el tema:

http://halteniarazon.blogspot.com.es/2010/11/yo-soy-el-patito-de-goma.html

http://eclijava.blogspot.com.es/2010/01/patito-de-goma.html

http://www.bonillaware.com/marketingemocional

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Como anunciábamos en el post de PAdES, el ETSI (Instituto Europeo para la Normalización de las Telecomunicaciones – European Telecommunications Standards Institute) ha organizado un nuevo evento “Plugtest” para firmas con formato XAdES (firma avanzada para ficheros XML) el cual está en activo desde el 14 de Marzo y finalizará el 28 de este mismo mes.

Este evento tiene como objetivo la validacióna distancia según los test propuestos por ETSI en las firmas XAdEs ( TS 101 903) y el perfil de referencia XAdES (TS 103 171).
Estas pruebas proveerán una cobertura completa de las dos especificaciones citadas incluyendo la prueba de la evolución de las firmas, simulando situaciones reales.

El evento “Plugtest” permitirá a los participantes realizar 4 tipos de tests (interoperabilidad y conformidad):

• Tests de generación y verficación cruzada (positivo)

• Tests de solo verificación (negativo)

• Tests de actualización de firma.

• Test de conformidad en el perfil de referencia de firma en XAdES.

El propósito del evento es:

• Permitir a los participantes asegurar el nivel de interoperabilidad de XAdES.

• Identificar temas adicionales que deberían tenerse en cuenta en futuras actividades de estandarización de XAdES.

• Mejorar la calidad de las especificaciones XAdES.

• Facilitar la introducción de las firmas XAdES, proveyendo los medios para solucionar los problemas de interoperabilidad antes del lanzar el despliegue…

Se puede obtener mayor información del evento en el portal de plugtests para firma electrónica:  http://xades-portal.etsi.org/pub/index.shtml

Al igual que en nuestra web, podemos dar una pequeña descripción de los perfiles según el nivel de protección ofrecido. Cada perfil incluye y extiende al previo:

• XAdES-BES, forma básica que simplemente cumple los requisitos legales de la Directiva para firma electrónica avanzada.

• XAdES-EPES, forma básica a la que se la ha añadido información sobre la política de firma.

• XAdES-T (timestamp), añade un campo de sellado de tiempo para proteger contra el repudio.

• XAdES-C (complete), añade referencias a datos de verificación (certificados y listas de revocación) a los documentos firmados para permitir verificación y validación off-line en el futuro (pero no almacena los datos en sí mismos).

• XAdES-X (extended), añade sellos de tiempo a las referencias introducidas por XAdES-C para evitar que pueda verse comprometida en el futuro una cadena de certificados.

• XAdES-X-L (extended long-term), añade los propios certificados y listas de revocación a los documentos firmados para permitir la verificación en el futuro incluso si las fuentes originales (de consulta de certificados o de las listas de revocación) no estuvieran ya disponibles.

• XAdES-A (archivado), añade la posibilidad de timestamping periódico (por ej. cada año) de documentos archivados para prevenir que puedan ser comprometidos debido a la debilidad de la firma durante un periodo largo de almacenamiento.

Para aquel que esté interesado, hay disponible una serie de kit’s de integración de descarga gratuita para java, .NET y php en nuestro portal para desarrolladores  developers.viafirma.com para firmar electrónicamente en formato XAdES.