4.2.1 Esquema APE-SNTS - AEAT: Oficina Virtual

Anuncio
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
Descargar