La Amenaza Fantasma


Aunque todavía no he recibido comentarios al POST anterior, sigo dándole al tema porque algunas cosas son menos obvias de lo que aparentan.

En el mismo sentido de la prgunta que he dejado en el aire, mi buen amigo César Belda, notario de Onda, gran experto en esto de la firma electrónica, ha dado el nombre de "La Amenza Fantasma" a una curiosa situación.

En la película de este título, perteneciente a la saga de "La guerra de las Galaxias", los malos tienen cientos de miles  de robots, pero un certero ataque a la nave controladora los deja a todos inactivos.

Esta situación presenta paralelismos con otra que se puede dar en el mundo de la firma electrónica: Uno de los requisitos para que una firma electrónica sea equivalente a la manuscrita, es que se acompañe de un certificado cualificado o "reconocido". Este, a su vez, debe ser expedido por un Prestador de Servicios de Certificación que emite Certificados Reconocidos, lo cual implica el cumplimiento de un elevado número de requisitos. Entre los requisitos hay uno, el de la constitución de una garantía económica de 3 millones de euros. La garantía puede ser mediante una de 3 formas:

  • Mediante un seguro de responsabilidad civil, que ninguna entidad aseguradora ESPAÑOLA proporciona. Además no existe previsión en el Consorcio de Compensación de Seguros ni en la Dirección General de Seguros de designar a una entidad para que diseñe el seguro (en los seguros obligatorios, como es este caso, la Ley del Seguro define que tiene que existir una forma de contratarlo).
  • Mediante un aval. Un aval no sirve para PSC porque el damnificado puede ser un titular del certificado o un tercero que confía, mientras que el beneficiario del aval puede ser uno que se nos haya ocurrido al contratarlo (por ejemplo, el Ministerio del Ramo, que no sé con qué excusa podría ejecutarlo)
  • Mediante un seguro de caución. Este es exactamente el mismo caso que el del aval, salvo por el matiz de que la garantía la proporciona una aseguradora en vez de una entidad financiera.

Bueno, como se ve, no hay forma de cumplir en España este requisito legal. Salvo por el pequeño matiz de que alguna aseguradora extranjera sí cuenta con seguros de este tipo (por cierto, también de dudosa ejecutabilidad, dadas las condiciones de contratación).

Bueno, a lo que iba. ¿qué pasaría si, por ejemplo, el PSC no renueva la póliza de seguro, o pasa un tiempo entre el vencimiento y su renovación?

¿dejan de servir los certificados? ¿la firma electrónica ya no es equivalente a la manuscrita? ¿lo firmado deja de ser válido? Es decir, ¿le pasa a la firma electrónica lo que a los robots de la amenaza fantasma? 

La ley 59/2003 de Firma Electrónica


Al intentar encontrar información sobre un aspecto que me preocupa de la aplicación de esta Ley, he dado con un artículo muy interesante escrito por la persona más directamente involucrada en su desarrollo, durante los años 2002 y 2003.

De paso, he encontrado un pequeño "kiosko virtual" en el ministerio de Industria, Comercio y Turismo, con los diferentes números de la revista Economía Industrial en formato electrónico.

El artículo de Salvador Soriano es un riguroso repaso a la Ley 59/2003, en un tono menos jurídico, pero eligiendo un lenguaje muy preciso, que no pueda dar lugar a falsas intepretaciones.

Por eso no he logrado confirmar ni desechar mi teoría sobre el tema, que expongo aquí por si hubiera algún amigo que quisiera comentar y exponer su punto de vista.

Lo que yo sostengo es que una firma electrónica es que es, ante todo, firma, y que el certificado que la acompaña es circunstancial a la firma, en el sentido de que puede reforzar presunciones hacia su reconocimiento pero no contra el.

Dicho con otras palabras: si los datos del certificado aportan algo a lo firmado, se acepta su relevancia, y si no, es como si no existieran.

Un ejemplo: supongamos que en un certificado se indica que una persona (Fulanito de Copas) es apoderada de la empresa "Aridos del Norte" y de "Bituminosos del Norte", para lo cual dispone de los poderes en papel, recién inscritos en el registro mercantil. Además acaba de obtener un "Certificado de Representante" en el que se señala la vigencia de sus poderes en Aridos. Supongamos que Fulanito trata con Menganito de Oros, apoderado, debidamente acreditado de "Carreteras del Sur", y que acuerdan la venta de Aridos y Bituminosos para la ejecución de proyectos de Carreteras. Firman un contrato en PDF con sus respectivos certificados entre Bituminosos y Carreteras, tras mostrarse su poderes. Sin embargo, Fulanito emplea para firmar el certificado en el que solo se expresa su capacidad de representación en Aridos.

¿Es válido el contrato?

Avances en VISA y Master Card


La SEPA (Single Euro Payment Area) será la zona de Europa en la que los usuarios podremos utilizar los servicios bancarios de forma equivalente a como lo hacemos en la actualidad en nuestro propio país.

Entre los objetivos más importantes de simplificación y ahorro de costes están los que se refieren a las transferencias bancarias (payment orders), los adeudos por domiciliación (direct debit) y las tarjetas de crédito.

Las entidades financieras están trabajando en los distintos frentes, y cuentan con aliados poderosos en lo que se refiere a las tarjetas de crédito.

Estos últimos años, las marcas de medios de pago han afrontado retos importantes, como los que se refieren al despliegue de los sistemas de pago para internet (3D Secure Verified by Visa y MasterCard Secure Code )

En el caso de EMV, la especificación de tarjetas chip, destinada a luchar contra el fraude en las operaciones "off-line", la posición española era resistente. En España, las operaciones se realizan mayoritariamente "on-line", con una estructura de costes de telecomunicaciones envidiable desde la óptica de las entidades financieras de los países vecinos, de forma que el nivel de seguridad es muy alto, y el fraude, comparativamente bajo.

Las entidades españolas, que ya habían decidido demorar el despliegue de tarjetas EMV a sus titulares hasta 2008, habían acometido ya la conversión de TPVs (Terminales Punto de Venta, terminales financieros de recogida de operaciones electrónicas con tarjetas de crédito, de débito y monedero) y Cajeros Automáticos, como consecuencia de la aplicación, desde el 1de enero de 2005, de las nuevas reglas europeas de atribución de responsabilidades en transacciones fraudulentas.

Sin embargo, las nuevas reglas SEPA imponen que antes de 2010, EMV esté completamente desplegado en la "Zona Euro", de forma que las entidades españolas tendrán que acometer las grandes inversiones que estaban intentando demorar.

Estas exigencias de grandes inversiones se producen además en un momento en el que la banca española viene de negociar, con la intermediación del Ministerio de Industria, Comercio y Turismo un plan de reducción de comisiones que tiene que completarse en tres (3) años.

El mundo de los Medios de Pago está viviendo los "tiempos interesantes" de la maldición china, en los que tan importantes son los retos como las oportunidades, con tasas de adopción de medios de pago crecientes siempre.

En estos tiempos interesantes, no será seguramente, el reto menor la anunciada salida a Bolsa de Master Card. Baldomero Falcones, actual presidente del Consejo de Administración de Master Card anunció en el reciente evento CIT 2006 organizado por IIR España la salida a Bolsa de la entidad, reservando un 10% (el control bisagra) a una Fundación.

Armonización europea de la factura telemática


Veo con disgusto que en la próxima reunión de trabajo abierta de factura electrónica en el marco del Comité Europeo de Normalización se presentan borradores de documentos sobre el grado de avance en la adopción de la factura electrónica en Europa que, además de incompletos y sesgados, reflejan una notable ausencia: la de España. No sé si es que los miembros del grupo de trabajo, coordinado por AFNOR (el equivalente de AENOR en Francia) no preguntaron o no recibieron respuesta, pero me parece una ausencia injusta.

La reunión es en Bruselas el próximo dia 11 de abril de 2006, con motivo de los trabajos del CEN/ISSS Workshop on «Interoperability of Electronic Invoices in the European Community» .

La página web del Comité de Interoperabilidad de las Facturas Electrónicas en la Comunidad Europea está hospedado en AFNOR.

A la vista de los propios esfuerzos de normalización de la factura electrónica por la Agencia Estatal de Administración Tributaria, España está muy infrarrepresentada en estos trabajos del CEN.

Lo cierto es que desde la publicación de la Directiva 115 del año 2001, la unión europea está manifestando un gran respaldo a la facturación electrónica, dentro del esfuerzo de armonización de los mecanismos tributarios relacionados con el IVA (Impuesto sobre el Valor Añadido) y la facturación de las empresas y de los profesionales.

Parte de ese esfuerzo puede verse en estas Reglas de Facturación del IVA.

Por otro lado, es inevitable plantearse cómo de sincronizados van los esfuerzos de normalización de la factura a nivel técnico, lo que claramente es un objetivo de este grupo de trabajo, respecto a los grupos de trabajo de OASIS que están avanzando no solo en el mensaje de factura, sino en otros mensajes necesarios en la comunicación entre empresas. De hecho, estamos en la fase previa a la publicación de la versión 2.0 de UBL.  

La banca pacta un nuevo sistema centralizado para frenar el fraude


Las estafas crecen un 20% al año y ya provocan pérdidas de 110 millones.

Un tipo que logra suplantar la personalidad de un cliente desviando dinero de su cuenta o usando su tarjeta de crédito, otro que solicita préstamos en distintas entidades en varios puntos del país con datos falsos, un tercero que hace creer en Internet que su página web es la de determinada caja de ahorros… Morosos e impostores logran timar cada año a las entidades financieras y a sus clientes en torno a 110 millones de euros al año. Y el problema crece a un ritmo del 20% anual. Internet y la banca telefónica multiplican además las posibilidades

Para intentar frenar el problema, el Centro de Cooperación Interbancaria (CCI), la asociación que agrupa a más de 200 bancos y cajas de toda España, está promoviendo el proyecto llamado Servicio de Prevención del Fraude. El grupo Santander, el BBVA, el Banco Popular, Bankinter, el Banco Pastor, el Banco Gallego, el Banco de Finanzas e Inversiones y la Caja de Ahorros del Mediterráneo han acordado ya su implantación, según ha podido saber EL MUNDO.

El proyecto, que será presentado en las próximas semanas al Ministerio del Interior y que puede arrancar este mismo año, está encabezado con la creación del llamado Centro de Observación del Delito Económico. «Se trata de un equipo profesional contratado, formado por expertos en la lucha contra el fraude», según afirma Rafael Marín, director de Administración del CCI.

El Code se encargará de vigilar la red y difundir alertas tempranas de nuevos fraudes para prevenir a los asociados del CCI, a sus clientes y al público en general. Se convertirá en un centro de estudio del delito en España, capaz de colaborar con las fuerzas de seguridad y en la formación del personal bancario.

Y, sobre todo, el proyecto prevé la creación de tres bases de datos con un sistema centralizado. «Hasta ahora, cada entidad se defiende como puede del fraude, pero uniendo fuerzas en un sistema que proporcione alertas a todos los bancos y cajas se puede ser mucho más eficaz», afirman los promotores.

Intentos. El fichero de Solicitudes y Operaciones Registradas (SOR) almacenará los datos de fraudes conocidos que han afectado a los usuarios en algún momento. Las entidades que lo han sufrido alimentarán esta base con sus datos y utilizarán herramientas automáticas de análisis de solicitudes.

DNI robado. El Servicio de Actualización de Datos Personales (SADP) integrará en una base de datos los datos de personas físicas y jurídicas que se quieran incluir voluntariamente en un fichero de vigilancia. Personas que han perdido su documentación o que han sufrido un robo pueden darse de alta. Si alguien pretende realizar una operación financiera con sus datos serán avisados en tiempo real. «Por ejemplo, se les enviará un mensaje a su móvil de que alguien intenta algo con sus cuentas en ese momento», explica Marín.

Incoherencias. La base de datos de información de solicitudes (SOL) comparará posibles incoherencias. Si una misma persona pide un préstamo en BBVA alegando que gana 50.000 euros y al día siguiente solicita otro en el Santander asegurando que su sueldo son 55.000, será descubierto. «Ningún banco sabrá a qué otra entidad se ha dirigido, pero sí que esa persona está dando datos incoherentes en otras oficinas», resume Marín.

Intimidad. Los promotores aseguran que el proyecto no va a poner en peligro la intimidad de los usuarios, «al contrario, se van a ver más protegidos». El CCI ha mantenido reuniones con la Agencia de Protección de Datos y el Banco de España y, de acuerdo con Interior, será explicado a las fuerzas y cuerpos de seguridad del Estado.

La tentación vive en la casa de al lado
Un ejemplo de fraude que los promotores del proyecto creen que podrán atajar es el del vecino defraudador. Se trata de un caso real que sucedió en Reino Unido y que fue neutralizado por un sistema de alerta temprana similar al que la banca española quiere introducir ahora en el país.

Un ciudadano que preparaba un cambio de vivienda cedió la llave a su vecino durante un tiempo y le pidió que le recogiera su correspondencia.

El vecino no resistió la tentación de abrir las cartas del banco y, al ver la existencia de fondos y cuentas, decidió hacer fortuna.Se hizo con claves que encontró en la vivienda y utilizó el servicio de banca telefónica de la entidad financiera. Siguió los pasos correctamente para desviar fondos a sus cuentas, pero cometió un error. No supo responder a una pregunta del banco sobre la fecha de nacimiento del cliente y colgó.

La equivocación bastó para que saltara una alerta en el sistema y que una investigación de la procedencia de la llamada, puesta posteriormente en conocimiento de la policía, sirvieran para descubrir todo el pastel.

El proyecto que impulsa el CCI no afecta al ya existente Registro de Aceptaciones Impagadas (RAI).

El RAI es el fichero utilizado por los bancos para ver si una empresa ha devuelto letras o pagarés; es propiedad del CCI y sólo se puede acceder caso a caso y tras consultar un informe.

Fuente: El Mundo
13.03.06

Noticias relacionadas:

Seguridad


Bloggers prestigiosos como Enrique Dans dedican comentarios a la Seguridad y ratifican el interés general en una disciplina que nos parece esencial a los que nos dedicamos a ella. También nos parece que no es suficientemente valorada.

Además me ha permitido descubrir el Blog de Fernando Aparicio, al que conozco desde hace años y con quien también he compartido cursos y seminarios en el Instituto de Empresa.

Veo que Fernando empezó su Blog más o menos al mismo tiempo que yo empecé el mío y que tenemos muchos puntos en común, de modo que espero hacer referencia a sus comentarios entre los que ya he visto algunos temas interesantes como la referencia a una Sentencia que llamó la atención hace unos días y que comenté en el Foro de las Evidencias Electrónicas.

Voto electrónico en Juntas de Accionistas


Después de referirme en el Post anterior a los prestadores de servicios de certificación y a Innovoto, he pensado que conviene comentar alguna cosa más sobre este tema, ya que recibo muchas consultas y percibo mucha desorientación.

Al organizar una Junta General, hay que prever el mecanismos para votar a distancia y delegar. Hay que pensar los medios con los que contarán los accionistas, y su procedencia (especialmente las empresas que cotizan en mercados internacionales).

El voto a distancia debe ser compatible con la celebración presencial de la Junta, lo que sigue siendo obligatorio (no se puede convocar una junta virtual: hay que indicar el lugar de la celebración).

Las reglas de limitación de voto, requisitos de quorum, número mínimo de votos en determinadas propuestas, implican considerar el voto a distancia como voto presente en la Junta.

Los votos recibidos pueden estar firmado con cualquier certificado, lo que implica ser capaces de verificar la validez de cualquier certificado, especialmente de los certificados "cualiicados" o "reconocidos".

Al coordinar con Iberclear y con las entidades depositarias es conveniente determinar el sistema de codificación de la tarjeta de asistencia, para permitir su empleo de forma electrónica.

En la convocatoria deben quedar claras las precedencias (voto-delegación, a distancia-presencial) así como los plazos de cada fase de gestión de la junta (convocatoria y definición inicial de puntos en el orden del día, petición por grupos de accionistas de introducción de puntos en el orden del día, publicación del orden del día definitivo, apertura de la urna virtual, cierre de la urna virtual, publicación de estadísticas de voto electrónico, consolidación del voto presencial y a distancia).

En caso de que se tenga constancia de que existen cadenas de representación fiduciaria (por ejemplo cuando las acciones se pueden contratar en diferentes paises, y los registros de Iberclear no reflejan al accionista final sino a alguno de los intermediarios), es conveniente disponer de sistemas que permitan asignar rangos de números de acciones del representante fiduciario, a favor de los representados fideicomitentes, de forma que estos puedan ejercer sus derechos de voto y delegación. El sistema también debe ser capaz de gestionar sistemas de gestión de representación para los accionistas que prefieran que sean especialistas los que en su nombre voten los puntos según sus intereses. 

Aunque el tema tiene cierta complejidad, a dia de hoy, la forma de organizar una junta que tenga en cuenta la participación a distancia de los accionistas está bastante clara. Por eso no se entienden esas convocatorias de juntas (copiadas unas de otras) que no saben ni identificar correctamente los tipos de certificados electrónicos que se pueden utilizar.

 Hay que reconocer que la conflictidad societaria (de los accionistas minoritarios) es muy baja en España, porque hay motivos de sobra para poder impugnar  algunas Juntas, según se aprecia de la redacción de las convocatoras.

 

 

 

 

Prestadores de Servicios de Certificación


Ahora que el DNI electrónico está volviendo a poner de moda la firma electrónica y la certificación digital, merece la pena hacer un pequeño censo de prestadores de servicios de certificación. Así, pasados unos años, podremos valorar si la aparición del DNI electrónico fue positiva o negativa para el sector.

Respecto a Europa, la fuente principal de información es el repositorio de prestadores de servicios de certificación, regulado por el artículo 11 de la Directiva 1999/93/CE de Firma Electrónica. Los paises que figuran a dia de hoy (los que han enviado información a la Comisión sobre el despliegue de la Directiva) son los siguientes:

  • Suercia
  • Finlandia
  • Bélgica
  • Reino Unido
  • Alemania
  • Austria
  • Dinamarca
  • Francia
  • Holanda
  • Italia
  • República Checa

De los paises mencionados, Italia es el que destaca por el número de PSC acreditados.

En España, la fuente principal es el Censo de Prestadores de la Secretaria de Estado de Telecomunicaciones y para la Sociedad de la Información del Ministerio de Industria, Comercio y Turismo. Este organismo mantiene la responsabilidad de supervisión del sector de la Certificación definida en la Ley 59/2003 de Firma Electrónica. En estos momentos, los PSC (Prestadores de Servicios de Certificación) que han presentado la documentación (y su revisión está finalizada o en curso) son los siguientes:

  • ANF-AC
  • CERES
  • CAMERFIRMA
  • FIRMAPROFESIONAL
  • ACCV
  • AC ABOGACÍA
  • CICCP
  • ANCERT- Agencia Notarial de Certificación
  • BANESTO
  • IZENPE
  • CATCERT
  • IPSCA
  • TELEFONICA DATA ESPAÑA S.A.
  • SERVICIO DE CERTIFICACIÓN DE LOS REGISTRADORES (SCR)

De estos prestadores, muy pocos están presentes en los principales navegadores.

Hay un completo análisis de prestadores de servicios de certificación que se incluyen en los navegadores en el sitio web de Innovoto.

Desde el punto de vista de Innovoto, es decir, del voto electrónico a distancia en Juntas Generales de Accionistas y otros órganos participativos, lo que importa es utilizar certificados reconocidos o cualificados, cuando el accionista sea español o esté en España, de forma que se dé cumplimiento a la Ley 59/2003, pero permitir de forma expresa que puedan utilizar certificados de otros prestadores que, aun no cumpliendo de forma expresa la Directiva 93/1999, permitan suponer una diligente actuación en la prestación de los servicios.

Además de todos estos listados de PSC, merece la pena referirse a dos más.

Como podeis ver, desde el punto de vista del titular, no es nada sencillo detectar qué PSC emiten los certificados más adecuados para una aplicación dada, pero podemos conjeturar que «cualquiera».

Desde el punto de vista del tercero que confía en el certificado, la entidad que desarrolla aplicaciones en las que se pueda usar la firma electrónica el dilema es más sencillo de resolver: hay que aceptar «todos». 

Actualización (18.10.2009)

He actualizado los enlaces porque los originales se han vuelto obsoletos:

Especificación AEAT para consulta de certificados revocados (YCAESTEC)


En el marco de la normativa de la AEAT sobre aceptación de certificados electrónicos, la agencia ha definido un protocolo muy sencillo (denominado ycaestec por ser el nombre de la página html en la que se describe).

La Y no se de donde sale, aunque es la misma letra con la que comienza YCAREQUI, la descripción de requisitos de los certificados que acepta la AEAT (CAREQUI puede significar Requisitos para las CA), de modo que YCAESTEC puede significar Especificaciones Técnicas de las CA.

Especificaciones técnicas del servicio Web de actualización de certificados revocados

El servicio deberá estar basado en el protocolo SOAP 1.0. La A.E.A.T. accederá a este servicio como cliente solicitando los certificados revocados a partir de una fecha y hora. La autoridad de certificación devolverá una lista con los certificados revocados o el código que indique que no se han producido revocaciones desde la fecha y hora solicitada.

Descripción del servicio.

Nombre

El nombre del servicio será serPubCR (Servicio Público de Certificados Revocados).

Tipos

Se define un nuevo tipo, ArrayOfArrayOf_xsd_string, fuera de los definidos en la especificación de XML Schema, que SOAP adopta. Este tipo será un array de cadenas de dos dimensiones (xsd:Array[][]) la primera dimensión contendrá la fecha de revocación (Formato ISO-8601 con las restricciones de W3C descritas en http://www.w3.org/TR/NOTE-datetime y la granularidad 6 (fecha completa con horas, minutos, segundos y décimas de segundo, e.g 2003-05-15T23:11:32.45) y la segunda contendrá el número de serie del certificado revocado (Este número de serie se expresará en notación hexadecimal, no debiendo superar los 32 caracteres hexadecimales). El array deberá contener al final del mismo la cadena «FINAL» en las dos dimensiones.

Este tipo se utiliza en el mensaje de respuesta de la operación desdeFecha del servicio.

Mensajes

Estructura del mensaje de petición:

  • Nombre, desdeFechaRequest: Obtención de los certificados revocados a partir de una fecha, con dos parámetros:
    • In0 (xsd:string) : Autoridad de certificación a la que se envía el mensaje.
    • In1 (xsd:dateTime) : Fecha y hora a partir de la cual se desean los certificados revocados. Formato ISO-8601 con las restricciones de W3C descritas en http://www.w3.org/TR/NOTE-datetime y la granularidad 6 (fecha completa con horas, minutos, segundos y décimas de segundo, e.g 2003-05-15T23:11:32.45)

Estructura del mensaje de respuesta

  • Nombre, desdeFechaResponse: Consta de dos campos, uno con el nombre de la AC que emite la respuesta y otro con la lista de certificados revocados según el tipo ArrayOfArrayOf_xsd_string definido anteriormente.
    • Out0 (xsd:String) : Autoridad de certificación que devuelve la respuesta.
    • Out1 (ArrayOfArrayOf_xsd_string) : Lista de los certificados revocados desde la fecha y hora indicada en el mensaje de petición.

Operaciones

Este servicio se compone de una única operación.

  • Nombre desdeFecha: que se compone de los dos mensajes siguientes:
    • Mensaje de petición: desdeFechaRequest
    • Mensaje de respuesta: desdeFechaResponse

Enlaces

Todas las operaciones utilizarán el formato RPC de SOAP. El cuerpo (body) de la petición SOAP deberá incluir un elemento que indique el tipo de función (operación) a ejecutar y otros elementos para los parámetros de la función. Las respuestas a su vez deberán tener un elemento que emule la función de petición e incluya los valores de retorno. A su vez el mensaje SOAP se encapsulará en un mensaje HTTPS

Todas las operaciones tendrán como espacio de nombres ‘urn:dit:soapservices:serPubCR’ y utilizará la codificación SOAP http://schemas.xmlsoap.org/soap/encoding para llamadas remotas a procedimientos (RPC).

Ejemplos de mensajes SOAP

Mensaje de petición

<?xml version="1.0" encoding="IS0-8859-1"?>
<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
	<ns1:desdeFecha xmlns:ns1="urn:dit:soapservices:serPubCR"
		xmlns:ns2="http://schemas.xmlsoap.org/soap/encoding/"
		SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
		<in0 xsi:type="xsd:string">CAGVA</in0>
		<in1 xsi:type="xsd:date">2003-05-15T23:00:03.23</in1>
	</ns1:desdeFecha>
</SOAP-ENV:Body>
</SOAP-env:Envelope>

Mensaje de respuesta

(Respuesta correcta)

<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
	<ns1:desdeFechaResponse xmlns:ns1="urn:dit:soapservices:serPubCR"
		SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
	<return>
	<out0 xsi:type="soapenc:String>CAGVA</out0>
	<out1 xsi:type="soapenc:Array"
		soapenc:arrayType="xsd:string[][193]"
		xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
		<item soapenc:arrayType="xsd:string[2]">
			<item>
			2003-06-16T09:29:27.00
			</item>
			<item>
			25B20688E
			</item>
		</item>
		<item soapenc:arrayType="xsd:string[2]">
			<item>
			2003-06-23T09:29:27.00
			</item>
			<item>
			25B206890
			</item>
		</item>
               .
               .
               .
		<item soapenc:arrayType="xsd:string[2]">
			<item>
			FINAL
			</item>
			<item>
			FINAL
			</item>
		</item>
	</out1>
	</return>
	</ns1:desdeFechaResponse>
</SOAP-ENV:Body>
</SOAP-env:Envelope>

(Respuesta errónea)

<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
	<SOAP-ENV:Fault>
		<faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
		<faultstring xsi:type="xsd:string>
			Error en el formato de la fecha. Formato válido 
			ISO-8601
		</faultstring>
	</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

NOTAS

1.- Documento WSDL de descripción del servicio SOAP.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNameSpace="urn:dit:soapservices:serPubCR"
	xmlns:impl="urn:dit:soapservices:serPubCR"
	xmlns:soapenc="http://schemas.xmlsoap.org/soap/soapencoding/"
	xmlns:wsdlsoap="http://schemas.xmlsoap.org/wdslsoap/"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns="http://schemas.xmlsoap.org/wsdl/">

<wsdl:types>
	<schema xmlns="http://www.w3.org/2001/XMLSchema/"
		targetNameSpace="urn:dit:soapservices:serPubCR">
		<import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
		<complexType name="ArrayOfArrayOf_xsd_string">
			<complexContent>
				<restriction base="soapenc:Array">
					<attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[][]" />
				</restriction>
			</complexContent>
		</complexType>
	</schema>
</wsdl:types>

<wsdl:message name="desdeFechaRequest" >
	<wsdl:part name="in0" type="xsd:string" />
	<wsdl:part name="in1" type="xsd:dateTime" />
</wsdl:message>
<wsdl:message name="desdeFechaResponse">
	<wsdl:part name="out0" type="xsd:string" />
	<wsdl:part name="out1" type="impl:ArrayOfArrayOf_xsd_string" />
</wsdl:message>

<wsdl:portType name="desdeFecha_servPubCR">
	<operation name="desdeFecha">
		<input name="desdeFechaRequest" message="impl:desdeFechaRequest" />
		<output name="desdeFechaResponse" message="impl:desdeFechaResponse" />
	</operation>
</wsdl:portType>

<wsdl:binding name="serPubCR_Bind" type="impl:desdeFecha_servPubCR">
	<wdslsoap:binding stype="rpc"  transport="http://schemas.xmlsoap.org/soap/https" />
	<wsdl:operation name="desdeFecha" soapAction="">
		<wsdl:input name="desdeFechaRequest">
			<wsdlsoap:body use="encoded" 
				encodingStyle="http://schemas.xlsoap.org/soap/encoding/"
				namespace="urn:dit:soapservices:serPubCR" />
		</wsdl:input>
		<wsdl:output name="desdeFechaResponse">
			<wsdlsoap:body use="encoded" 
				encodingStyle="http://schemas.xlsoap.org/soap/encoding/"
				namespace="urn:dit:soapservices:serPubCR" />
		</wsdl:output>
	</wsdl:operation>
</wsdl:binding>

<wsdl:service name="serPubCR">
	<wsdl:port name="desdeFecha_servPubCR"
		binding="impl:serPubCR_Bind">
		<wsdlsoap:address
			localtion="http://..../.../.../serPubCR" />
	</wsdl:port>
</wsdl:service>

</wsdl:definitions>

2.- Cabecera SOAPAction

No deberá ser obligatoria y si se utiliza, podrá ir a blanco.

Lectores de tarjeta chip para el DNI electrónico


Cuando uno ya tiene su flamante DNI electrónico, llega el momento de utilizarlo.

¿Qué hay que hacer ahora? Las 3 reglas.

Regla número 1: memorizar el PIN y guardar el papelito en casa en la caja fuerte (o en el calcetín).

Regla número 2: preparar un ordenador con la infraestructura adecuada. Para ello necesitamos un lector de tarjeta chip.

Además de enchufar el dispositivo, necesitamos instalar su software, y también el software del DNI.

Regla número 3: Obtener un software de firma electrónica. Camerfirma ofrece uno gratuito. Una versión menos reciente de su software está disponible aquí. (en esta versión por un bug en la instalacion es necesario ejecutar:
inicio –> ejecutar –> regsvr32 «C:\Archivos de programa\camerfirma\desktopfirma\capicom.dll»)

La «Regla número 3» es un amplio mundo de posibillidades de firma electrónica. Se puede firmar con Adobe Acrobat, con las versiones más modernas de Office, y con muchas aplicaciones web de las administraciones públicas.

Lo que sí es cierto es que conviene perder el miedo a firmar electrónicamente.