Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Unidad de E-Business Apartado Postal Electrónico Protocolos de Integración de Modalidad 3 de Organismos Emisores con el APE-SNTS Propuesta de Nombre del Proyecto Apartado Postal Electrónico Nombre del Documento Versión Protocolos de Integración de Modalidad 3 del servicio APE- 1.2 SNTS Número de páginas 51 Descripción Este documento describe el protocolo de integración de la modalidad 3 de Organismos Emisores con el nuevo Servicio de Notificaciones Telemáticas Seguras ofrecido sobre el sistema Apartado Postal Electrónico de Correos. Elaborado por Unidad de E-Business Confidencial Página 1 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Control de Versiones Autor: Unidad de e-Business Revisado por: Aprobado por: Fecha: 9/3/2010 Fecha: Fecha: Resumen: Este documento describe los procesos y los protocolos de integración entre los sistemas de la AEAT y el servicio APE-SNTS de Correos. Lista de distribución: Por Correos Por [otras empresas] Histórico de versiones Versión y Fecha Motivo versión [0.1]; [dd/mm/yyyy] Versión inicial. 1.1; 9/3/2010 Versión en la que se definen los protocolos de modalidad 3: - Envío de notificaciones - Acceso a notificaciones - Envío de puestas a disposición - Envío de acuses de recibo Queda pendiente definir el protocolo de actualización del censo para usuarios voluntarios. 1.2; 23/3/2010 Actualización del “XML Schema” y WSDL para compatibilizar los requerimientos de la AEAT con la solución global. Inclusión de un nuevo WSDL para el envío de información desde el APE-SNTS a la entidad emisora. En el envío de notificaciones/comunicaciones se manejarán 3 tipos de roles: 1. Destinatario Buzón donde se almacenará el mensaje. 2. Titular Titular de la notificación/comunicación que podrá o no podrá coincidir con el Destinatario. 3. Autorizados Persona física o jurídica con “Autorización” para gestionar las comunicaciones/notificaciones de un “Titular”. Confidencial Página 2 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Índice de Contenidos 1. INTRODUCCIÓN ............................................................................................................ 7 2. CONSIDERACIONES GENERALES ............................................................................. 7 2.1 Alcance................................................................................................................. 7 2.2 Resumen de protocolos de modalidad 3 ............................................................. 7 2.3 Protocolos y Tecnologías ..................................................................................... 9 2.3.1 Servicio W eb ............................................................................................. 10 2.3.2 Editran ....................................................................................................... 11 3. PROTOCOLOS DE MODALIDAD 3 ............................................................................ 13 3.1 Escenario ........................................................................................................... 13 3.1.1 3.2 Obligados .................................................................................................. 13 Activación del Buzón de la DEH ........................................................................ 13 3.2.1 Voluntarios ................................................................................................. 13 3.2.2 Obligados .................................................................................................. 13 3.3 Actualización de Censo en modo ACTIVO. ....................................................... 14 3.3.1 Voluntarios ................................................................................................. 14 3.3.2 Obligados .................................................................................................. 14 3.4 Actualización de Censo en modo PASIVO para subscripciones Voluntarias.... 15 3.4.1 Descripción General del Protocolo ............................................................ 15 3.4.2 Implementación sobre servicios W eb ....................................................... 18 3.5 Envío de Notificaciones...................................................................................... 20 3.5.1 Voluntarios ................................................................................................. 20 3.5.2 Obligados .................................................................................................. 20 3.5.3 Protocolo ................................................................................................... 20 3.6 Acceso a las Notificaciones ............................................................................... 27 3.6.1 Notificación o Comunicación no notificada ............................................... 27 3.6.2 Notificación o Comunicación ya notificada ................................................ 27 3.6.3 Descripción general del protocolo ............................................................. 27 3.6.4 Implementación sobre servicios W eb ....................................................... 30 Confidencial Página 3 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.7 Recuperación de Eventos de Puesta a Disposición / Recogida / Caducidad en modo ACTIVO. ...................................................................................................................... 32 3.8 Recuperación de Eventos de Puesta a Disposición / Recogida / Caducidad en modo PASIVO. ...................................................................................................................... 33 3.8.1 Descripción General del Protocolo ............................................................ 33 3.8.2 Implementación sobre servicios W eb ....................................................... 38 4. ANEXO ......................................................................................................................... 40 4.1 Modalidades de envío ........................................................................................ 40 4.2 Esquemas XML .................................................................................................. 41 4.2.1 Esquema APE-SNTS ................................................................................ 41 4.3 Descriptor de interfaz W SDL de servicio APE ................................................... 41 4.4 Ejemplos XML .................................................................................................... 41 4.4.1 Ejemplo de Remesa de Resúmenes de Notificación / Comunicación ...... 41 4.4.2 Ejemplo de ADMISIÓN Remesa de Resúmenes de Notificación / Comunicación 42 4.4.3 Ejemplo SOAP sobre HTTPS de Remesa de Resúmenes de Notificación / Comunicación .......................................................................................................... 43 4.4.4 Ejemplo SOAP sobre HTTPS de Remesa de Información de Admisión .. 43 4.4.5 Ejemplo de Petición de Recuperación de Notificación / Comunicación.... 43 4.4.6 Ejemplo de Respuesta a Petición de Recuperación de Notificación / Comunicación 44 4.4.7 Ejemplo SOAP sobre HTTPS de Petición de Recuperación de Notificación / Comunicación .......................................................................................................... 44 4.4.8 Ejemplo SOAP sobre HTTPS de Respuesta a Petición de Recuperación de Notificacion / Comunicacion ........................................................................................................ 44 4.4.9 Ejemplo de remesa de certificaciones con una Certificación de Acuse de Recibo 44 4.4.10 Ejemplo de Respuesta a REMESA de CertificaciónES ............................ 47 4.4.11 Ejemplo SOAP sobre HTTPS de una Petición de Certificación de Acuse de Recibo 48 4.4.12 Ejemplo SOAP sobre HTTPS de una Respuesta a una Petición de Certificación de Acuse de Recibo ...................................................................................................... 48 4.4.13 Ejemplo de envío de remesa de actualización de censo. ......................... 48 4.4.14 Ejemplo de RESPUESTA A remesa de actualización de censo. ............. 49 4.4.15 Ejemplo SOAP SOBRE HTTPS de envío de remesa de actualización de censo. 4.4.16 Ejemplo SOAP SOBRE HTTPS RESPUESTA A remesa de actualización de censo 50 49 Estándares Referenciados .......................................................................................... 51 Confidencial Página 4 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Listado de Tablas Tabla 2. Tabla de prefijos y espacios de nombres de esquemas XML utilizados por los protocolos. ............................................................................................10 Tabla 3. Estructura de datos de Envío de Remesa de Actualización de Censo (ERAC). 16 Tabla 4. Correspondencia de campos entre estructura ERAC y RERAC. ........17 Tabla 5. Lista de posibles códigos de error de validación de firma en estructura RERAC. 18 Tabla 6. Lista de posibles códigos de error de petición en estructura RERAC. 18 Tabla 7. Estructura de datos de Remesa de Resúmenes de Notificación / Comunicación (RRN)....................................................................................................23 Tabla 8. Estructura de datos de Remesa de Información de Admisión de Resumen de Notificación / Comunicación (RIA). ........................................................24 Tabla 10. Lista de posibles códigos de error de campo Código de Remesa en estructura RIA. 25 Tabla 12. Estructura de datos de Petición de Recuperación de Notificación / Comunicación (PTN). ...................................................................................................29 Tabla 13. Respuesta Contenedor(es) de Notificación(es) / Comunicación(es) (RCN). 29 Tabla 14. Lista de posibles códigos de error de validación de firma en estructura RCN. 29 Tabla 15. Lista de posibles códigos de error de petición en estructura RCN. ...30 Tabla 16. Estructura de datos de Envío de Remesa de Certificaciones (ERC).36 Tabla 17. Correspondencia de campos entre estructura ERC y RERC. ...........37 Tabla 19. Lista de posibles códigos de error de petición en estructura RCN. ...37 Tabla 20. Estructura de datos de Envío de Remesa de Actualización de Censo (ERAC). Error! Bookmark not defined. Tabla 21. Correspondencia de campos entre estructura ERAC y RERAC.Error! Bookmark not defined. Tabla 22. Lista de posibles códigos de error de validación de firma en estructura RERAC. Error! Bookmark not defined. Confidencial Página 5 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Tabla 23. Lista de posibles códigos de error de petición en estructura RERAC.Error! Bookmark not defined. Tabla 24. Tabla resumen de las modalidades de envío de Notificaciones / Comunicaciones. 40 Tabla 25. Tabla resumen de los estándares referenciados. .............................51 1. Confidencial Página 6 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 INTRODUCCIÓN Desde el mes de Abril de 2010 el Servicio de Notificaciones Telemática Seguras será ofrecido por el módulo de Notificaciones Telemáticas del servicio Apartado Postal Electrónico de Correos. Como parte de este cambio, el servicio APE va a habilitar 3 modalidades de envío de Notificaciones / Comunicaciones desde los Organismos Emisores. El objetivo de esta documento es definir los protocolos de integración de la modalidad 3 entre el servicio APE-SNTS y los Organismos Emisores y que abarque tanto a usuarios voluntarios como obligados. 2. CONSIDERACIONES GENERALES 2.1 Alcance En el apartado 4.1 se resumen las modalidades de envío consideradas por el servicio Apartado Postal Electrónico en el ámbito de las Notificaciones y Comunicaciones Telemáticas Seguras. Este documento describe el conjunto de protocolos, estándares, etc. para implementar vía servicios Web y Editran la modalidad 3. 2.2 Resumen de protocolos de modalidad 3 En la Tabla 20 del anexo 4.1 se presenta el cuadro resumen del conjunto de modalidades de envío que soportará el nuevo servicio APE-SNTS. En el caso de la modalidad 3 se identifican los siguientes protocolos (en apartados posteriores se podrá encontrar una especificación más detallada de cada uno de ellos): - Protocolo de Actualización del Censo: o - Sólo aplica a usuarios voluntarios y existe en dos modalidades: Activa: Donde el Organismo Emisor requiere periódicamente al servicio APESNTS el envío de las actualizaciones pendientes desde un momento concreto. Pasiva: Donde es el propio servicio del APE-SNTS el que, periódicamente envía de forma automática al Organismo Emisor las últimas actualizaciones. (PROTOCOLO PENDIENTE DE DEFINICIÓN) Protocolo de Envío de Notificaciones / Comunicaciones: o El Organismo Emisor envía al servicio APE-SNTS un resumen de los datos identificativos de cada Notificación / Comunicación sin incluir su contenido (ej.: contenido PDF). Entre los datos se incluye la huella digital del contenido sin cifrar de la Notificación / Comunicación. o El servicio APE-SNTS procesará los resúmenes de Notificación / Comunicación y, en función del protocolo de integración utilizado, procederá de una forma u otra: En el caso de servicios Web, el servicio APE-SNTS retorna síncronamente la Información de Admisión de cada resumen de Notificación / Comunicación enviada. Confidencial Si los datos resumen pertenecen a una Notificación, la Información de Admisión es firmada por Correos. Página 7 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Si los datos resumen pertenecen a una Comunicación, la Información de Admisión se envía sin firmar En el caso de Editran, el servicio APE-SNTS retorna asíncronamente las correspondientes Certificaciones de Puesta a Disposición. Si los datos resumen pertenecen a una Notificación, cada Certificación de Puesta a Disposición es firmada por Correos. Si los datos resumen pertenecen a una Comunicación, Certificación de Puesta a Disposición se envía sin firmar cada En el apartado 3.5 se puede ver la descripción detallada de este protocolo. - Protocolo de Acceso a Notificación / Comunicación (sólo implementado sobre servicios Web): o El receptor accede al resumen de la Notificación / Comunicación. Si se accede a una Notificación se solicita al receptor una firma. Si se accede a una Comunicación no se solicita la firma. o En ese momento, el servicio APE-SNTS solicita el contenido de la Notificación / Comunicación al Organismo Emisor enviándole un Token de Petición firmado junto con el certificado electrónico utilizado por el receptor. o Bajo recepción del Token de Petición, el Organismo Emisor recupera el contenido de la Notificación / Comunicación y lo retorna como respuesta. o El servicio APE-SNTS recibe el contenido de la Notificación / Comunicación, calcula su huella y la compara con la original enviada en los datos resumen del Protocolo de Envío de Notificaciones / Comunicaciones. El servicio APE-SNTS no deja registro permanente alguno del contenido de la Notificación / Comunicación en su sistema. o El servicio APE-SNTS descarga el contenido recuperado de la Notificación / Comunicación al programa (Applet o Control ActiveX) instalado en el ordenador del receptor para que la pueda visualizar. En el apartado 3.6 se puede ver la descripción detallada de este protocolo. - Protocolo de Intercambio de Acuses de Puesta a Disposición: o Disponible en dos modalidades: Activa: El Organismo Emisor solicita al Servicio APE-SNTS las Certificaciones de Puesta a Disposición de un conjunto de Notificaciones / Comunicadas remitidas con anterioridad. En el caso de servicios Web sólo podrá solicitar una Certificación de Puesta a Disposición por cada interacción. En el caso de Editran podrá solicitar varias. El Servicio APE-SNTS recupera las Certificaciones de Puesta Disposición solicitadas y se las envía al Organismo Emisor. Pasiva: Confidencial a El Servicio APE-SNTS, periódicamente, recupera las Certificaciones de Puesta a Disposición disponibles desde la última actualización y se las envía al Organismo Emisor. Página 8 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 La Certificación de Puesta a Disposición es firmada por el servicio APE-SNTS en el caso de que se trate de una Notificación. En el caso de una certificación de una Comunicación no. En el apartado 3.7 se puede ver la descripción detallada de este protocolo. - Protocolo de Intercambio de Acuses de Recibo: o Disponible en dos modalidades: Activa: El Organismo Emisor solicita al Servicio APE-SNTS las Certificaciones de Acuse de Recibo de un conjunto de Notificaciones / Comunicaciones que remitió con anterioridad. En el caso de servicios Web sólo podrá solicitar una Certificación de Acuse de Recibo por cada interacción. En el caso de Editran podrá solicitar varias. El Servicio APE-SNTS recupera las Certificaciones de Acuse de Recibo solicitadas y se las envía al Organismo Emisor. Pasiva: El Servicio APE-SNTS, periódicamente, recupera las Certificaciones de Acuse de Recibo disponibles desde la última actualización y se las envía al Organismo Emisor. En el caso de que el Receptor acepte o rechace la Notificación, la Certificación de Acuse de Recibo es firmada por el servicio APE-SNTS. En el caso de que la Notificación fuera rechazada por caducidad, sólo es firmada por el servicio APE-SNTS. En el caso de una certificación de una Comunicación no se firma ningún evento. En el apartado Error! Reference source not found. se puede ver la descripción detallada de este protocolo. 2.3 Protocolos y Tecnologías Los protocolos descritos para cada una de las modalidades incluidas en el presente documento tendrán una implementación basada en servicios Web o Editran. Cada modalidad define cómo implementar sobre estas tecnologías las interacciones necesarias para llevar a cabo los siguientes procesos: Se puede implementar sobre … Proceso Servicios Web Editran Actualización del Censo Usuarios (sólo aplica a Usuarios Voluntarios) X X Envío de Resúmenes de Notificación / Comunicación X X Recuperación de la Notificación / Comunicación desde el Organismo Emisor X No aplica Envío de Puestas a Disposición X X Envío de Acuses de Recibo o Rechazo X X Confidencial Página 9 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Tabla 1. Resumen de las tecnologías sobre las que se implementará los protocolos de la modalidad 3. Como parte de la configuración de la integración de un determinado Organismo Emisor, éste podrá seleccionar una tecnología, servicios Web o Editran, por cada uno de los procesos anteriores. 2.3.1 SERVICIO WEB Los protocolos descritos para cada una de las modalidades incluidas en el presente documento tendrán una implementación basada en servicios Web1. Los mensajes y protocolos aquí descritos se codifican en XML1.0 [XML], se utilizan espacios de nombre [XMLNS] y se utiliza el marco de trabajo de mensajería de servicios Web SOAP 1.1 [SOAP] y la descripción de la interfaz de los servicios Web se basará en WSDL1.1 [WSDL]. Para garantizar la confidencialidad, integridad, autenticidad y no repudio de los mensajes intercambiados en los protocolos se utilizará el estándar XML Digital Signature [XMLDSIG] a nivel de mensaje y SSLv3\TLSv1 [SSL/TLS] con autenticación de cliente a nivel de transporte. El protocolo subyacente de transporte para la implementación de los servicios Web será SOAP sobre HTTPS o XML sobre Editran. La convención de prefijos de los espacios de nombre utilizados a lo largo del presente documento se resume en la siguiente tabla: Prefijo Espacio de nombres XML Especificación ds: http://www.w3.org/2000/09/xmldsig# W3C Recommendation, "XML-Signature Syntax and Processing", 10 June 2008. xs: http://www.w3.org/2001/XMLSchema W3C Recommendation, "XML Schema Part 1: Structures Second Edition", 28 October 2004. soap-env: http://schemas.xmlsoap.org/soap/envelope/ etsi: http://uri.etsi.org/01903/v1.3.2# W3C Recommendation, "Simple Object Access Protocol (SOAP) 1.1 ", 8 May 2000. XADES ETSI TS 101 903 v1.3.2 Tabla 2. Tabla de prefijos y espacios de nombres de esquemas XML utilizados por los p rotocolos. Las estructuras de datos, mensajes y protocolos que se describen a continuación tiene asociado el siguiente espacio de nombres XML: urn:correos:ape:1.0 A menos que se indique de otra forma en esta especificación, todos los valores de referencia URI utilizados en elementos o atributos definidos en el espacio de nombres urn:correos:ape:1.0 consistirán de al menos un carácter, que no sea espacio en blanco, y se requiere que sean absolutas (ver RFC 2396). 1 La versión de los estándares utilizados se ajusta a lo especificado en el Perfil Básico de Servicios 1.1 Web del WS-I. Ver: http://wsi.org/profiles/BasicProfile-1.1.html. Confidencial Página 10 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Todos los valores de fecha y hora de esta especificación siguen el tipo xs:dateTime, definido en el estándar W3C XML Schema Datatypes y debe estar expresado en formato UTC sin componente de zona horaria. 2.3.1.1 Consideraciones de Seguridad - Seguridad a nivel de transporte: o - Comunicación entre el Organismo Emisor y el Servicio APE: SSLv3/TSLv1 sobre HTTP con autenticación de cliente. Seguridad a nivel de mensajes: o Firmas XMLDSig: Todas las firmas, salvo las incluidas en las Certificaciones de Puesta a Disposición y Acuse de Recibo, seguirán el estándar XML Digital Signature [XMLDSIG] y tendrán las siguientes características: Tipo de firma: enveloped. Debe contener un único elemento ds:Reference con las siguientes características: URI en blanco. Debe incluir un elemento ds:CanonicalizationMethod con el siguiente algoritmo: http://www.w3.org/2001/10/xml-exc-c14n# Debe especificar como método de firma ds:SignatureMethod: http://www.w3.org/2000/09/xmldsig#rsa-sha1 Debe declarar las la siguiente transformacion: http://www.w3.org/2000/09/xmldsig#enveloped-signature - No se debe incluir un elemento ds:KeyInfo. Firmas Xades-BES: las certificaciones emitidas por el servicio APE-SNTS de puesta a disposición y acuse de recibo se firmarán según el protocolo de firma XADES-BES [XADESBES]. Este tipo de firma contiene los elementos mínimos y necesarios para que la firma se considere firma electrónica avanzada de acuerdo con la Ley 59/2003, de 19 de diciembre, de firma electrónica. Si además, y como ocurre en el ámbito del servicio APE-SNTS, este tipo de firmas se generan utilizando un certificado digital reconocido y un dispositivo seguro de creación de firma, permite que se eleven a la categoría de firma electrónica reconocida y por tanto se equiparan a la firma manuscrita, tal y como establece la mencionada ley. Estas firmas sólo serán generadas por el servicio APE-SNTS, por tanto se omite la especificación sobre su método de creación. Se pueden ver ejemplos de certificaciones de puesta a disposición y acuse de recibo en los anexos Error! Reference source not found., Error! Reference source not found., Error! Reference source not found. y Error! Reference source not found.. Confidencial Página 11 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 2.3.2 EDITRAN En el caso de intercambios de información masiva se recomienda el uso de ficheros Editran. Los ficheros de Editran contendrán las estructuras XML que soportan cada uno de los protocolos definidos a lo largo de este documento. Todas los Organismos Emisores que deseen utilizar Editran deberán dar de alta en su Editran la sesión adecuada para soportar la aplicación correspondiente, en base a los datos sobre la configuración Editran del servicio APE-SNTS se proporcionará al Organismo Emisor. El servicio APE-SNTS habilitará, por su parte, la sesión correspondiente en base a la información aportada por el Organismo Emisor. Estos datos de configuración se recogerán en un formulario a completar e intercambiar por ambas partes. Confidencial Página 12 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3. PROTOCOLOS DE MODALIDAD 3 A esta modalidad, pertenecen todas aquellas Notificaciones / Comunicaciones telemáticas cuya recogida se realice bajo firma del servicio APE-SNTS y del interesado (sólo para el caso de Notificaciones). La entrega física de la Notificación / Comunicación al servicio APE-SNTS por el sistema del Organismo Emisor se realizará en el momento en el que el interesado desee acceder a su contenido, siendo únicamente posible la visualización por éste último. 3.1 Escenario Esta modalidad de notificación soporta las peculiaridades de Notificación / Comunicación telemática por solicitud voluntaria y también cuando la persona física o jurídica esté obligada a recibirlas por esta vía. 3.1.1 OBLIGADOS Se debe indicar al receptor obligado que para garantizar el correcto funcionamiento del sistema deberá tener instalado en su PC un software del servicio APE-SNTS que la va a permitir la generación de firmas electrónicas y descarga de las certificaciones. En todos los casos, este servicio de notificaciones cumple los requisitos de prestación del servicio recogidos en la Orden Ministerial de Presidencia PRE/1551/2003, de 10 de Junio y los apartados segundo y tercero del artículo 28 de la ley 11/2007, de 22 de Junio, de acceso electrónico de los ciudadanos a los Servicios Públicos. 3.2 Activación del Buzón de la DEH 3.2.1 VOLUNTARIOS Mediante la firma electrónica de un formulario con los datos del titular y las condiciones de uso del sistema. Además de la creación del buzón, deberá suscribirse a los diferentes procedimientos de los Organismos Emisores adheridos al sistema. Podrá darse de baja y modificar las condiciones de uso mediante transacciones habilitadas para ello. 3.2.2 OBLIGADOS El censo de usuarios obligados estará gestionado únicamente por el Organismo Emisor Cuando el Organismo Emisor envíe una notificación / comunicación a un destinatario obligado marcará ese envío como emitido a un usuario obligado. El servicio APE-SNTS creará el buzón, si no existiera ya, y almacenará en él la notificación / comunicación. Ese usuario quedará marcado como obligado para todos los procedimientos del Organismo Emisor que envió la notificación / comunicación. El usuario, la primera vez que acceda, firmará electrónicamente un formulario en el que completará los datos del titular y aceptará las condiciones de uso del sistema. Si tuviera notificaciones / comunicaciones sin leer, el servicio APE-SNTS le mostrará un aviso. Confidencial Página 13 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.3 Actualización de Censo en modo ACTIVO. 3.3.1 VOLUNTARIOS Con la periodicidad que decida el Organismo Emisor, podrá solicitar la actualización de altas y bajas en procedimientos de una DEH. 3.3.1.1 Protocolos 3.3.1.1.1 Web services síncronos Envío bajo demanda de tres posibles tipos de solicitudes: Censo Completo. Actualización desde el último evento recibido. Individual por DEH. Respuesta con las DEH, y tipo de movimiento (alta/baja), que aplican a la solicitud realizada. PENDIENTE DE DEFINIR 3.3.2 OBLIGADOS No aplica. Confidencial Página 14 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.4 Actualización de Censo en modo PASIVO para subscripciones Voluntarias. 3.4.1 DESCRIPCIÓN GENERAL DEL PROTOCOLO El objetivo de este protocolo es que el Organismo Emisor reciba periódicamente y de forma automática desde el servicio APE-SNTS las actualizaciones del censo que se vayan generando en este último. Dicho envío será en remesas de N eventos con un tiempo de espera entre envíos a fin de no saturar el sistema. En caso de que transcurrido cierto lapso de tiempo no se hayan generado el número máximo de eventos, se enviarán las actualizaciones que existan disponibles hasta ese momento. En caso de que el servicio del Organismo Emisor encargado de procesar las peticiones procedentes del APE-SNTS no esté disponible el tiempo entre reintentos se irá incrementando. Se define: - Remesa de Actualización de Censo: petición emitida por el servicio APE-SNTS hacia el Organismo Emisor con las últimas Actualizaciones de Censo disponibles desde el último envío. - Actualización de Censo: Información sobre el estado de subscripción de un determinado usuario a un determinado procedimiento para un Organismo Emisor. - Respuesta a Remesa de Actualización de Censo: respuesta emitida por un Organismo Emisor al servicio APE-SNTS como respuesta a una Petición de Remesa de Actualización de Censo y que contendrá tantas “Respuesta a Actualización de Censo” como “Actualizaciones de Censo” se han incluido en la petición. - Respuesta a Actualización de Censo: respuesta emitida por un Organismo Emisor al servicio APE-SNTS como respuesta a una Petición de Actualización de Censo. Este protocolo se ejecutará sobre dos intercambios de información: - Envío de una ‘Petición de Remesa de Actualización de Censo’ desde el servicio APE-SNTS al Organismo Emisor. - Envío de una ‘Respuesta de Remesa de Actualización de Censo’ desde el Organismo Emisor al servicio APE-SNTS con el resultado de la recepción. En el caso de servicios Web, se ejecutarán ambos intercambios de información sobre una interacción petición / respuesta síncrona. En el caso de Editran se ejecutarán de manera asíncrona en modo batch. 3.4.1.1 Estructura Lógica de los Datos Envío de Remesa de Actualización de Censo (ERAC) ID CAMPO ERAC 0 Confidencial Campo Envío de Remesa de Actualización de Censo Obligatorio Descripción SI Engloba un envío de una remesa de Actualizaciones de Página 15 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Censo. ERAC 1 Identificador de referencia. SI Identificador asociado a la petición que deberá ser devuelto en la respuesta asociada. ERAC 2 Actualización de Censo SI Se enviarán actualizaciones disponibles. ERAC 2.0 Identificador Único de la Actualización de Censo SI Identificador único de Actualización de Censo para dicho Organismo Emisor. ERAC 2.1 Identificador del Organismo Emisor SI Identificador del Organismo Emisor al que pertenece el Acto Notificado al que el usuario se ha subscrito. ERC 2.2 Identificador del Subscriptor SI Identificador del usuario que se ha subscrito al Acto Notificado. ERAC 2.3 Identificador del Acto Notificado. SI Identificador del Acto Notificado al que el Subscriptor se ha subscrito. las últimas N de censo Posibles Valores: ERAC 2.4 Tipo de Acción sobre dicha subscripción 1. Alta 2. Baja 3. Baja por Administración. 4. No Autorizado Si por motivos judiciales o administrativos el usuario no está autorizado a disponer de una DEU SI la ERAC 2.5 Fecha y Hora SI Fecha y hora generada por el servicio APE-SNTS en la que se produjo el cambio de estado de la subscripción. ERAC 2.6 Firma Digital Actualización Censo SI Firma por parte de la Actualización de Censo. ERAC 3 Firma Digital Remesa de Actualización de Censo SI Firma por parte de Correos de la Remesa con todas las Actualizaciones de Censo. Tabla 3. Estructura de datos de Envío de Remesa de Actualización de Censo (ERAC). Respuesta al Envío de Remesa de Actualización de Censo (RERAC) ID CAMPO RERAC 0 Confidencial Campo Respuesta al Envío de Remesa de Actualizaciones de Censo Obligatorio Descripción SI Engloba una respuesta asociada a una petición de Envío de Remesa de Actualizaciones de Censo. Página 16 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 RERAC 1 Identificador de Referencia de la Petición SI RERAC 2.A Código de Error de Validación de Firma de la Petición SI (*) (*) Sólo en caso de que exista un error de validación de firma; en cuyo caso el campo RERAC 2.B no será incluido. RERAC 2.B Respuesta sobre el procesamiento de cada Actualización de Censo. SI (*) (*) Sólo en caso de que la validación de firma haya sido exitosa. SI Identificador Único de la Actualización de Censo incluido en cada una de las Actualizaciones de Censo enviadas en la petición. NO(*) (*) Sólo en caso de que exista un error de validación de firma; en cuyo caso el campo RERC 2.B.2.B no será incluido. NO(*) (*) Sólo en caso de que la firma asociada a la Actualización de Censo haya sido validada pero no así los datos que componen la Actualización de Censo en sí. NO Firma por parte del Organismo Emisor del contenido de esta respuesta. RERAC 2.B.1 Identificador de la Actualización de Censo procesada RERAC 2.B.2.A Código de Error de Validación de Firma de la Certificación RERAC 2.B.2.B Código de Error en Validación de los datos de la Actualización de Censo RERAC 3 Firma de la respuesta. Valor incluido en ERAC 1 Los siguientes campos de la RCAR se retornarán con el mismo valor que aquel recibido en los campos de la correspondiente PRC: Campos ERC ERAC 1 ERAC 2.0 Campos RERC RERAC 1 RERAC 2.B.1 Tabla 4. Correspondencia de campos entre estructura ERAC y RERAC. Posibles valores del Código de Error de Validación de Firma (campo con identificador RERAC 2.A y 2.B.2.A ): CODIGO FIRMA_INVALIDA FIRMA_INVALIDA_CERTIFICADO_EXPIRADO FIRMA_INVALIDA_CERTIFICADO_REVOCADO FIRMA_INVALIDA_CERTIFICADO_NO_RECONOCIDO FIRMA_INVALIDA_INTEGRIDAD_ROTA Confidencial DESCRIPCIÓN El contenido de la firma no es válido El certificado incluido en la firma está expirado. El certificado incluido en la firma está revocado. El certificado incluido en la firma no está soportado. La información firmada no coincide con la información verificada. Página 17 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Tabla 5. Lista de posibles códigos de error de validación de firma en estructura RERAC. Posibles valores de Error en Datos de Actualización de Censo (campo con identificador RERAC 2.B.2.A): Código EMISOR_NO_RECONOCIDO SUBSCRIPTOR_ACTUALMENTE_OBLIGADO ACTO_NOTIFICADO_DESCONOCIDO ERROR_INTERNO Descripción El NIF del emisor no es el esperado. El usuario se ha dado de baja de un procedimiento para el que está obligado. El identificador del “Acto Notificado” no está reconocido por el Organismo Emisor. Cualquier otro tipo de error no esperado. Tabla 6. Lista de posibles códigos de error de petición en estructura RERAC. 3.4.1.2 Esquema XML 3.4.1.2.1 Petición de Envío de Remesa de Actualizaciones de Censo. - Esquema XML: ver descripción de elemento RemesaActualizacionCenso en el anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.13 3.4.1.2.2 Respuesta a Petición de Envío de Remesa de Actualización de Censo. - Esquema XML: ver descripción de elemento RespuestaRemesaActualizacionCenso en el anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.14 3.4.2 IMPLEMENTACIÓN SOBRE SERVICIOS WEB En esta sección se definen los aspectos de la vinculación SOAP de la interacción ‘Petición de Envío de Remesa de Actualizaciones de Censo, definida en el apartado anterior. Esta vinculación utiliza la versión SOAP 1.1 y HTTP 1.1 sobre SSLv3\TLSv1. 3.4.2.1 Operativa Básica Los elementos ‘RemesaActualizacionCenso’ y ‘RespuestaRemesaActualizacionCenso’ que completan el protocolo petición-respuesta de la interacción ‘Petición de Envío de Remesa de Actualizaciones de Censo’ se encierran dentro del cuerpo del mensaje SOAP. Estos dos mensajes se implementarán sobre un patrón de intercambio de mensajes de peticiónrespuesta SOAP síncrono: El servicio APE-SNTS enviará la petición RemesaActualizacionCenso dentro del cuerpo del mensaje SOAP al Organismo Emisor. Confidencial Página 18 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 El servicio Organismo Emisor retornará un elemento RespuestaRemesaActualizacionCenso dentro del cuerpo de otro mensaje SOAP o generará un fallo SOAP. Si el Organismo Emisor no pudiera procesar, por RespuestaRemesaActualizacionCenso generará un fallo SOAP. cualquier motivo la Bajo recepción de la respuesta RespuestaRemesaActualizacionCenso, el servicio APE-SNTS no deberá enviar un código de fallo u otro mensaje de error al Organismo Emisor. 3.4.2.2 Parámetros a definir No Aplica. 3.4.2.3 Descripción de la Interfaz La implementación de esta interfaz sobre WSDL 1.1 se basa en: - Estilo del binding: ‘Document’. - Uso: ‘literal’. - Estilo de los parámetros ‘Bare’. En el anexo 4.3 se puede ver el WSDL que define esta operación. 3.4.2.4 Vinculación sobre HTTPS El objeto RemesaActualizacionCenso será enviado por el servidio APE-SNTS como contenido de una petición HTTPS POST. Como respuesta a esa petición, el servicio APE-SNTS retornará en el contenido de la petición HTTPS POST, con código de error HTTP 200, un elemento RespuestaRemesaActualizacionCenso. En los anexos 4.4.15 y 4.4.16 se puede ver un ejemplo de mensaje RemesaActualizacionCenso y RespuestaRemesaActualizacionCenso sobre SOAP HTTPS. Confidencial Página 19 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.5 Envío de Notificaciones 3.5.1 VOLUNTARIOS Se almacenan las referencias (datos resumen) de las notificaciones / comunicaciones con su huella digital en el buzón del destinatario (sea el titular de la notificación o no). Los datos resumen de la notificación / comunicación contendrán una marca indicando que se envían a un usuario voluntario. Si el usuario estaba dado de alta como obligado, al recibir estos datos resumen pasará a ser voluntario. Si no estuviese creado el buzón, se comunica la incidencia correspondiente al Organismo Emisor. Se envía un aviso al titular del buzón por un email y/o SMS de la puesta a disposición. El acceso a la notificación / comunicación sólo está disponible para el titular del buzón. En caso de que el destinatario (titular del buzón) y el titular de la notificación / comunicación no sean la misma persona, se indicará en un campo específico para tal efecto quien es el Titular de la Notificación/Comunicación. 3.5.2 OBLIGADOS Las referencias (datos resumen) de las notificaciones / comunicaciones deben estar marcadas como obligatorias. Si el usuario estaba dado de alta como voluntario, al recibir esta referencia pasará a condición de obligado para todos los procedimientos del Organismo Emisor que envió los datos resumen. Pueden enviarse los NIF de personas físicas que están autorizadas a visualizar los documentos. o Por cada autorizado, se podrá incluir la dirección de correo electrónico y/o el número de teléfono, para el aviso mediante correo electrónico y/o SMS respectivamente. o En caso de que no se incluya dirección de correo electrónico, el “Autorizado” esté registrado en el APE-SNTS y haya proporcionado una dirección de correo electrónico, se usará esta última. o En caso de que no se incluya número de teléfono, el “Autorizado” esté registrado en el APE-SNTS y haya proporcionado un número de teléfono, se usará esta último. o En el caso de aviso por SMS a los autorizados cuando el APE-SNTS actúa “de oficio”, solo se enviará un SMS al primero de la lista que cumpla la condición. Se almacenan los datos resumen de las notificaciones / comunicaciones con su huella digital en el buzón del obligado. Si no estuviese creado se crea en ese momento. Se envía un aviso al email y/o SMS que conste en el buzón del obligado (sólo en el caso de que el buzón esté activado). El acceso a la notificación / comunicación está disponible para el obligado (titular del buzón) y las personas físicas autorizadas. 3.5.3 PROTOCOLO 3.5.3.1 Descripción general del protocolo Se define: - Resumen de Notificación / Comunicación: descripción resumida de una Notificación / Comunicación sin incluir el contenido de la misma (ej.: el contenido binario del PDF). Se incluirá Confidencial Página 20 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 la información suficiente para que el servicio APE-SNTS pueda solicitar posteriormente al Organismo Emisor el contenido completo de la Notificación / Comunicación. - Remesa de Resúmenes de Notificaciones / Comunicaciones: conjunto de Resúmenes de Notificación / Comunicación enviados al servicio Apartado Postal Electrónica para su procesamiento. - Información de Admisión de Notificación / Comunicación: información sobre el resultado del proceso de admisión (o error) de un Resumen de Notificación / Comunicación ejecutado por el servicio APE-SNTS. Esta Información de Admisión será enviada por el servicio APE-SNTS al Organismo Emisor. - Remesa Información de Admisión de Notificación / Comunicación: conjunto de elementos de Información de Admisión de Notificación / Comunicación enviados por el servicio APE-SNTS al Organismo Emisor. Este protocolo se ejecutará sobre dos intercambios de información: 1. Envío de una Remesa de Resúmenes de Notificaciones / Comunicaciones desde el Organismo Emisor al servicio APE-SNTS. 2. Envío de una Remesa de Información de Admisión desde el servicio APE-SNTS al Organismo Emisor. En el caso de servicios Web, se ejecutarán ambos intercambios de información sobre una interacción petición / respuesta síncrona. En el caso de Editran, y dada su naturaleza asíncrona, sólo se ejecutará la primera interacción. El servicio APE-SNTS, realizará en modo batch la admisión y, directamente, generará las correspondientes Certificaciones de Puesta a Disposición, respondiendo al Organismo Emisor con una ‘Respuesta de Certificaciones de Puesta a Disposición’ descrito en el apartado Error! Reference source not found.. 3.5.3.2 Estructura Lógica de los Datos RRN - Remesa de Resúmenes de Notificación / Comunicación ID CAMPO RRN Campo Remesa de Resúmenes de Notificación / Comunicación Obligatorio Descripción SI Engloba un Remesa de Resúmenes de Notificación / Comunicación. Identificador de la remesa definido por el Organismo Emisor. Es meramente referencial. El APE-SNTS no realiza ningún tipo de procesamiento sobre el mismo y su valor simplemente es retornado en la respuesta como mecanismo de control. RRN 1 Identificador de la Remesa SI RRN 2 Resumen de Notificación/Comunicación: SI 1 o N Resúmenes de Notificaciones / Comunicaciones remitidas por el Organismo Emisor. RRN 2.1 Identificador del Organismo Emisor SI NIF del Organismo Emisor. RRN 2.2 Identificador de la Notificación / Comunicación SI Identificador único de Notificación asignado por el Organismo Emisor. Confidencial / Comunicación Página 21 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Para un mismo Organismo Emisor, nunca no se podrá repetir el mismo Identificador de Notificación / Comunicación, aunque viaje en remesas diferentes. RRN 2.3 Tipo de correspondencia: Notificación / Comunicación SI Podrá ser una Notificación o una Comunicación. NIF/NIE del destinatario SI Identidad del Comunicación. RRN 2.5 Acto notificado SI Código del procedimiento que generó la Notificación / Comunicación. RRN 2.5 Número de Expediente NO Número del expediente correspondiente a la tramitación que ha dado lugar a la Notificación / Comunicación, según las especificaciones de PISTA Ventanilla Única II. RRN 2.7 Número de Registro NO Número de registro de salida del documento a notificar según las especificaciones de PISTA Ventanilla Única II. RRN 2.8 Fecha de Registro NO Fecha en la que se ha registrado la salida del documento a notificar según las especificaciones de PISTA Ventanilla Única II. RRN 2.9 Asunto SI Identifica el servicio o aplicación del Organismo Emisor desde el que se envía la Notificación / Comunicación. En el buzón del destinatario se visualizará como asunto de la Notificación / Comunicación. RRN 2.10 Cuerpo NO Se corresponde con el cuerpo del mensaje que será remitida al usuario. RRN 2.11 Versión documento NO Versión de la Notificación / Comunicación remitida por el Organismo Emisor. RRN 2.12 Fecha Hora Entrega NO Fecha en la que se ha registrado la salida del documento a notificar según las especificaciones de PISTA Ventanilla Única II. RRN 2.13 Huella digital del contenido en claro de la Notificación / Comunicación SI Código SHA-1 del contenido original en claro de la Notificación / Comunicación. RRN 2.14 Marca que indique si la Notificación / Comunicación está o no cifrada en origen SI - RRN 2.15 Marca que indique si la Notificación / Comunicación pertenece a un procedimiento obligatorio SI Permitirá conocer si la Notificación / Comunicación es remitida a un usuario que obligatoriamente debe recibir sus Notificaciones / Comunicaciones a través del servicio Apartado Postal Electrónico. RRN 2.15.1 Titular Notificación Procedimiento Voluntario NO En caso de que el Destinatario no coincida con el Titular de la Notificación se usará este campo para indicar quien es el Titular. RRN 2.15.2 Lista NIFs autorizados NO NIFs de los usuarios del servicio autorizados a acceder a la Notificación / Comunicación. Sólo aplica en el caso de usuarios obligados. RRN 2.15.2.1 Dirección de correo electrónico del usuario autorizado. NO Dirección de correo electrónico que se usará para avisar RRN 2.4 Confidencial destinatario de la Notificación Página 22 de 51 / Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 al autorizado. RRN 2.15.2.2 Número de teléfono para la recepción de SMS NO Número de teléfono que se usara para enviar un SMS de aviso al autorizado. RRN 2.16 Firma del Organismo Emisor sobre el Resumen de Notificación / Comunicación NO Firma XML sobre el contenido del Resumen de la Notificación / Comunicación. RRN 3 Firma del Organismo Emisor sobre la Remesa de Resúmenes de Notificación / Comunicación SI Firma XML sobre el contenido del Resumen de la Notificación / Comunicación completa. Tabla 7. Estructura de datos de Remesa de Resúmenes de Notificación / Comunicación (RRN) RIA - Remesa Información de Admisión de Resumen de Notificación / Comunicación Para cada Resumen de Notificación / Comunicación recibida, el servicio APE-SNTS retornará un elemento Información de Admisión indicando el resultado del proceso de admisión. ID CAMPO Campo Obligatorio Descripción SI Engloba una Remesa elemento Información Admisión RIA1 Identificador Remesa Resumen Notificación / Comunicación que originó esta respuesta SI Deberá ser el valor del campo RRN1 de la Remesa de Resumen de Notificación / Comunicación a la que se responde RIA 2 Código de error de validación de firma de la remesa NO Código de error asociado al la validación de la firma de la remesa RIA 3 Información de Admisión SI Estructura que agrupa la Información de Admisión de una Notificación / Comunicación. SI Identificador del Organismo Emisor que envío la Notificación / Comunicación cuya Información de Admisión se incluye. RIA Remesa Información de Admisión RIA 3.1 Identificador del Organismo Emisor de de RIA 3.2 Identificador de la Notificación / Comunicación SI Identificador único de Notificación / Comunicación asignado por el Organismo Emisor a la que se corresponde esta Información de Admisión. RIA 3.3 Tipo de Correspondencia: Notificación / Comunicación SI Podrá ser una Notificación o una Comunicación. NIF/NIE del destinatario SI Identidad del destinatario de la Notificación / Comunicación. Huella Digital del contenido sin cifrar de la Notificación / Comunicación original SI Código SHA-1 del contenido original en claro de la Notificación / RIA 3.4 RIA 3.5 Confidencial Página 23 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Comunicación. RIA 3.6.A Código de Validación de la Firma de la Notificación NO RIA 3.6.B Código de Error de Admisión de la Notificación NO RIA 3.7 Fecha de Admisión / Rechazo. Indica el resultado del proceso de admisión realizado por el servicio APE-SNTS En caso de no existir implica que la admisión ha sido correcta. Fecha en formato UTC (sin el componente de zona) relativa a la “Admisión” o “Rechazo” de dicha Notificación / Comunicación. SI SI en servicios Web y Tipo de Mensajería ‘Notificación’ RIA 3.8 Firma del servicio APE-SNTS sobre la Información de Admisión Firma XML sobre el contenido de la Información de Admisión NO en servicios Web y Tipo Mensajería ‘Comunicación’ NO en Editran RIA 4 Firma del Servicio APE-SNTS sobre la Remesa de Información de Admisión SI en Servicios Web SI en Editran Firma XML sobre el contenido de la de Remesa de Información de Admisión Tabla 8. Estructura de datos de Remesa de Información de Admisión de Resumen de Notificación / Comunicación (RIA). Los siguientes campos de la RIA se retornarán con el mismo valor que aquel recibido en los campos de la correspondiente RRN: Campos RIA RIA1 RIA3.1 RIA3.2 RIA3.3 RIA3.4 RIA3.5 Campos RRN RRN1 RRN2.1 RRN2.2 RRN2.3 RRN2.4 RRN4.13 Tabla 9. Correspondencia de campos entre estructura RRN y RIA. Posibles valores del Código de Error de verificación de firma en Remesa Notificación/Comunicación (campo con identificador RIA2 y RIA 3.6.A respectivamente): CODIGO FIRMA_INVALIDA FIRMA_INVALIDA_CERTIFICADO_EXPIRADO FIRMA_INVALIDA_CERTIFICADO_REVOCADO Confidencial y/o DESCRIPCIÓN El contenido de la firma no es válido El certificado incluido en la firma está expirado. El certificado incluido en la firma está revocado. Página 24 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador FIRMA_INVALIDA_CERTIFICADO_NO_RECONOCIDO FIRMA_INVALIDA_INTEGRIDAD_ROTA Fecha 31/3/2010 El certificado incluido en la firma no está soportado. La información firmada no coincide con la información verificada. Tabla 10. Lista de posibles códigos de error de campo Código de Remesa en estructura RIA. Posibles valores de Error de Admisión (campo con identificador RIA3.6.B): Código EMISOR_NO_RECONOCIDO DESTINATARIO_NO_EXISTE IDENTIFICADOR_MENSAJE_DUPLICADO ACTO_NOTIFICADO_NO_RECONOCIDO ERROR_INTERNO Descripción El NIF del emisor no está registrado en el sistema. El NIF del destinatario no está registrado en el sistema. El identificador de la Notificación/Comunicación ya existe en el sistema. El “Acto Notificado” no está registrado en el sistema. Cualquier otro tipo de error no esperado. Tabla 11. Lista de posibles códigos de error de campo Estado de Admisión en estructura RIA. 3.5.3.3 Esquema XML 3.5.3.3.1 Remesa de Resúmenes de Notificación / Comunicación - Esquema XML: Ver descripción de elemento RemesaMensajeLigeroFirmaGlobal en anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.1. 3.5.3.3.2 Remesa de Información de Admisión - Esquema XML: ver descripción de elemento AdmisionRemesaMensajeLigeroFirmaGlobal en anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.2. 3.5.3.4 Implementación sobre servicios Web y HTTPS En esta sección se definen los aspectos de la vinculación SOAP de la interacción ’Envío Remesa Resumen Notificacion / Comunicacion’, definida en el apartado anterior. Esta vinculación utiliza la versión SOAP 1.1 y HTTP 1.1 sobre SSLv3\TLSv1. 3.5.3.4.1 Operativa Básica Los elementos ‘RemesaMensajeLigeroFirmaGlobal’ y ‘AdmisionRemesaMensajeLigeroFirmaGlobal’ que completan el protocolo petición-respuesta de Confidencial Página 25 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 la interacción ’Envío Remesa Resumen Notificación / Comunicación’ se encierran dentro del cuerpo del mensaje SOAP. Estos dos mensajes se implementarán sobre un patrón de intercambio de mensajes de peticiónrespuesta SOAP síncrono: El Organismo Emisor enviará la petición RemesaMensajeLigeroFirmaGlobal dentro del cuerpo del mensaje SOAP al servicio APE-SNTS. El servicio APE-SNTS retornará un elemento AdmisionRemesaMensajeLigeroFirmaGlobal dentro del cuerpo de otro mensaje SOAP o generará un fallo SOAP si se produjo un error de sistema al procesar la remesa. Bajo recepción de la respuesta AdmisionRemesaMensajeLigeroFirmaGlobal, el Organismo Emisor no deberá enviar un código de fallo u otro mensaje de error al servicio APE-SNTS. 3.5.3.4.2 Descripción de la Interfaz La implementación de esta interfaz sobre WSDL 1.1 se basa en: - Estilo del binding: ‘Document’. - Uso: ‘literal’. - Estilo de los parámetros ‘Bare’. En el anexo 4.3 se puede ver el WSDL que define esta operación. 3.5.3.4.3 Vinculación sobre HTTPS El objeto RemesaMensajeLigeroFirmaGlobal contenido de una petición HTTPS POST. será enviado por el Organismo Emisor como Como respuesta a esa petición, el servicio APE-SNTS retornará en el contenido de la petición HTTPS POST un elemento AdmisionRemesaMensajeLigeroFirmaGlobal con código de error HTTP 200. Si se retornara un fallo SOAP como respuesta, se devolverá un código de error HTTP 500. En el anexo 4.4.7 y 4.4.8 se puede ver un ejemplo de mensaje AdmisionRemesaMensajeLigeroFirmaGlobal y RemesaInformacionAdmision sobre SOAP sobre HTTPS, respectivamente. Confidencial Página 26 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.6 Acceso a las Notificaciones Cuando un usuario tenga acceso a más de un buzón, se le obligará a elegir a cuál quiere acceder. Dentro de un buzón, sólo se visualizarán las Notificaciones / Comunicaciones a las que está autorizado. Una vez se seleccione la referencia (datos resumen) de una Notificación / Comunicación se procederá como se describe a continuación. 3.6.1 NOTIFICACIÓN O COMUNICACIÓN NO NOTIFICADA 1. En el caso de acceder a una Notificación, se solicita una firma electrónica del receptor sobre la referencia (datos resumen) completa de la Notificación (incluida la huella digital) y la fecha y hora del acceso que tengan los servidores del servicio APE-SNTS en ese momento. Si se accede a una Comunicación no se solicita la firma. 2. El servicio APE-SNTS genera y envía un Token de Petición firmado, al Organismo Emisor que le devuelve la Notificación / Comunicación y sus meta-datos asociados. Este Token de Petición incluirá el certificado electrónico con el que accedió al servicio el receptor. 3. El servicio APE-SNTS recibe la Notificación / Comunicación sin cifrar, calcula la huella digital del documento y la compara con aquella enviada cuando se remitieron los datos resumen de la Notificación / Comunicación. Si no coincide con el de la Notificación / Comunicación a la que quiere acceder se genera una incidencia. Si coincide, la descarga al programa (Applet o Control ActiveX) instalado en el ordenador del receptor. El servicio APE-SNTS no deja registro permanente alguno del contenido de la Notificación / Comunicación en su sistema. 4. El programa instalado en el ordenador del receptor le muestra el contenido de la Notificación / Comunicación al tiempo que solicita a los servidores del servicio APE-SNTS que genere la certificación de la Notificación / Comunicación con la misma fecha y hora de la firma del destinatario. Este programa da también la posibilidad de la descarga a local de la certificación completa junto con el documento de la Notificación / Comunicación para posterior verificación gratuita en lo servidores del servicio APE-SNTS, sin limitación de tiempo. 3.6.2 NOTIFICACIÓN O COMUNICACIÓN YA NOTIFICADA Si no ha transcurrido más de un mes desde la puesta a disposición, la operativa es la misma que en el caso anterior salvo la petición de firma del receptor. Si ha transcurrido más de un mes desde la puesta a disposición, se establecerá mediante un link una sesión contra el servidor del Organismo del Emisor para que se le muestre la Notificación / Comunicación previa autenticación en su sistema. 3.6.3 DESCRIPCIÓN GENERAL DEL PROTOCOLO Se define: - Token de Petición de Notificación / Comunicación: conjunto de atributos que identifican unívocamente a la Notificación / Comunicación que se desea recuperar desde el sistema de información de un Organismo Emisor. Confidencial Página 27 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 - Petición de Recuperación de Notificación / Comunicación: petición realizada por el servicio APE-SNTS, en el que incluye el Token de Notificación / Comunicación, de la Notificación / Comunicación a la que se desea acceder. - Notificación / Comunicación: conjunto de información que componen una Notificación / Comunicación. Incluye el contenido original de la misma. - Respuesta de Recuperación de Notificación / Comunicación: respuesta a una Petición de Recuperación de Notificación / Comunicación que incluye tantas Notificaciones / Comunicaciones como fueran solicitadas en la petición. El proceso de envío de una Petición de Recuperación de Notificación / Comunicación y obtención de la Notificación / Comunicación asociada se realizará sobre una interacción petición / respuesta síncrona, cuando se implemente sobre servicios Web. NOTA: este protocolo sólo contempla implementación sobre servicios Web. Interacción ’Recuperación de Notificación / Comunicación’: el servicio APE-SNTS envía el Token de Petición de Notificación / Comunicación al Organismo Emisor, y éste le devuelve respuesta con la Notificación / Comunicación asociada. 3.6.3.1 Estructura Lógica de los Datos PRN – Petición de Recuperación de Notificación / Comunicación ID CAMPO Campo Obligatorio Descripción PTN0 Token de Petición de Recuperación Notificación / Comunicación SI Engloba una petición de recuperación del contenido de una comunicación / notificación. PTN1 Identificador de referencia de la petición. SI Identificador asociado a la petición. Se espera que ese mismo valor sea devuelto en la respuesta asociada. PTN2 Identificador del Organismo Emisor SI Identificador del Organismo Emisor de la Notificación / Comunicación PTN3 Identificador de la Notificación / Comunicación SI Identificador único de la Notificación / Comunicación PTN4 NIF/NIE del Receptor SI Identidad del receptor que aceptado la Notificación Comunicación PTN5 Fecha y hora SI Fecha y hora en formato UTC en el que se creó este Token de Petición PTN6 Certificado electrónico del receptor SI Certificado electrónico del receptor que accede a la Notificación / Comunicación Confidencial ha / Página 28 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador PTN7 Firma del servicio APE-SNTS sobre el Token de Petición Fecha 31/3/2010 SI Firma XML sobre el contenido del Token de Petición Tabla 12. Estructura de datos de Petición de Recuperación de Notificación / Comunicación (PTN). RCN – Respuesta Contenido de Notificación / Comunicación ID CAMPO Campo Obligatorio Descripción RCN1 Respuesta Contenido de Notificación / Comunicación SI Engloba una Respuesta con el contenido de la Notificacion / Comunicacion solicitada. RCN2 Identificador de la Petición asociada. SI Debe ser el valor del campo PTN1 de la Petición asociada. RCN3.A Código de Error Validación Firma NO Código de error asociado a la validación de la firma que se recibió como entrada. RCN3.B Código de Error Petición NO Código de error asociado al procesamiento de la petición que se recibió como entrada. RCN4 Tipo MIME en el que se representa el Contenido de la Notificación / Comunicación SI Tipo MIME que indica el tipo de contenido incluido en la Notificación / Comunicación (RFC2045,RFC2046]) RCN5 Contenido de la Notificación / Comunicación SI Contenido en base 64 del contenido de la Notificación / Comunicación RCN6 Firma del Organismo Emisor sobre el Contenedor de la Notificación / Comunicación NO Firma XML sobre el contenido del Resumen de la Notificación / Comunicación. Tabla 13. Respuesta Contenedor(es) de Notificación(es) / Comunicación(es) (RCN). Posibles valores del Código de Error de Validación de Firma (campo con identificador RCN 3.A): CODIGO FIRMA_INVALIDA FIRMA_INVALIDA_CERTIFICADO_EXPIRADO FIRMA_INVALIDA_CERTIFICADO_REVOCADO FIRMA_INVALIDA_CERTIFICADO_NO_RECONOCIDO FIRMA_INVALIDA_INTEGRIDAD_ROTA DESCRIPCIÓN El contenido de la firma no es válido El certificado incluido en la firma está expirado. El certificado incluido en la firma está revocado. El certificado incluido en la firma no está soportado. La información firmada no coincide con la información verificada. Tabla 14. Lista de posibles códigos de error de validación de firma en estructura RCN. Confidencial Página 29 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Posibles valores de Error de Petición (campo con identificador RIA3.B): Código EMISOR_NO_RECONOCIDO RECEPTOR_NO_RECONOCIDO MENSAJEID_NO_RECONOCIDO HUELLA_DIGITAL_INVALIDA ERROR_INTERNO Descripción El NIF del emisor no es el esperado. El NIF del receptor no es el esperado. El MensajeID no es válido. La huella digital no coincide. Cualquier otro tipo de error no esperado. Tabla 15. Lista de posibles códigos de error de petición en estructura RCN. 3.6.3.2 Esquema XML 3.6.3.2.1 Petición de Recuperación de Notificación / Comunicación - Esquema XML: Ver descripción de elemento TokenRecuperacionContenido en anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.5. El elemento ds:KeyInfo debe contener exactamente un elemento hijo ds:X509Data con el contenido binario en base 64 del certificado electrónico del receptor como valor de un elemento ds:X509Certificate. 3.6.3.2.2 Respuesta de Recuperación de Notificación / Comunicación - Esquema XML: Ver descripción de elemento ContenidoMensajeLigero en anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.6. 3.6.4 IMPLEMENTACIÓN SOBRE SERVICIOS WEB En esta sección se definen los aspectos de la vinculación SOAP de la interacción definida en el apartado anterior. Esta vinculación utiliza la versión SOAP 1.1 y HTTP 1.1 sobre SSLv3\TLSv1. 3.6.4.1 Operativa Básica El intercambio de los elementos ‘TokenRecuperacionContenido’ y ‘ContenidoMensajeLigero’ se realiza sobre un intercambio SOAP de petición-respuesta síncrono. Ambos elementos se encierran dentro del cuerpo del mensaje SOAP. Estos dos mensajes se implementarán sobre un patrón de intercambio de mensajes de peticiónrespuesta SOAP síncrono: El Servicio APE-SNTS enviará la petición TokenRecuperacionContenido dentro del cuerpo del mensaje SOAP al Organismo Emisor. El Organismo Emisor retornará un elemento ContenidoMensajeLigero dentro del cuerpo de otro mensaje SOAP o generará un fallo SOAP. Confidencial Página 30 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Bajo recepción de la respuesta ContenidoMensajeLigero, el Servicio APE-SNTS no deberá enviar un código de fallo u otro mensaje de error al Organismo Emisor. 3.6.4.2 Parámetros a definir Ningunio. 3.6.4.3 Descripción de la Interfaz La implementación de esta interfaz sobre WSDL 1.1 se basa en: - Estilo del binding: ‘Document’. - Uso: ‘literal’. - Estilo de los parámetros ‘Bare’. 3.6.4.4 Vinculación sobre HTTPS El objeto TokenRecuperacionContenido será enviado por el servicio APE-SNTS como contenido de una petición HTTPS POST. Como respuesta a esa petición, el Organismo Emisor retornará en el contenido de la petición HTTPS POST, con código de error HTTP 200, un elemento ContenidoMensajeLigero. Si se produjo un error de sistema al procesar la petición, retornará un código de error HTTP 500. En los anexos 4.4.7 y 4.4.8 se puede ver un ejemplo de mensaje TokenRecuperacionContenido y ContenidoMensajeLigero sobre SOAP y HTTPS. Confidencial Página 31 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.7 Recuperación de Eventos de Puesta a Disposición / Recogida / Caducidad en modo ACTIVO. Pendiente de redefinir. Confidencial Página 32 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.8 Recuperación de Eventos de Puesta a Disposición / Recogida / Caducidad en modo PASIVO. 3.8.1 DESCRIPCIÓN GENERAL DEL PROTOCOLO El objetivo de este protocolo es que el Organismo Emisor reciba de periódicamente y de forma automática desde el servicio APE-SNTS las Certificaciones de Puesta a Disposición y/o Acuse de Recibo que se vayan generando en este último. Dicho envío será en remesas de N certificaciones con un tiempo de espera entre envíos a fin de no saturar el sistema. En caso de que transcurrido cierto lapso de tiempo no se hayan generado el número máximo de Certificaciones, se enviarán las que existan disponibles hasta ese momento. En caso de que el servicio del Organismo Emisor encargado de procesar las peticiones procedentes del APE-SNTS no esté disponible el tiempo entre reintentos se irá incrementando. Se define: - Remesa de Certificaciones: Petición enviada por el servicio APE-SNTS hacia el Organismo Emisor con las N últimas Certificaciones disponibles desde el último envío. - Certificación: Certificación electrónica emitida y firmada por Correos 2 y el receptor, si se trata de una Notificación, o sin firmar por ninguna de las partes, si se trata de una Comunicación (ver modalidad 3 en Tabla 20, anexo 4.1). Esta certificación confirma la puesta a disposición, aceptación o rechazo, con fecha y hora, de una Notificación / Comunicación por parte del receptor. En el caso de que el destinatario no hubiera accedido a la Notificación / Comunicación transcurridos 10 días naturales desde su puesta a disposición, se dará por rechazada siendo firmado el rechazo únicamente por Correos (si era una Notificación; en el caso de una Comunicación el evento de recogida / rechazo no se firma). - Resultado Procesamiento Remesa de Certificaciones: Respuesta emitida por un Organismo Emisor al servicio APE-SNTS como resultado del recibir y procesar una petición de Remesa de Certificaciones que contiene tantas Respuestas de Certificación como certificaciones hubiesen sido incluidas en la petición. - Respuesta de Certificación: Información sobre la validación o no de la recepción de una Certificación por parte de un Organismo Emisor. Este protocolo se ejecutará sobre dos intercambios de información: - Envío de una ‘Petición de Remesa de Certificaciones’ desde el servicio APE-SNTS al Organismo Emisor. - Envío de una ‘Respuesta de Remesa de Certificaciones’ desde el Organismo Emisor al servicio APE-SNTS con el resultado de la recepción. En el caso de servicios Web, se ejecutarán ambos intercambios de información sobre una interacción petición / respuesta síncrona. 2 La firma de Correos incluirá los datos que componen el evento de recogida así como la firma que el receptor realizó sobre el evento de recogida en el momento de recoger/rechazar la Notificación / Comunicación. Confidencial Página 33 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 En el caso de Editran se ejecutarán de manera asíncrona en modo batch. 3.8.1.1 Estructura Lógica de los Datos Envío de Remesa de Certificaciones (ERC) ID CAMPO ERC 0 Campo Envío de Remesa de Certificaciones Obligatorio Descripción SI Engloba un envío de una remesa de Certificaciones. ERC 1 Identificador de referencia. SI Identificador asociado a la petición que deberá ser devuelto en la respuesta asociada. ERC 2 Certificación SI Se incluirán las 1 a N Certificaciones disponibles desde el último envío. ERC 2.0 Identificador Único de la Certificación SI Identificador único Certificación para Organismo Emisor. de dicho ERC 2.1 Datos del Organismo Emisor SI Datos del Organismo Emisor de la Notificación / Comunicación cuya certificación se retorna. ERC 2.2 Identificador de la Notificación / Comunicación SI Identificador único de Notificación / Comunicación. ERC 2.3 Tipo de Correspondencia: Notificación / Comunicación SI Podrá ser una Notificación o una Comunicación. Datos del destinatario de la Notificación / Comunicación. ERC 2.4 Datos del Destinatario SI Persona física: NIF/NIE Nombre, Apellidos y Persona jurídica: NIF y Razón Social Datos de la persona física / jurídica que recogió la Notificación / Comunicación. ERC 2.5 Datos del Receptor NO Persona física: NIF/NIE Nombre, Apellidos y Persona jurídica: NIF y Razón Social. Además se deberá incluir el número de serie y el nombre Confidencial Página 34 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 de la autoridad de certificación del certificado X.509 que utilizó el Receptor para recoger la Notificación / Comunicación Su inclusión solo es obligatoria en los casos de Certificaciones de Acuse de Recibo por parte del usuario. ERC 2.6 Acto notificado SI Código del procedimiento que generó la Notificación / Comunicación para la que se emite la presente Certificación de Acuse de Recibo. ERC 2.7 Huella Digital del contenido sin cifrar de la Notificación / Comunicación original SI Código SHA-1 del contenido original en claro de la Notificación / Comunicación. SI Fecha y hora generada por el servicio APE-SNTS en la que puso la Notificación / Comunicación a disposición del destinatario en su buzón electrónico. ERC 2.8 Fecha y Hora de la Puesta a Disposición Indicará el tipo de certificación: ERC 2.9 ERC 2.10 ERC 2.11 ERC 2.12 Confidencial Tipo Motivo del Rechazo Fecha y Hora de la generación de la Certificacion. Código de Verificación Electrónica SI Recogida Aceptada. Recogida Rechazada. Rechazada por Caducidad La Notificación / Comunicación no fue recogida en el tiempo . SI(*) (*) En el caso de que el Tipo de Recogida fuera ‘Rechazada por el Receptor’ en el campo ERC 2.9, este elemento será obligatorio y deberá incluir un texto introducido por el Receptor que indique el motivo del rechazo. SI Fecha y hora generada por el servicio APE-SNTS en la que se generó/recuperó la Certificación. Código de Verificación Electrónica que permitirá realizar un cotejo visual de la copia impresa de la diligencia generada a partir de esta Página 35 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 certificación. SI(*) Servicios Web / Editran y Notificación ERC 2.13 Firma de recogida del usuario. NO Servicios Web / Editran y Comunicación Firma electrónica generada por el usuario que recogió la Notificación sobre los datos ERC 2. (*) Sólo se generará en el caso de que el campo ERC 2.9 coincida con una recogida por aceptación o rechazo. El servicio APE-SNTS no la incluirá en el caso de una Comunicación. Firma electrónica generada por el servicio APE-SNTS sobre los datos ERC 2. SI Servicios Web / Editran y Notificación ERC 2.14 Firma de la Certificación ERC 3 Firma electrónica sobre la petición de remesa completa NO Servicios Web / Editran y Comunicación Tal y como se muestra en el cuadro de modalidades de envío del apartado 4.1, la modalidad 3 establece, en el caso de Notificaciones, que la Certificación de Acuse de Recibo y Puesta a Disposición sea firmada por el servicio APE-SNTS, mientras que la de una Comunicación no. NO Firma electrónica generada por el servicio APE-SNTS sobre la Respuesta completa. Tabla 16. Estructura de datos de Envío de Remesa de Certificaciones (ERC). Respuesta al Envío de Remesa de Certificaciones (RERC) ID CAMPO Campo Obligatorio Descripción RERC 0 Respuesta al Envío de Remesa de Certificaciones SI Engloba una respuesta asociada a una petición de Envío de Remesa de Certificaciones. RERC 1 Identificador de Referencia de la Petición SI Valor incluido en ERC 1 RERC 2.A Código de Error de Validación de Firma de la Petición SI (*) (*) Sólo en caso de que exista un error de validación de firma; en cuyo caso el campo RERC 2.B no será incluido. RERC 2.B Respuesta sobre el procesamiento de cada Certificación. SI (*) (*) Sólo en caso de que la validación de firma haya sido exitosa. RERC 2.B.1 Identificador de Certificación Procesada SI Identificador Único de Certificación incluido en cada una de las Confidencial Página 36 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 certificaciones petición. RERC 2.B.2.A Código de Error de Validación de Firma de la Certificación RERC 2.B.2.B Código de Error en Validación de los datos de la Certificación RERC 3 Firma de la respuesta. enviadas en la NO(*) (*) Sólo en caso de que exista un error de validación de firma; en cuyo caso el campo RERC 2.B.2.B no será incluido. NO(*) (*) Sólo en caso de que la firma asociada a la certificación haya sido validada pero no así los datos que componen la certificación NO Firma por parte del Organismo Emisor del contenido de esta respuesta. Los siguientes campos de la RCAR se retornarán con el mismo valor que aquel recibido en los campos de la correspondiente PRC: Campos ERC ERC 1 ERC 2.0 Campos RERC RERC 1 RERC 2.B.1 Tabla 17. Correspondencia de campos entre estructura ERC y RERC. Posibles valores del Código de Error de Validación de Firma (campo con identificador RERC 2.A y 2.B.2.A ): CODIGO FIRMA_INVALIDA FIRMA_INVALIDA_CERTIFICADO_EXPIRADO FIRMA_INVALIDA_CERTIFICADO_REVOCADO FIRMA_INVALIDA_CERTIFICADO_NO_RECONOCIDO FIRMA_INVALIDA_INTEGRIDAD_ROTA DESCRIPCIÓN El contenido de la firma no es válido El certificado incluido en la firma está expirado. El certificado incluido en la firma está revocado. El certificado incluido en la firma no está soportado. La información firmada no coincide con la información verificada. Tabla 18. Lista de posibles códigos de error de validación de firma en estructura RCN. Posibles valores de Error en Datos de Certificación (campo con identificador E): Código EMISOR_NO_RECONOCIDO RECEPTOR_NO_RECONOCIDO DESTINATARIO_NO_RECONOCIDO ERROR_INTERNO Descripción El NIF del emisor no es el esperado. El NIF del receptor no es el esperado. El NIF del destinatario no es el esperado. Cualquier otro tipo de error no esperado. Tabla 19. Lista de posibles códigos de error de petición en estructura RCN. Confidencial Página 37 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.8.1.2 Esquema XML 3.8.1.2.1 Petición de Envío de Remesa de Certificaciones - Esquema XML: ver descripción de elemento RemesaCertificaciones en el anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.9. 3.8.1.2.2 Respuesta a Petición de Envío de Remesa de Certificaciones - Esquema XML: ver descripción de elemento RespuestaRemesaCertificaciones en el anexo 4.2.1. - Ejemplo XML: ver anexo 4.4.10. 3.8.2 IMPLEMENTACIÓN SOBRE SERVICIOS WEB En esta sección se definen los aspectos de la vinculación SOAP de la interacción ‘Petición de Envío de Remesa de Certificaciones, definida en el apartado anterior. Esta vinculación utiliza la versión SOAP 1.1 y HTTP 1.1 sobre SSLv3\TLSv1. 3.8.2.1 Operativa Básica Los elementos ‘RemesaCertificaciones’ y ‘RespuestaRemesaCertificaciones’ que completan el protocolo petición-respuesta de la interacción ‘Petición de Envío de Remesa de Certificaciones’ se encierran dentro del cuerpo del mensaje SOAP. Estos dos mensajes se implementarán sobre un patrón de intercambio de mensajes de peticiónrespuesta SOAP síncrono: El servicio APE-SNTS enviará la petición RemesaCertificaciones dentro del cuerpo del mensaje SOAP al Organismo Emisor. El servicio Organismo Emisor retornará un elemento RespuestaRemesaCertificaciones dentro del cuerpo de otro mensaje SOAP o generará un fallo SOAP. Si el Organismo Emisor no pudiera procesar, por RespuestaRemesaCertificaciones generará un fallo SOAP. cualquier motivo la Bajo recepción de la respuesta RespuestaRemesaCertificaciones, el servicio APE-SNTS no deberá enviar un código de fallo u otro mensaje de error al Organismo Emisor. 3.8.2.2 Parámetros a definir No Aplica. Confidencial Página 38 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 3.8.2.3 Descripción de la Interfaz La implementación de esta interfaz sobre WSDL 1.1 se basa en: - Estilo del binding: ‘Document’. - Uso: ‘literal’. - Estilo de los parámetros ‘Bare’. En el anexo 4.3 se puede ver el WSDL que define esta operación. 3.8.2.4 Vinculación sobre HTTPS El objeto RemesaCertificaciones será enviado por el servidio APE-SNTS como contenido de una petición HTTPS POST. Como respuesta a esa petición, el servicio APE-SNTS retornará en el contenido de la petición HTTPS POST, con código de error HTTP 200, un elemento RespuestaRemesaCertificaciones. En los anexos 4.4.11 y 4.4.12 se puede ver un ejemplo de mensaje RemesaCertificaciones y RespuestaRemesaCertificaciones sobre SOAP HTTPS. Confidencial Página 39 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 4. ANEXO 4.1 Modalidades de envío MODALIDADES NOTIFICACIONES Firma Correos Firma Correos Firma (Notificado + Correos) Firma (Notificado + Correos) Firma (Notificado + Correos) Firma Correos Con validación revocación 1C Firma Correos Firma Correos Firma Correos + Cert.usuar. Firma Correos Firma Correos Firma Correos Con validación revocación 2. Certificación de recogida por Correos Eventos: Admisión P. Disposición Acceso Rechazo No accedido Acceso: Identificación certificado 2N Firma Correos Firma Correos Firma Correos Firma Correos Firma Correos Con validación revocación 2C Sin firma Sin firma Sin firma Sin firma Sin firma Con validación revocación 3. Recogida bajo firma del notificado (descarga de la notificación a correos en el momento del acceso del notificado) Eventos: Admisión P. Disposición Token petición Acceso Rechazo No accedido Acceso: Identificación certificado 1N COMUNICACIONES 1. Recogida bajo firma del notificado Eventos: Admisión P. Disposición Petición clave cifrado Acceso Rechazo No accedido Acceso: Identificación certificado 3N Firma Correos Firma Correos Firma Correos + Cert.usuar. Firma (Notificado + Correos) Firma (Notificado + Correos) Firma Correos Con validación revocación 3C Sin firma Sin firma Firma Correos + Cert.usuar. Sin firma Sin firma Sin firma Con validación revocación Tabla 20. Tabla resumen de las modalidades de envío de Notificaciones / Comunicaciones. Confidencial Página 40 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 4.2 Esquemas XML 4.2.1 ESQUEMA APE-SNTS 4.3 Descriptor de interfaz WSDL de servicio APE 4.4 Ejemplos XML 4.4.1 EJEMPLO DE REMESA DE RESÚMENES DE NOTIFICACIÓN / COMUNICACIÓN <?xml version="1.0" encoding="UTF-8"?> <ape:RemesaMensajeLigeroFirmaGlobal ape:idRef="IdRemesaMensajesLigeros" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../ws/ape-snts.xsd"> <!-Mensaje ligero 1 - Notificación con un autorizado --> <ape:Mensaje ape:idUnico="MensajeID1" tipo="NOTIFICACION"> <ape:Emisor>A28000001</ape:Emisor> <ape:SubscripcionObligatoria> <ape:Destinatario>12345678Z</ape:Destinatario> <ape:Autorizados nif="13321231A" /> </ape:SubscripcionObligatoria> <ape:ActoNotificado>CODIGOPROCEDIMIENTO</ape:ActoNotificado> <ape:Asunto>Asunto de ejemplo</ape:Asunto> <ape:Cuerpo>Cuerpo del mensaje</ape:Cuerpo> <ape:Contenido> <ape:HuellaDigital algoritmo="SHA-1">SIujkgzmvCSIujkgzmvCSIujkgzmvCSIujkgzmvC</ape:HuellaDigital> </ape:Contenido> </ape:Mensaje> <!-Mensaje ligero 2 - Comunicación --> <ape:Mensaje ape:idUnico="MensajeID2" tipo="COMUNICACION"> <ape:Emisor>A28000001</ape:Emisor> <ape:SubscripcionObligatoria> <ape:Destinatario>11113334Z</ape:Destinatario> </ape:SubscripcionObligatoria> <ape:ActoNotificado>CODIGOPROCEDIMIENTO</ape:ActoNotificado> <ape:Asunto>Asunto de ejemplo</ape:Asunto> <ape:Cuerpo>Cuerpo del mensaje</ape:Cuerpo> <ape:Contenido> <ape:HuellaDigital algoritmo="SHA-1">SIujkgzmvCSIujkgzmvCSIujkgzmvCSIujkgzmvC</ape:HuellaDigital> </ape:Contenido> Confidencial Página 41 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 </ape:Mensaje> <!-Firma XMLDSig Detached sobre el elemento ContenidoFirmado --> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>KxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdA</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>+90M4CQ9U25SIujkgzmvC9dfSxEnLe2F45OSDbJpYS1YTBZoDSn1/DSjwxwgDXs8BwPz+mvxh5vy B17T7+Co9iBnP0uvDly+O5CPd2+9IxD5HkWO4hzMg/bc8IWu6bpVwMK1ji0KfG/CVkBYkbZJledT vhPH6pA/iqn2iKFGHi5nGqVxd0+s2ZeCdtm3tkCyJjEjZRVljm+Zr2hqIrmXjyEP+PqCSm7ybkjv dDOKLf1qTPDh/SPWwos4AhvB7wkPhi3OFN7LStoJiQyY0EhlCGARA1CurdwPbfkJZJzJQB+oi3ZF 8VcwX3rjIs75B+Vs5MbZDJ2zQ/3xJMCs7XBEdA==</ds:SignatureValue> </ds:Signature> </ape:RemesaMensajeLigeroFirmaGlobal> 4.4.2 EJEMPLO DE ADMISIÓN REMESA DE RESÚMENES DE NOTIFICACIÓN / COMUNICACIÓN <?xml version="1.0" encoding="UTF-8"?> <ape:AdmisionRemesaMensajeLigeroFirmaGlobal ape:idRef="PeticionRMLFG_1" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../ws/ape-snts.xsd "> <!-- El primero de los mensajes fue ACEPTADO y el segundo RECHAZADO --> <ape:AdmisionMensaje> <ape:MensajeID>MensajeID1</ape:MensajeID> <ape:Emisor>A28000001</ape:Emisor> <ape:Destinatario>12345678Z</ape:Destinatario> <ape:ActoNotificado>CODIGOPROCEDIMIENTO</ape:ActoNotificado> <ape:HuellaDigital algoritmo="SHA-1">SIujkgzmvCSIujkgzmvCSIujkgzmvCSIujkgzmvC</ape:HuellaDigital> <ape:FechaHoraAdmision>2001-12-31T12:00:00</ape:FechaHoraAdmision> </ape:AdmisionMensaje> <ape:AdmisionMensaje> <ape:MensajeID>MensajeID2</ape:MensajeID> <ape:Emisor>A28000001</ape:Emisor> <ape:Destinatario>11113334Z</ape:Destinatario> <ape:ActoNotificado>CODIGOPROCEDIMIENTO</ape:ActoNotificado> <ape:HuellaDigital algoritmo="SHA-1">SIujkgzmvCSIujkgzmvCSIujkgzmvCSIujkgzmvC</ape:HuellaDigital> <ape:FechaHoraAdmision>2001-12-31T12:00:00</ape:FechaHoraAdmision> <ape:ErrorAdmision>ERROR_INTERNO</ape:ErrorAdmision> </ape:AdmisionMensaje> <!-- Firma XMLDSig Enveloped --> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod> <ds:DigestValue>KxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdA</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>+90M4CQ9U25SIujkgzmvC9dfSxEnLe2F45OSDbJpYS1YTBZoDSn1/DSjwxwgDXs8BwPz+mvxh5vy B17T7+Co9iBnP0uvDly+O5CPd2+9IxD5HkWO4hzMg/bc8IWu6bpVwMK1ji0KfG/CVkBYkbZJledT vhPH6pA/iqn2iKFGHi5nGqVxd0+s2ZeCdtm3tkCyJjEjZRVljm+Zr2hqIrmXjyEP+PqCSm7ybkjv dDOKLf1qTPDh/SPWwos4AhvB7wkPhi3OFN7LStoJiQyY0EhlCGARA1CurdwPbfkJZJzJQB+oi3ZF 8VcwX3rjIs75B+Vs5MbZDJ2zQ/3xJMCs7XBEdA==</ds:SignatureValue> </ds:Signature> </ape:AdmisionRemesaMensajeLigeroFirmaGlobal> Confidencial Página 42 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 4.4.3 EJEMPLO SOAP SOBRE HTTPS DE REMESA DE RESÚMENES DE NOTIFICACIÓN / COMUNICACIÓN HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ape:RemesaMensajeLigeroFirmaGlobal > … </ape: RemesaMensajeLigeroFirmaGlobal > </soap-env:Body> </soap-env:Envelope> 4.4.4 EJEMPLO SOAP SOBRE HTTPS DE REMESA DE INFORMACIÓN DE ADMISIÓN HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ape:AdmisionRemesaMensajeLigeroFirmaGlobal> … </ape:AdmisionRemesaMensajeLigeroFirmaGlobal> </soap-env:Body> </soap-env:Envelope> 4.4.5 EJEMPLO DE PETICIÓN DE RECUPERACIÓN DE NOTIFICACIÓN / COMUNICACIÓN <?xml version="1.0" encoding="UTF-8"?> <ape:TokenRecuperacionContenido ape:idRef="idToken_NCC-121312332" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../ws/ape-snts.xsd "> <ape:MensajeID>NCC-1123123</ape:MensajeID> <ape:Emisor>A28000001</ape:Emisor> <ape:Receptor>12345678Z</ape:Receptor> <ape:FechaHoraCreacion>2001-12-31T12:00:00</ape:FechaHoraCreacion> <!-- Certificado del receptor --> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MCAAAABA</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <!-- Firma sobre el Token --> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod> <ds:DigestValue>KxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdA</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>+90M4CQ9U25SIujkgzmvC9dfSxEnLe2F45OSDbJpYS1YTBZoDSn1/DSjwxwgDXs8BwPz+mvxh5vy B17T7+Co9iBnP0uvDly+O5CPd2+9IxD5HkWO4hzMg/bc8IWu6bpVwMK1ji0KfG/CVkBYkbZJledT vhPH6pA/iqn2iKFGHi5nGqVxd0+s2ZeCdtm3tkCyJjEjZRVljm+Zr2hqIrmXjyEP+PqCSm7ybkjv Confidencial Página 43 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 dDOKLf1qTPDh/SPWwos4AhvB7wkPhi3OFN7LStoJiQyY0EhlCGARA1CurdwPbfkJZJzJQB+oi3ZF 8VcwX3rjIs75B+Vs5MbZDJ2zQ/3xJMCs7XBEdA==</ds:SignatureValue> </ds:Signature> </ape:TokenRecuperacionContenido> 4.4.6 EJEMPLO DE RESPUESTA A PETICIÓN DE RECUPERACIÓN DE NOTIFICACIÓN / COMUNICACIÓN <?xml version="1.0" encoding="UTF-8"?> <ape:ContenidoMensajeLigero ape:idRef="idToken_NCC-121312332" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../ape-snts.xsd "> <ape:Contenido mime="application/pdf">YXNkZmFzZg==</ape:Contenido> </ape:ContenidoMensajeLigero> 4.4.7 EJEMPLO SOAP SOBRE HTTPS DE PETICIÓN DE RECUPERACIÓN DE NOTIFICACIÓN / COMUNICACIÓN HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ape:TokenRecuperacionContenido> … </ape:TokenRecuperacionContenido> </soap-env:Body> </soap-env:Envelope> 4.4.8 EJEMPLO SOAP SOBRE HTTPS DE RESPUESTA A PETICIÓN DE RECUPERACIÓN DE NOTIFICACION / COMUNICACION HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ape:ContenidoMensajeLigero> … </ape:ContenidoMensajeLigero> </soap-env:Body> </soap-env:Envelope> 4.4.9 EJEMPLO DE REMESA DE CERTIFICACIONES CON UNA CERTIFICACIÓN DE ACUSE DE RECIBO <?xml version="1.0" encoding="UTF-8"?> <ape:RemesaCertificaciones ape:idRef="RemesaCert_OE_1" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../apesnts.xsd"> <ape:Certificacion ape:idUnico="633252" tipo="ACUSE_DE_RECIBO:ACEPTADA" formatoNuevo="true"> <ape:DatosCertificados Id="DatosCertificadosID"> <ape:MensajeID>MIRMIRNOT70</ape:MensajeID> <ape:Emisor> <ape:PersonaJuridica> <ape:RazonSocial>Ministerio Del Interior</ape:RazonSocial> Confidencial Página 44 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 <ape:NIF>G47579765</ape:NIF> </ape:PersonaJuridica> </ape:Emisor> <ape:Destinatario> <ape:PersonaFisica> <ape:Nombre>Juan Español Español</ape:Nombre> <ape:NIF>12345678Z</ape:NIF> </ape:PersonaFisica> </ape:Destinatario> <ape:HuellaDigital algoritmo="SHA1">020HfZ6eQ11RvQLgMd0UdvoGyJ+WQ15vhsc3ff5QYAQ=</ape:HuellaDigital> <ape:InformacionEvento tipo="PUESTA_DISPOSICION"> <ape:Fecha>2010-02-25T18:13:18+01:00</ape:Fecha> </ape:InformacionEvento> <ape:InformacionEvento tipo="ACUSE_DE_RECIBO:ACEPTADA"> <ape:Fecha>2010-02-25T22:13:18+01:00</ape:Fecha> <ape:Receptor> <ape:PersonaFisica> <ape:Nombre>Juan Español Español</ape:Nombre> <ape:NIF>12345678Z</ape:NIF> </ape:PersonaFisica> <ape:DatosCertificado> <ape:NumeroSerie>5901</ape:NumeroSerie> <ape:AutoridadCertificadora>CN=PRUEBA, O=PRUEBA</ape:AutoridadCertificadora> </ape:DatosCertificado> </ape:Receptor> </ape:InformacionEvento> <ape:CodigoVerificacionElectronica>12345678Z311220014940</ape:CodigoVerificacionElectronica> <ape:TipoMensajeria>NOTIFICACION</ape:TipoMensajeria> <ape:ActoNotificado>INTERVENCION_ONG</ape:ActoNotificado> </ape:DatosCertificados> <!-- Firma del Usuario Final sobre la certificación de recogida --> <ape:FirmaReceptor xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:etsi="http://uri.etsi.org/01903/v1.3.2#" Id="FirmaReceptorRecogida"> <ds:SignedInfo Id="FirmaReceptorRecogida-SignedInfo"> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference Id="FirmaReceptorRecogida-SignedPropertiesID" Type="http://uri.etsi.org/01903/v1.2.2#SignedProperties" URI="#FirmaReceptorRecogida-SignedProperties"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>xONwPM5Zg3yr3RzFKRnKtMoL+UE=</ds:DigestValue> </ds:Reference> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <ds:XPath> <!-- REVISAR TRANSFORMACIÓN XPATH AL PODER CONTENER VARIAS CERTIFICACIONES EN UNA MISMA PETICIÓN !!!! --> not(ancestor-or-self::ds:Signature) </ds:XPath> </ds:Transform> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>+2/F4a7LtvqGeDWW7LHNNkSYw+A=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue Id="FirmaReceptorRecogidaValor">JvEsRDd0GVJlOaWWBvrGZEv87Pm+nhoU9bO3ZXRyQvdNZaOp6xzevR2cW0yt0ip/px4f0yW6DNsonJe HTw3eF22co5OBUhk=</ds:SignatureValue> <ds:KeyInfo Id="FirmaReceptorRecogidaCertificado"> <ds:X509Data> <ds:X509Certificate>MIIITTCCBzWgAwIBAgICFw0wDQYJKoZIhvcNAQEFBQAwggExMQswCQYDVQQGEwJFUzE7MDkGA1UE ChMyQWdlbmNpYSBDYXRhbGFuYSBkZSBDZXJ0aWZpY2FjaW8gKE5JRiBRLTA4MDExNzYtSSkxNDAy BgNVBAcTK1Bhc3NhdGdlIGRlIGxhIENvbmNlcGNpbyAxMSAwODAwOCBCYXJjZWxvbmExLjAsBgNV cHM6Ly93d3cuY2F0Y2VydC5uZXQvdmVySURDYXQwDQYJKoZIhvcNAQEFBQADggEBAF+ZB43i4agN AGmrGzLDGs3wFzygd7aqM2DmmeflpBsaLAlXfhkfMy0A4sobGjwdS/Xr7AAr/zlIoaqydyigp7uh vwEfHfzOe7IRLtmHKKoMGYP7QLRLvWBLEY1XYWciBza49R2iaLf7RO6tDgyJo5ymEb24SDup+8a7 AhNnKxKPHzyS/w3KKL96n1is7ddpJIyXoDtKGADa3WT2PpMMKjZgEIUMNUQWgOEcoFcyepYEUXFd HyM33UgTwguQuo6wvfHJv/fOlItPTOa/i6vFkHx5T9SoyaWp7bnr/5nhf8JhIAELTpiOWiObkojt jsTTfszHWUDIpjTlgfIsIZeZOeQ=</ds:X509Certificate> </ds:X509Data> Confidencial Página 45 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>ucOmoUNmE2dcXOS0hTh3uVI/qD0WKewl7XB+YI5oDF8CUOFAiMtS7k84SJX1XPMXAY5CJa9grkv8 BUlJnJBt7FqsGqDLr8k=</ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> <ds:Object Id="FirmaReceptorRecogida-Object"> <etsi:QualifyingProperties Target="#FirmaReceptorRecogida"> <etsi:SignedProperties Id="FirmaReceptorRecogida-SignedProperties"> <etsi:SignedSignatureProperties> <etsi:SigningTime>2010-02-25T18:13:18+01:00</etsi:SigningTime> <etsi:SigningCertificate> <etsi:Cert> <etsi:CertDigest> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>aAUXodVJA4VHAk/zTf9Tq5nxIgE=</ds:DigestValue> </etsi:CertDigest> <etsi:IssuerSerial> <ds:X509IssuerName>CN=PRUEBA, O=PRUEBA</ds:X509IssuerName> <ds:X509SerialNumber>5901</ds:X509SerialNumber> </etsi:IssuerSerial> </etsi:Cert> </etsi:SigningCertificate> <etsi:SignaturePolicyIdentifier> <etsi:SignaturePolicyImplied /> </etsi:SignaturePolicyIdentifier> <etsi:SignerRole> <etsi:ClaimedRoles> <etsi:ClaimedRole>claimedRole</etsi:ClaimedRole> </etsi:ClaimedRoles> </etsi:SignerRole> </etsi:SignedSignatureProperties> </etsi:SignedProperties> </etsi:QualifyingProperties> </ds:Object> </ape:FirmaReceptor> <!-- Firma de Acuse de Recibo Aceptación generado por CORREOS - cubre la firma del usuario final --> <ape:FirmaCorreos xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:etsi="http://uri.etsi.org/01903/v1.3.2#" Id="FirmaAcuseReciboAPE"> <ds:SignedInfo Id="FirmaAcuseReciboAPE-SignedInfo"> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference Id="FirmaAcuseReciboAPE-SignedPropertiesID" Type="http://uri.etsi.org/01903/v1.2.2#SignedProperties" URI="#FirmaAcuseReciboAPE-SignedProperties"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>xONwPM5Zg3yr3RzFKRnKtMoL+UE=</ds:DigestValue> </ds:Reference> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <ds:XPath> <!-- REVISAR TRANSFORMACIÓN XPATH AL PODER CONTENER VARIAS CERTIFICACIONES EN UNA MISMA PETICIÓN !!!! --> not(ancestor-or-self::ds:Signature) </ds:XPath> </ds:Transform> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>+2/F4a7LtvqGeDWW7LHNNkSYw+A=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue Id="FirmaAcuseReciboAPEValor">JvEsRDd0GVJlOaWWBvrGZEv87Pm+nhoU9bO3ZXRyQvdNZaOp6xzevR2cW0yt0ip/px4f0yW6DNso rhieqFue1XlWDEGB93pIGLUAybsIr0WDP0kqPMHHeRDqvecZRcwCXa/0Gl5cWKhpL4vQtuKPkhMi nJeHTw3eF22co5OBUhk=</ds:SignatureValue> <ds:KeyInfo Id="FirmaAcuseReciboAPECertificadoCorreos"> <ds:X509Data> Confidencial Página 46 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 <ds:X509Certificate>BwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cHM6Ly9vY3NwLmNhdGNlcnQubmV0MBgGCCsGAQUFBwED HyM33UgTwguQuo6wvfHJv/fOlItPTOa/i6vFkHx5T9SoyaWp7bnr/5nhf8JhIAELTpiOWiObkojt jsTTfszHWUDIpjTlgfIsIZeZOeQ=</ds:X509Certificate> </ds:X509Data> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>ucOmoUNmE2dcXOS0hTh3uVI/qD0WKewl7XB+YI5oDF8CUOFAiMtS7k84SJX1XPMXAY5CJa9grkv8 BUlJnJBt7FqsGqDLr8k=</ds:Modulus> <ds:Exponent>AQAC</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> <ds:Object Id="FirmaAcuseReciboAPE-Object"> <etsi:QualifyingProperties Target="#FirmaAcuseReciboAPE"> <etsi:SignedProperties Id="FirmaAcuseReciboAPE-SignedProperties"> <etsi:SignedSignatureProperties> <etsi:SigningTime>2010-02-25T18:13:18+01:00</etsi:SigningTime> <etsi:SigningCertificate> <etsi:Cert> <etsi:CertDigest> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>aAUXodVJA4VHAk/zTf9Tq5nxIgE=</ds:DigestValue> </etsi:CertDigest> <etsi:IssuerSerial> <ds:X509IssuerName>CN=PRUEBA, O=PRUEBA</ds:X509IssuerName> <ds:X509SerialNumber>5901</ds:X509SerialNumber> </etsi:IssuerSerial> </etsi:Cert> </etsi:SigningCertificate> <etsi:SignaturePolicyIdentifier> <etsi:SignaturePolicyImplied /> </etsi:SignaturePolicyIdentifier> <etsi:SignerRole> <etsi:ClaimedRoles> <etsi:ClaimedRole>claimedRole</etsi:ClaimedRole> </etsi:ClaimedRoles> </etsi:SignerRole> </etsi:SignedSignatureProperties> </etsi:SignedProperties> </etsi:QualifyingProperties> </ds:Object> </ape:FirmaCorreos> </ape:Certificacion> <!-- Firma sobre toda la remesa --> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:DigestValue>KxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdA</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>+90M4CQ9U25SIujkgzmvC9dfSxEnLe2F45OSDbJpYS1YTBZoDSn1/DSjwxwgDXs8BwPz+mvxh5vy B17T7+Co9iBnP0uvDly+O5CPd2+9IxD5HkWO4hzMg/bc8IWu6bpVwMK1ji0KfG/CVkBYkbZJledT vhPH6pA/iqn2iKFGHi5nGqVxd0+s2ZeCdtm3tkCyJjEjZRVljm+Zr2hqIrmXjyEP+PqCSm7ybkjv dDOKLf1qTPDh/SPWwos4AhvB7wkPhi3OFN7LStoJiQyY0EhlCGARA1CurdwPbfkJZJzJQB+oi3ZF 8VcwX3rjIs75B+Vs5MbZDJ2zQ/3xJMCs7XBEdA==</ds:SignatureValue> </ds:Signature> </ape:RemesaCertificaciones> 4.4.10 EJEMPLO DE RESPUESTA A REMESA DE CERTIFICACIÓNES <?xml version="1.0" encoding="UTF-8"?> <ape:RespuestaRemesaCertificaciones ape:idRef="RemesaCert_OE_1" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../ape-snts.xsd "> <ape:RespuestaCertificacion ape:idUnico="633252" /> Confidencial Página 47 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 <!-- Firma sobre el Contenido --> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod> <ds:DigestValue>KxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdA</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>+90M4CQ9U25SIujkgzmvC9dfSxEnLe2F45OSDbJpYS1YTBZoDSn1/DSjwxwgDXs8BwPz+mvxh5vy B17T7+Co9iBnP0uvDly+O5CPd2+9IxD5HkWO4hzMg/bc8IWu6bpVwMK1ji0KfG/CVkBYkbZJledT vhPH6pA/iqn2iKFGHi5nGqVxd0+s2ZeCdtm3tkCyJjEjZRVljm+Zr2hqIrmXjyEP+PqCSm7ybkjv dDOKLf1qTPDh/SPWwos4AhvB7wkPhi3OFN7LStoJiQyY0EhlCGARA1CurdwPbfkJZJzJQB+oi3ZF 8VcwX3rjIs75B+Vs5MbZDJ2zQ/3xJMCs7XBEdA==</ds:SignatureValue> </ds:Signature> </ape:RespuestaRemesaCertificaciones> 4.4.11 EJEMPLO SOAP SOBRE HTTPS DE UNA PETICIÓN DE CERTIFICACIÓN DE ACUSE DE RECIBO HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ape:RemesaCertificaciones> … </ape:RemesaCertificaciones> </soap-env:Body> </soap-env:Envelope> 4.4.12 EJEMPLO SOAP SOBRE HTTPS CERTIFICACIÓN DE ACUSE DE RECIBO DE UNA RESPUESTA A UNA PETICIÓN DE HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ape:RespuestaRemesaCertificaciones> … </ape:RespuestaRemesaCertificaciones> </soap-env:Body> </soap-env:Envelope> 4.4.13 EJEMPLO DE ENVÍO DE REMESA DE ACTUALIZACIÓN DE CENSO. <?xml version="1.0" encoding="UTF-8"?> <ape:RemesaActualizacionCenso ape:idRef="RemesaCenso_1" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../ape-snts.xsd "> <ape:ActualizacionCenso ape:idUnico="ActualizacionCenso_1"> <ape:Emisor>00NIFAEAT</ape:Emisor> <ape:Subscriptor>03466994C</ape:Subscriptor> <ape:ActoNotificado>PROC-21434</ape:ActoNotificado> <ape:Accion>ALTA</ape:Accion> <ape:FechaHora>2001-12-31T12:00:00</ape:FechaHora> <ds:Signature> ... </ds:Signature> Confidencial Página 48 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 </ape:ActualizacionCenso> <ape:ActualizacionCenso ape:idUnico="ActualizacionCenso_2"> <ape:Emisor>00NIFAEAT</ape:Emisor> <ape:Subscriptor>03478497J</ape:Subscriptor> <ape:ActoNotificado>PROC-21434</ape:ActoNotificado> <ape:Accion>BAJA</ape:Accion> <ape:FechaHora>2001-12-31T12:00:00</ape:FechaHora> <ds:Signature> ... </ds:Signature> </ape:ActualizacionCenso> <!-- Firma sobre la REMESA --> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod> <ds:DigestValue>KxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdA</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>+90M4CQ9U25SIujkgzmvC9dfSxEnLe2F45OSDbJpYS1YTBZoDSn1/ DSjwxwgDXs8BwPz+mvxh5vyB17T7+Co9iBnP0uvDly+O5CPd2+9IxD5HkWO4hzMg/bc8IWu6 bpVwMK1ji0KfG/CVkBYkbZJledTvhPH6pA/iqn2iKFGHi5nGqVxd0+s2ZeCdtm3tkCyJjEjZ RVljm+Zr2hqIrmXjyEP+PqCSm7ybkjvdDOKLf1qTPDh/SPWwos4AhvB7wkPhi3OFN7LStoJi QyY0EhlCGARA1CurdwPbfkJZJzJQB+oi3ZF8VcwX3rjIs75B+Vs5MbZDJ2zQ/3xJMCs7XBEdA==</ds:SignatureValue> </ds:Signature> </ape:RemesaActualizacionCenso> 4.4.14 EJEMPLO DE RESPUESTA A REMESA DE ACTUALIZACIÓN DE CENSO. <?xml version="1.0" encoding="UTF-8"?> <ape:RespuestaRemesaActualizacionCenso ape:idRef="RemesaCenso_1" xmlns:ape="urn:correos:ape:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:correos:ape:1.0 ../ape-snts.xsd "> <ape:RespuestaActualizacionCenso idUnico="ActualizacionCenso_1"/> <ape:RespuestaActualizacionCenso idUnico="ActualizacionCenso_2"/> <!-- Firma sobre la RESPUESTA --> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod> <ds:DigestValue>KxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdAKxdA</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>+90M4CQ9U25SIujkgzmvC9dfSxEnLe2F45OSDbJpYS1YTBZoDSn1/ DSjwxwgDXs8BwPz+mvxh5vyB17T7+Co9iBnP0uvDly+O5CPd2+9IxD5HkWO4hzMg/bc8IWu6 bpVwMK1ji0KfG/CVkBYkbZJledTvhPH6pA/iqn2iKFGHi5nGqVxd0+s2ZeCdtm3tkCyJjEjZ RVljm+Zr2hqIrmXjyEP+PqCSm7ybkjvdDOKLf1qTPDh/SPWwos4AhvB7wkPhi3OFN7LStoJi QyY0EhlCGARA1CurdwPbfkJZJzJQB+oi3ZF8VcwX3rjIs75B+Vs5MbZDJ2zQ/3xJMCs7XBEdA==</ds:SignatureValue> </ds:Signature> </ape:RespuestaRemesaActualizacionCenso> 4.4.15 EJEMPLO SOAP SOBRE HTTPS DE ENVÍO DE REMESA DE ACTUALIZACIÓN DE CENSO. HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: Confidencial Página 49 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ape:RemesaActualizacionCenso> … </ape:RemesaActualizacionCenso> </soap-env:Body> </soap-env:Envelope> 4.4.16 EJEMPLO SOAP SOBRE HTTPS RESPUESTA A REMESA DE ACTUALIZACIÓN DE CENSO HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn SOAPAction: <soap-env:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> < ape:RespuestaRemesaActualizacionCenso> … </ape:RespuestaRemesaActualizacionCenso> </soap-env:Body> </soap-env:Envelope> Confidencial Página 50 de 51 Nombre del Documento Protocolos de Integración de Modalidad 3 del servicio APE-SNTS Nombre del Proyecto / Iniciativa Apartado Postal Electrónico Tipo de documento Versión Estado Especificación 1.2 Borrador Fecha 31/3/2010 Estándares Referenciados Acrónimo [HTTP] [XML] [XMLNS] [XSD] [WSI] [SOAP] [SOAPBP] [WSDL] Estándares de Seguridad [TLS] [SSL] [HTTPS] [XMLDSIG] [WSSEC] Estándar Estándares Core RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 Extensible Markup Language (XML) 1.0 (Second Edition) http://www.w3.org/TR/REC-xml-names/ XML Schema Part 2: Datatypes Basic Profile Version 1.1 (BP1.1) Simple Object Access Protocol (SOAP) 1.1 Simple SOAP Binding Profile Version 1.0 (SSBP1.0) Web Services Description Language (WSDL) 1.1 TLS1.1 FC 4346 The SSL Protocol Version 3.0 RFC 2818: HTTP over TLS XML Signature Syntax and Processing (Recomendación W3C de 10 de Junio de 2008) Web Services Security: SOAP Message Security 1.1 (WS-Security 2004) OASIS Standard Specification, 1 February 2006 [WSISec] Basic Security Profile Version 1.1 [XADES-BES] XADES ETSI TS 101 903 v1.3.2 Tabla 21. Tabla resumen de los estándares referenciados. Confidencial Página 51 de 51