Especificacion Funcional Del Protocolo de Sustitucion de Certificados en Soporte Papel SCSPv3

Especificacin Funcional del
Protocolo de Sustitucin de
Certificados en Soporte Papel
SCSPv3
Sustitucin de Certificados en Soporte Papel

Ministerio de Poltica Territorial y Administracin Pblica
Especificacin Funcional SCSPv3
1.0
16/09/2012
Protocolo SCSP v3
Protocolo de Sustitucin de Certificados en
Soporte Papel versin 3
Especificacin Funcional del protocolo SCSP

Autor:
Tipo de Documento:
Grupo de Trabajo:
Versin:
Fecha:
Fichero:
Divisin de Proyectos de Administracin Electrnica- MINHAP

Especificacin funcional
Eliminacin de Certificados
1.0
21-07-2011
20120912-Especificacion-Funcional_SCSPv3.doc
Historia del Documento

Fecha
Versin
Descripcin
21 de julio de 2011
Creacin 1 versin consolidada de SCSPv3 partiendo de

la Especificacin funcional y tcnica de SCSPv2
16 de septiembre 2012
1.1
Correccin de errores en algunas etiquetas, referencias al

MPTAP, y otros errores menores
Documentacin Relacionada
Nombre del documento
Versin
Descripcin
ET_elimin_certificados_2-7 con control de

2.7
cambios.doc
Especificacin tcnica SCSP v2
EF_elimin_certificados_4-2.doc
4.2
Especificacin funcional SCSP v2
20100518-EspecificacionSCSP_v3_ReleaseNotes.doc
2.0
Especificacin de cambios de SCSPv2 a

SCSPv3
1.01
Especificacin
SCSP v2
de
errores
SOAPFAULT
1.0
Especificacin
SCSP v3
de
errores
SOAPFAULT
Especificacion SOAP Fault_v1.01.doc

20110721-EspecificacionSCSP_v3_SOAPFAULT.doc
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
2 de 32
Protocolo SCSP v3
EspecificacionFuncional_Esquemas_formatos_SCSP_v3.
1.0
doc
Descripcin de los esquemas (ficheros

XSD) de los mensajes intercambiados,
formato del tipo de dato de cada atributo
y ejemplos de cada tipo de mensaje
ndice
1
INTRODUCCIN ................................................................................................................................................ 5
DESCRIPCIN DEL PROTOCOLO SCSP ................................................................................................. 6

2.1 CARACTERSTICAS GENERALES DEL PROTOCOLO SCSP................................................................................ 7
2.2 ROLES DEFINIDOS EN EL PROTOCOLO .............................................................................................................. 8
2.3 MODOS DE FUNCIONAMIENTO DEL PROTOCOLO .............................................................................................. 8
2.4 TRATAMIENTO DE LAS TRANSMISIONES DE DATOS POR PARTE DE LOS REQUIRENTES/EMISORES .............. 9
2.4.1 Funcionamiento Sncrono ................................................................................................................ 10
2.4.2 Funcionamiento Asncrono .............................................................................................................. 11
ELEMENTOS ESTNDAR DEL SISTEMA ............................................................................................... 14

3.1 SARA ............................................................................................................................................................... 14
3.2 PROTOCOLO DE COMUNICACIONES HTTPS .................................................................................................. 14
3.3 USO DE LA FIRMA DIGITAL PARA IDENTIFICACIN ........................................................................................ 14
3.3.1 Certificados X509v3 reconocidos (y aceptados por @firma) ............................................. 14
3.3.2 Formato de firma................................................................................................................................ 14
3.3.3 Modificacin del Formato de firma............................................................................................... 15
3.4 USO DE ESQUEMAS .......................................................................................................................................... 15
3.4.1 Espacio de nombres .......................................................................................................................... 16
3.5 MECANISMO DE AUTORIZACIN ..................................................................................................................... 16
3.5.1 Alternativas de autorizacin ........................................................................................................... 16
3.5.2 Nodos de interoperabilidad ............................................................................................................. 17
3.6 IDENTIFICADORES DE PETICIN ..................................................................................................................... 17
3.6.1 Identificadores de solicitud ............................................................................................................. 18
3.6.2 Identificadores de transmisin ...................................................................................................... 18
3.7 SEGURIDAD Y TRAZABILIDAD.......................................................................................................................... 18
3.8 OBLIGACIONES DE INTEROPERABILIDAD........................................................................................................ 18
3.9 CIFRADO DE MENSAJES................................................................................................................................... 18
3.9.1 Tokens de seguridad ws-security ................................................................................................. 19
MENSAJES INTERCAMBIADOS ................................................................................................................ 20

4.1 MENSAJE DE PETICIN SCSPV3 ................................................................................................................... 20
4.1.1 Emisor ..................................................................................................................................................... 21
4.1.2 Solicitante ............................................................................................................................................. 22
4.1.3 Titular ..................................................................................................................................................... 23
4.1.4 Transmisin .......................................................................................................................................... 24
4.2 MENSAJE DE RESPUESTA SCSPV3 ................................................................................................................ 25
4.2.1 Emisor ..................................................................................................................................................... 26
4.2.2 Solicitante ............................................................................................................................................. 26
4.2.3 Titular ..................................................................................................................................................... 26
4.2.4 Transmisin .......................................................................................................................................... 26
4.3 MENSAJE DE CONFIRMACIN DE PETICIN SCSPV3 ................................................................................... 27
4.4 MENSAJE DE SOLICITUD DE RESPUESTA SCSPV3 ....................................................................................... 28
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
3 de 32
Protocolo SCSP v3
4.5
DATOS ESPECFICOS ....................................................................................................................................... 29
GESTIN DE ERRORES ................................................................................................................................ 29
ANEXO I: WSDL Y XSD (FORMATOS Y ESQUEMAS).................................................................... 30
ANEXO II: DEFINICIONES RELEVANTES .......................................................................................... 31
Lista de figuras
Figura 1.- Peticin SCSPv3 ........................................................................................... 21
Figura 2.- Datos del Emisor .......................................................................................... 22
Figura 3.- Datos del Solicitante ..................................................................................... 23
Figura 4.- Datos del titular ............................................................................................ 24
Figura 5.- Datos de la transmisin ................................................................................. 25
Figura 6.- Respuesta SCSPv3 ........................................................................................ 25
Figura 7.- Datos de la transmisin en la respuesta ........................................................... 27
Figura 8.- Confirmacin de peticin................................................................................ 28
Figura 9.- Solicitud de respuesta ................................................................................... 28
Lista de Tablas
No se encuentran elementos de tabla de ilustraciones.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
4 de 32
Protocolo SCSP v3
1 Introduccin
El presente documento describe la especificacin del protocolo Sustitucin de Certificados en
Soporte Papel, adelante SCSP, Versin 3.
El objetivo de este protocolo es la utilizacin de la transmisin de datos como medio estndar
de sustitucin de certificados en papel mediante la definicin del formato de informacin tanto
requerida como suministrada de manera general, y en la parte correspondiente a cada servicio
de manera especfica, entre AAPPs para cumplir con la normativa vigente en la que no se
puede pedir documentacin a los ciudadanos que ya obre en poder de las AAPPs.
Tomando como referencia la versin
muchos servicios, como:
de SCSPv2 vigente desde el ao 2006 en su uso en
Consulta de estar al corriente de Deuda con la TGSS

Consulta de estar al corriente de pagos con la AEAT
Servicio de Comunicacin del Cambio de Domicilio
Servicio de Consulta de la Renta
Servicios de Verificacin de Datos de Identidad y de Residencia
Servicios de consulta de Estar dado de alta en la TGSS 1
Domicilio Fiscal 2
Impuesto de Actividades Econmicas
ha puesto en evidencia una serie de carencias o mejoras necesarias que han desembocado en
la versin 3 de SCSP.
La versin SCSPv3 incorpora las siguientes novedades 4 :
Nuevo espacio de nombres: intermediacion.redsara.es en lugar de www.map.es
Introduce nuevos campos en el esquema (Datos Genricos) asociados al Solicitante
de la informacin que se haban identificado como necesarios en el uso de la versin 2.
El detalle en los apartados siguientes.
Se aumenta la longitud de varios campos, como el Idpeticion a 26, IdTransmision a 29.
Adopta como mecanismo de firma WS-Security (ms estandarizado e implementado por
las distintas plataformas SOA) como modelo de referencia
V2 con namespace de datos especficos no estndar
No compatible V2 en la respuesta y DatosEspecificos
V3 con firma XMLDsig
Ver la Nota de versiones con el detalle de dichos cambios.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
5 de 32
Protocolo SCSP v3
Incorpora la posibilidad de cifrado en las respuestas, mecanismo solicitado por algunos

organismos cedentes en el caso de servicios intermediados.
Incluye un atributo opcional (Id) en los elementos susceptibles de ser cifrados para
agilizar las bsquedas por referencia en lugar de por Xpath.
2 Descripcin del protocolo SCSP

La especificacin del protocolo SCSP define los siguientes elementos:
Descripcin general del protocolo y su funcionamiento
Roles
Requirente (cliente)
Emisor (Servidor)
Modos de funcionamiento
Sncrono
Asncrono
Tratamiento de las solicitudes y transmisiones de datos por parte de los
requirentes/emisores
Composicin de los mensajes
Validacin del esquema
Firma y Validacin de la firma y del certificado con el que se firm
Cifrado y Descifrado del mensaje si procede
Descripcin de los mensajes intercambiados que conforman el protocolo y de los
formatos de campos especificados:
Peticin
Respuesta
Confirmacin de Peticin
Solicitud de Respuesta
Datos Especficos
Soap-Fault
Esta especificacin persigue definir de manera exhaustiva un modelo de intercambio
estandarizado de informacin entre administraciones pblicas al objeto de suprimir los
certificados en soporte papel.
Para complementar este documento se han generado tambin los siguientes documentos
especficos:
Especificacion-SCSP_v3_SOAPFAULT.doc 1.0
descripcin del mensaje SOAPFAULT SCSP v3
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Especificacin
de
Fecha
16/09/2012
errores
Hoja
6 de 32
Protocolo SCSP v3
Especificacion-Funcional_Esquemas_formatos_SCSP_v3.doc Descripcin de los

esquemas (ficheros XSD) de los mensajes intercambiados, formatos de los tipos de
datos de cada atributo y ejemplos de cada tipo de mensaje.
2.1 Caractersticas Generales del Protocolo SCSP

El protocolo SCSP establece las siguientes premisas.
Formato estandarizado XML para las transmisin de estos datos, y protocolo SOAP para
su transmisin. Estandarizacin de formatos para datos comunes a todos los
certificados a sustituir, libertad de formato para los datos especficos de cada uno. Se
definen en concreto en el apartado de mensajes.
El protocolo de transporte ser http.
La confidencialidad de la informacin se realizar en base a interconexin de servidores
utilizando protocolo SSL.
Servicios Web XML para el acceso a los datos, estilo de llamada basada en documentos
XML.
La publicacin y realizacin de los esquemas (xsd) y descripcin de los servicios (wsdl)
para cada servicio web, ser responsabilidad de cada Organismo Emisor. Debe
respetarse los mensajes estndar, peticin, respuesta, confimacion de peticin,
solicitud de respuesta y Soap Fault. De cara a facilitar la distribucin, y complementario
al directorio de servicios responsabilidad de cada organismo emisor, existir un
Directorio adicional centralizado en el MPTAP.
Control de acceso al sistema mediante certificados X509 V3 reconocidos y firma
electrnica avanzada, para asegurar los siguientes aspectos: autenticidad,
confidencialidad, disponibilidad y conservacin de la informacin.
El protocolo permitir funcionamiento tanto sncrono como asncrono.
El modelo de peticiones simples podr utilizar el modelo asncrono de trasmisin como
mecanismo de contingencia, pero nunca al contrario.
El mecanismo de llamada y obtencin de respuesta, para el proceso asncrono, estar
basado en polling.
El modelo de peticiones mltiples-asncronas har referencia a un nico tipo de
certificado en cada peticin.
La respuesta recibida en el modelo de peticiones mltiples-asncronas es nica para
cada peticin. Las respuestas deben contener tantas transmisiones como solicitudes
contuviera la peticin, con independencia del nmero de ellas que se hayan resuelto
correctamente.
Los errores que se puedan generar durante la utilizacin del sistema se transmitirn
utilizando el estndar SOAP Fault. Es decir, si alguna solicitud provoca un error SOAP
Fault entonces nicamente se devuelve ste objeto, no un mensaje de respuesta (No se
retorna el valor de las que se procesaron correctamente). En caso de que alguna de las
solicitudes incluidas dentro de la peticin conlleve la asignacin de un nuevo Tiempo
Estimado de Respuesta (TER), entonces se devolver un mensaje de respuesta sin
transmisiones con el nuevo TER y en donde el nodo numElementos tendr el valor 0.
Las transmisiones con errores que vayan incluidas en respuestas asncronas correctas
lo indicarn en el campo de datos especficos.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
7 de 32
Protocolo SCSP v3
2.2 Roles definidos en el protocolo

El protocolo SCSP contempla dos roles fundamentales, el rol de emisor y el de
requirente.
Se entiende por Emisor al organismo encargado de suministrar la informacin y es
responsable de:
La definicin y publicacin de los servicios web (WSDL, XSD, etc.)
cumpliendo con las especificaciones SCSP.
Obtener la informacin de sus sistemas (backoffice) segn las condiciones
del servicio y devolverla en el mensaje de respuesta.
Generacin del Identificador de la transmisin efectuada y su marca de
tiempo.
En el caso de ofrecer un servicio asncrono definir en nmero de
Solicitudes mximo que acepta el servicio. Se recomienda no superar las
1000. En algunos casos hay emisores que han fijado su valor a 100.
Registrar las solicitudes recibidas y las
almacenarlas el tiempo que requiere la ley.
transmisiones
enviadas
Se entiende por Requirente al organismo encargado de pedir la informacin. Se

adaptar a las condiciones definidas por el Emisor. Ser el responsable de:
Consumir los servicios web (WSDL, XSD,...) cumpliendo con las especificaciones
definidas.
Generacin del Identificador de la peticin enviada y de las Solicitudes a incluir en
dicha peticin.
Cumplimentar adecuadamente las peticiones enviadas garantizando la veracidad
de los datos enviados, y la adecuacin de los mismos tal y como se desarrolla en
los siguientes apartados.
Registrar las solicitudes enviadas y las transmisiones recibidas y almacenarlas el
tiempo que requiere la ley.
2.3 Modos de funcionamiento del protocolo

El protocolo de Sustitucin de Certificados en soporte Papel (SCSP) est pensado para
funcionar tanto de manera sncrona como de manera asncrona. El funcionamiento
sncrono es una simplificacin del funcionamiento asncrono.
En el modo sncrono se intercambian dos mensajes, peticin y respuesta.
Una peticin estar compuesta por un nodo Atributos, donde se describirn los datos
de cada peticin (Identificador de la peticin, nmero de elementos, Marca de tiempo timestamp-, Cdigo nico de certificado al que hace referencia la peticin y nodo
Estado con la descripcin del estado correspondiente a esa peticin) y el nodo
Solicitudes.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
8 de 32
Protocolo SCSP v3
El nodo solicitudes estar compuesto por la lista de solicitudes de transmisin,

SolicitudTransmision que contendr los datos genricos de cada Solicitud y los datos
especficos de las mismas.
La estructura de los datos genricos ser comn a todos los servicios que usen SCSP
como protocolo de intercambio de datos, mientras que los datos especficos sern
particulares de cada Emisor/Servicio.
En general una peticin estar identificada con un ID nico que cada Emisor validar
que no est repetido. (AtributosIdPeticion)
Cada peticin podr tener tantas solicitudes (Identificadas unvocamente dentro de la
peticin) como soporte el servicio, y se indicar en el campo numElementos.
Cada respuesta tendr tantas transmisiones como solicitudes haya recibido.
Cada transmisin de datos contendr la siguiente informacin:
Identificador nico de la trasmisin generados por el emisor y el timestamp de
cuando se ha generado
Datos de negocio de la respuesta (Datos Especficos)
2.4 Tratamiento de las transmisiones de datos por parte de

los requirentes/emisores
Las transmisiones de datos realizadas deben de adoptar medidas tcnicas y de
organizacin necesaria que aseguren los aspectos siguientes:
Autenticidad
Confidencialidad
Integridad
No Repudio
Disponibilidad
Conservacin de la informacin
Para hacerlo se har uso del principio de proporcionalidad, es decir, que las medidas de
seguridad debern tener en cuenta el estado de la tecnologa y ser proporcionadas a la
naturaleza de los datos y de los tratamientos a proteger y a los riesgos a los que estn
expuestos.
La autenticidad de la informacin se garantizar por el uso de certificados X509v3
reconocidos y aceptados por todas las partes.
La confidencialidad se conseguir mediante el uso de SSL en las comunicaciones.
Se podr, adicionalmente garantizar la confidencialidad extremo a extremo
mediante mecanismos de cifrado.
La autenticidad y el No repudio se conseguirn mediante mecanismos de huella y
firma electrnica.
La disponibilidad se conseguir mediante redundancia de los equipos
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
9 de 32
Protocolo SCSP v3
La conservacin de la informacin mediante mecanismos de almacenamiento y

recuperacin de informacin adecuados
2.4.1 Funcionamiento Sncrono

Los tratamientos que se realizarn a la hora de enviar una peticin/solicitud de datos
por parte del requirente sern:
Composicin del mensaje
Validacin del esquema de peticin (salida)
Cifrado del mensaje si procede
Firma de la peticin a enviar
Registro de la peticin
Envo de la peticin
Gestin de la respuesta (a definir en detalle)
Los tratamientos que se realizarn a la hora de recibir y procesar una peticin/solicitud
de datos por parte del emisor sern:
Recepcin del mensaje
Validacin de la Firma (autenticacin y autorizacin del requirente)
Descifrado del mensaje si procede
Validacin del esquema de peticin (entrada)
Registro de la peticin recibida
Gestin de la peticin recibida (Tratamiento de la solicitud)
Generacin de la respuesta con el Identificador nico de cada transmisin.
Envo de la respuesta (a definir en detalle)
Los tratamientos que se realizarn a la hora de enviar una respuesta/transmisin de
datos por parte del emisor sern:
Generacin de la respuesta con el Identificador nico la transmisin.
Composicin del mensaje de respuesta
Validacin del esquema de respuesta (salida)
Cifrado del mensaje si procede (Ver informacin a cifrar)
Firma de la respuesta a enviar (se firma la respuesta integra, nunca partes)
Registro de la Transmisin (Generacin de la traza correspondiente)
Envo de la respuesta.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
10 de 32
Protocolo SCSP v3
En el caso en el que se produzca un error en cualquiera de los pasos indicados por parte
del emisor se devolver una respuesta de tipo SOAP-FAULT. La especificacin de los
errores posibles se detalla en el documento de Especificacin de errores SOAPFAULT
SCSP v3. Si el procesamiento ha sido correcto se devolver en el nodo
peticionAtributosCodigoEstado el valor 0003 TRAMITADA.
Los tratamientos que se realizarn a la hora de recibir
respuesta/transmisin de datos por parte del requirente sern:
procesar
una
Recepcin del mensaje de respuesta

Validacin de la Firma (autenticacin y autorizacin del emisor)
Validacin del esquema de respuesta (entrada)
Gestin de la respuesta recibida (Tratamiento de la respuesta por el
organismo requirente)
Las operaciones de cifrado y descifrado son opcionales en funcin de las caractersticas de los
servicios, segn requieran confidencialidad extremo a extremo por parte del emisor.
El Organismo Emisor definir cual el su Tiempo Mximo de Respuesta en el funcionamiento
sncrono, tal que superado el mismo, si se diera el caso, no generara una transmisin vlida,
sino un error.
2.4.2 Funcionamiento Asncrono

Los tratamientos que se realizarn a la hora de enviar una peticin/solicitud de datos
asncrona por parte del requirente sern:
Composicin del mensaje
Validacin del esquema de peticin (salida)
Cifrado del mensaje si procede
Firma de la peticin a enviar
Envo de la peticin
Los tratamientos que se realizarn a la hora de recibir y procesar una peticin/solicitud
asncrona de datos por parte del emisor sern:
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
11 de 32
Protocolo SCSP v3
Gestin de la peticin recibida (Tratamiento de la solicitud y validaciones
especficas)
Generacin de mensaje de confirmacin de peticin indicando el Tiempo
Estimado de Respuesta (TER) en horas en las que podr estar disponible la
respuesta. El estado de la peticin devuelto ser 0002, EN PROCESO.
Composicin del mensaje de confirmacin de peticin
Validacin del esquema de confirmacin de peticin (salida)
Firma mensaje de confirmacin de peticin a enviar
Registro del mensaje (Generacin de la traza correspondiente)
Envo del mensaje de confirmacin de peticin
Los tratamientos que se realizarn a la hora de gestionar la confirmacin de peticin
remitida por el Emisor, por parte del requirente sern:
Gestin de la peticin recibida (Tratamiento de la solicitud y validaciones
especficas),
Actualizar el estado de la peticin a 0002, EN PROCESO.
Actualizar el valor de TER (Tiempo Estimado de Respuesta) para que el
mdulo de polling (del organismo requirente) solicite la respuesta.
Los tratamientos que se realizarn a la hora de solicitar una respuesta/transmisin de
datos por parte del requirente sern:
Verificar que ha vencido el Tiempo Estimado de Respuesta
Composicin del mensaje de Solicitud de respuesta
Validacin del esquema de Solicitud de respuesta (salida)
Firma de la Solicitud de respuesta a enviar
Registro de la
correspondiente)
Solicitud
de
respuesta
(Generacin
de
la
traza
Enviar un mensaje de Solicitud de Respuesta

Los tratamientos que se realizarn a la hora de recibir y procesar una Solicitud de
Respuesta por parte del emisor sern:
Recepcin del mensaje de Solicitud de Respuesta
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
12 de 32
Protocolo SCSP v3
Validacin de la Firma (autenticacin y autorizacin en el caso en el que

requirente es el mismo que hizo la peticin)
Validacin del esquema de Solicitud de Respuesta (entrada)
Registro del mensaje (Generacin de la traza correspondiente)
Gestin de la Solicitud de Respuesta recibida ( verificacin Tratamiento de la
respuesta por el organismo requirente)
Si la respuesta est disponible, se genera la respuesta completa. El valor
del atributo AtributosEstadoCodigoEstado ira fijado a 0003,
TRAMITADA.
Si la respuesta no est disponible se genera una respuesta con el nodo
Transmisiones vaco y se indicar un nuevo TER. El valor del atributo
AtributosEstadoCodigoEstado ira fijado a 0002 EN PROCESO.
Envo de la Respuesta
Los tratamientos que se realizarn a la hora de recibir
respuesta/transmisin de datos por parte del requirente sern:
procesar
una
Recepcin del mensaje de respuesta

Validacin de la Firma (autenticacin y autorizacin del emisor)
Validacin del esquema de respuesta (entrada)
Gestin de la respuesta recibida (Tratamiento de la respuesta por el
organismo requirente)
Si la respuesta es definitiva, procesaremos la respuesta entera y se
marcar como tramitada. En este caso el valor del atributo
AtributosEstadoCodigoEstado ira fijado a 0003 , TRAMITADA,
Si la respuesta no est disponible, actualizar la fecha del ltimo sondeo
y registrar el valor del nuevo TER que indica cuando deber volver a
enviar una nueva solicitud de respuesta. El valor del atributo
EstadoCodigoEstado ira fijado a 0002 en proceso.
En caso de error se registrar en el sistema. Los requirentes podrn
habilitar mecanismos de gestin de errores para reintentar una
comunicacin cuando el error obtenido sea subsanable (Error de
comunicaciones, errores temporales de sistemas, etc..)
Las operaciones de cifrado y descifrado son opcionales en funcin de las caractersticas de los
servicios, segn requieran confidencialidad extremo a extremo y as haya sido definido por el
emisor.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
13 de 32
Protocolo SCSP v3
3 Elementos estndar del sistema

Conforme a la especificacin funcional el sistema requiere de la definicin de una serie de
caractersticas esenciales que cualquier organismo ha de cumplir independientemente de que
realice su propia implementacin de la especificacin o utilice las libreras ya desarrolladaspor
el MPTAP.
Estas caractersticas esenciales abarcan desde especificaciones de arquitectura de sistema,
especificaciones de interoperabilidad en las comunicaciones hasta requisitos de seguridad y
trazabilidad. Seguidamente se resumen las caractersticas estndar y posteriormente se
detallarn en mayor medida.
3.1 SARA
Se plantea la opcin utilizacin preferente de la red SARA para realizar todas las
comunicaciones entre organismos requirentes y emisores. El uso de esta red es debido a la
seguridad ofrecida en las comunicaciones debido a que todas las comunicaciones van
encriptadas a nivel de enlace.
Un organismo Emisor podra, por necesidades de su negocio, ofrecer los servicios a travs de
otras redes, pblicas o privadas siendo el responsable de los mecanismos de seguridad que
deba exigir.
3.2 Protocolo de comunicaciones HTTPS

Adicionalmente al uso de la red SARA para asegurar las comunicaciones a nivel de transporte
entre los organismos, y permitir adicionalmente la identificacin de las partes intervenientes
en la comunicacin, las comunicaciones de los mensajes SOAP se realizarn a travs de SSL.
Siendo el protocolo de transporte elegido HTTP.
3.3 Uso de la firma digital para identificacin

Todas las comunicaciones realizadas entre un requirente y un emisor irn firmadas
digitalmente con el objetivo de garantizar la autenticacin (identificacin), no repudio e
integridad de la informacin intercambiada. El proceso de firma a realizar seguir las
siguientes pautas:
3.3.1 Certificados X509v3 reconocidos (y aceptados por @firma)

La firma se realizar utilizando certificados X509 versin 3 segn la normativa vigente.
Estos certificados identificarn a las mquinas de cada organismo (requirente o emisor)
intervinientes en la comunicacin. Siendo responsabilidad por tanto de cada organismo
de su uso.
Estos certificados podrn ser emitidos por cualquier Autoridad de Certificacin
reconocida tanto por el emisor como por el requirente.
3.3.2 Formato de firma
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
14 de 32
Protocolo SCSP v3
Por motivos de interoperabilidad con los estndares actuales ms modernos, se ha

optado por sustituir el mecanismo de firma basado en XML-DSig puro, por el
especificado dentro de la familia WS-Security. Se permitir, en caso de no necesitar
cifrado, por temas de compatibilidad hacia atrs, el usar versin 3 de SCSP con
XMLDsig aunque no es la opcin recomendada.
Se seguirn utilizando los mismos algoritmos matemticos que en la versin 2 si bien
los sistemas debern estar preparados para soportar algoritmos ms seguros de firma y
huella digital (digest).
A continuacin se detallan los algoritmos usados para el proceso de firmado, incluyendo
los algoritmos relacionados con las transformaciones, procesos de canonicalizacin,
etc.. involucrados en la misma.
Se firmar todo el body, no descartndose, que por motivos de cada servicio,
adicionalmente se deba firmar algn otro elemento. Los objetos firmados sern la
Peticin, y la Respuesta.
Los algoritmos utilizados en el proceso de firma sern:
DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
SignatureMethod Algorithm= http://www.w3.org/2000/09/xmldsig#rsa-sha1
CanonicalizationMethod Algorithm= http://www.w3.org/2001/10/xml-exc-c14n#
Aunque existen otros mecanismos definidos por el estndar WS-Security, el mecanismo
de acceso a los elementos de seguridad (utilizados para la firma y el cifrado en WSsecurity) ser por referencia a un BinarySecurityToken
(wsse:SecurityTokenReference).
El formato de firma digital, en el caso de utilizar XML-Dsig ser el XML Digital Signatura
definido por la W3C (http://www.w3.org/TR/xmldsig-core/). Donde el algoritmo de
canonicalizacin y transformacin a utilizar por razones de interoperabilidad ser
http://www.w3.org/2001/10/xml-exc-c14n.
3.3.3 Modificacin del Formato de firma

Por motivos de seguridad se podran cambiar los mecanismos relativos a la firma,
algoritmos de huella, firma, etc.
En caso de que sea necesario este cambio se acordar mediante el grupo de trabajo de
Sustitucin de certificados/intercambio de datos buscando una amplia aceptacin.
En cualquier caso, los formatos de firma indicados son un conjunto mnimo, pudiendo
un emisor aceptar libremente ms formatos de firma, siempre que sean reconocidos por
la poltica de firma del organismo, siendo igualmente vlidos.
3.4 Uso de esquemas

Cualquier organismo que decida realizar la implementacin de estas especificaciones deber
adecuar el formato de los mensajes intercambiados a los esquemas definidos en el presente
documento. Dicha definicin se encuentra en el apartado 9 de este documento. El objeto de
estos esquemas es determinar el formato de los mensajes intercambiados y supone un
estndar de comunicacin para el intercambio de datos entre requirentes y emisores.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
15 de 32
Protocolo SCSP v3
3.4.1 Espacio de nombres

Debido a la desaparicin del Ministerio de Administraciones Pblicas, y con el objetivo
de obtener un lugar de referencia para poder ubicar los esquemas de SCSP se ha
www.map.es
por
decidido
sustituir
los
namespaces
referentes
a
intermediacion.redsara.es para hacerlos independientes de la nomenclatura de los
organismos que los usan, e indicar el hecho de que la versin soportada es adecuada
para la intermediacin.
Tambin se ha cambiado el versionado de los esquemas, dejndose intactos los datos
especficos, que dependen de cada negocio.
A este objeto se ha elegido como raz la siguiente URI:
http://intermediacion.redsara.es/scsp/esquemas/
A partir de esta referencia, y actualizando el ndice de versin V3 (versin 3) de los
esquemas, se tienen los siguientes namespaces de uso obligatorio:
Mensajes generales:
Peticin http://intermediacion.redsara.es/scsp/esquemas/V3/peticion/
Confirmacin http://intermediacion.redsara.es/scsp/esquemas/V3/confirmacionPeticion/
Solicitud de Respuesta http://intermediacion.redsara.es/scsp/esquemas/V3/solicitudRespuesta/
Respuesta http://intermediacion.redsara.es/scsp/esquemas/V3/respuesta
Soap Fault Atributos http://intermediacion.redsara.es/scsp/esquemas/V3/soapfaultatributos/
Mensajes Especficos:
Datos Especficos http://intermediacion.redsara.es/scsp/esquemas/datosespecificos
3.5 Mecanismo de autorizacin

Los organismos emisores tienen que disponer de mecanismos que permitan la definicin de
polticas de autorizacin para el control de los requirentes a la hora de solicitar un certificado.
De tal forma se define la necesidad de la existencia dentro del organismo emisor de un sistema
para la autorizacin de los requirentes, ya sea a travs de una tabla de autorizaciones o
haciendo uso de cualquier otro mecanismo.
El objetivo es autorizar a los requirentes a pedir slo los certificados a los cuales se les habilita
y no a otros.
3.5.1 Alternativas de autorizacin

Con el fin de tener una amplia capacidad de autorizacin se tendrn en cuenta los
siguientes elementos a la hora de autorizar el acceso a un servicio
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
16 de 32
Protocolo SCSP v3
Canal de comunicacin mediante identificacin SSL de cliente

Firma electrnica de las peticiones
Atributos
especficos
del
(IdentificadorSolicitante)
solicitante
definidos
en
el
protocolo
Otros atributos contemplados en el mensaje de peticin.

Se recomienda ser lo suficientemente flexibles como para permitir la prestacin de
servicios por Nodos de Interoperabilidad.
3.5.2 Nodos de interoperabilidad

Cuando un Organismo preste servicios como nodo de interoperabilidad reconocido en
el ENI RD 4/2010, firmar las peticiones con un certificado que le identifique a l como
requirente o emisor segn el caso.
En el caso de comportarse como requirente, el campo IdentificadorSolicitante llevar el
NIF/CIF del organismo cesionario que usa los servicios del nodo de interoperabilidad.
En las etiquetas:
NombreSolicitante Nombre del organismo cesionario que solicita los datos
UnidadTramitadora Unidad gestora del Organismo Cesionario
3.6 Identificadores de peticin

Para poder realizar una trazabilidad de las peticiones tanto recibidas como emitidas en un
requirente o emisor, se define un identificador de peticin que servir cmo identificador nico
de una transmisin emitidas desde un requirente a un emisor o a la inversa.
Para garantizar la unicidad de los identificadores de peticin para todos los organismos
requirentes de un servicio este Identificador deber tener una parte que identifique
unvocamente al organismo.
Como recomendacin, dicho identificador de peticin estar formado por la concatenacin de:
Nmero de serie del certificado digital X509 con el que se firman las peticiones
(codificado en hexadecimal, maysculas y sin espacios en blanco)
Huella del certificado
Un identificador nico del organismo (por ejemplo el acrnimo del organismo)
y un nmero secuencial de peticin y cuya longitud total no exceda de la longitud del campo.
El nmero secuencial podr ser alfanumrico.
ste identificador de peticin nico ser generado por el organismo requirente para
identificar sus peticiones siendo necesario que el organismo emisor almacene dicho
identificador junto con la peticin para mantener la trazabilidad de las peticiones.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
17 de 32
Protocolo SCSP v3
3.6.1 Identificadores de solicitud

Dentro de cada peticin, podrn ir una o ms solicitudes. En el caso de peticiones
sncronas solo habr una solicitud. En el caso de peticiones asncronas, podrn ir mas
solicitudes y existir un identificador nico de cada solicitud por cada peticin generada.
3.6.2 Identificadores de transmisin

En la peticin, dentro de cada solicitud, este valor ser nulo.
En la respuesta, para garantizar los mecanismos de auditora y trazabilidad, el emisor
generar un Identificador nico de cada transmisin realizada por l, para cada tipo de
certificado. Este identificador nico se podr usar a modo de cdigo seguro de
Verificacin o referencia de la transmisin realizada por el emisor y podr ser
verificada por los rganos de fiscalizacin, control y auditora correspondientes.
3.7 Seguridad y trazabilidad

Todos los organismos tanto requirentes como emisores debern acogerse al documento de
seguridad y trazabilidad definido e incluido en sta especificacin tcnica con el objeto de
garantizar la auditora del sistema.
3.8 Obligaciones de interoperabilidad

Debido a las diferentes tecnologas existentes en la actualizar cualquiera de los servicios
ofrecidos por un emisor han de cumplir con una serie de requisitos de interoperabilidad.
Los requisitos mnimos que han de ofrecer los servicios son:
Dentro del fichero de definicin del servicio (WSDL) se incluirn las referencias import
a los esquemas peticin, respuesta, solicitud de respuesta, confirmacin de peticin y
datos especficos. Igualmente los esquemas que definen el formato de los mensajes
intercambiados no debern incluir sentencias import a otros esquemas distintos de los
especificados en este documento.
Algoritmo de transformacin y canonicalizacin. Es necesario que el algoritmo sea
http://www.w3.org/2001/10/xml-exc-c14n.
Los servicios publicados cumplirn el estndar WS-I de interoperabilidad de servicios.
3.9 Cifrado de Mensajes

Los mecanismos de cifrado se utilizarn en aquellas situaciones que el emisor lo considere necesario por
motivos de confidencialidad de la informacin a intercambiar. En el caso de ser necesario cifrar los
mensajes, el mecanismo de firma ser obligatoriamente ws-security y el de cifrado WS-Encryption
Por defecto, el cifrado ir siempre en la respuesta cuando se considere necesario, aunque por necesidades
del servicio se podra aplicar a cualquier mensaje intercambiado, y se cifrar exclusivamente aquella
informacin especialmente sensible que se quiera proteger. Por regla general se cifrar el contenido del
nodo <datos especficos> en peticiones sncronas con una nica solicitud, tal y como se muestra en los
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
18 de 32
Protocolo SCSP v3
ejemplos posteriores, no siendo obligatorio el cifrado en ningn caso sino potestad del organismo que
presta el servicio.
En la peticiones/respuestas asncronas (usadas generalmente para una peticin con mltiples solicitudes)
se cifrar el nodo Solicitudes/Transmisiones, respectivamente.
Los nodos posibles para ser cifrados son los siguientes:
Peticion.xsd Solicitudes
Respuesta.xsd Transmisiones
Datos-Especificos.xsd DatosEspecificos
solicitud-respuesta.xsd SolicitudRespuesta
confirmacin-peticion.xsd Confirmacionpeticin.
Se incluye un atributo opcional (Id) en estos elementos susceptibles de ser cifrados para agilizar las
bsquedas por referencia en lugar de por Xpath.
<xs:attribute name="Id" type="xs:string" use="optional"/>

Ya que todos los mensajes intercambiados son bilaterales, el mensaje ir cifrado para un nico
destinatario, no soportndose el cifrado para varios destinatarios en un mismo mensaje.
El mecanismo de cifrado es el siguiente:
1) El organismo que deba cifrar la informacin, generar una clave simtrica utilizando el algoritmo
AES 128. (Las implementaciones debern soportar longitudes mayores para cuando se recomiende
el cambio por motivos de seguridad, por ejemplo AES 256)
Algorithm= http://www.w3.org/2001/04/xmlenc#aes128-cbc
2) Se cifrar el contenido del nodo datos especficos en el caso de peticiones sncronas. En la
peticiones/respuestas asncronas (usadas generalmente para una peticin con mltiples
solicitudes) se cifrar el nodo Solicitudes/Transmisiones.
3) El organismo cifrar la clave simtrica anteriormente generada, utilizando el algoritmo asimtrico
rsa, para garantizar la confidencialidad hacia el solicitante de la informacin. Para ello utilizar la
clave pblica extrada del certificado con el que se firm la peticin. No se soportar enviar otra
informacin adicional no relacionada con el requirente. El algoritmo utilizado sera:
Algorithm= http://www.w3.org/2001/04/xmlenc#rsa-1_5
4) Se compondrn los tokens de seguridad necesarios y el mensaje segn el formato acordado como
se describe a continuacin.
5) Una vez cifrado el mensaje, es cundo se procede a la firma del mismo (y no antes). De esta
forma se garantiza la integridad de la transmisin y la confidencialidad extremo a extremo de la
misma.
3.9.1 Tokens de seguridad ws-security

El mecanismo de acceso a los elementos de seguridad utilizados para la firma y el cifrado en WSsecurity ser por referencia a un BinarySecurityToken.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
19 de 32
Protocolo SCSP v3
A continuacin se recoge el formato de estos elementos:

SecurityTokenReference
<wsse:SecurityTokenReference
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-utility-1.0.xsd wsu:Id="STRId-2056288912">
<wsse:Reference URI="#CertId-15915065" VALOR DE LA REFERENCIA DEL CERTIFICADO
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile1.0#X509v3"/></wsse:SecurityTokenReference>
BinarySecurityToken
<wsse:BinarySecurityToken
wssecurity-utility-1.0.xsd
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
EncodingType=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0#Base64Binary
ValueType=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
wsu:Id="CertId-15915065" Referencia del certificado> VALOR DEL CERTIFICADO USADO PARA
LA FIRMA </wsse:BinarySecurityToken>
EncryptedKey- Clave simtrica cifrada asimtricamente
<xenc:EncryptedKey Id="EncKeyId-22EFAB4BB8C7B31B6612452246585372">
<xenc:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-1_5/>
<ds:KeyInfo xmlns:ds=http://www.w3.org/2000/09/xmldsig#>
<wsse:SecurityTokenReference>
<wsse:Reference
URI="#22EFAB4BB8C7B31B6612452246584411"
open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
ValueType="http://docs.oasis-
</wsse:SecurityTokenReference>
</ds:KeyInfo><xenc:CipherData>
<xenc:CipherValue>KJSAriyP VALOR DE LA CLAVE CIFRADA teBoE=</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList> LISTA DE ELEMENTOS CIFRADOS CON ESTA CLAVE
<xenc:DataReference URI="#EncDataId-632300976"/></xenc:ReferenceList>
</xenc:EncryptedKey>
4 Mensajes intercambiados
4.1 Mensaje de Peticin SCSPv3
A continuacin se recoge el esquema de peticin SCSPv3.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
20 de 32
Protocolo SCSP v3
Como se aprecia en la Figura 1.- Peticin SCSPv3, la peticin estar formada por dos ramas de
informacin, la rama definida como Atributos, y la de Solicitudes.
Figura 1.- Peticin SCSPv3
La rama Atributos, contiene los datos de control relativos a toda la peticin.

La rama Solicitudes contiene las Solicitudes de Transmisin (Nodo SolicitudTransmision)
formadas por el bloque DatosGenericos y el bloque DatosEspecficos.
La estructura de DatosGenericos recoge todas las consideraciones legales a tener en cuenta
en la transmisin de datos entre Administraciones, registrando la informacin relativa a:
Emisor: Se refiere al organismo que proporciona la informacin
Solicitante: Se refiere al Organismo que solicita la informacin
Titular: Se refiere al administrado sobre quien se recaba Informacin
Transmisin: Se refiere a la transmisin concreta realizada
La estructura de DatosEspecficos en la entrada contendr los parmetros especficos de
cada servicio, y ser definida por el emisor.
4.1.1 Emisor
La identificacin del Emisor estar formada por el Nif del emisor y su Nombre.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
21 de 32
Protocolo SCSP v3
Es responsabilidad del requirente completar adecuadamente esta informacin ya que

podra ser validada por el emisor y causa de rechazo de peticiones.
Figura 2.- Datos del Emisor
4.1.2 Solicitante
La identificacin del Solicitante estar formada por los siguientes campos:
IdentificadorSolicitante: Nif del organismo solicitante de la Informacin
NombreSolicitante: Nombre del Organismo que solicita los datos.
UnidadTramitadora: Se corresponder con la unidad de gestin autorizada a
realizar la consulta y responsable de la tramitacin administrativa a la que se
refiere la consulta y la transmisin de datos. Tiene que tener la competencia
del Procedimiento indicado en la solicitud.
IdExpediente: Nmero de expediente, si lo hay, por el cual se realiza la
consulta.
CodProcedimiento: Cdigo del
usuario/organismo a efectuar
estandarizados (SIA en el caso
organismo emisor en funcin
pudiera implementar)
Procedimiento para el que se autoriza al

la consulta. Se recomienda usar cdigos
de la AGE, aunque depender del criterio del
de los procedimientos de autorizacin que
NombreProcedimiento: Nombre del Procedimiento para el que se autoriza al

organismo a efectuar la consulta
Funcionario: Datos identificativos del Funcionario
Consentimiento: Indica si se tiene consentimiento o no es necesario (consulta
por ley)
Finalidad: Indica la descripcin de la finalidad de la consulta. Complementario a
la informacin relativa al procedimiento.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
22 de 32
Protocolo SCSP v3
Figura 3.- Datos del Solicitante
4.1.3 Titular
La identificacin del titular estar formada por los siguientes campos en la parte
genrica:
TipoDocumentacion: Tipo de documentacin identificativa (Los valores
aceptados a fecha 31-07-2011 son DNI, NIE, CIF, NIF o pasaporte) En caso de
que se considerara otro valor se tendra que evaluar. No todos los valores
estn soportados por los distintos servicios/negocios teniendo que concretar en
cada caso.
Documentacion: Indicar el valor de la documentacin identificativa del titular
sobre el que se quiere consultar la informacin. Los formatos sern los oficiales
en cada caso concreto, como se indica en la tabla referente a formatos de los
mensajes.
NombreCompleto: Se recomienda usarlo slo en el caso de Personas Jurdicas.
En el caso de personas fsicas se recomienda usar las etiquetas Nombre, y
Apellido[1|2]. El organismo emisor puede establecer la obligatoriedad de incluir
estos campos.
Nombre: Nombre del titular de la solicitud. Se recomienda usar el mismo
nombre que aparece oficialmente en la documentacin acreditativa de la
identidad de la persona, DNI, NIE, etc..
Apellido1: Primer Apellido del titular de la solicitud. Se recomienda usar el
mismo nombre que aparece oficialmente en la documentacin acreditativa de
la identidad de la persona, DNI, NIE, etc..
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
23 de 32
Protocolo SCSP v3
Apellido2: Segundo Apellido del titular de la solicitud. Se recomienda usar el

mismo nombre que aparece oficialmente en la documentacin acreditativa de
la identidad de la persona, DNI, NIE, etc.. si existe.
Figura 4.- Datos del titular

En caso de necesitar ms elementos identificativos del Titular, u otro dato de inters se tendr
que recoger en la parte de datos especficos.
En el caso en el que se quiera prestar servicio permitiendo identificar al titular por otros
elementos unvocos distintos de la documentacin (y otros atributos necesarios) podra
hacerse siendo responsabilidad del emisor ofrecer el servicio, as como la validacin de que los
datos indicados para la identificacin sean nicos. (Apellidos, fecha de nacimiento, lugar de
nacimiento, etc...)
4.1.4 Transmisin
La identificacin de la transmisin efectivamente realizada estar formada por los
siguientes campos en la parte genrica:
CodigoCertificado: Cdigo nico que identifica el certificado o trasmisin de
datos solicitada. Debe coincidir con el indicado en el nodo atributos.
IdSolicitud: Identificador nico de la solicitud incluido en la transmisin de
datos. Lo indica el Requirente.
IdTransmision: Identificador nico de la transmisin enviada por el emisor. En
la peticin vendr vaco siendo ignorado por el emisor en otro caso. Permitir
acceder a los datos de las transmisiones efectuadas por parte de los rganos
de fiscalizacin a modo de CSV.
FechaGeneracion: Indica la fecha en la que se gener la transmisin de datos.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
24 de 32
Protocolo SCSP v3
Figura 5.- Datos de la transmisin
Se deber ofrecer un mecanismo a los rganos de fiscalizacin y control para la

validacin de la transmisin efectuada para un NIF concreto.
4.2 Mensaje de Respuesta SCSPv3

A continuacin se recoge el esquema de respuesta SCSPv3.
Como se aprecia en la Figura 6.- Respuesta SCSPv3. Mensaje de Respuesta SCSPv3, la
respuesta estar formada por dos ramas de informacin, la rama definida como Atributos, y
la de Transmisiones.
Figura 6.- Respuesta SCSPv3
La rama Atributos, contiene los datos de control relativos a toda la respuesta.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
25 de 32
Protocolo SCSP v3
La rama Transmisiones contiene las Transmisiones de Datos (Nodo TransmisionDatos)

formadas por el bloque DatosGenericos y el bloque DatosEspecficos.
La estructura de DatosGenericos recoge todas las consideraciones legales a tener en cuenta
en la transmisin de datos entre Administraciones, registrando la informacin relativa a:
Emisor: Se refiere al organismo que proporciona la informacin
Solicitante: Se refiere al Organismo que solicita la informacin
Titular: Se refiere al administrado sobre quien se recaba Informacin
Transmisin: Se refiere a la transmisin concreta realizada
La estructura de DatosEspecficos en la respuesta contendr los parmetros especficos de
cada servicio, y ser definida por el emisor.
Salvo que se produzca un error, los datos relativos la parte genrica el emisor podr responder
con los enviados por el requirente.
En caso de que los datos que se envan en la peticin no fueran informados, y cuando existan
en el emisor y sean relevantes para el servicio, se deben rellenar adecuadamente por el
Emisor.
Este comportamiento permitir validar la calidad de las respuestas.
4.2.1 Emisor
Ver apartado 4.1.1 Emisor
4.2.2 Solicitante
Ver apartado 4.1.2 Solicitante
4.2.3 Titular
Ver apartado 4.1.3 Titular
4.2.4 Transmisin
Ver apartado 4.1.3 Transmisin
La identificacin de la transmisin efectivamente realizada estar formada por los
siguientes campos en la parte genrica:
CodigoCertificado: Cdigo nico que identifica el certificado o trasmisin de
datos solicitada. Debe coincidir con el indicado en el nodo atributos.
IdSolicitud: Identificador nico de la solicitud incluido en la transmisin de
datos. Lo indica el Requirente.
IdTransmision: Identificador nico obligatorio de la transmisin enviada por el
emisor. En la peticin vendr vaco siendo ignorado por el emisor en otro caso.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
26 de 32
Protocolo SCSP v3
Permitir acceder a los datos de las transmisiones efectuadas por parte de los
rganos de fiscalizacin a modo de CSV.
FechaGeneracion: Indica la fecha en la que se gener la transmisin de datos.
Figura 7.- Datos de la transmisin en la respuesta
Se deber ofrecer un mecanismo a los rganos de fiscalizacin y control para la

validacin de la transmisin efectuada para un NIF concreto.
4.3 Mensaje de Confirmacin de peticin SCSPv3

A continuacin se recoge el mensaje de confirmacin de peticin SCSPv3.
Este mensaje es igual que en SCSPv2 (salvo el namespace). Se usar en los servicios
asncronos como respuesta al mensaje de peticin para indicar el tiempo en el que podra estar
disponible la respuesta con las transmisiones de datos solicitadas
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
27 de 32
Protocolo SCSP v3
Figura 8.- Confirmacin de peticin

Como se aprecia en la Figura 8.- Confirmacin de peticin., la respuesta estar formada por
una rama de informacin, la rama definida como Atributos.
Los atributos son los relativos a la peticin recibida:
IdPeticion: Identificador de la peticin realizada de transmisin de datos.
NumElementos: Indica el nmero de elementos que forman parte de la peticin. Debe
coincidir con los indicados en la respuesta y con el nmero de solicitudes y
transmisiones a intercambiar.
TimeStamp: Marca de tiempo en la que se ha realizado la confirmacin de peticin.
Formato: AAAA-MM-DDThh:mm:ss.mmmhh:mm
Estado: Bloque con la informacin de control. Si no se ha producido ningn error su
valor ser 0002 EN PROCESO. Si se ha producido un error, indicar el error
correspondiente.
CodigoCertificado: Se refiere al Certificado de datos al que sustituye la transmisin.
4.4 Mensaje de Solicitud de respuesta SCSPv3

A continuacin se recoge el mensaje de solicitud de respuesta SCSPv3.
Este mensaje es igual que en SCSPv2. Se usar en los servicios asncronos como respuesta al
mensaje de peticin para indicar el tiempo en el que podra estar disponible la respuesta con
las transmisiones de datos solicitadas
Figura 9.- Solicitud de respuesta
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
28 de 32
Protocolo SCSP v3
Como se aprecia en la Figura 9.- Solicitud de respuesta, la Solicitud de respuesta estar

formada por una rama de informacin Atributos.
Los atributos son los relativos a la peticin enviada:
IdPeticion: Identificador de la peticin realizada de transmisin de datos.
NumElementos: Indica el nmero de elementos que forman parte de la peticin. Debe
coincidir con los indicados en la peticin, en la respuesta y con el nmero de solicitudes
y transmisiones a intercambiar.
TimeStamp: Marca de tiempo en la que se ha realizado la solicitud de respuesta.
Formato: AAAA-MM-DDThh:mm:ss.mmmhh:mm
Estado: Bloque con la informacin de control. En este mensaje debe No debe ir
informado.
CodigoCertificado: Se refiere al Certificado de datos al que sustituye la transmisin.
4.5 Datos Especficos

Si bien no es un mensaje concreto sino un componente general que puede ser incluido
tanto en el mensaje de peticin como en el de respuesta, se analizan las
caractersticas generales que deben cumplir los datos especficos, as como las
recomendaciones al respecto para una mejor implementacin.
Los datos especficos se definirn bajo un nico namespace, tanto si se
incluyen en la peticin, en la respuesta o en ambos casos.
En caso de implementarse en un nico fichero y ser requerido tanto en la
peticin como en la respuesta se optar por una estructura de tipo switch
para indicar que en cada caso solo pueden venir los datos de entrada o la
respuesta.
Si los parmetros de entrada se quieren devolver en la respuesta, la parte de
respuesta debera quedar como opcional y validarse por parte del emisor que
cuando se reciba en la entrada debe ignorarse o generarse el error
correspondiente.
Se recomienda incluir un indicador de Negocio del estado del tratamiento de
cada solicitud/transmisin conteniendo los datos especficos de cada negocio.
En relacin al tratamiento asncrono este indicador permitir devolver el

estado de cada peticin incluso en el caso de que produzca un fallo en el
tratamiento.
En caso de no incluirse, en el procesamiento asncrono implicar que si

falla una de las solicitudes/transmisiones, deber fallar toda la
peticin/transmisin de datos, generando un SOAPFAULT.
5 Gestin de Errores
Se entender que no se ha producido un error cuando no ha fallado ningn sistema,
mecanismo de comunicacin o similar, aunque la operacin solicitada (Consulta de datos,
Actualizacin de datos) no se haya podido realizar. Es decir cuando es una casustica
contemplada en el Negocio. En estos casos, casustica de Negocio, la respuesta generada
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
29 de 32
Protocolo SCSP v3
seguir las especificaciones generales del modelo de intercambio de informacin SCSP,

especificado en los mensajes de respuesta.
Se devolver un mensaje SOAP Fault cuando el error detectado pertenezca a alguno de los
siguientes tipos:
Error de conexin a la BD.
Error de conexin a la sistemas externos (@Firma, CICS, Servidores Externos, etc).
Error en la validacin de esquemas (o peticin recibida sin firma).
Error por Validacin de la Firma digital, o problemas en la autorizacin y autenticacin.
No estar firmado alguno de los mensajes, peticin, respuesta, confirmacin de peticin
o solicitud de respuesta.
Certificado caducado, revocado o no vlido
Error del Sistema Interno en el tratamiento de la peticin.
Los mensajes SoapFault no se firmarn.
En el resto de casos, no contemplados en la lista anterior, se entender que la peticin se ha
podido tramitar y se devolver un mensaje de Respuesta especificando en las etiquetas
correspondientes el cdigo y el texto del error o estado correspondiente (una vez mapeado) al
considerarse una respuesta contemplada por el negocio.
Este apartado se desarrolla en profundidad en el documento:

Especificacion-SCSP_v3_SOAPFAULT.doc
6 Anexo I: WSDL y XSD (Formatos y Esquemas)

Este apartado se desarrolla en profundidad en el documento
Especificacion-Funcional_Esquemas_formatos_SCSP_v3.doc
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
30 de 32
Protocolo SCSP v3
7 Anexo II: Definiciones relevantes

CAID: Centro de Atencin a Integradores y Desarrolladores del Ministerio de Poltica
Territorial y Administracin Pblica de la Plataforma de Intermediacin.
Cedente: Organismo que proporciona datos y responsable de los mismos segn la
LOPD. Ofrecer los datos a travs de un Emisor SCSP.
Cesionario: Organismo que Solicita los datos en virtud de un procedimiento o trmite.
Consumir los datos/transmisiones a travs de un requirente.
Emisor: Organismo que proporciona el servicio SCSP para la transmisin de datos.
Nodo de Interoperabilidad: (Segn el RD4/2010) Organismo que presta servicios
de interconexin tcnica, organizativa y jurdica entre sistemas de informacin para un
conjunto de Administraciones Pblicas bajo las condiciones que stas fijen. Podr ser en
este caso tanto requirente como emisor de datos.
Plataforma de Intermediacin: Sistema que facilita la interoperabilidad entre
Organismos Cesionarios y Cedentes de datos cumpliendo las especificaciones de
Sustitucin de Certificados en Soporte Papel.
Procedimiento administrativo: proceso mediante el cual un rgano administrativo
adopta decisiones sobre las pretensiones formuladas por la ciudadana o sobre las
prestaciones y servicios cuya satisfaccin o tutela tiene encomendadas. Estar regulado
por una Norma que implicar la necesidad de conocer o consultar los datos requeridos y
que es exigida como requisito para otorgar en el acceso dicha consulta de datos.
Requirente: Organismo que consume el servicio SCSP para la solicitud y transmisin
de datos.
Servicio pblico: cualquier actividad realizada por la Administracin Pblica dirigida a
la ciudadana para satisfacer sus necesidades, derechos u obligaciones.
Un servicio puede estar asociado con uno o varios procedimientos administrativos o,
por el contrario, no tener relacin alguna.
Solicitud de Consentimiento: La solicitud de consentimiento para consultar datos de
carcter personal debe ser acorde a lo recogido en la LOPD y normativa vinculante al
intercambio de datos entre Administraciones. (Ley 11/2007 Art 6.2b, RD 1672/2009 Art
2). El derecho se ejercitar de forma especfica e individualizada para cada
procedimiento concreto, sin que el ejercicio del derecho ante un rgano u organismo
implique un consentimiento general referido a todos los procedimientos que aquel
tramite en relacin con el interesado.
Trmite o fase: actividad o grupo de actividades relacionadas entre s que tienen por
objeto cumplir una misma funcin concreta dentro de cada una de las fases del
procedimiento. El trmite est constituido por un conjunto de actuaciones dentro de un
procedimiento, con sustantividad propia, por lo que genera efectos jurdico-procesales.
Unidad de Auditoras: (Responsable de Auditora) Ser la unidad encargada de la
realizacin de las tareas de Auditoras, tanto en el Organismo Cedente como en el
Cesionario.
Unidad Responsable de Autorizacin: Unidad de gestin perteneciente al
Organismo Cesionario que autoriza en el Organismo Cesionario la consulta de datos
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
31 de 32
Protocolo SCSP v3
para el procedimiento o trmite en virtud del cual se solicita la informacin a las

distintas Unidades Tramitadoras.
La unidad Responsable de Autorizacin podr aplicar el control centralizado o distribuido
Unidad Tramitadora: Unidad de gestin perteneciente al Organismo Cesionario que
tramita el procedimiento o trmite en virtud del cual se solicita la informacin.
Autor/Editor
Nombre fichero:
MINHAP
Versin
1.1
Fecha
16/09/2012
Hoja
32 de 32

Especificacion Funcional Del Protocolo de Sustitucion de Certificados en Soporte Papel SCSPv3

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Especificacion Funcional Del Protocolo de Sustitucion de Certificados en Soporte Papel SCSPv3

Загружено:

Авторское право:

Доступные форматы

Especificacin Funcional del

Sustitucin de Certificados en Soporte Papel

Especificacin Funcional del protocolo SCSP

Divisin de Proyectos de Administracin Electrnica- MINHAP

Historia del Documento

Creacin 1 versin consolidada de SCSPv3 partiendo de

Correccin de errores en algunas etiquetas, referencias al

ET_elimin_certificados_2-7 con control de

Especificacin tcnica SCSP v2

Especificacin funcional SCSP v2

Especificacin de cambios de SCSPv2 a

Especificacion SOAP Fault_v1.01.doc

Descripcin de los esquemas (ficheros

DESCRIPCIN DEL PROTOCOLO SCSP ................................................................................................. 6

ELEMENTOS ESTNDAR DEL SISTEMA ............................................................................................... 14

MENSAJES INTERCAMBIADOS ................................................................................................................ 20

DATOS ESPECFICOS ....................................................................................................................................... 29

GESTIN DE ERRORES ................................................................................................................................ 29

ANEXO I: WSDL Y XSD (FORMATOS Y ESQUEMAS).................................................................... 30

ANEXO II: DEFINICIONES RELEVANTES .......................................................................................... 31

de SCSPv2 vigente desde el ao 2006 en su uso en

Consulta de estar al corriente de Deuda con la TGSS

V2 con namespace de datos especficos no estndar

No compatible V2 en la respuesta y DatosEspecificos

V3 con firma XMLDsig

Ver la Nota de versiones con el detalle de dichos cambios.

Incorpora la posibilidad de cifrado en las respuestas, mecanismo solicitado por algunos

2 Descripcin del protocolo SCSP

Especificacion-Funcional_Esquemas_formatos_SCSP_v3.doc Descripcin de los

2.1 Caractersticas Generales del Protocolo SCSP

2.2 Roles definidos en el protocolo

Se entiende por Requirente al organismo encargado de pedir la informacin. Se

2.3 Modos de funcionamiento del protocolo

El nodo solicitudes estar compuesto por la lista de solicitudes de transmisin,

2.4 Tratamiento de las transmisiones de datos por parte de

La conservacin de la informacin mediante mecanismos de almacenamiento y

2.4.1 Funcionamiento Sncrono

Recepcin del mensaje de respuesta

2.4.2 Funcionamiento Asncrono

Enviar un mensaje de Solicitud de Respuesta

Validacin de la Firma (autenticacin y autorizacin en el caso en el que

Recepcin del mensaje de respuesta

3 Elementos estndar del sistema

3.2 Protocolo de comunicaciones HTTPS

3.3 Uso de la firma digital para identificacin

3.3.1 Certificados X509v3 reconocidos (y aceptados por @firma)

3.3.2 Formato de firma

Por motivos de interoperabilidad con los estndares actuales ms modernos, se ha

3.3.3 Modificacin del Formato de firma

3.4 Uso de esquemas

3.4.1 Espacio de nombres

3.5 Mecanismo de autorizacin

3.5.1 Alternativas de autorizacin

Canal de comunicacin mediante identificacin SSL de cliente

Otros atributos contemplados en el mensaje de peticin.

3.5.2 Nodos de interoperabilidad

3.6 Identificadores de peticin

3.6.1 Identificadores de solicitud

3.6.2 Identificadores de transmisin

3.7 Seguridad y trazabilidad

3.8 Obligaciones de interoperabilidad

Los servicios publicados cumplirn el estndar WS-I de interoperabilidad de servicios.

3.9 Cifrado de Mensajes