Xnoccio.com

Hace pocos días salía a producción la primera fase del Portal de Datos Abiertos de la junta de Andalucía. Esta primera fase del proyecto tiene como objetivo ofrecer una aproximación a los datos disponibles en la Junta de Andalucía, así como establecer un punto único de acceso a los mismos. Los servicios ofrecidos en esta etapa pueden catalogarse como 2 estrellas, según la clasificación del Open Linked Data propuesta por Tim Berners-Lee.

Para mediados de 2012 será publicada la versión final del Portal, en la que se habrán realizado las siguientes actuaciones:

• Modelado semántico de los datos.
• Ampliar el catálogo de datos disponible.
• Dotar al Portal de la infraestructura necesaria para ofrecer conjuntos de datos de 4 y 5 estrellas. El Portal ofrecerá un SPARQL endpoint (implementado con Virtuoso), así como servicios de suscripción a los contenidos (para lo que se habilitará un servidor iCMS público).
• Incorporar un conjunto de aplicaciones de ejemplo y documentación técnica destinada a desarrolladores, con el objetivo de facilitar la construcción de sistemas que reutilicen la información disponible.

En el siguiente diagrama se muestra la infraestructura tecnológica (presentada por la Junta de Andalucía en el evento Opendatasev  que tuvo lugar el pasado noviembre) que dará soporte a la iniciativa de apertura de datos en la Junta de Andalucía:

 Izenpe, autoridad de certificación del Gobierno Vasco y Viafirma han llegado a un acuerdo para la creación de Izenbox, una plataforma de portafirmas electrónico que Izenpe pone a disposición de las entidades públicas y privadas de Euskadi.

Esta plataforma está basada en el portafirmas Viafirma Inbox, sobre el cual se han desarrollado un conjunto de optimizaciones aprovechando la experiencia de Izenpe. Izenpe ofrece esta plataforma en formato cloud-computing, totalmente personalizada para cada corporación, de forma que las instituciones que la utilizan evitan todas las complejidades relacionadas con la gestión y mantenimiento del servicio pero disfrutan de una plataforma ajustada a sus necesidades.Izenbox dispone de características avanzadas como:

• 100% multitenant.
• Soporte universal de navegadores y sistemas operativos (Windows, Linux, Mac OS X, IE, Firefox, Chrome, Safari…).
• Firma electrónica avanzada de documentos en dispositivos móviles (iPhone, iPad, Android, BlackBerry…).
• Flujos de firma complejos (múltiples líneas de firma, utilización de cargos, grupos, etc.).
• Delegación de firma.
• Integración con gestores documentales (Alfresco, Nuxeo, Documentum, Sharepoint, Filenet…).
• Posibilidad de personalizar dinámicamente la interfaz de usuario.
• Conversión automática de documentos a PDF.
• Soporte de comunicaciones internas.
• Plataforma de verificación y custodia de documentos.
• Generación de Código Seguro de Verificación (CSV) y recibos visuales de firma con códigos de barra y bidimensionales.
• Búsqueda avanzada y filtro de peticiones de firma.
• Herramienta visual drag & drop de definición de circuitos de firma.
• Formatos de firma XAdES y PAdES.

Izenbox ha sido ya puesto en marcha en varias entidades públicas locales de Euskadi.

Todos sabemos las ventajas que tiene trabajar con plantillas xhtml a la hora de generar la capa de presentación o incluso para generar emails o pdfs a través de seam.

El problema viene cuando utilizamos una gran cantidad de plantillas xhtml personalizadas y necesitamos gestionarlas de manera externa a la aplicación y almacenarlas por ejemplo en un repositorio externo: BD, gestor documental, ftp, en disco, etc.

Por defecto, el render de Seam permite generar renderizados de vistas (views) que están contenidas dentro de la propia aplicación. Un ejemplo:

renderer.render("/pdf/templatePdf.xhtml");

La anterior linea intentará generar el renderizado a partir de un resource en la propia aplicación, es decir, el archivo templatePdf.xhtml debe estar físicamente en el webapps de la aplicación.

¿Y qué ocurre si tenemos un templatePdf.xhtml externo, quizás en un repositorio o lo queremos generar dinámicamente?

Lo que tenemos que hacer es implementar un cargador de resources que controle cuándo queremos renderizar una vista normal o una vista en un repositorio externo.

Esta distinción se hará a nivel de URL, es decir, cuando queramos renderizar una vista normal nos bastaría con:

renderer.render("/pdf/templatePdf.xhtml")

mientras que para renderizar vistas externas podríamos poner algo como:

renderer.render("CUSTOM-/pdf/templatePdf.xhtml")

es decir, anteponemos un prefijo, por ejemplo “CUSTOM-”.

Ahora nos toca decirle al cargador de resources que cuando se solicite un recurso con el prefijo “CUSTOM-” lo trate de manera especial, cargándolo por ejemplo de un repositorio de plantillas, de un FTP, generándolas nosotros dinámicamente o lo que necesitéis. Aquí os pongo la implementación de la clase:

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandler;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.jboss.seam.ScopeType;
import org.jboss.seam.annotations.Name;
import org.jboss.seam.annotations.Scope;
import org.jboss.seam.contexts.ServletLifecycle;
import org.jboss.seam.core.ResourceLoader;
import org.jboss.seam.util.Resources;

@Name("org.jboss.seam.core.resourceLoader")
@Scope(ScopeType.STATELESS)
public class CustomResourceLoader extends ResourceLoader {

    public static final String TEMPLATE_PREFIX = "CUSTOM-";

    @Override
    public URL getResource(final String resource) {
        URL url = null;
        if (resource.startsWith(TEMPLATE_PREFIX)) {
            final String uriViewId = resource.substring(TEMPLATE_PREFIX.length());
            try {
                url = new URL("internal", "", 0, uriViewId, getHandler(uriViewId));
            } catch (final MalformedURLException e) {
                if (log.isErrorEnabled()) {
                    log.error("Unable to build the URL", e);
                }
            }
        } else {
            url = Resources.getResource(resource, ServletLifecycle.getServletContext());
        }
        return url;
    }

    // @return Our own implementation of an URLStreamHandler to get the template
    //         from the content repository.
    private static URLStreamHandler getHandler(final String uriViewId) {
        return new URLStreamHandler() {
            private final String uuid = uriViewId;

            @Override
            protected URLConnection openConnection(final URL url) throws IOException {
                return new URLConnection(url) {

                    @Override
                    public void connect() throws IOException {
                        // Gets not called in this case
                    }

                    @Override
                    public InputStream getInputStream() throws IOException {
                        initHandler();
                        try {
                            // Cargamos el contenido de la plantilla .xhtml
                            byte [] content = ....... ;
                            final InputStream input = new ByteArrayInputStream(content);
                            return input;
                        } catch (final Exception e) {
                            throw new IOException(e.getMessage(), e);
                        }
                    }

                    private void initHandler() {
                        log.debug("Init Handler");
                    }
                };
            }
        };
    }

    /**
     * Sistema de Logs
    */
    protected static transient Log log = LogFactory.getFactory().getInstance(CustomResourceLoader.class);

}

Quizás el equipo de desarrollo de Seam Framework propongo otro tipo de soluciones en el futuro para estos casos, pero por ahora, tenemos que hacer un poco de magia.

En el capítulo de movilidad, y cuando nos referimos a firma electrónica móvil, ya son muchos los casos de éxito y experiencias reales como hablar con propiedad a la hora de atrevernos a etiquetar sus niveles de madurez.

Desde una simple invocación a firma en servidor, pasando por la firma “in-side” del dispositivo hasta llegar a la firma desde dispositivos seguros de creación de firma, tenemos para todos los gustos.

En mi anterior post sobre la “Firma Electrónica Reconocida” toqué parte de la firma móvil, esbozando una similitud a la nomenclatura recogida en la Ley 59/2003 donde describe la firma electrónica, teniendo como resultado:

• Firma Móvil Simple
• Firma Móvil Avanzada
• Firma Móvil Reconocida

Al igual que hice en mi anterior artículo, matizo que “firma simple” no está recogido como tal en la normativa, pero como término sí es aceptado en nuestro sector.

En aquel artículo aclarar cada modalidad con una descripción aproximada, y en esta ocasión, lo intentaré hacer con casos reales.

Emulación

Sin duda, lo más extendido en el mercado es la “Firma Móvil Simple”, en mi opinión, una emulación de firma móvil, ya que en ningún momento la firma se realiza en un dispositivo móvil. Se trata de una invocación a servidor para que se éste quien firme el documento con un certificado instalado también en servidor.

Nos encontramos por tanto en la base de la pirámide, donde podríamos meter todos los casos de uso que conocemos y que, en mi opinión, no se tratan de firmas móviles aunque se insista e intente confundir a la audiencia.

Pool de Certificados

Nos encontramos con casos de uso de Firma Móvil Avanzada, es decir, firmas electrónicas avanzadas al tener en todo momento el control exclusivo del certificado durante el momento de la firma y dentro del dispositivo móvil.

¿En qué consiste exactamente?

Denominamos pool de certificados a la posibilidad de disponer de un repositorio de certificados de usuario de forma remota, y que éstos puedan ser demandados desde dispositivos móviles para su uso dentro del mismo.

¿Cómo se hace?

El certificado digital viaja de forma segura entre el repositorio y el dispositivo móvil. Además de la encriptación en la comunicación, el certificado necesitará el PIN en el momento de su uso, y sólo el propietario lo conoce.

Además, la transacción va acompañada de un OTP (One Time Password), es decir, el dispositivo móvil sólo dispondrá del certificado digital para esa operación y por un tiempo limitado.

¿El resultado?

Una firma dentro del dispositivo móvil, con el certificado digital bajo el control del usuario.

¿Por qué esta modalidad?

En tiempos de crisis, la optimización de recursos agudiza y exprime los presupuestos anuales en las empresas y administraciones públicas, y el hecho de compartir un dispositivo móvil entre varios usuarios resulta convincente para esta toma de decisiones.

En nuestro caso, una cadena de hospitales, tres turnos de médicos/enfermeras, 1 mismo iPad compartido (8 horas cada uno).

Una vez el certificado dentro del dispositivo, ya podemos usarlo en una Firma Móvil, y pasamos a último nivel de la pirámide.

Firma Móvil

Por último, y en el más alto nivel de maduración, nos encontramos con aquellas firmas electrónicas que son realizadas con Certificados Digitales “inside” del dispositivo móvil.

Si nos referimos a Certificados basados en software (p12) y gestionados en tu dispositivo, por ejemplo, desde tu iTunes, estamos hablando de Firma Móvil Avanzada.

Si nos referimos a Certificados instalados dentro de una SIM, y a su vez ésta es considerada como un Dispositivo Seguro de Creación de Firmas (ej. certificaciones FIPS-140), entonces estaríamos hablando de Firma Móvil Reconocida.

El punto de Equilibrio

Entre todas las modalidades, y como siempre, optamos por el equilibrio entre la legalidad y la usabilidad será nuestra factor de éxito, y por ello, la Firma Móvil Avanzada sea la modalidad más extendida entre nuestros casos de éxito.

La Sede Electrónica de la Diputación de Cádiz, el Ayuntamiento de Pozuelo, el Sistema de Bonificaciones de la Fundación Tripartita o el Título Electrónico de SIGNE entre otros muchos, son casos de éxito que ofrecen a sus usuarios un canal más para sus tramitaciones con firma, la Firma Móvil.

En estos días hemos sido testigo de un importante paso hacia la democratización del uso del DNIe para los usuarios de Windows, y me refiero a la incorporación del Driver del DNIe en las actualizaciones automáticas de Windows Update.

Cuando toca criticar se critica, pero cuando hay que apoyar, aquí mi mi granito de arena para hacer eco de esta buena noticia para los usuarios de Windows.

Tras la novedad este post lo que pretende es demostrar su utilidad, y para ello, armándome de valor , le robé a mi mujer por un rato su portátil con Windows 7 para comprobar en persona la mejora.

Enchufar y Listo

En cuanto pinchas el lector automáticamente se inicia la búsqueda del nuevo componente y en un minuto ya está listo para su uso.

Uso del PIN

La primera vez que vas a utilizar tu DNIe te avisa del uso de tu PIN por parte de una Aplicación. Una vez confiada, no volverá a preguntártelo.

Autenticación y Firma

Como ya sabéis, el DNIe posee 2 certificados, uno para autenticar y otro para firmar. Entre las novedades de la incorporación del driver en Windows se comenta que se ha reducido el número de veces que te solicitan confirmación del PIN.

No sé si antes existía esta diferencia o no (no soy usuario de windows), pero en esta prueba que hice en persona, noté que, independientemente de la solicitud del PIN, sólo en el caso de la firma windows me pide confirmación de la operación.

Caducidad

Como siempre, en caso de caducidad Windows avisará al usuario mediante el siguiente mensaje.

(esta captura es real, así que mi próximo post relacionado con el DNIe ya podéis averiguar de qué tratará ).

Listo para Usar

Ahora sólo tenemos que usarlo, y para ello, probamos con Viafirma Platform. Realicé la misma prueba desde IExplorer, Chrome y Firefox. Sin embargo, según explica ZonaTIC en su sección del DNIe, Firefox no se entera de este nuevo driver, y cito textualmente:

[...] Este driver basado en la nueva arquitectura “Smart Card Mini-Driver” (conocida también como “Smart Card Module”) de Microsoft, funciona enInternet Explorer y en Google Chrome, pero no en Mozilla Firefox que utiliza la arquitectura PKCS#11. [...]

Sin embargo, con el Applet de Viafirma esto no es problema, y con Firefox también podrás usar tu DNIe.

El excluido

En resumen, pretendía confirmar en primera persona las buenas noticias de la semana pasada, pero lamentablemente me quedo con mal sabor de boca con un “pero” en la solución, ya que Firefox ha sido excluido de esta gran noticia para los usuarios de Windows, es decir, espaldarazo a uno de los navegadores más utilizado en el mundo (según quién lo mida):

www.w3schools.com (setptiembre 2011)

www.netmarketshare.com

W3 Counter (octubre-2011)

No son pocos los foros de discusión en los que en mayor o menor medida se continúa debatiendo sobre el éxito o el fracaso de la implantación del DNIe en España.

Sin embargo, este artículo no pretende ser uno más de ellos, sino más bien pretende plantear una pregunta muy relacionada al uso de un dispositivo como el DNIe según la normativa de Firma Electrónica; ¿estamos preparados para la Firma Reconocida?

Para ponernos en situación, una breve y necesaria explicación sobre los niveles de la firma según nuestra normativa actual.

Niveles de Firma

Según la Ley 59/2003 de Firma Electrónica, estas tres modalidades de firma electrónica quedarían definidas de la siguiente forma:

Artículo 3. Firma electrónica, y documentos firmados electrónicamente.

1. La firma electrónica es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante.
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.
3. Se considera firma electrónica reconocida la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma.

Esto aterrizado a la tierra y con ejemplos prácticos sería igual a:

1. firma simple: por ejemplo, CSV (código de verificación segura) proporcionado por un Registro Electrónico, Internet Banking, etc. y que nos permite identificar un documento asociado a un titular. En realidad, el concepto de firma “simple” no viene recogido como tal en la Ley de Firma Electrónica, pero sí se ha popularizado de esta forma, sobre todo si va de la mano de otros mecanismos contemplados en normativas asociadas, como la Ley 11/2007 y la vinculación de CSV’s generados desde una Sede Electrónica. (ver artículo sobre este asunto en el Blog de Julián Inza)
2. firma avanzada: la más conocida, extendida y veterana en nuestra país, el más claro ejemplo, la firma realizada en la Agencia Tributaria a la hora de presentar nuestro borrador y con nuestro certificado digital basado en software (p12) de la FNMT (y otras CA’s).
3. firma reconocida; se trata de una firma avanzada pero que además ha sido realizada con un certificado reconocido, es decir, fue emitido por una CA autorizada por el MITyC, y además, y aquí viene lo más importante, fue generado desde un dispositivo seguro de creación de firma, por ejemplo un HSM o el famoso DNIe.

Equivalente a la Firma Manuscrita

Siendo purista, sólo la firma reconocida es la que tiene plena equivalencia con la manuscrita, pero entonces, ¿alguien se atrevería a afirmar que la AEAT lleva años aceptando firmas “no legales”? ¿De cuántos millones de operaciones y documentos firmados estamos hablando?

De la misma forma en la que en materia jurídica se deben aplicar criterios de proporcionalidad, aquí estaríamos ante algo parecido: ¿sacrificamos tecnicismos en detrimento de masificar un servicio a la ciudadanía?, es decir, ¿de cuántos millones de declaraciones presentadas electrónicamente estaríamos hablando a día de hoy si la AEAT hubiera exigido firmas reconocidas en lugar de avanzadas. Probablemente no darían ni para la portada de un post.

Democratización

No cabe duda que el DNIe ha conseguido estar en el bolsillo de más de 25 millones de españoles pero, en cuántos de ellos tenemos un certificado digital (en realidad un par de ellos), y en cuántos otros tenemos un mero plástico identificativo (el carné de identidá como dirían mis padres).

Firma Móvil

Con este escenario de distintos niveles de firma, y el fomento del uso de un tipo de dispositivo que no llega a cuajar como el DNIe, tenemos los ingredientes necesarios para hablar de la Firma Móvil.

No hay discusión sobre la penetración de smartphones en nuestras vidas, a nivel personal y a nivel profesional. Por ello nos enfrentamos a un fenómeno parecido al descrito antes con la AEAT.

Es decir, con la AEAT podemos presumir de ser el motor de la Firma Electrónica en España, y lo consiguió porque, manteniendo las distancias, no era algo tan complicado. En este caso, se valieron de firmas avanzadas y con ello pudimos usar certificados digitales en formato software p12. El resultado: masificación del servicio.

Y qué tiene esto que ver con la Firma Móvil, mucho.

Firma Móvil: reconocida

Las primeras experiencias de Firma Móvil en este país comenzaron por lo complicado, por la firma reconocida, cómo no.

Acuerdos titánicos entres las grandes operadoras (Vodafone y Movistar) con la FNMT para conseguir lo imposible; tener el certificado de éstos en la SIM de los terminales vendidos como una práctica habitual.

De esta forma cubrirían el requisito para ser firma reconocida: [...] generada mediante un dispositivo seguro de creación de firma [...].

Para ello, tendrían que certificar la SIM y el proceso de creación del certificado dentro de la misma.

Seis años después de aquel intento qué tenemos: prototipos y soluciones en cajones de muchos ilusionados, entre ellos nosotros con nuestro primer prototipo para Symbian con un cliente de firma, allá por 2006.

Firma Móvil: avanzada

Buscamos facilitar las cosas? buscamos democratizar el servicio, bueno, de esto ya se encargan los grandes, pero en este caso, los grandes del lado de la fabricación, y me refiero a Apple, Android , BlackBerry y Microsoft.

¿Algo natural?; conectar tu iPhone, abrir iTunes y sincronizar (arrastrar) tu música, fotos, vídeos, contactos….y, tus Certificados Digitales en formato software (p12), ¿por qué no? Práctico y Cotidiano.

Firma Móvil: simple

Bueno, por seguir con la definición que hice al principio de Firma Electrónica, no voy a dejar esta comparación sin su pareja, por lo que estaríamos hablando de firma simple en el móvil aquella en la que, de algún modo, se inicia en el dispositivo móvil, pero que en la práctica no se realiza en él.

Prácticas habituales en este caso son aplicaciones que realizan una petición de firma a servidor, en donde se tiene un Certificado Digital instalado, y es ahí donde se realiza la firma.

En este caso, en ningún momento se puede garantizar que el firmante puede mantener bajo su exclusivo control los datos de creación de firma (su certificado) porque sencillamente, éste no está en el terminal, sino en un servidor remoto.

En próximos artículos hablaré de las distintas prácticas de Firma Móvil aquí descritas con casos de uso reales.

Conclusiones

Me siento privilegiado por haber sido testigo de primera línea de la evolución de la Firma Electrónica en España (y por suerte en LATAM), y más aún de la Firma Móvil, y por ello tengo claro una cosa: lo práctico sube como la espuma, y si lo práctico se hace cotidiano, tendremos éxito.

El pasado 26 octubre 2011 se celebró en Sevilla el encuentro tecnológico para jornadas e-TIC de la Administración Electrónica. En ellas se dieron cita proveedores y administración pública, repasando la actualidad más reciente en cuanto a la simplificación de servicios en la administración pública.

Como no podía ser de otra forma, asuntos candentes como la crisis económica, la reducción del gasto o la situación del sector TIC en Andalucía se pusieron a debate desde varios puntos de vista.

Ponentes destacados como Juan Antonio Cobeña, Director de la Administración Electrónica en la Junta de Andalucía, o Domingo Laborda Carrión, antiguo Director de Modernización Administrativa del MAP y Observatorio de Red.es entre otros, compartieron sus experiencias y esfuerzos en sus intentos para la modernización y simplificación de los servicios públicos.

Regulación vs. Madurez de cumplimiento

Alusión obligada al año 2007 como un año muy fructífero en cuanto a regulación de nuestro sector TIC, con leyes que a la postre serían la guía de nuestro trabajo en estos últimos años, como las leyes 11/2007 “Acceso electrónico de los Ciudadanos a los Servicios Públicos”, 30/2007 “Contratos del Sector Público”, 37/2007 “Reutilización de información del Sector Público” ó 56/2007 “Medidas de Impulso a la Sociedad de la Información”, pero que a día de hoy distan mucho de su madurez de cumplimiento.

No en vano, casi cinco años después, publicamos con entusiasmo iniciativas o hitos relacionados con estas leyes de 2007, y que si hiciéramos ejercicio de auto-crítica, nos preguntaríamos, ¿en qué hemos fallado para tardar tanto, o por qué aún no estamos entre los 10 primeros países del ranking?

Un rápido repaso con ejemplos de andar por casa

Siguiendo un ejemplo para cada una de las leyes citadas anteriormente y que, no olvidemos, fueron aprobadas en 2007, podríamos citar líneas de trabajo de rabiosa actualidad, como son:

11/2007 “Acceso electrónico de los Ciudadanos a los Servicios Públicos”

Guía de trabajo sin duda para todos nosotros, y que me gustaría destacar  dos conceptos muy inmaduros a día de hoy:

• Neutralidad Tecnológica, amparado en esta Ley como un Principio General, y que brilla por su ausencia en la mayoría de servicios públicos: “…inténtelo desde Windows.”
• Dispositivos Móviles, reconocido en esta Ley como un canal más de comunicación con el que el Ciudadano tiene derecho a relacionarse con la Administración Pública. En este caso observamos una carrera vertiginosa entre Sistemas Operativos y Fabricantes de Smartphones a la que difícilmente los servicios públicos puedan sumarse en forma y tiempo.

Nos encontramos por tanto, ante un reto mayor para el principio de Neutralidad Tecnológica, y por el que nosotros los proveedores TIC debemos contribuir en favor de la administración.

ENI – Esquema Nacional de Interoperabilidad

También sobre esta Ley 11/2007 pudimos celebrar el pasado verano la aprobación de la mayoría de las Normas Técnicas de Interoperabilidad previstas por el ENI, si bien aún faltan algunas, podemos decir que tenemos tela con la que cortar.

30/2007 “Contratos del Sector Público”

Nosotros, proveedores TIC de las Administraciones Públicas, ¿cuántos contratos hemos firmado en los últimos dos años con éstas? La pregunta no pretende hacer sangre ante la caída acentuada de presupuestos, más bien va dirigida a un aspecto muy significativo: ¿cuántos de ellos han sido notificados (adjudicación) vía fax y firmados de puño y letra con su debido sello?

Sin ir más lejos, hemos sido adjudicatarios en este año de dos licitaciones para Portafirmas Electrónico y Plataforma de Firma Electrónica, para administración local y estatal (Ayto. Pozuelo y AEMET respectivamente), y ambos fueron firmados de la manera tradicional.

Facturae

Relacionado también con esta Ley, tenemos la difusión e implantación de la factura-e. Formato no exento de controversias y una muy escasa participación e implantación.

De hecho, recién salida del horno, tenemos borrador oficial para el formato facturae 4.0, válido hasta el próximo enero de 2012, donde se publicará versión definitiva atendiendo a los comentarios o revisiones recogidos hasta entonces.

También recientemente se aprobó por Consejo de Ministros la Orden PRE/2794/2011 encargada de articular la difusión de la Factura-e (nuevamente). En este caso, recae la responsabilidad en dos Ministerios, MAP y MITyC para su difusión en AAPP y Entidades Privadas (en especial pymes) respectivamente.

Además de la difusión por parte de estos Ministerios de la factura-e, la Orden regula la creación de una Comisión Técnica para brindar soporte a ambos Ministerios, además de formar parte del Foro Nacional. Foro al que también se adhierenentidades no estatales, entre ellas, AMETIC, la patronal de las TIC.

Con estas medidas recientes, sumadas a las que arrancaron hace una año para la creación de una Arquitectura Normalizada y Centralizada para la Factura-e, se pretende dar cumplimiento a parte de lo que se recogió en esa Ley 30/2007.

37/2007 “Reutilización de información del Sector Público”

Hace apenas unos días el Consejo de Ministros aprobó un Real Decreto para la reutilización de la información pública, contribuyendo al proyecto www.aporta.es, iniciativa de 2009 para poner en práctica esta ley y favorecer la Apertura de Datos.

En resumen, nos queda mucho por hacer pero no cabe duda que hemos recorrido un gran camino.

Aprovechando la publicación en el BOE de la Disposición 14814 sobre la recogida de avales mediante firma electrónica, y gracias la confianza e interés demostrada por varios partidos en Viafirma, acabamos de lanzar una nueva aplicación web destinada a este fin que ofrecemos de manera gratuita.

Gracias a “Viafirma Avalando“, que es como hemos denominado a esta aplicación, se ofrece a todos los ciudadanos la posibilidad de avalar a los partidos mediante DNIe y certificados electrónicos.

La firma de estos avales no significa dar el voto ni comprometerse con el partido, sino que es una forma de ayudar a los partidos tradicionales que no han obtenido representación en ninguna de las Cámaras en la anterior convocatoria de elecciones.

Os dejamos un enlace a los dos partidos que han colaborado con nosotros, aunque esperamos que pronto sean más los que se sumen a esta iniciativa

http://www.avalando.es/pa/
http://www.avalando.es/foro/

• La información reside los sistemas origen, por lo que no es necesario replicarla para su almacenamiento en un sistema centralizado.
• Para permitir que los contenidos de un sistema sean accesibles por iCMS sólo es necesario contar con un “driver” o adaptador (aplican los formatos y vocabularios a la información). En la mayoría de los casos no es necesario realizar ningún tipo de modificación en dichos sistemas.
• Los sistemas interesados (por ejemplo, reutilizadores de la información) en consumir cierta información pueden suscribirse a las colecciones pertinentes (datasets) y, cada vez que se producen cambios en las mismas, el servidor iCMS correspondiente realiza notificaciones dichos sistemas.

Unos compañeros acaban de publicar el plugin de Chuck Norris para Redmine en el repositorio oficial de plugins de la plataforma. El plugin básicamente añade a la pestaña Overview (Vistazo) aleatoriamente una cita del amigo Chuck. Además, en función del estado de las peticiones del proyecto, Chuck estará contento o enfadado.

Os adjuntamos un pantallazo del resultado: