E s tá n d a r p a r a e l i n te r c a mb i o d e S i s te …...Secretaría de la Función...

|

Secretaría de la Función Pública

Estándar para el intercambio de Sistemas Automatizados de Control de Gestión

Fecha: 12 de noviembre 2018

1

|


Formato G10-F01 Especificación Técnica

Contenido

1. Objetivo del documento

2. Descripción del estándar de oficio electrónico

3. Descripción de los Códigos generales de error que se presentarán en los diversos escenarios de Interoperabilidad

4. Descripción de los Códigos de error que se presentarán en los diversos escenarios de Interoperabilidad

5. Servicios de Interoperabilidad

6. Operaciones de Interoperabilidad

7. Seguridad y conectividad

Objetivo del documento El presente documento tiene por objeto definir, conforme a lo establecido en el artículo décimo tercero del Acuerdo por el que se establece el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal, publicado en el Diario Oficial de la Federación el 6 de septiembre de 2011, las especificaciones técnicas básicas que las Instituciones de la Administración Pública Federal, así como la Procuraduría General de la República, deberán observar para garantizar el intercambio de información en sus sistemas automatizados de control de gestión.

2

|


Antecedente El Acuerdo Secretarial por el que se establece el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal (EIDA), publicado en el Diario Oficial de la Federación (DOF), el 6 de septiembre de 2011, es la base que integra las operaciones de la Administración Pública Federal (APF), con el fin de ofrecer mejores servicios públicos, ejerciendo un gobierno más eficiente, así como apoyando la construcción, protección y mejora del acceso a los bienes públicos de información. La Ley de Firma Electrónica Avanzada publicada en el DOF el 11 de enero de 2012 y su Reglamento, tienen el objeto de regular el uso de la firma digital y de los medios electrónicos en los actos jurídicos, de comunicaciones, procedimientos administrativos, trámites y prestación de servicios que realicen los servidores públicos de la APF en el ámbito de sus atribuciones, entre sí y con los particulares. El 28 de mayo de 2012, la Unidad de Gobierno Digital da a conocer la primer versión del Documento Técnico de Interoperabilidad de los Sistemas Automatizados de Control de Gestión (DTISACG) mismo que sienta las bases para el modelo de interoperabilidad del gobierno mexicano alineado al EIDA. Las Dependencias y Entidades de la APF, así como la Procuraduría General de la República (PGR) deberán apegarse al EIDA para la integración de los sistemas automatizados de control de gestión con que operan y el 21 de noviembre de 2012 publicó una versión actualizada. El 3 de julio de 2015, la Secretaría de Gobernación mediante el Archivo General de la Nación, publicó los Lineamientos para la creación y uso de Sistemas Automatizados de Gestión y Control de Documentos que tiene por objeto establecer las bases para la creación y uso de sistemas automatizados de gestión y control de documentos. El 12 de noviembre de 2018, se publica en las wikiguías de gobmx el Estándar para el intercambio de Sistemas Automatizados de Control de Gestión, de esta manera se establece las especificaciones técnicas que permitan el intercambio de información con independencia del aplicativo o herramienta que cada Dependencia de gobierno determine utilizar, se describe la estructura del documento y las especificaciones a nivel de campo. El presente estándar actualiza lo establecido en el documento técnico para la interoperabilidad de los sistemas automatizados de control de gestión, dado a conocer por la Unidad de Gobierno Digital de la Secretaría de la Función Pública con fecha 21 de noviembre de 2012.

3

|


1. Descripción del estándar de oficio electrónico

4

|


5

|


3

6

|


7

|


Atributos

Name Type Use Descripción

FolioOficio xs:string requerido Folio del Oficio electrónico

NumeroOficioElectronico xs:string opcional -

Confidencialidad TipoConfencialida requerido Tipo de confidencialidad del Oficio Electrónico.

Elemento: Diagrama

8

|


Elemento: TipoOficios


TipoOficio TipoOficioElectronico requerido Especifica si el oficio es una Solicitud o una Respuesta a una Solicitud

EnReferenciaAFolio xs:string opcional Folio de Oficio electrónico al que este oficio hace referencia (o da alcance)

EnRespuestaDe xs:string opcional Para oficio de Tipo Respuesta; contiene el Folio de la Solicitud al que se responde

Confidencialidad TipoConfidencialidad requerido Tipo de confidencialidad del Oficio Electrónico.

Diagrama

9

https://docs.google.com/document/d/1SaEfcRL0Ot80hj-XuP0wnm9Cj3TGtuaDahSdHcaIp6E/edit?ts=5bc60816#heading=h.ymfzma

https://docs.google.com/document/d/1SaEfcRL0Ot80hj-XuP0wnm9Cj3TGtuaDahSdHcaIp6E/edit?ts=5bc60816#heading=h.ymfzma

|


Elemento: Fechas


FechaElaboracion xs:dateTime requerido Fecha de elaboración del oficio

EstampadoTiempo EstampillaDeTiempo requerido Nodos que mostraran el estampado del tiempo en TSA

FechaEstampado xs:dateTime requerido

TokenTSA Token requerido

Hash Hash requerido

NoCertificadoTSA Certificado requerido

Diagrama

10

|


Elemento: AsuntoInstruccion


AsuntoInstruccion xs:string requerido Elemento cuyo valor es el texto plano del asunto o instrucción.

Diagrama

Elemento: TrasnformacionImpresa


TransformacionImpresa TransformacionOficioElectronico opcional Elemento opcional que permitiría realizar una transformación del Oficio Electrónico para generar su representación impresa.

Diagrama

11

|


Elemento: Remitente


Institucion xs:string requerido Nombre de la institución de Remitente

UnidadOrganizacional xs:string requerido Nombre de la Unidad Organizacional perteneciente

Prsona xs:string requerido Datos personales del remitente

Elemento: Atributos Persona

nombre xs:string requerido -

primerApellido xs:string requerido -

segundoApellido xs:string requerido -

Curp xs:string requerido -

idCargo xs:int requerido -

cargo xs:string requerido -

abrTitulo xs:string requerido -

Diagrama

12

|


Elemento: Destinatarios/Destinatario


Institucion xs:string requerido Nombre de la institución del destinatario


Prsona xs:string requerido Datos personales del destinatario

13

|


Atributos Persona








Diagrama

14

|


Elemento: Copias/Copia


Institucion xs:string requerido Nombre de la institución del copiado


Persona xs:string requerido Datos personales del copiado

Atributos Persona








Diagrama

15

|


Elemento: Anexos


Anexo Anexo opcional -

Atributos: Anexos

tipoDeFormato tipoDeFormato opcional Archivos abiertos: PDF, CSV, JSON, XML, ODT.

Diagrama

16

|


Elemento: Addenda


Addenda Addenda opcional Nodo opcional para recibir las extensiones al presente esquema que sean de utilidad al emisor o receptor del Oficio Electrónico. Este elemento posibilita extender la integración entre los SACG, al permitir agregar información que pueda ser procesada de forma automática. Como regla, los elementos aquí agregados al XML del Oficio Electrónico, deberán mantener al Oficio y al Mensaje de Interoperabilidad que se utilice para él envió de este Oficio, como XML válidos. La estructura de dicha información debería ser especificada por la instancia y reforzada su validación mediante la publicación de un esquema de XML como el presente XSD.

Diagrama

17

|


Elemento: FirmasElectronicas


FirmaElectronica FirmaElectronicaOficio requerido En el intercambio de Oficios entre Instancias (escenario de Interoperabilidad entre SACG) se espera que el Oficio contenga la Firma de Autor, sin embargo, para permitir la adopción o uso del Oficio Electrónico al interior de las Instituciones (escenario sin Interoperabilidad entre SACG), se especifica el elemento FirmaElectronica de Autor como opcional. Las instancias (SACG) que reciban un Oficio Electrónico de otra Instancia, deberán validar que el Oficio si contenga la Firma Electrónica de Autor y esta sea válida. El elemento que contiene la información de firma del autor del Oficio Electrónico. Como Propósito de la Firma, se sugiere utilizar alguna descripción como: "Autoría", "Integridad y No repudio" o similar. Para mayor información sobre las características del elemento hijo 'Signature', ver documentación del Tipo Complejo FirmaElectronicaOficio.

Atributos FirmaElectronica

certificadoFirmante xs:base64 requerido -

noCertificadoFirmante xs:int requerido -

18

|


sello xs: base64 requerido -

Diagrama

Elemento: Archivos


ContenidoBase64 xs:base64 Opcional Contenido en base64 de los archivos

ReferenciasURI xs:URI Opcional Información para la descarga URI

DireccionURI xs:URI Opcional

Anotacion xs:string Opcional

Atributos Archivo

identificador xs:int Opcional -

Diagrama

19

|


Acuse

Atributos


folioOficio xs:string requerido Folio del Oficio electrónico

numeroOficioElectronio xs:string opcional -

versionEsquema xs:string requerido Versión del Esquema del oficio electrónico

Nodos


IdentificadorDelAcuse xs:string requerido Identificador único del acuse

TipoAcuse xs:string requerido Tipo de Acuse electrónico al que este oficio hace referencia

EnReferenciaAFolio xs:string requerido Para oficio de Tipo Respuesta; contiene el Folio de la Solicitud al que se responde

20

|


Confidencialidad TipoConfidencialidad requerido Tipo de confidencialidad del

Oficio Electrónico.

FechaEstampado EstampillaDeTiempo requerido Nodo que mostrará el estampado del tiempo en TSA

Diagram

21

|


2. Descripción de los Códigos de generales de error que se presentarán en los diversos escenarios de Interoperabilidad

Código de Error Descripción

400 BAD REQUEST La solicitud no fue válida. Este código se devuelve cuando el servidor ha intentado procesar la solicitud, pero algún aspecto de la solicitud no es válido; por ejemplo, un recurso formateado de forma incorrecta o un intento de despliegue de un proyecto de sucesos no válido en el tiempo de ejecución de sucesos. La información acerca de la solicitud se proporciona en el cuerpo de la respuesta e incluye un código de error y un mensaje de error.

401 UNAUTHORIZED El servidor de aplicaciones devuelve este código de respuesta cuando está habilitada la seguridad y faltaba la información de autorización en la solicitud.

403 FORBIDDEN Indica que el cliente ha intentado acceder a un recurso al que no tiene acceso. Podría producirse si el usuario que accede al recurso remoto no tiene privilegios suficientes. Los usuarios que intenten acceder a proyectos de sucesos privados que son propiedad de otros podrían recibir también este error.

404 NOT FOUND Indica que el recurso de destino no existe. Esto podría deberse a que el URI no está bien formado o a que se ha suprimido el recurso.

405 METHOD NOT ALLOWED Se produce cuando el recurso de destino no admite el método HTTP solicitado; por ejemplo, el recurso de funciones solo permite operaciones GET.

406 NOT ACCEPTABLE El recurso de destino no admite el formato de datos solicitado en la cabecera de Accept o el parámetro accept. Es decir, el cliente ha solicitado la devolución de los datos en un determinado formato, pero el servidor no puede devolver datos en ese formato.

22

|


409 CONFLICT Indica que se ha detectado un cambio conflictivo durante un intento de modificación de un recurso. El cuerpo de la respuesta contiene más información.

415 UNSUPPORTED MEDIA TYPE El recurso de destino no admite el formato de datos del cuerpo de la solicitud especificado en la cabecera de Content-Type.

500 INTERNAL SERVER ERROR Se ha producido un error interno en el servidor. Esto podría indicar un problema con la solicitud o un problema en el código del lado del servidor. Se puede encontrar información

3. Descripción de los Códigos de error que se presentarán en los diversos escenarios de

Interoperabilidad

Código de Error Descripción

400 BAD REQUEST La solicitud no fue válida. Este código se devuelve cuando el servidor ha intentado procesar la solicitud, pero algún aspecto de la solicitud no es válido; por ejemplo, un recurso formateado de forma incorrecta o un intento de despliegue de un proyecto de sucesos no válido en el tiempo de ejecución de sucesos. La información acerca de la solicitud se proporciona en el cuerpo de la respuesta e incluye un código de error y un mensaje de error.

401 UNAUTHORIZED El servidor de aplicaciones devuelve este código de respuesta cuando está habilitada la seguridad y faltaba la información de autorización en la solicitud.

403 FORBIDDEN Indica que el cliente ha intentado acceder a un recurso al que no tiene acceso. Podría producirse si el usuario que accede al recurso remoto no tiene privilegios suficientes. Los usuarios que intenten acceder a proyectos de sucesos privados que son propiedad de otros podrían recibir también este error.

23

|


404 NOT FOUND Indica que el recurso de destino no existe. Esto podría deberse a que el URI no está bien formado o a que se ha suprimido el recurso.

405 METHOD NOT ALLOWED Se produce cuando el recurso de destino no admite el método HTTP solicitado; por ejemplo, el recurso de funciones solo permite operaciones GET.

406 NOT ACCEPTABLE El recurso de destino no admite el formato de datos solicitado en la cabecera de Accept o el parámetro accept. Es decir, el cliente ha solicitado la devolución de los datos en un determinado formato, pero el servidor no puede devolver datos en ese formato.

409 CONFLICT Indica que se ha detectado un cambio conflictivo durante un intento de modificación de un recurso. El cuerpo de la respuesta contiene más información.

415 UNSUPPORTED MEDIA TYPE El recurso de destino no admite el formato de datos del cuerpo de la solicitud especificado en la cabecera de Content-Type.

500 INTERNAL SERVER ERROR Se ha producido un error interno en el servidor. Esto podría indicar un problema con la solicitud o un problema en el código del lado del servidor. Se puede encontrar información

24

|


4. Servicios de Interoperabilidad

Servicio de envío y recepción de oficios electrónicos Entrada (Literal): La entrada de esta operación es el elemento, el cual tiene la estructura descrita en la siguiente tabla:

Ítem Payload

Petición XML de envío

<?xml version="1.0" encoding="utf-8"?> <OficioElectronico xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" versionEsquema="" folioOficio="" numeroOficioElectronico=""> <TipoOficios> <TipoOficio>Respuesta</TipoOficio> <EnReferenciaAFolio></EnReferenciaAFolio> <EnRespuestaDe>SEP-23-00100000000000005</EnRespuestaDe> <Confidencialidad>Reservada</Confidencialidad> <IdentificadorDelOficio></IdentificadorDelOficio> </TipoOficios> <Fechas> <EstampadoTiempo> <FechaEstampado>2018-10-22T15:29:05.491-05:00</FechaEstampado> <TokenTSA>MIAGCSqGSJhbCBkZS.......FJyHRrxxW4MAAAAA</TokenTSA> <Hash>cMVr7hpCbRkcppJvM75sYD//Nto2qnoPwpnXnJKp4VA=</Hash> <NoCertificadoTSA>100584845342868</NoCertificadoTSA> </EstampadoTiempo> </Fechas> <AsuntoInstruccion>Aplicación de Gráfica Base</AsuntoInstruccion> <TransformacionImpresa>https://sectur.org/sectur-35-00987.pdf</TransformacionImpresa>

25

|


<Remitente> <Institucion>Secretaria de la Funcion Publica</Institucion> <UnidadOrganizacional>Servicios Digitales y Ciudadanía Digital</UnidadOrganizacional>

<Persona nombre="Daniel Alberto" primerApellido="Hernandez" segundoApellido="Herrera" curp="" idCargo="03" cargo="Director General Adjunto" abrTitulo="Mtro."></Persona> </Remitente> <Destinatarios> <Destinatario> <Institucion>Fondo Nacional de Fomento al Turismo</Institucion> <UnidadOrganizacional>Comunicación Digital</UnidadOrganizacional> <Persona nombre="Rossella" primerApellido="Ciscomani" segundoApellido="Freaner" curp="" idCargo="06" cargo="Gerente y Enlace" abrTitulo="Lic."></Persona> </Destinatario> </Destinatarios> <Copias> <Copia> <Institucion>Secretaria de la Funcion Publica</Institucion> <UnidadOrganizacional>Unidad de Gobierno Digital</UnidadOrganizacional> <Persona nombre="Tania Paola" primerApellido="Cruz" segundoApellido="Romero" curp="" idCargo="02" cargo="Titular" abrTitulo="Mtra."></Persona> </Copia> <Copia> <Institucion>Secretaria de Turismo</Institucion> <UnidadOrganizacional>Estrategia Digital</UnidadOrganizacional> <Persona nombre="Diego" primerApellido="Rendon" segundoApellido="Elizondo" curp="" idCargo="08" cargo="Director" abrTitulo="Lic."></Persona> </Copia> </Copias> <Anexos></Anexos> <Addenda></Addenda>

26

|


<FirmasElectronicas> <FirmaElectronica sello="VPmS+......pTZg==" certificadoFirmante="MIIAw.....oQmXQ==" noCertificadoFirmante="00001000000400032474"> </FirmaElectronica> </FirmasElectronicas> <Archivos identificador="sectur-35-00987"> <ContenidoBase64>PCFET0NUWVBFIGh0bWw+DQo....JvZHk+DQo8L2h0bWw+</ContenidoBase64> <ReferenciasURI > <DireccionURI>https://gob.mx/archivpenzip.zip</DireccionURI> <Anotacion>El archivo esta en formato zip, la contraseña es: UgD2018Final</Anotacion> </ReferenciasURI> </Archivos> </OficioElectronico>

Salida (Literal): La salida de esta operación es el elemento, el cual tiene la estructura descrita en la siguiente tabla:

Ítem Payload (json, xmlsoap)

Ejemplo de Respuesta JSON

Ejemplo de Respuesta XmlSOAP

27

|


Operaciones de Interoperabilidad En este apartado se describen, mediante escenarios, las operaciones con las que se construye el flujo de Mensajes y se conforma el esquema de operación de la Plataforma, así como el detalle de la construcción de dichos Mensajes. La descripción detallada de los tipos de Mensajes utilizados en las operaciones a las que hace referencia este Documento Técnico, se encuentra en el archivo XSD 1. Creación, envío, acuse, respuesta y alcance del oficio electrónico.

Descripción: Implementar el estándar de intercambio de oficios electrónicos, entre entes o dependencias de la Administración Pública Federal (APF) utilizando el estándar de oficio electrónico para asegurar la comunicación entre las dependencias. Creación y envío del oficio electrónico de la dependencia A, a la dependencia B.

▪ Remitente Instancia A

Al ingresar tiene las bandejas de enviados y recibidos que le permiten consultar su historial de oficios enviados y recibidos.

➢ Selecciona elaboración de oficio nuevo: Ingresa a la plantilla de oficio Campos pre llenados del emisor:

● Dependencia (emisor) ● Unidad administrativa (emisor) ● Título ● Nombre del servidor público emisor ● Nombre del puesto (emisor) (ejemplo, si el usuario es la titular de la Unidad de Gobierno Digital se

pondrá Unidad de Gobierno Digital, si es el DGA de Servicios digitales sería Dirección General Adjunta de Servicios Digitales

● Leyenda oficial del Año. ● Número de oficio (emisor)

o En caso de no contar con sistema se deberá de utilizar el estándar que es: siglas de la unidad administrativa/ número de la UA/ en su caso siglas de siguiente nivel inferior jerárquico (De acuerdo a la estructura establecida por cada dependencia).

● Domicilio (Calle, Número exterior y Número interior Código Postal, Colonia, Estado, Municipio o Alcaldía) de procedencia o lugar en donde se emite el Oficio.

➢ Selecciona al destinatario considerando CURP o datos (dependencia, nombres, apellidos) del destinatario.

28

|


Al seleccionar destinatario se pre llenan los campos de destinatario en la plantilla incluyendo:

● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa

➢ Selecciona a los usuarios a los que se enviará copia del oficio

Al seleccionar destinatarios de copia se auto llena la sección inferior de ccp; incluyendo el siguiente listado y la palabra

“Presente” el final de los datos de la persona. ● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa

➢ Selecciona el nivel de confidencialidad que puede ser:

● Confidencial ● Parcialmente Confidencial ● Reservada ● Parcialmente Reservada

➢ Se complementan los siguientes campos del oficio:

● Captura el campo de “Asunto” ● Opcional: Selecciona los archivos para adjuntar ● Captura de texto del oficio ● Firma del oficio: una vez terminado el llenado de campos, se procede a realizar el firmado del oficio

utilizando la efirma del remitente ● Sello digital de tiempo mediante el servicio de TSA de gobmx

➢ Seleccionar la opción de envío de oficio

▪ SACG Instancia A

● Genera XML acorde al estándar de Oficio electrónico propuesto ● Los archivos adjuntos se envían en formato MIME (Content-Transfer-Encoding: base64) ● El SACG envía el XML del oficio mediante web service tipo SOAP

▪ SACG Instancia B

● El SACG recibe por SOAP el XML enviado

29

|


▪ Destinatario Instancia B

El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio.

➢ Representación en pdf El oficio en XML deberá tener una representación impresa en formato pdf. Para reducir el esfuerzo necesario para la POC se

puede utilizar la representación que actualmente genera los SACG.

30

|


1. Creación y envío del acuse de recibido de la dependencia B a la dependencia A.


➢ Genera XML acorde al estándar de Oficio electrónico propuesto con los siguientes datos: ● Número de oficio (recibido) ● Folio (asignado) ● Sello digital de tiempo

El SACG envía el XML del oficio al Security server mediante web service tipo SOAP

▪ SACG Instancia A El SACG recibe por SOAP el XML enviado

▪ Destinatario Instancia A El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio en alcance.

➢ Representación en pdf El oficio en alcance en XML deberá tener una representación impresa en formato pdf.

31

|


2. Respuesta del oficio de la dependencia B enviado por la dependencia A.

▪ Remitente Instancia B

Al ingresar tiene las bandejas de enviados y recibidos que le permiten consultar su historial de oficios enviados y recibidos.

➢ Selecciona elaboración de responder un oficio recibido: Ingresa a la plantilla de oficio Campos pre llenados del emisor:






32

|






Al seleccionar destinatarios de copia se auto llena la sección inferior de ccp incluyendo el siguiente listado y la palabra

“Presente” el final de los datos de la persona. ● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa

➢ Selecciona el nivel de confidencialidad que puede ser: ● Confidencial ● Parcialmente Confidencial ● Reservada ● Parcialmente Reservada


● Captura el campo de “Asunto” ● Opcional: Selecciona los archivos para adjuntar ● Captura de texto del oficio ● Firma del oficio: una vez terminado el llenado de campos, se procede a realizar el firmado del oficio

utilizando la efirma del remitente ● Sello digital de tiempo mediante el servicio de TSA de gobmx ● Número de oficio al que responde



● Genera XML acorde al estándar de Oficio electrónico propuesto ● Los archivos adjuntos se envían en formato MIME (Content-Transfer-Encoding: base64) ● El SACG envía el XML del oficio al Security server mediante web service tipo SOAP


33

|


El SACG recibe por SOAP el XML enviado por X-ROAD

▪ Destinatario Instancia A El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio.



3. Opcional: Crear un alcance al oficio enviado de la dependencia A, a la dependencia B.

34

|


▪ Remitente Instancia A Al ingresar tiene las bandejas de enviados y recibidos que le permiten consultar su historial de oficios enviados y recibidos.

➢ Selecciona elaboración de alcance a un oficio enviado previamente: Ingresa a la plantilla de oficio Campos pre llenados del emisor:










Al seleccionar destinatarios de copia se auto llena la sección inferior de ccp incluyendo el siguiente listado y la palabra

“Presente” el final de los datos de la persona. ● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia

35

|


● Unidad administrativa

➢ Selecciona el nivel de confidencialidad que puede ser:

● Confidencial ● Parcialmente Confidencial ● Reservada ● Parcialmente Reservada


● Número de oficio de alcance ● Captura el campo de “Asunto” ● Opcional: Selecciona los archivos para adjuntar ● Captura de texto del oficio ● Firma del oficio: una vez terminado el llenado de campos, se procede a realizar el firmado del oficio

utilizando la efirma del remitente ● Sello digital de tiempo mediante el servicio de TSA de gobmx



● Genera XML acorde al estándar de Oficio electrónico propuesto. ● Los archivos adjuntos se envían en formato MIME (Content-Transfer-Encoding: base64) ● El SACG envía el XML del oficio al Security server mediante web service tipo SOAP


El SACG recibe por SOAP el XML enviado por X-ROAD

▪ Destinatario Instancia B El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio.



36

|


37

|


Especificación de Escenarios Flujo normal de eventos: En el flujo normal de eventos se consideran los siguientes pasos:

38

|


7. Seguridad y conectividad La utilización de los protocolos HTTPS, SSL y TLS con versiones seguras en la totalidad del aplicativo/sistema es de gran importancia ya que se asegura que la información que viaja entre los servidores y usuarios está encriptada a un nivel alto y aumenta la calidad de la seguridad y confidencialidad de los datos. En términos de la Ley General de Datos Personales en Posesión de los Sujetos Obligados, es responsabilidad de cada dependencia y entidad de la Administración Pública Federal, y empresa productiva del Estado (Institución), determinar el cumplimiento de las disposiciones previstas en la legislación vigente en materia de datos personales. Para efectos del “Acuerdo por el que se emite la guía para la estandarización y certificación de los trámites digitales con el Sello de Excelencia de Gobierno Digital”, esta unidad administrativa únicamente validará que se cumpla con la opinión correspondiente del área jurídica de cada Institución. La comunicación entre los puntos debe ser segura por medio del protocolo de seguridad HTTPS, a fín de garantizar la integridad y la confidencialidad durante la trasmisión. Los servicios de interoperabilidad que se implementen deben hacer uso de servicios web basados en estándares abiertos, con formato de mensajes SOAP/XML sobre protocolo HTTPS. Bajo este esquema se debe integrar el uso de WS-Security (Web Services Security), que cumpla con el estándar de la versión 1.1, específicamente la implementación de la especificación XML-SIGnature, de tal forma que el mensaje SOAP-XML sea firmado electrónicamente antes de enviarlo a la instancia destino, para que garantice la autenticidad, integridad y no repudio de los mismos. Para que las instancias puedan usar la Firma Electrónica Avanzada (efirma) en los Oficios Electrónicos, deberá integrarse un componente en los SACG. El firmado electrónico que efectúan las instancias asegura la auditoría de los oficios generados por las mismas, permite mantener integra la información. El firmado electrónico debe incluir todos los elementos XML del oficio. El XML contará con un estampado de tiempo que se utiliza para dar certidumbre de que los oficios existieron en un momento determinado. Los estampados de tiempo servirán como evidencia forense del envío y recepción de los oficios. El formato de fechas deberá expresarse en UTC (Universal Time Coordinated) y apegarse a la definición TSP (Time-Stamp Protocol) de PKI (Public Key Infrastructure).

39

E s tá n d a r p a r a e l i n te r c a mb i o d e S i s te …...Secretaría de la Función...

Documents

Transcript of E s tá n d a r p a r a e l i n te r c a mb i o d e S i s te …...Secretaría de la Función...