Archivo de la categoría: Electronic Signature

Proyecto Binum. Firma electrónica combinada RSA y curvas elípticas


En Albalia hemos creado un laboratorio de productos y servicios relacionado con la Sociedad de las Información que desarrolla mecanismos probatorios en torno a los documentos electrónicos, sistemas de notificación y publicación fehaciente y otras iniciativas avanzadas.

Cuando identificamos ciertos riesgos en el uso de algoritmos concretos de hash y de criptografía asimétrica nos planteamos la conveniencia de utilizar sistemas duales que garantizaran que si se producen colisiones respecto de un algoritmo se mantenga otro en el que la colisión respecto al mismo documento sea virtualmente imposible.

Uno de los resultados de esta iniciativa es el Proyecto Binum.

Binum es un proyecto de I+D+i realizado en cooperación por Idoneum Electronic Identity y Albalia Interactiva y con la colaboración de la Universitat de les Illes Balears que tiene por objeto la creación de un criptosistema PKI de firma electrónica que combina los algoritmos criptográficos RSA y de curvas elípticas.

Las tareas realizadas en el año 2008 para este proyecto han sido cofinanciadas por el Ministerio de Industria, Turismo y Comercio, dentro del Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica 2008-2011 (con referencia TSI-020100-2008-681).

El objeto del proyecto Binum es crear la tecnología suficiente para poder realizar implementaciones de sistemas PKI lo más seguras posibles llevando el estado del arte un poco más allá mediante al uso combinado de los algoritmos RSA y de curvas elípticas.

Para ello son necesarios principalmente los elementos que se detallan a continuación:

  • Estudio y propuesta de modificación de especificaciones, estándares y protocolos para la inclusión de esta novedad, que permita una evolución de los sistemas usados en la actualidad a esta nueva tecnología.
  • Realización de una aplicación que demuestre dichos conceptos.
  • El desarrollo de un dispositivo seguro de creación de firma, compatible con la definición que de éste hace la ley 59/2003, de 19 de diciembre, de firma electrónica, y el desarrollo técnico de estas características en la especificación CEN CWA 14169.
  • El desarrollo del middleware necesario para poder interactuar con el dispositivo seguro de creación de firma desde aplicaciones ejecutadas en ordenadores personales y demás sistemas.

Servicios DSS en EADTrust


EADTrustEADTrust es la denominación del conjunto de servicios on-line que impulsa Albalia, relacionados con la firma electrónica, la factura electrónica y la administración electrónica. Entre los servicios disponibles están los relacionados con el sellado de tiempo (timestamping) tan necesarios en los servicios de autenticidad de la sociedad de la información.

Desde hace unos dias hemos liberado la funcionalidad DSS (Digital Signature Service) que permite firmar electrónicamente y verificar firmas electrónicas de forma remota. Esta funcionalidad va a quedar a disposición de los integradores que van a poder desarrollar servicios cliente DSS sin coste alguno.

El entorno que ahora se publica cuenta con algunas restricciones que no se aplicarán a los servicios comerciales: solo gestionará firmas XAdES X-L , no se permitirán frecuencias de consulta o peticiones de servicio superiores a 10 por minuto, la TSA utilizada es la propia de EADTrust, los servicios de validación no son configurables.

La especificación DSS (Digital Signature Services) alcanzó el nivel de Standard de OASIS en junio de 2007, en su versión 1.0. Esta especificación simplifica la gestión de las firmas electrónicas en las organizaciones, permitiendo la definición de modelos de gestión centrados en servidores que se alinean con las arquitecturas de sistemas más avanzadas. Las claves privadas se pueden gestionar de forma segura en entornos centralizados y puede evitarse la dispersión de material criptográfico en los ordenadores individuales de los usuarios, robusteciendo la política de seguridad mientras se saca partido a las múltiples funcionalidades de la firma electrónica.

DSS describe dos protocolos de tipo petición/respuesta basados en XML, uno para generar firmas electrónicas  y otro para verificarlas. Al usar estos protocolos, un cliente puede enviar documentos al servidor y obtener el documento firmado electrónicamente, o enviar un documento firmado al servidor y obtener los datos de la comprobación de la firma electrónica.

DSS da cobertura a diferentes tipos de firmas electrónicas, como las basadas en XML and CMS. Se desarrolla sobre un núcleo de elementos y procedimientos que pueden perfilarse para proporcionar determinadas funciones como time-stamping (incluyendo los basados en XML), validaciones de vigencia de certificados de múltiples prestadores de servicios de certificación, sellos corporativos, sellos de sede electrónica, marcas de notificación o publicación fehaciente, o firma de código ejecutable.

El estándar DSS de OASIS se desarrolló gracias al esfuerzo de reprerentantes de la American Bar Association, Cancillería Federal de Austria, BEA Systems, CATCert-Agencia Catalana de Certificacio, IBM, Nokia, Universal Postal Union, y otros.

Estos servicios representan la posibilidad de que el sector privado pueda disfrutar de servicios equivalentes a los que proporciona la herramienta @firma del MAP y de la Junta de Andalucía, o PSIS (Plataforma de Servicios de Identificación y firma) de CatCert en el sector público, pero actualizados a las versiones más recientes de los estándares técnicos. También en muchos organismos del ámbito público pueden preferir el uso de EADTrust al de @firma, dependiendo de cuales sean sus necesidades en relación con la firma electrónica.

Algo muy necesario en el marco de las obligaciones marcadas por la Ley 11/2007 y la Ley 30/2007 para el sector público y la Let 22/2007 y la Ley 56/2007.

Recibir facturas electrónicas


A veces, los interesados en recibir facturas electrónicas se encuentran con el problema de comunicar a sus proveedores este interés, a ser posible sin necesidad de tener que hacerlo uno por uno. Por otro lado los proveedores deben verificar la conformidad de sus clientes respecto a la recepción de la factura electrónica.

Ambos intereses se concilian gracias a los directorios de facturación electrónica. En estos directorios, el receptor se da de alta autorizando la recepción de facturas electrónicas y comunicando los sistemas de facturación preferidos señalando sus requisitos técnicos. El emisor, consulta por el CIF verificando esos datos y obteniendo la dirección de envío, adaptándose al mecanismo preferido por el emisor.

La siguiente pantalla muestra el aspecto del directorio de ASIMELEC cuando se consulta por el CIF de Albalia Interactiva.

Guia eFactura

Guia eFactura

La siguiente información es la pantalla equivalente en el Directorio de Facturae (del Ministerio de Industria, Turismo y Comercio).

Directorio facturae

Lo que queda claro es que Albalia Interactiva acepta facturas electrónicas XML en las diferentes versiones de UBL y facturae, y también en PDF (firmadas electrónicamente), y que acepta firmas electrónicas XAdES EPES y XL según diferentes versiones de la norma. Y que en estos momentos preferimos recibir las facturas en formato facturae 3.1 y firma XAdES-XL.

Para que estos directorios sean útiles, es importante que las empresas receptoras se den de alta, y que las empresas emisoras integren los webservices de los directorios en sus aplicaciones de facturación.

En estos momentos ya existen 2 plataformas que integran los servicios de directorio de ASIMELEC: la desarrollada por FENITEL y de la que se benefician los instaladores de infraestructuras de telecomunicaciones y la desarrollada por la propia Albalia Interactiva: Faccil.

Publicacion fehaciente en el «Perfil del Contratante»


En los foros de el Economista se inicia un diálogo entre «aibapas» y «Experto Derecho Editores» que centra los aspectos principales del problema a que da lugar la aplicación de la Ley 30/2007 de Contratos del sector público.

En el artículo 42 de la Ley de Contratos del Sector Público se habla del Perfil de Contratante, a través del cual los organismos públicos deberán publicar en Internet la información contractual del órgano de contratación.

En el propio artículo se hace referencia a la necesidad de «acreditar fehacientemente el momento de inicio de la difusión pública de la información que se incluya en el mismo».

Dispone el art. 42.3 de la Ley 30/2007, de 30 de octubre, de Contratos del Sector Público (EDL 2007/175022):

“3.- El sistema informático que soporte el perfil del contratante deberá contar con un dispositivo que permita acreditar fehacientemente el momento de inicio de la difusión pública de la información que se incluya en el mismo”.

Este párrafo se incardina dentro del art. 42: “Perfil del contratante” y, como indica expresamente el párrafo 1º del artículo, hace referencia los requisitos que se imponen a la Administración o entes del Sector Público contratantes para informar de su actividad contractual vía las páginas Web institucionales.

Por su naturaleza, estamos ante un supuesto en el que el término fehaciente se especializa por el carácter electrónico del medio de comunicación, y tiene como objeto el garantizar a los licitadores y ciudadanos en general los plazos que disponen para el ejercicio de determinados derechos; así, el artículo 37.6 de la Ley prevé un plazo de diez días hábiles contados a partir del siguiente al que se notifique o publique el acto impugnado para interponer el recurso especial en materia de contratación, o el 135.4, respecto de la adjudicación provisional de los contratos, que impone un plazo de quince días hábiles mínimo para elevar las adjudicaciones provisionales a definitivas contados desde el siguiente a aquél en que se publique aquélla en un diario oficial o en el perfil del contratante del órgano de contratación.

Tratándose de la acreditación de la fehaciencia de anuncios efectuados por medios telemáticos, habrá que acudir para interpretar qué se entiende por fehaciente a la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos (EDL 2007/41808):

La Ley 11/2007, en su art. 6.2, letra i), eleva al rango de derecho el de los ciudadanos “a la garantía de la seguridad y confidencialidad de los datos que figuren en los ficheros, sistemas y aplicaciones de las Administraciones Públicas”. Desde esta perspectiva, fehaciencia es el derecho, que no debe quedar al arbitrio de la Administración o Ente Público, de que la información, en este caso fecha de publicación la Web, en el perfil del contratante, es veraz e inmodificable por el contratante. Para el desarrollo de este derecho, la Ley 11/2007 prevé las siguientes obligaciones por la Administración o Ente contratante:

1º .- El establecimiento de una Sede Electrónica, con los requisitos del art. 10 de la Ley , especialmente en su párrafo 2º que obliga al titular de la sede electrónica sobre la integridad, veracidad y actualización de la información.

2º .- El uso por la Administración o Ente contratante de sistemas de firma electrónica para la actuación administrativa automatizada , con los requisitos exigidos por el artículo 18 que, a su vez, remite a la legislación específica sobre firma electrónica avanzada.

3º.- El equivalente, aunque sea referido de las comunicaciones bilaterales de la Administración o Ente con el particular, del art. 27. 3 de la Ley 11/2007 cuando señala, sobre las comunicaciones electrónicas, que Las comunicaciones a través de medios electrónicos serán válidas siempre que exista constancia de la transmisión y recepción, de sus fechas, del contenido íntegro de las comunicaciones y se identifique fidedignamente al remitente y al destinatario de las mismas.

En resumen, a los efectos del art. 42.3, la acreditación fehaciente le corresponde a la Administración o Ente Público contratante, siendo la fehaciencia a estos efectos que se haga por medios de firma electrónica avanzada, dónde consta fecha, hora y huella digital de la notificación en el perfil del contratante dentro de la Web, de acuerdo con las obligaciones que se impone a la Administración o Ente del Sector Público por la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.

Sin embargo hay algunos aspectos que, en mi opinión siguen sin estar claros en la respuesta, y que deben ser resueltos en las implementaciones.

En primer lugar la fehaciencia implica la existencia de un mecanismo creible, fidedigno, incuestionable. Algo que como terceros de confianza se atribuye a la actuación de notarios, jueces, secretarios judiciales y funcionarios en el ejercicio de sus atribuciones. Por regla general determina un mecanismo probatorio independiente del ente que precisa la fehaciencia (para evitar que se produzca la colisión de suponer ser «juez y parte» en el procedimiento de que se trate).

La firma electrónica, por sí misma, solo aporta fehaciencia (elevada pero no incuestionable) respecto a la identidad del firmante (al menos sobre la atribuibilidad de la firma al firmante) y presupone su «voluntad de firmar», pero no garantiza aspectos como la efectiva publicación o su fecha.

Si a la firma electrónica le añadimos un timestamping (en la modalidad de firma ES-T) añadimos la fehaciencia de que el documento firmado electrónicamente existía con anteriodad a la fecha y hora indicada en el fechado electrónico, pero no su publicación.

El mecanismo fehaciente de publicación en el perfil del contratante de más valor es un servicio de terceros que obtenga el documento de la sede electrónica del organismo contratante (en la correspondiente sección del perfil del contratante) y genere sobre el un sello de tiempo. El sello de tiempo debería estar disponible junto al documento publicado en el perfil del contratante, y junto a ellos un enlace al tercero de confianza electrónico en el que sea posible obtener el documento original junto con los detalles (metadatos) de su publicación.

Si el servicio es de alta calidad, comprobará además que el documento referenciado no se ha retirado de la sede electrónica y ha permanecido disponible durante el tiempo marcado hasta su prescripción, y reflejará cualquier incidencia al respecto en el ámbito de los metadatos asociados al documento.

Una via alternativa con un alto grado de presunción (aunque capacidad probatoria inferior) es la publicación en un Boletin Oficial o en un periódico de tirada adecuada en el ámbito en el que sea precisa la fehaciencia (nacional, local o autonómica).

Algunos de los servicios de terceros son los de Contratación del Estado, en el ámbito público o los de Albalia Interactiva (a través de su plataforma EADTrust) en el ámbito privado.

Firma electrónica en UBL


En el marco de OASIS se está trabajando para definir la recomendación de uso de la firma electrónica que se utilizará en los mensajes UBL.

El uso más obvio es el del mensaje «Order» (pedido) ya que habitualmente tiene carácter contractual, pero en el caso europeo, es importante también la firma de la factura electrónica (Invoice), por lo que este es el uso más inmediato de esta recomendación.

No se trata de definir una norma. De hecho la recomendación se alinea con la norma de ETSI TS 101 903.

Sin embargo, dada la amplitud de posibilidades en la generación de modelos de firma electrónica que se prevé en la norma y las dificultades que puede tener la adopción de sistemas de firma electrónica en un contexto internacional, definir una recomendación simplificará la interoperabilidad de los sistemas de facturación electrónica.

En mi posición, como miembro del grupo de trabajo que redactará la recomendación, me inclino por proponer firmas electrónicas desarrolladas en la modalidad «enveloped» de forma que al ser la firma un nodo XML del mensaje UBL no se dificulta el entendimiento del mensaje, incluso si el receptor no es capaz de gestionar firmas electrónicas.

Además el tipo de firma debería ser de tipo ES-X-L adjuntando la información de timestamping y validación en origen, de forma que el receptor no tenga que lidiar con un complejo sistema de prestadores de servicios de certificación, como el que existe en Europa, con diferentes lenguas que habría que entender.

Este tipo de firmas ya están contempladas en la actual norma facturae 3.1, por lo que, en cierto modo, ya estaría dado un pequeño paso en la convergencia de facturae 4.0 con UBL 3.0 (o UN/CEFACT Cross Industry Invoice 1.0, si es que finalmente se llama así la norma de CEFACT que parte de la UBL 2.1 de OASIS).

De momento ya hay una propuesta respecto a la forma de incluir firmas electrónica en los mensajes UBL 2.0. que ha desarrollado Oriol Bausà de Invinet.

Generación de facturae para SAP desde iDoc con Biztalk


Aunque generar ficheros facturae a partir de los ficheros iDoc obtenidos en SAP no es muy complicado cuando contamos con herramientas como Biztalk, surge la necesidad de firmar electrónicamente los ficheros resultantes.

Biztalk es un entorno de interoperabilidad creado por Microsoft que lleva varios años de evolución y que ya usan más de 9.000 empresas en todo el mundo. Permite convertir entre diferentes formatos (gestionando las reglas de conversión que puedencrearse con las herramientas incluidas en la plataforma), así como lidiar con diferentes protocolos de comunicaciones. Se suele usar en proyectos EDI, algunos tan específicos como los financieros de SWIFT, y también en entornos multifabricante porque permite resolver muchos retos de conectividad. Gestiona colas y cuenta con procedimientos de recuperación lo que lo hace adecuado para convivir con entornos Host Mainframe y aplicaciones de misión crítica.

En los proyectos en los que convive con SAP, Biztalk concentra los diferentes mecanismos de comunicación con bancos, clientes proveedores, …gestionando las conversiones iDoc. Por supuesto, no se limita solo a gestionar facturas, pero en este caso interesa precisamente por su adecuación a esta tarea. Nos permite enviar y recibir mensajes INVOIC típicos de EDI (probado en nuestros proyectos con versiones D93A y D96A de EDIFACT), y tratar con mensajes de factura UBL (versiones 1 y 2) y los específicos destinados a las administraciones públicas españolas: facturae 3.0 y 3.1.

Para las conversiones es frecuente que tengamos que personalizar las estructuras de conversión, en función de los criterios de implementación de SAP en el cliente, pero gracias a las herramientas disponibles, es un trabajo que se puede hacer muy rápidamente.

Pero nuestro punto fuerte viene cuando tenemos que aplicar firmas electrónicas (obligatorias en las facturas y recomendables en los pedidos). Por eso hemos desarrollado una personalización de nuestra Suite Backtrust, específicamente para que pueda ser invocada desde Biztalk, como uno más de los servicios que se orquestan desde la plataforma. Backtrust for Biztalk permite generar diferentes tipos de firmas electrónicas XML (XAdES) y específicamente los tipos ES-EPES y ES-X-L especificados por ETSI (TS 101 903) y de uso prescrito a partir de la Orden PRE 2971/2007, por lo que es adecuado para generar las facturas electrónicas que se exigen cuando el destinatario es una administración pública.

De igual forma si el usuario del sistema es una administración pública o un organismo dependiente, es posible tratar las firmas electrónicas y validarlas contra los servicios OCSP y CRL de los propios prestadores de certificación, o servicios de centralización de la validación como @firma del MAP o EADTrust.

Interlocución telemática


El 29 de diciembre de 2007 se publicó en el BOE la LMISI, Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Una de las características de esta norma es que impone a las empresas privadas ciertas obligaciones coherentes con el derecho de los ciudadanos a usar la vía telemática que se consagra en la  LAECSP, Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos .

En el artículo 2 de la LMISI se establece la obligación de ciertas empresa de disponer de un medio de interlocución telemática para la prestación de servicios al público de especial trascendencia económica. Y en la disposición final cuarta se indica que esta obligación entrará en vigor a los doce meses de la publicación de la Ley en el Boletín Oficial del Estado.

Todo el artículo tiene su interés, pero conviene destacar que sin perjuicio de la utilización de otros medios de comunicación a distancia con los clientes, las empresas que presten servicios al público en general de especial trascendencia económica deberán facilitar a sus usuarios un medio de interlocución telemática que, mediante el uso de certificados reconocidos de firma electrónica, les permita la realización de ciertos trámites como la contratación electrónica, modificación de condiciones contractuales, altas, bajas, quejas, histórico de facturación, sustitución de informaciones y datos en general, así como el ejercicio de los derechos de acceso, rectificación, oposición y cancelación en materia de protección de datos

Las empresas obligadas por esta normativa son aquellas con más de 100 empleados o un volumen de operaciones superior a los 6 millones de euros que presten servicios al público considerados como de especial trascendencia económica, como banca, electricidad, agua y gas, y telecomunicaciones, entre otros.

Para facilitar a todo tipo de empresas el cumplimiento de esta norma, Albalia Interactiva ha desarrollado en el marco de su gama de servicios EADTrust la funcionalidad de Interlocución Telemática que se integra con facilidad en el entorno web  de la empresa. De esta manera, en un tiempo record, es posible contar con este tipo de servicios y cumplir los plazos marcados por la ley. Los formularios firmados electrónicamente se guardan en formato XAdES-X-L (según se define por la norma TS 101 903) por lo que incluyen todas las evidencias electrónicas que afectan a la validez del certificado en el momento de la firma.

El sistema es personalizable con la imagen del web de la entidad y permite definir todo tipo de trámites y formularios. Además, es posible diseñar entornos mixtos en los que el formulario se completa y se prevalida en la entidad y se firma electrónicamente en la plataforma EADTrust.

Trámites que debe permitir la interlocución telemática

Mediante el uso de certificados reconocidos de firma electrónica, la interlocución telemática debe permitir a los clientes y usuarios la realización de, al menos, los siguientes trámites:

  • Contratación electrónica de servicios, suministros de bienes, la modificación y finalización o rescisión de los contratos, así como cualquier acto o negocio jurídico entre las partes.
  • Consulta de los datos de cliente, que incluirán información sobre su historial de facturación de, al menos, los tres últimos años y el contrato suscrito.
  • Presentación de quejas, incidencias, sugerencias y reclamaciones, garantizando la constancia de su presentación para el consumidor y asegurando una atención personal directa.
  • Ejercicio de los derechos de acceso, rectificación, cancelación y oposición en los términos previstos en la normativa reguladora de protección de datos de carácter personal.

Empresas afectadas por la normativa

Las empresas obligadas por esta normativa son aquellas que agrupen a más de cien trabajadores o cuenten con un volumen anual de operaciones superior a los 6.010.121 euros y que, en ambos casos, operen en los siguientes sectores:

  • Servicios de comunicaciones electrónicas a consumidores.
  • Servicios financieros destinados a consumidores, que incluyen los servicios bancarios, de crédito o de pago, los servicios de inversión, las operaciones de seguros privados, los planes de pensiones y la actividad de intermediación de seguros.
  • Servicios de suministro de agua a consumidores.
  • Servicios de suministro de gas al por menor.
  • Servicios de suministro eléctrico a consumidores finales.
  • Servicios de agencia de viajes.
  • Servicios de transporte de viajeros por carretera, ferrocarril, vía marítima o aérea.
  • Actividades de comercio al por menor.

Además, el Gobierno y las Comunidades Autónomas, podrán ampliar el ámbito de aplicación de esta obligación a otras empresas distintas de las previstas en la Ley, en aquellos casos en los que se considere que en el desarrollo de su actividad normal deban tener una interlocución telemática con sus clientes o usuarios.

Hito en EADTrust. Ceremonia de generación de claves root


Ayer tuvo lugar un hecho histórico en el desarrollo de EADTrust, Prestador de servicios de confianza digital, lo que supone un motivo de orgullo para todos los integrantes del equipo.

Llevamos a cabo la ceremonia de generación de claves de la autoridad de certificación root de la PKI en sede notarial. En la foto adjunta estamos los presentes en el acto.

De izquierda a derecha, yo mismo, Julián Inza, y seguidamente Fernando Pino, Maria Luisa Blasco, Luis Osses y Santi Casas.

Julian Inza - Fernando Pino - Maria Luisa Blasco - Luis Osses - Santi Casas

Julian Inza – Fernando Pino – Maria Luisa Blasco – Luis Osses – Santi Casas

No está en la foto, pero tuvo una contribución esencial, Mar de las Heras que ha aportado buena parte de los documentos legales del evento.

La fecha del 24 de septiembre de 2008, dia de la Virgen de la Merced, adquiere un nuevo significado para nosotros.

Colaboración en epractice.eu


La posibilidad de colaborar con epractice.eu está abierta a quienes estén interesados en la temática del impulso de la administración electrónica. Aunque yo llevo cierto tiempo como miembro de la comunidad, hoy he enviado mi primer artículo en el Blog conjunto.

Future trends in electronic invoicing

About one month ago, it was distributed a draft of the conclusions of the EC electronic invoice experts group regarding future regulation needs to push development and disemination of electronic invoices.

I was disappointed to find that one of the conclusions implies that electronic signature is seen as a barrier for further development of the electronic invoice, and a feature that some of the members of the expert group see as superfluous feature.

In my opinion, electronic documents need ways to reinforce security to allow to tell apart fake documents from authentic documents. Ths is generally true even for informative documents with less impact on companies results.

It is also true that electronic signature is not the only way to reinforce security regarding autenticity of documents. For example, a document can be assumed to be authentic if it is retrieved from a trusted source, even if it is not completed with an electronic signature. But then we must define what are the requirements of such «trusted sources» to keep that assumption.

On the other hand, both approaches, electronic signatures and reference or trusted sources (which in turn frecuently are based in electronic signature derived schemes) need more precise definition to avoid lack of interoperability, which, in my opinion is the real barrier for electronic invoice wide deployment.

Some common authenticity mechanisms are required both for electronic invoices (those that are born electronically from the beginning) and for invoices certified scanning (invoices digital copies that become equivalente to an original, after a security mechanism has been added to a common scanning).

This approach, «certified scanning», has been initiated in Spain with high success.

Certified scanning is a process in which an electronic signature is applied to a image file while it is scanned from a document paper. This image is stored in a secured database and the main concepts and terms of the paper document are added as metadata to the contextual fields of the image file in the database.

Once a paper document is «certifiedly scanned» the digital copy becomes equivalente to an original, and the paper source can be destroyed. The new «electronic original» can then be used for auditing purposes.

For the companies that receive thousands of invoices, «certified scanning» adoption imply benefiting from most of the advantages of the electronic invoice without dealing with the slow adoption pace that their suppliers could show.

If we want to support «certified scanning» we need a common definition of the requirements for that conversion. And they should not be very different form the requirements for «electronic invoices» .

If we accept authenticity mechanisms not based in electronic signature, they should be common for both approaches. And if electronic signature is still to be used in the future as the authenticity mechanism of the electronic invoice, the broad options in variants should be reduced and clearly defined (in my opinion, the XL definition of CAdES -TS 101 733- or XAdES -TS 101 903- should be used, including both validation and timestamping, from the signer side).

PEPPOL. Simplificación de gestiones transfronterizas


Una solución  electrónica integrada que eliminará las barreras para la contratación pública a través de las fronteras nacionales.

Ese es el objetivo de una completa propuesta de proyecto que se remitió recientemente a la Comisión de la Unión Europea desde un consorcio internacional con participantes de nueve países.

El Secretariado Noruego de eProcurement (contratación pública electrónica) es el órgano de coordinación para la propuesta y el posible proyecto piloto.

La aplicación de la solución a través de las fronteras va a sacar partido de las fortalezas y ventajas de cada nación en los sistemas nacionales existentes y facilitará de forma conjunta el despliegue  de una solución interoperable de contratación pública electrónica extendida a toda la UE. Si la solución tiene éxito, puede ser extendida a una mayor utilización por toda Europa.

El proyecto se titula “Pan-European Public Procurement On-Line” (Contratación pública pan-europea on-line), abreviado PEPPOL, y ha sido organizada como un consorcio.

El objetivo del proyecto PEPPOL es facilitar a los operadores económicos europeos, en particular las PYMEs de un país, la respuesta a las oportunidades de contratación pública ante poderes adjudicadores de otro pais a través del uso de soluciones de eProcurement (contratación pública electrónica) interoperables que actuan a nivel de toda la Unión Europea.

La solución interoperable de servicios del Proyecto PEPPOL se basa en especificaciones funcionales y consiste en una serie de Bloques constitutivos que cubren los diferentes requisitos de negocio identificados relativos a la utilización transfronteriza de las soluciones existentes para la Firma Electrónica (eSignature), Dossier Virtual de Empresa (Virtual Company Dossier), Catálogos Electrónicos (eCatalogues), Pedido Electrónico (eOrdering) y Factura Electrónica (eInvoicing). Los Bloques relativos a un aspecto pueden ser modificado sin que ello necesariamente tenga un impacto en los demás.

El consorcio PEPPOL consta de 14 participantes y un número de sub-contratistas de nueve naciones que representan a siete administraciones públicas. Los participantes tienen una amplia experiencia y profundo conocimiento de la contratación pública electrónica, sobre la base de sus soluciones nacionales o regionales en fases operacionales o de piloto avanzado que abarcan toda la cadena de valor de la contratación pública.

Para garantizar la difusión por toda la UE y la selección de resultados del proyecto, se ha establecido un grupo de referencia para los Estados miembros ajenos del consorcio. Asimismo se asignarán recursos pata futuras ampliaciones del consorcio.

Pan-European Public Procurement On-Line (Contratación pública pan-europea on-line)

Pan-European Public Procurement On-Line (Contratación pública pan-europea on-line)

El proyecto PEPPOL está organizado en cinco Paquetes de Trabajo (Work packages) funcionales, del WP1 al  WP5 y tres horizontales, del WP6 al WP8:

  • WP1 – eSignature, coordinado por la ciudad de Bremen, Alemania, que fue una de las primeras administraciones que ofreció aplicaciones que utilizan firma electrónica a gran escala.  El Documento «Directrices para las especificaciones comunes de Utilización transfronteriza pública de e-procurement» dice lo siguiente: «La falta de interoperabilidad entre los diferentes esquemas nacionales para firmar electrónicamente los documentos de concursos y ofertas es el más importante factor de bloqueo a las transacciones electrónicas transnacionales».
  • WP2 – Virtual Company Dossier (VCD), coordinado por la Universidad de Koblenz, Alemania. Este coordinador tiene un papel principal en BRITE (Business Register Interoperability Throughout Europe, Interoperabilidad de Registro Mercantiles  en toda Europa), y por lo tanto tiene la experiencia pertinente para la creación del VCD.
  • WP3 – eCatalogues, coordinado por Consip SpA, Italia, que contribuirá con su conocimiento en eCatalogues y con su consolidada experiencia internacional al consorcio.
  • WP4 – eOrdering, coordinado por ScotGov, Reino Unido. El coordinador de este Paquete aportará conocimientos específicos para el proyecto de eOrdering sobre la base de sus 5 años de experiencia que hasta la fecha han dado lugar a la manipulación electrónica de pedidos por valor de más de 2 millones de libras esterlinas.
  • WP5 – eInvoicing, coordinado por la Agencia Nacional de TI y Telecomunicaciones (NITA, National IT and Telecom Agency), Dinamarca. La NITA contribuirá con la experiencia danesa sobre Factura Electrónica.

Además, hay tres Paquetes horizontales: WP6 – Administración del Proyecto, coordinado por Ehandel.no, Noruega; WP7 – Sensibilización, difusión, creación de consenso y formación, coordinado por Peppol.at, Austria, y WP8 – Arquitectura de la solución, diseño y validación, coordinado por NITA, Dinamarca.

Además de los países mencionados, Finlandia, Hungría e Islandia son miembros del consorcio. André Hoddevik, Responsable del Secretariado noruego de e-Procurement actuará como coordinador de la propuesta y del proyecto piloto.