¶ 1. Introducción
La presente guía técnica tiene por finalidad desarrollar los aspectos operativos y procedimentales necesarios para la correcta implementación de la Norma Técnica de Interoperabilidad establecida por el Decreto N° 12, de 2023.
Esta guía no crea obligaciones adicionales para los órganos de la Administración del Estado. Sin perjuicio de lo anterior, la Norma Técnica de Interoperabilidad si mandata a regular los siguientes aspectos en esta guía técnica, los cuales se entienden integrados a dicha Norma:
i) El procedimiento de designación de un(a) funcionario(a) responsable por la información contenida en los servicios de interoperabilidad (artículo 7).
ii) La forma de designar y modificar la designación de un(a) funcionario(a) responsable de publicar los servicios de interoperabilidad y mantenerlos actualizados (artículo 8).
iii) Los campos mínimos del directorio de datos, lo que incluye cuáles órganos el dato, periodicidad y fecha de su última actualización, el carácter de los datos, entre otros (artículo 10).
iv) Los requisitos para la publicación de esquemas (artículo 11), y v) el formato del consentimiento tipo (artículo 15).
.
¶ 2. Componentes de la Red de Interoperabilidad
La Red de Interoperabilidad se compone de elementos técnicos que permiten a los Órganos de la Administración del Estado intercambiar datos, documentos y expedientes electrónicos de forma segura, estandarizada y trazable. Véase Modelo de Interoperabilidad.
Los componentes principales son:
- Nodo de interoperabilidad: software instalado en cada organismo que actúa como su punto único de conexión con la Red.
- Servicios centralizados de interoperabilidad: infraestructura provista por la Secretaría de Gobierno Digital que incluye el Catálogo de Servicios, Registro de Trazabilidad, Catálogo de Esquemas, Gestor de Autorizaciones y Gestor de Solicitudes.
- Repositorio de certificados públicos: componente que almacena las llaves públicas necesarias para autenticar, firmar y validar mensajes.
- Portal PISEE: plataforma web donde los OAE administran servicios, revisan trazabilidad y monitorean su operación.
- Punto de conexión para nodos: canal seguro y bidireccional que vincula los nodos con los servicios centralizados.
Estos componentes son provistos por la Secretaría de Gobierno Digital para todos los organismos que integren la Red de Interoperabilidad.
¶ 2.1 Nodo de interoperabilidad
El nodo de interoperabilidad es un componente de software alojado en la infraestructura de cada OAE y constituye el único medio autorizado para intercambiar datos, documentos y expedientes a través de la Red de Interoperabilidad.
Permite que los sistemas institucionales se comuniquen con otros organismos mediante:
- Autenticación y autorización mutua
- Encriptación y transmisión segura de los mensajes
- Registro de trazabilidad
- Descubrimiento y consumo de servicios publicados en el Catálogo
- Recepción de solicitudes desde otros organismos
El nodo transmite los mensajes sin modificar su formato original, asegurando integridad de extremo a extremo.
La Secretaría de Gobierno Digital disponibiliza un nodo para los organismos que requieran una implementación inmediata. No obstante, cada OAE es libre de utilizar cualquier nodo de interoperabilidad (propio, desarrollado por terceros o provisto por un proveedor externo) siempre que dicho nodo cumpla con los requisitos establecidos en esta guía y en la Norma Técnica de Interoperabilidad, y que sea validado conforme al procedimiento descrito en el apartado 2.2.1 "Requisitos de un nodo de interoperabilidad".
A continuación, se presenta el flujo de comunicación entre consumidores y proveedores de datos, documentos y/o expedientes electrónicos:
¶ 2.1.1. Requisitos de un nodo de interoperabilidad
Todo nodo que forme parte de la Red de Interoperabilidad deberá cumplir, al menos, con los siguientes estándares y funcionalidades:
1. Establecer una conexión segura entre los órganos de la Administración del Estado
Antes de intercambiar información, el nodo debe ejecutar una serie de tareas que garanticen una conexión segura:
- Autenticación mutua: el nodo debe presentar sus credenciales y validar las de su contraparte, reconociéndose ambos como integrantes de la Red de Interoperabilidad.
- Verificación de autorizaciones:
- El nodo consumidor debe obtener, desde los servicios centralizados, la autorización para utilizar el servicio solicitado, y adjuntarla en el mensaje enviado al proveedor.
- El nodo proveedor debe validar dicha autorización utilizando la llave pública de firma entregada por los servicios centralizados.
- Encriptación de los mensajes en tránsito: el nodo debe encriptar toda la información que se intercambie, asegurando confidencialidad y calidad del dato.
- Uso del protocolo correspondiente: la especificación técnica de autenticación, autorización y encriptación dependerá del protocolo autorizado que utilice el servicio véase "Protocolos Autorizados".
2. Enviar y recibir datos, documentos y expedientes electrónicos entre órganos de la Administración del Estado
El nodo debe tener la capacidad de, una vez establecida la conexión segura:
- Enviar mensajes al nodo de otro organismo utilizando el protocolo definido para ese servicio.
- Esperar la respuesta del nodo receptor.
- Entregar dicha respuesta al sistema institucional que originó la solicitud.
Los nodos permiten tanto la emisión como la recepción de mensajes, facilitando la interoperación entre OAE conectados a la Red.
3. Permitir el flujo bidireccional de mensajes
El nodo debe asegurar la posibilidad de recibir solicitudes desde otros organismos y emitir solicitudes hacia ellos, de acuerdo con los permisos vigentes.
4. Registrar la trazabilidad de la entrada y salida de mensajes
Toda comunicación entre organismos debe generar un registro de los metadatos asociados a cada transacción, conforme al apartado “Registro de trazabilidad”. Este registro debe enviarse mediante los servicios centralizados, según el procedimiento descrito en "Punto de conexión para los nodos".
5. Conectar y comunicarse con el Gestor de Autorizaciones
Cuando un organismo requiera datos de carácter sensible:
- El nodo del consumidor debe adjuntar al mensaje el permiso obtenido desde el Gestor de Autorizaciones.
- El nodo del proveedor debe validar ese permiso cuando reciba una solicitud.
La responsabilidad del manejo adecuado de autorizaciones recae en el organismo que realiza el consumo y en el que provee el servicio.
6. Ser la única vía de acceso a los servicios de interoperabilidad
El nodo debe funcionar como enlace exclusivo entre los sistemas del organismo y los servicios disponibles en el Catálogo, evitando vías paralelas de integración.
7. Encriptar mensajes y respuestas
Toda comunicación entre organismos debe estar encriptada de extremo a extremo. Esto implica cifrado en el emisor y descifrado únicamente en el receptor. Los mecanismos autorizados se detallan en el Anexo “Mecanismos de Encriptado”.
8. Validar el certificado del nodo consumidor
El nodo proveedor debe confirmar que el certificado del nodo que envía la solicitud es válido y corresponde al organismo que afirma representar.
9. Auto-monitorear sus propias operaciones
El organismo responsable del nodo debe contar con mecanismos para:
- Mantener el nodo en ejecución y detectar caídas.
- Revisar los registros de actividad.
- Verificar el origen de conexiones externas y bloquear comportamientos sospechosos.
- Supervisar el uso de recursos en los servidores donde se aloja el nodo.
- Monitorear el volumen de tráfico e informar anomalías a la Secretaría de Gobierno Digital mediante ticket a la Mesa de Servicios.
10. Utilizar protocolos autorizados por la Secretaría de Gobierno Digital
Los nodos solo podrán usar protocolos incluidos en esta guía o validados por la Secretaría. Estos definen la tecnología de comunicación, mecanismos de autenticación y autorización, métodos de cifrado y, en los casos que corresponda, firma digital o envolturas de mensajes.
¶ 2.1.2 Validación de nodos de desarrollo propio
Cuando un organismo opte por desarrollar su propio nodo (ya sea propio, desarrollado por terceros o provisto por un proveedor externo) éste deberá someterse a un proceso de validación por parte de la Secretaría de Gobierno Digital. Cada organismo es responsable de asegurar que su nodo cumple con esta guía técnica y de realizar las validaciones de seguridad asociadas a su implementación, asumiendo también la responsabilidad por cualquier vulnerabilidad en materia de ciberseguridad.
La solicitud de validación debe realizarse mediante un ticket dirigido al equipo PISEE a través de la Mesa de Servicios. En la solicitud, el organismo deberá informar los nombres y datos de contacto de las personas responsables del desarrollo, y adjuntar evidencia de las consultas realizadas a los servicios centralizados, incluyendo una prueba exitosa en el ambiente de TEST.
Los aspectos que serán evaluados en el proceso de validación son:
- La correcta comunicación del nodo con otros nodos utilizando únicamente los protocolos permitidos por esta guía.
- El registro adecuado de la trazabilidad de las transacciones.
- El cumplimiento de la comunicación con los servicios centralizados de interoperabilidad.
La Secretaría de Gobierno Digital contará con un plazo de 15 días hábiles para revisar el nodo y verificar que cumple íntegramente con las exigencias de esta guía. Tras la revisión, se emitirá un informe con el resultado.
- Si no existen incumplimientos, el nodo será considerado válido.
- Si existen observaciones o incumplimientos, el organismo deberá realizar las correcciones necesarias y solicitar una nueva validación.
La Secretaría se reserva la facultad de ampliar el plazo de revisión cuando existan razones técnicas o administrativas que lo justifiquen.
¶ 2.1.3 Portal PISEE
La Red de Interoperabilidad cuenta con un portal web denominado Portal PISEE, que permite a los organismos administrar sus servicios de interoperabilidad. Solo pueden acceder funcionarios o asesores a honorarios designados para este fin y debidamente enrolados en la plataforma. La autenticación se realiza mediante ClaveÚnica.
El portal ofrece un panel de control desde el cual es posible:
- Explorar el Catálogo de Servicios de Interoperabilidad del Estado.
- Administrar los servicios que el organismo pone a disposición de otros OAE, incluyendo agregarlos, modificarlos, eliminarlos y gestionar accesos.
- Administrar los servicios que el organismo consume de otros OAE, pudiendo buscarlos, agregarlos, modificarlos o eliminarlos.
- Revisar la información de trazabilidad de las transacciones.
Visualizar el estado de operación de los servicios publicados y consumidos.
El acceso a esta plataforma debe ser solicitado a través de la Mesa de Servicios, indicando el nombre, RUT y correo institucional del usuario a registrar.
¶ 2.1.4 Punto de conexión para los nodos de interoperabilidad
La Red de Interoperabilidad dispone de un Punto de Conexión accesible por Internet, a través del cual los nodos intercambian información con los servicios centralizados, incluyendo trazabilidad, permisos, certificados y datos de configuración.
Los nodos deben conectarse a este Punto de Conexión utilizando sus credenciales de acceso, estableciendo una conexión persistente y bidireccional, que permite tanto enviar como recibir información desde los servicios centralizados. Esta conexión habilita el flujo continuo de:
- Actualizaciones de certificados
- Endpoints de servicios
- Llaves de firma
- Tokens de permisos
- Otros datos necesarios para la operación de los nodos
Los nodos desarrollados por los organismos deberán conectarse utilizando las URL, datos técnicos y credenciales entregadas por la Secretaría de Gobierno Digital una vez que el nodo haya sido validado.
¶ Servicios centralizados de interoperabilidad
Los servicios centralizados de interoperabilidad corresponden al conjunto de herramientas de software e infraestructura que sustentan el funcionamiento de la Red de Interoperabilidad. Estos servicios permiten registrar, descubrir, autorizar y monitorear los intercambios entre los Órganos de la Administración del Estado (OAE). Los servicios centralizados incluyen el Catálogo de Servicios de Interoperabilidad, el Registro de Trazabilidad, el Catálogo de Esquemas, el Gestor de Solicitudes y el Gestor de Autorizaciones. El Gestor de Solicitudes y el Gestor de Autorizaciones se encuentran actualmente en desarrollo. Todos estos componentes son provistos por la Secretaría de Gobierno Digital.
¶ El Catálogo de Servicios de Interoperabilidad
El Catálogo de Servicios de Interoperabilidad es el repositorio central de todos los servicios disponibles para el intercambio de datos entre organismos. Está implementado mediante una herramienta de tipo Service Discovery, que permite registrar y descubrir servicios de manera estandarizada.
El Service Discovery ofrece las siguientes capacidades:
- Identificación de servicios a través de un nombre único independiente de la URI del servicio.
- Registro de múltiples URIs para un mismo servicio, permitiendo configuraciones con ambientes replicados o contingencias.
- Incorporación de metadata adicional, como etiquetas o descripciones que facilitan la comprensión del servicio.
- Descubrimiento automático, permitiendo que los nodos consumidores obtengan las URIs del servicio sin coordinación directa con el proveedor.
El acceso al catálogo se realiza exclusivamente a través de los nodos de la Red. Su administración se realiza mediante una interfaz web disponible en el Portal PISEE, a la cual solo pueden acceder usuarios registrados. Para obtener acceso, se debe solicitar mediante Mesa de Servicios indicando nombre, RUT y correo institucional.
¶ Registro de Trazabilidad
El Registro de Trazabilidad es el repositorio central donde se almacena la metadata de las transacciones realizadas a través de la Red de Interoperabilidad. Cada transacción debe generar trazas que permitan comprender su recorrido y determinar, en caso de error, en qué etapa se produjo la falla. Cada transacción de interoperabilidad debe registrar cuatro eventos obligatorios:
- El consumidor envía la consulta
- El proveedor recibe la consulta
- El proveedor envía la respuesta
- El consumidor recibe la respuesta
La metadata registrada debe cumplir con lo exigido por la Ley N° 21.180 sobre Transformación Digital del Estado, y enviarse al Registro de Trazabilidad de los Servicios Centralizados conforme al Artículo 9 de la Norma Técnica de Interoperabilidad.
¶ Estructura de la metadata de trazabilidad
Los metadatos deben almacenarse en formato JSON y seguir la estructura definida a continuación:
Tabla 1 - Descripción de la trazabilidad
| ID |
Donde el ID es un identificador único de la transacción. Este ID se compone de: ID del organismo + ULID. ULID corresponde a una cadena de texto única, compuesta por 48 bits de una marca de tiempo (tiempo UNIX en milisegundos) y 80 bits aleatorios, todo esto convertido en base64, quedando de la siguiente forma: PE-MIN-00525 . 01AN4Z07BY 79KA1307SR9X4MV3 |-------------| |----------| |----------------| ID organismo Timestamp Entropy
|
| Consumidor | Identificador único del organismo consumidor, según lo establecido en el Gestor de Códigos. |
| Proveedor | Identificador único del organismo proveedor, según lo establecido en el Gestor de Códigos. |
| Procedimiento | Identificador del procedimiento administrativo según el Catálogo de Procedimientos Administrativos |
| Servicio | Nombre del servicio web tal como aparece en el catálogo. |
| Funcionario o asesor a honorarios | Funcionario que requiere el dato. |
| Código Respuesta | Código de estado de respuesta HTTP. |
| Tipo Respuesta | Mensaje de la respuesta. |
| Datos Solicitud | Lista de los nombres de los datos solicitados. |
| Nodo Envío | Identificador del Nodo que realiza el envío. |
| Fecha Hora | Fecha y hora del envío, en UTC-0. |
| Autorización | Método de autorización utilizado para solicitar la información. |
| Tipo Traza |
Identificador de la etapa en la interoperabilidad que se está registrando. Las opciones son: 1.- Envío de consulta (la realiza el consumidor del servicio) 2.- Recepción de consulta (la realiza el proveedor del servicio) 3.- Envío de respuesta (la realiza el proveedor del servicio) 4.- Recepción de respuesta (la realiza el consumidor del servicio) |
| Gestión (*) | Gestión que se encarga |
| Plazo (*) | Plazo establecido para la realización de la gestión en cuestión |
| Run (*) | En el caso de que se interoperen datos de carácter sensible, es el rol único nacional del interesado cuyos datos están involucrados en la interacción |
| Token de autorización sensible (*) | En el caso de que se interoperen datos de carácter sensible, acá está el token autorización aprobado por el ciudadano. |
*Gobierno Digital incorporará estos campos a la estructura JSON durante el año 2026.
¶ Registro en tiempo real
Los nodos de interoperabilidad, al estar conectados de manera persistente al Punto de Conexión, pueden enviar la trazabilidad automáticamente y en tiempo real para cada mensaje entrante o saliente.
Si ocurre un problema de comunicación con el Punto de Conexión, el nodo debe almacenar localmente las trazas generadas para evitar la pérdida de información.
Una vez restablecida la conexión, el nodo debe enviar todas las trazas pendientes, siguiendo el mismo formato que en el envío automático.
¶ Registro diferido
Cuando el nodo no pueda enviar la trazabilidad en línea, deberá almacenarla temporalmente de forma local utilizando el mismo formato JSON definido para el Registro de Trazabilidad, y enviarla posteriormente en paquetes de trazabilidad dentro de los plazos establecidos, es decir, hasta siete días después de transcurridas las primeras 48 horas desde el envío del primer paquete.
¶ Repositorio de Certificados Públicos
El Repositorio de Certificados Públicos es un componente central de los servicios de interoperabilidad, encargado de almacenar las llaves públicas utilizadas por los organismos para identificarse, encriptar, firmar y validar los mensajes intercambiados en la Red de Interoperabilidad.
Los certificados almacenados en este repositorio se basan en criptografía de clave pública, lo que implica que cada certificado posee un par de llaves: una privada, bajo custodia exclusiva del organismo propietario, y una pública, registrada en el repositorio para su validación por parte de otros organismos.
Figura 3 - Certificados de seguridad con llaves asimétricas.
Los OAE que integran la Red pueden acceder a las llaves públicas de todos los organismos con los que interoperan. Estas llaves son utilizadas automáticamente por los nodos para establecer conexiones seguras, verificar firmas digitales y validar la identidad de sus contrapartes.
Certificados disponibles en el Repositorio
El repositorio mantiene los siguientes tipos de certificados:
- Certificados X.509 para el establecimiento de canales de comunicación seguros mediante TLS.
- Certificados ed25519 para la firma y validación de mensajes intercambiados entre organismos.
Estos certificados son distribuidos a los nodos a través del Punto de Conexión, que transmite automáticamente las actualizaciones y llaves públicas necesarias para operar.
Obtención de certificados institucionales
Al integrarse a la Red de Interoperabilidad, cada organismo recibe los certificados públicos y privados que lo habilitan para consumir y proveer servicios del Catálogo. Paralelamente, la Secretaría de Gobierno Digital registra las llaves públicas en el Repositorio.
Obtención de certificados públicos de otros organismos
Los nodos reciben automáticamente las llaves públicas necesarias para interoperar con otros OAE al conectarse a los servicios centrales, mediante mensajes del tipo PISEEEMessageType, según lo especificado en la sección sobre conexión al Punto de Conexión para nodos.
¶ Catálogo de Esquemas
El Catálogo de Esquemas es el repositorio donde se publican los esquemas que describen la estructura de los mensajes que se intercambian mediante los servicios de interoperabilidad.
Estos esquemas pueden ser consultados por los organismos consumidores para entender la estructura de los mensajes asociados a un servicio y preparar sus integraciones en consecuencia.
La publicación y administración de los esquemas se realiza a través del Portal PISEE, donde los organismos proveedores pueden registrar o actualizar los esquemas correspondientes a sus servicios.
¶ Gestión de Esquemas
La gestión de esquemas define el proceso mediante el cual los órganos de la Administración del Estado publican, actualizan y administran los esquemas utilizados para estructurar los datos que se intercambian a través de la Red de Interoperabilidad. Este proceso es administrado por la Secretaría de Gobierno Digital y aplica tanto a esquemas basales como documentales, asegurando que su estructura, reglas y versiones se mantengan consistentes entre proveedores y consumidores.
¶ Publicación de esquemas
Para ser incorporado al Catálogo, un esquema debe cumplir ciertos requerimientos técnicos. Debe estar construido en una tecnología estable, ampliamente utilizada y con reglas claras para su validación. Cada esquema debe contener una descripción en el propio archivo o en el lugar que la tecnología permita.
Los OAE que necesiten publicar un esquema deben registrarlo en el Catálogo, quedando en estado “pendiente de publicar” mientras es revisado por la Secretaría de Gobierno Digital.
La Secretaría dispone de un plazo de 15 días hábiles para analizarlo, pudiendo aceptarlo, rechazarlo, pedir antecedentes adicionales o realizar cambios antes de la publicación, informando al organismo responsable.
Una vez aprobado, el esquema queda disponible para todos los organismos a través del Catálogo.
¶ Modificación de esquemas
Los esquemas pueden requerir modificaciones por ajustes en sus campos, valores permitidos o la incorporación de nuevas versiones.
Antes de realizar cambios, el OAE responsable debe informar por correo electrónico a todas las contrapartes que consumen el esquema, con al menos 15 días hábiles de anticipación. El aviso debe incluir la identificación del esquema, su versión previa, la modificación propuesta y la justificación técnica, e incorporarse con copia a la Secretaría de Gobierno Digital.
Una nueva versión puede publicarse manteniendo la versión anterior disponible durante un mínimo de 120 días hábiles. Si el esquema o su metadato no existe en el Catálogo o no puede generarse desde los esquemas basales, el organismo puede incorporarlo manualmente.
La Secretaría puede dar de baja una versión si contiene errores, permitiendo que el organismo la corrija y publique una versión ajustada. Dentro de los 90 días hábiles siguientes a la publicación, la Secretaría consultará a los organismos afectados y podrá dar de baja la nueva versión o publicar modificaciones de oficio siguiendo el mismo procedimiento.
¶ Avisos a organismos consumidores
Cuando un esquema sea dado de baja o modificado de oficio, la Plataforma de Interoperabilidad notificará a todos los OAE que consumen o proveen servicios asociados, para que actualicen sus integraciones según corresponda.
¶ Gestor de Autorizaciones
El Gestor de Autorizaciones permitirá que las personas naturales otorguen su consentimiento para que los órganos de la Administración del Estado interoperen información y datos sensibles. Para ello, la Secretaría de Gobierno Digital dispondrá de una plataforma encargada de verificar la identidad digital de la persona.
Una vez que la persona se autentique, la plataforma le mostrará la solicitud realizada por el órgano correspondiente, la cual podrá aceptar o rechazar. En caso de aceptación, el sistema generará un documento digital dirigido al organismo proveedor de la información, de manera que este pueda verificar la validez de la autorización otorgada.
¶ Gestor de Solicitudes
El Gestor de Solicitudes es una herramienta en desarrollo que formará parte de los servicios centralizados de la Red de Interoperabilidad. Su objetivo será facilitar la integración a un servicio de interoperabilidad de un proveedor para interoperar un dato o información por una única vez o para solicitar acceso permanente a un servicio de interoperabilidad.
¶ 3. Operación de la Red de Interoperabilidad
¶
3.1 Integración del nodo con los servicios centralizados
La integración entre los nodos de interoperabilidad y los servicios centralizados se realiza mediante el Punto de Conexión a los Servicios Centralizados, definido como la herramienta a través de la cual los nodos intercambian información de trazabilidad, permisos, certificados y servicios. Para operar correctamente, cada nodo debe:
- Mantener una conexión persistente con el Punto de Conexión, que permite enviar y recibir información necesaria para su funcionamiento (p. ej., certificados públicos, endpoints y trazabilidad).
- Procesar los mensajes enviados por los servicios centralizados, incluyendo la recepción de llaves públicas mediante los mensajes del tipo PISEEEMessageType, utilizados para actualizar certificados y otra información requerida para interoperar.
- Enviar la trazabilidad de cada intercambio al servidor correspondiente utilizando el mismo mecanismo persistente de conexión, en tiempo real o diferido según el estado de la comunicación.
En conjunto, estos elementos permiten que cada nodo opere utilizando información actualizada, reciba las llaves y configuraciones necesarias desde los servicios centrales y envíe la trazabilidad conforme a la Norma Técnica de Interoperabilidad.
¶ 3.2 Flujo general de interoperación
El flujo general de una interoperación entre organismos se compone de cuatro eventos obligatorios que permiten identificar cada etapa del intercambio de información. Este flujo aplica a toda transacción realizada a través de la Red de Interoperabilidad, ya sea de datos, documentos o expedientes electrónicos.
Los eventos que conforman el flujo son los siguientes:
- El consumidor envía la consulta: el organismo consumidor transmite la solicitud al organismo proveedor.
- El proveedor recibe la consulta: el organismo proveedor recibe el mensaje enviado por el consumidor.
- El proveedor envía la respuesta: el organismo proveedor remite la respuesta correspondiente a la consulta realizada.
- El consumidor recibe la respuesta: el organismo consumidor recibe la respuesta enviada por el proveedor.
Estos pasos deben registrarse en el sistema de trazabilidad, permitiendo reconstruir el recorrido del mensaje y determinar, en caso de fallas, en qué etapa del proceso se produjo el error.
A continuación, se presenta un diagrama del flujo de comunicación entre consumidores y proveedores de datos, documentos y/o expedientes electrónicos:
¶ 3.3 Conexión al Service Discovery (Catálogo de servicios)
Para acceder al Service Discovery de los servicios centralizados de interoperabilidad, los nodos requieren un agente Consul que permita consultar las URIs actualizadas de los servicios de interoperabilidad publicados en la Red.
Los agentes Consul deben estar configurados para apuntar al Service Discovery el cual se encuentra en la siguiente dirección:
|
https://catalogo.pisee.cl:8500 |
Y se deben autenticar ante el Service Discovery mediante Mutual TLS, para lo cual se debe solicitar, a la Secretaría de Gobierno Digital a través de la Mesa de Servicios, las llaves de identificación (público y privada) para efectuar la conexión.
¶ 3.4 Conexión al Punto de conexión para nodos de interoperabilidad
Para que los nodos puedan conectarse al Punto de conexión para nodos de la Red de interoperabilidad, el primer paso es buscar el endpoint del mismo en el Service Discovery utilizando su nombre de servicio:
|
“CentralServerPISEEE” |
Una vez obtenida la ruta se debe crear una conexión hacia el Punto de conexión. Esta conexión debe ser:
Mediante HTTP/2: los objetivos principales al utilizar HTTP/2 son reducir la latencia, permitiendo una multiplexación completa de solicitudes y respuestas; minimizar la sobrecarga de protocolo mediante una compresión eficiente de campos de encabezados de HTTP y, principalmente, poder utilizar un canal doble de comunicación (pull - push).
Persistente: se debe crear una conexión que se mantenga abierta entre el nodo y el Punto de conexión, utilizando las características de HTTP/2. El propósito de mantener abierta la conexión es utilizarla como un canal de comunicación de doble vía para enviar y recibir información.
Doble Vía: la conexión al Punto de conexión debe ser de doble vía, ya que ambas partes (nodo y Punto de conexión) se envían mutuamente información.
Carga de certificados de confianza (Servidor → Nodo)
Solicitud de token de permisos (Nodo → Servidor)
Registro de trazabilidad (Nodo → Servidor)
TLS Mutuo: la conexión al Punto de conexión se realiza intercambiando certificados mutuamente, para que tanto el Punto de conexión como el nodo puedan identificar inequívocamente a su contraparte y puedan confiar en ella, encriptando además el canal de comunicación de punto a punto.
//Crea la configuración del cliente
client := &h2conn.Client{
Client: &http.Client{
// Define la capa de transporte como http2
Transport: &http2.Transport{
// Aquí especifica que el canal tiene TLS Mutuo
TLSClientConfig: &tls.Config{
RootCAs: CertificadosPublicoDelServidor,
Certificates: []tls.Certificate{MiCertificado},
},
},
},
}
client.Method = "PUT"
client.Header = make(http.Header)
// Establece la conexión
connection, resp, err := client.Connect(ctx, url.Address)Código 1 - Ejemplo de conexión (en Golang)
¶ 3.5 Comunicación con el Punto de conexión para nodos
Una vez conectado al Punto de conexión para nodos de interoperabilidad de los servicios centralizados, y establecido el canal de comunicación persistente, ambas órganos se comunicarán intercambiando mensajes con un formato específico llamado PISEEEMessageType, que corresponde a documentos en un formato JSON específicos.
El formato tiene un campo llamado MsgType que indica qué tipo de mensaje se está enviando:
TRACE
AUTHENTICATE
AUTHORIZED
CERTIFICATE
ENDPOINT
REVOKE_JWT_CU
FORCEDOWNLOADLuego vienen las secciones con el contenido del mensaje según el tipo indicado. Las secciones son: “authentication”, “authorization”, “trace”, “certificates”, “endpoint”.
{
"MsgType": "string",
"authentication": {
"id": "string",
"password":"string",
"authenticated":true,
"error":"string"
},
"authorization": {
"service": "string",
"consumer": "string",
"token": "string",
"founded": true
},
"trace": {
"id": "string",
"consumidor": "string",
"tramite": "string",
"servicio": "string",
"funcionario": "string",
"codigoRespuesta": 0,
"tipoRespuesta": "string",
"datosSolicitados": ["dato1","dato2"],
"nodoEnvio": "string",
"fechaHora": "string",
"signature": "string",
"autorizacion": "string",
"tipoTraza": 1
},
"certificates": [
{
"id": 0,
"organismo": "string",
"certificado": "string",
"tipo": "string",
"recibido": true
}
],
"endpoint": {
"service":"string"
}
}
Código 2 - Formato completo de los mensajes PISEEEMessageType
¶ 3.6 Consumo de servicios
El propósito fundamental de los nodos es permitir que los organismos llamen a los servicios de interoperabilidad publicados en el Catálogo, actuando como intermediarios encargados de descubrir el servicio, comunicarse con el proveedor, validar los mensajes y registrar la trazabilidad dentro de una conexión segura.
Para realizar una llamada a un servicio, el nodo debe ejecutar internamente una serie de pasos que permiten obtener la información necesaria para interoperar.
¶ Obtener endpoints de los servicios
El nodo puede obtener los endpoints de los servicios a los que desea acceder a través del Service Discovery.
nombreServicio := “DatosBasicosSRCeI”
servicios, err := clientConsul.Agent().ServicesWithFilter("Service == \"" + nombreServicio + "\"")Código 3 - Ejemplo de consulta de endpoint (Golang)
Una vez conectado, el nodo realiza una consulta utilizando el nombre del servicio buscado. El Service Discovery entrega una lista de servicios coincidentes y los metadatos asociados necesarios para interoperar.
servicios[0].ID
servicios[0].Address
servicios[0].Tags
servicios[0].Meta[“TYPE”]
servicios[0].Meta[“ORGANISMO”]
servicios[0].Meta[“NOMBRE_SERVICIO_PISEE”]
servicios[0].Meta[“SERVICIO_SII_PISEE”]Código 4 - Lista de servicios
Entre los metadatos disponibles se encuentran la dirección real del endpoint (Address), el tipo de protocolo del servicio (TYPE), el organismo proveedor (ORGANISMO) y los tags asociados según la definición del protocolo.
La guía recomienda almacenar localmente la ruta del endpoint y sus parámetros, y consultar nuevamente el Service Discovery solo cuando exista un error o cuando el proveedor haya modificado la ruta del servicio.
¶ Identificar el protocolo del servicio
La Red de Interoperabilidad permite que los proveedores expongan sus servicios utilizando distintos protocolos, los cuales pueden ser seleccionados libremente por cada organismo proveedor.
Para interoperar correctamente, el nodo debe identificar el protocolo indicado en los metadatos del endpoint, específicamente en el campo TYPE.
Solo se consideran válidos los protocolos incluidos en la guía o aquellos validados por la Secretaría de Gobierno Digital, según lo indicado en el "Protocolos validos".
¶ Obtener permisos para el servicio
Una vez obtenido el endpoint y los metadatos que definen el protocolo, el nodo debe solicitar autorización para utilizar el servicio.
Cada protocolo establece sus propios mecanismos de autorización, que pueden requerir permisos desde los servicios centralizados, tokens específicos provistos por el organismo proveedor o mecanismos basados en plataformas externas como OAuth2.
Los detalles específicos para la autorización se encuentran descritos en "Autorización y Autenticación".
¶ 3.7 Publicación y administración de servicios
Los organismos pueden administrar los servicios de interoperabilidad que ponen a disposición de otros OAE a través del Portal PISEE. Desde esta plataforma, cada organismo puede registrar nuevos servicios, modificarlos, eliminarlos y administrar los permisos asociados a cada consumidor.
Para cada servicio publicado, el organismo proveedor debe mantener actualizada la información técnica, de modo que los consumidores puedan conocer su funcionamiento y realizar las integraciones correspondientes.
Entre los datos que deben mantenerse al día se encuentran:
- El nombre del servicio.
- Su descripción.
- El endpoint.
- El protocolo utilizado.
- La información del procedimiento administrativo asociado.
- La periodicidad del servicio cuando corresponda.
Los organismos también pueden consultar, desde el Portal PISEE, los servicios que consumen de otros OAE, incorporarlos a su lista de consumo y administrar los accesos correspondientes.
La guía establece que cualquier cambio relevante en un servicio debe ser actualizado en el catálogo y comunicado mediante los canales formales definidos por Gobierno Digital. Esto permite que los organismos consumidores adapten sus integraciones cuando sea necesario.
¶ 4. Protocolos de comunicación autorizados
La Red de Interoperabilidad permite el uso de distintos protocolos para el intercambio de datos, documentos y expedientes entre organismos. Todos los protocolos deben cumplir las exigencias de seguridad, autenticación, autorización, confidencialidad y trazabilidad establecidas en esta guía. A continuación, se describen los protocolos autorizados.
¶ 4.1 Protocolo de Mensajes para los Órganos de la Administración del Estado (MPGA-1)
El protocolo MPGA-1 permite que los órganos de la Administración del Estado intercambien información de forma segura, estandarizada y trazable. Soporta tanto el envío de mensajes unitarios como la transmisión de archivos de gran tamaño, utilizando siempre los mecanismos de autenticación, autorización, encriptación e integridad definidos por la Red de Interoperabilidad.
¶ Mensajes unitarios
Formato de mensajes
MPGA-1 permite el uso de múltiples formatos para el contenido del mensaje. Se pueden interoperar datos en texto plano, XML, JSON, CSV, YAML o cualquier otro formato requerido por un organismo para cumplir un estándar específico. Para contenido binario no existen restricciones tecnológicas ni de tipo de archivo (PDF, Word, PNG, JPG, etc.).
Todo el contenido del mensaje se envuelve en una estructura PASETO que incluye los datos, metadata del envío y una firma digital que asegura la integridad del mensaje.
La metadata del envío contiene todas las cabeceras del mensaje original, además de una cabecera adicional con el ID de la traza.
Canal de comunicación
El canal de comunicación debe ser HTTP/2 con TLS 1.3 o superior, utilizando obligatoriamente TLS mutuo al establecer la conexión.
Autenticación
La autenticación entre organismos se realiza mediante la verificación mutua de certificados durante la apertura del canal. Para esta verificación es necesario haber obtenido previamente las llaves públicas de los certificados de las contrapartes desde el Repositorio de Certificados Públicos.
Autorización
Una vez autenticadas ambas partes, el nodo consumidor debe obtener un token de autorización desde el Punto de Conexión, el cual devolverá el permiso correspondiente si el organismo cuenta con acceso al servicio solicitado.
Este token es un JWT firmado digitalmente, que debe adjuntarse en cada mensaje enviado al proveedor. El proveedor valida su firma y revisa que el permiso corresponda al servicio solicitado. No es necesario solicitar un token por cada mensaje, ya que puede utilizarse durante todo su periodo de validez.
Debido a que MPGA-1 transporta el mensaje original completo, los organismos pueden aplicar controles adicionales, como Oauth2, API Keys o tokens internos, según sus necesidades particulares.
Encriptación de mensajes
La encriptación se realiza mediante las propiedades del canal TLS 1.3, que garantiza confidencialidad en tránsito.
Incorruptibilidad de mensajes
La integridad del mensaje se garantiza mediante la firma digital incluida en la envoltura PASETO. El receptor verifica esta firma utilizando la llave pública del organismo emisor almacenada en el Repositorio de Certificados Públicos, asegurando que el contenido no haya sido alterado y que el origen sea auténtico.
¶ Envío de grandes archivos (MPGA-File)
MPGA-File es un subprotocolo de MPGA-1 diseñado para transmitir archivos de gran tamaño mediante streaming directo entre los nodos.
El proceso inicia con el envío de un mensaje MPGA que contiene la metadata del archivo. Luego se abre un canal temporal para la transmisión punto a punto del archivo. Una vez completado el envío, el receptor devuelve un mensaje confirmando la recepción.
Formato de mensajes de grandes archivos
El envío consta de dos mensajes:
- Metadata: con el formato estándar MPGA.
- Archivo: enviado tal como es, sin un formato particular, mediante el canal de streaming.
Canal de comunicación
La conexión se realiza mediante HTTP/2 en un canal persistente y bidireccional. Para abrir el canal se deben enviar dos cabeceras:
- “Authorization” con el token de permiso.
- “X-PISEE-META” con la metadata codificada en el formato esperado por el receptor.
Tras completar la transmisión del archivo, el receptor confirma la recepción y se cierra el canal HTTP/2.
Autenticación
La autenticación es la misma que en MPGA-1, basada en verificación mutua de certificados.
Autorización
La autorización también es la misma que en MPGA-1 y utiliza el token obtenido desde los servicios centralizados.
Encriptación de mensajes
Tanto la metadata como el archivo se transmiten encriptados mediante TLS 1.3.
Incorruptibilidad de mensajes
La metadata utiliza el mecanismo de integridad de MPGA-1. Para el archivo, la verificación se realiza mediante un hash enviado dentro de la metadata del primer mensaje, permitiendo confirmar que el archivo recibido coincide con el enviado.
¶ 4.2 Protocolo de Mensajes para los Órganos de la Administración del Estado (MPGA-2)
La Red de Interoperabilidad del Estado dispone de un segundo protocolo denominado MPGA-2, diseñado para transmisiones de datos a alta velocidad mediante streaming. Este protocolo mantiene los requisitos de seguridad, autenticación, autorización e integridad establecidos en la guía, y permite el intercambio de información en cualquier formato, tanto textual como binario.
¶ Formato de mensajes
MPGA-2 permite enviar datos en cualquier formato, sin restricciones sobre si el contenido es texto o binario. Todo el mensaje original se incluye íntegramente dentro de una estructura Protobuf, que contiene:
- Datos enviados por el organismo.
- Metadata del envío.
- Firma digital para garantizar la integridad.
La diferencia con MPGA-1 es que el mensaje original se adjunta sin codificación, en binario, y la envoltura se define completamente en Protobuf.
La definición de la envoltura Protobuf utilizada por MPGA-2 está especificada en la guía e incluye los mensajes, estructuras, servicios y enumeraciones necesarios para realizar la transmisión por streaming. Esta estructura define elementos como ULID del mensaje, firma digital, indicadores de respuesta, tipo de autorización, cuerpo original de la solicitud (incluyendo método HTTP, headers, parámetros y cuerpo), así como estructuras de resultado y tipos de autorización.
(En tu documento esta definición irá incluida tal como aparece en el archivo original.)
syntax = "proto3";
package poroto;
option go_package = "MPGA2/mpga2_message";
service ProductService{
rpc SendMPGA2(stream MPGA2) returns (stream MPGA2){}
rpc GetToken(TokenRequest) returns (TokenRequest){}
}
enum AutorizationType {
AUTORIZACION_OAE = 0;
AUTORIZACION_CIUDADANA = 1;
AUTORIZACION_FIJA = 2;
}
enum MethodType {
GET = 0;
HEAD = 1;
POST = 2;
PUT = 3;
DELETE = 4;
CONNECT = 5;
OPTIONS = 6;
TRACE = 7;
PATCH = 8;
}
message MPGA2 {
reserved 6 to 10, 14 to 19;
string ulid = 1;
string signature = 2;
bool isResponse = 4;
bool confidencial = 5;
Resultado resultado = 11;
Autorization autorization = 12;
OriginalRequest originalRequest = 13;
}
message Autorization {
reserved 6 to 10;
AutorizationType tipo = 1;
string service = 2;
string organismoOrigen = 3;
string organismoDestino = 4;
string token = 5;
}
message OriginalRequest {
reserved 7 to 10;
MethodType metodo = 1;
bytes body = 2;
map<string, string> header = 3;
map<string, string> pathparam = 4;
map<string, string> queryparam = 5;
bool multipart = 6;
}
message Resultado {
reserved 3 to 10;
int32 status = 1;
string error = 2;
}
message HealthCheckRequestResponse {
reserved 5 to 10;
string service = 1;
bool status = 2;
bool dial = 3;
bool head = 4;
}message TokenRequest {
reserved 5 to 10;
string servicio = 1;
string organismoSolicitante = 2;
string organismoAutorizador = 3;
string token = 4;
}
¶ Canal de comunicación
El protocolo MPGA-2 utiliza un canal basado en streaming, permitiendo transmisiones sostenidas y de alta velocidad. De acuerdo con el archivo, la operación se realiza mediante un servicio Protobuf que define métodos de envío de mensajes MPGA-2 en ambos sentidos (bidireccional).
El canal utiliza una conexión persistente que permite enviar y recibir mensajes continuos según la definición de rpc SendMPGA2(stream MPGA2) returns (stream MPGA2).
¶ Autorización y autenticación
MPGA-2 incluye dentro de su estructura Protobuf un bloque completo de autorización, que define:
- Tipo de autorización (OAE, ciudadana o fija).
- Servicio solicitado.
- Organismo origen y organismo destino.
- Token de autorización.
El token viaja dentro de la estructura Protobuf y puede ser solicitado mediante el método GetToken, también definido en el servicio Protobuf.
La autenticación entre nodos sigue las mismas reglas generales de MPGA-1 (certificados y validación mutua), aunque MPGA-2 no redefine este proceso porque depende del canal seguro establecido previamente.
¶ Encriptación
El cifrado no se realiza en la estructura Protobuf sino en el canal de transporte, siguiendo las mismas exigencias que MPGA-1 (TLS en la conexión establecida). MPGA-2 transmite su contenido binario a través de ese canal cifrado.
¶ Integridad de mensajes
La estructura Protobuf incluye un campo de firma digital (signature), que permite validar la integridad del mensaje recibido y verificar que el contenido no haya sido alterado. La verificación se realiza utilizando la llave pública del organismo emisor que está almacenada en el Repositorio de Certificados Públicos.
¶ 4.3 Protocolo SOAP sobre PISEE 1
El protocolo SOAP sobre PISEE 1 corresponde a un mecanismo heredado de la primera versión de la Plataforma Integrada de Servicios Electrónicos del Estado. Permite la comunicación entre organismos mediante mensajes XML estructurados y transportados sobre HTTP, manteniendo compatibilidad con servicios que aún funcionan bajo este estándar.
Formato de mensajes
Los mensajes se estructuran en XML bajo la forma de un “sobre” SOAP, que contiene encabezados y cuerpo según las especificaciones tradicionales de este estándar.
Canal de comunicación
La comunicación se realiza sobre HTTP/1.1 protegido con TLS 1.2 o superior, asegurando cifrado durante el tránsito de la información.
Autenticación
La autenticación se efectúa mediante credenciales enviadas por el mecanismo de autenticación básica de HTTP.
Autorización
La autorización es administrada por el servidor PISEE 1, que mantiene el registro de organismos autorizados a consumir cada servicio disponible.
Encriptación de mensajes
El cifrado de los mensajes se garantiza mediante el uso de TLS 1.2 o superior en el canal de comunicación.
Integridad de mensajes
El protocolo SOAP sobre PISEE 1 no incorpora mecanismos adicionales de integridad más allá de los proporcionados por la capa TLS.
¶ 4.4 Protocolos validados por la Secretaría de Gobierno Digital
Además de los protocolos nativos de la Red de Interoperabilidad (MPGA-1, MPGA-File y MPGA-2), los organismos pueden utilizar protocolos externos o previamente existentes, siempre que cumplan las exigencias de seguridad, trazabilidad y autenticación establecidas en esta guía. Estos protocolos deben ser validados formalmente por la Secretaría de Gobierno Digital a través de la Mesa de Servicios antes de su uso en la Red.
Protocolos del Ministerio de Bienes Nacionales (GeoNooe)
Corresponden a servicios web utilizados para la publicación e intercambio de información geoespacial. Están documentados por el Ministerio de Bienes Nacionales (IDE Chile). Los mensajes pueden utilizar XML o JSON, dependiendo del servicio, y operan sobre canales HTTPS con cifrado TLS 1.2 o superior vease https://www.ide.cl/index.php/geonodo2/manual-geonodo.
Protocolos del Servicio de Impuestos Internos (SII)
El SII utiliza servicios web que pueden operar en JSON o XML según el tipo de servicio tributario. Estos servicios aceptan dos mecanismos de autorización: token propio del SII u Oauth-2. Funcionan sobre HTTP/1.1 protegido con TLS 1.2 o superior.
Protocolos del Servicio de Registro Civil e Identificación (SRCeI)
Estos servicios están basados en REST, utilizan formato JSON y operan sobre HTTP/1.1 con cifrado TLS 1.2 o superior. Incluyen mecanismos propios de autorización y validación que deben ser respetados por los organismos consumidores.
Otros protocolos
La Secretaría de Gobierno Digital puede validar protocolos adicionales siempre que:
- cumplan con los requisitos de seguridad y trazabilidad definidos en esta guía,
- utilicen cifrado robusto mediante TLS,
- incluyan mecanismos verificables de autenticación y autorización,
- sean compatibles con la operación de la Red de Interoperabilidad.
Los organismos que requieran utilizar un protocolo distinto a los descritos deben solicitar su validación aportando antecedentes técnicos y de seguridad a través de la Mesa de Servicios.
¶ 5. Glosario
| Término | Definición |
| Canal doble de comunicación (pull - push) | Existiendo dos partes en un canal de comunicación, el método Pull permite recibir peticiones con origen en la otra parte, y responderlas. El método Push, en cambio, permite enviar datos a la otra parte sin necesidad de una petición previa. Un canal de comunicación puede permitir exclusivamente alguna de estas formas, o si es bidireccional, permitir ambas. |
| Consul | Es una herramienta de Hashicorp, cuya función principal es facilitar la comunicación entre servicios productores y consumidores, llevando a cabo el registro y descubrimiento de los mismos. Sus características más importantes son: descubrimiento de servicios, Health checking a nivel de servicio, y almacenamiento clave-valor. |
| GeoNodo | Componente de software alojado en la infraestructura informática de un órgano de la Administración del Estado, que le permite interoperar datos geoespaciales con otros organismos del Estado, cumpliendo con los estándares y protocolos definidos en la Norma Técnica de Interoperabilidad. |
| HTTP 1.1 | Es el protocolo de comunicación que permite las transferencias de información a través de archivos (XML, HTML, etc.) en la World Wide Web. |
| HTTP/2 | Protocolo de Transferencia de Hipertexto, versión 2; es un protocolo de red utilizado por la World Wide Web que llega con el objetivo de actualizar el protocolo HTTP/1.1, con el que es compatible. |
| Legacy System | Es un sistema informático (equipos informáticos o aplicaciones) que ha quedado anticuado, pero que sigue siendo utilizado por el usuario/a (generalmente, una organización o empresa) y no se quiere o no se puede reemplazar o actualizar de forma sencilla. |
| Punto de conexión a los Servicios centralizados | Herramienta de software por medio de la cual los nodos se comunican con los Servicios Centralizados de Interoperabilidad e intercambian información de trazabilidad, permisos, certificados y servicios. |
| Repositorio de Certificados Públicos | Repositorio de las llaves públicas que permiten a los órganos de la Administración del Estado validar la identidad de otros organismos que se conectan con ellos a través de la Red de interoperabilidad. |
| Multiplexación | Se refiere al mismo concepto si se trata de buses de datos que haya que compartir entre varios dispositivos (discos, memoria, etc.). Otro tipo de multiplexación en informática es el de la CPU, en la que a un proceso le es asignado un quantum de tiempo durante el cual puede ejecutar sus instrucciones, antes de ceder el sitio a otro proceso que esté esperando en la cola de procesos listo a ser despachado por el planificador de procesos. |
| Mutual TLS | Es un método de autenticación mutua que garantiza que las partes de cada extremo de una conexión de red son quienes dicen ser, verificando que ambas tienen la clave privada correcta. La información incluida en sus respectivos certificados TLS proporciona una verificación adicional. |
| OAE | Órgano de la Administración del Estado. |
| Oauth2 | OAuth 2 es un framework de autorización, que permite a las aplicaciones obtener acceso (limitado) a las cuentas de usuario de determinados servicios. Consiste en delegar la autenticación de usuario al servicio que gestiona las cuentas, de modo que sea éste quien otorgue el acceso para las aplicaciones de terceros. OAuth 2 provee un flujo de autorización para aplicaciones web, aplicaciones móviles e incluso programas de escritorio. |
| PASETO | Paseto (Platform-Agnostic SEcurity TOkens) es una especificación e implementación de referencia para tokens seguros sin estado. |
| PISEE 1 | Primera versión de la Plataforma Integrada de Servicios Electrónicos del Estado. |
| Service Discovery | Es el proceso de detección automática de dispositivos y servicios en una red informática. Esto reduce la necesidad de configuración manual por parte de usuarios y administradores. |
| Servicio Web de Interoperabilidad | Pieza de software diseñada para intercambiar datos entre aplicaciones a través de una red, utilizando estándares y protocolos abiertos. |
| SGD | Secretaría de Gobierno Digital, del Ministerio de Hacienda. |
| Timeout | Es una situación donde un llamado del cliente a un recurso alojado en un servidor no obtiene resultado después de un periodo de tiempo predefinido. |
| Mensaje Unitario | Es un mensaje que busca transmitir o consultar datos, documentos o expedientes relativos a un procedimiento individual a diferencia de los procesos masivos donde se intercambian múltiples datos en un solo mensaje.. |
| Protobuf, Protobuffer o Protocol Buffers | Es un formato de serialización de datos binario y eficiente, desarrollado por Google, que permite a los desarrolladores definir estructuras de datos en un archivo .proto y luego generar código fuente en varios lenguajes para serializar y deserializar esas estructuras |
| Proveedor | Órgano de la administración del Estado que ofrece un servicio web de interoperabilidad al cual otros OAE podrían acceder si cuentan con los permisos necesarios. |
| Consumidor | Órgano de la administración del Estado que consulta un servicio web de interoperabilidad provisto por otro OAE. |
¶ Agradecimientos
La Secretaría de Gobierno Digital agradece la colaboración de las siguientes personas, quienes participaron en el proceso validación del contenido mínimo que debe contener esta guía, fortaleciendo la calidad técnica de este documento:
- Alejandro Vera (CHILETEC)
- Boris de los Ríos (Corporación Municipal de Renca)
- Camila Gatica (ACTI)
- Federico Burgos (ACTI)
- Isabel Barboza (Newtenberg)
- José Flores (CHILETEC)
- Jose Correa (U. Chile)
- Marco Antonio Orellana (ACTI)
- Paulina Rivera (Chiletec)
- Thierry de Saint Pierre (ACTI)
- Tomas Araneda (ACTI)
- Verónica Achá (Ministerio de Desarrollo Social y Familia)
- Willy Giese (ACTI)
¶ 6. Anexos
¶
6.1 Formato tipo de consentimiento informado
Para llevar a cabo este procedimiento administrativo, se requiere acceder a los siguientes datos personales sensibles y/o documentos que contienen datos sensibles, los cuales serán solicitados a los órganos que se indican:
- [Dato y/o documento 1 requerido], solicitado a [Nombre del órgano 1]
- [Dato y/o documento 2 requerido], solicitado a [Nombre del órgano 2]
- [Etc.]
Por este acto, usted consiente de forma libre, específica, informada e inequívoca que las instituciones públicas mencionadas remitan digitalmente los datos y/o documentos indicados a [nombre del OAE], sólo para la tramitación del procedimiento administrativo. Este consentimiento se otorga en conformidad con lo dispuesto en la Ley N°19.628 y sus modificaciones, y permite prescindir de la entrega física de dichos documentos, facilitando la tramitación del procedimiento administrativo.
Usted tiene derecho a:
- Acceder a sus datos personales tratados por [nombre del OAE].
- Solicitar la rectificación, actualización o supresión de sus datos cuando corresponda.
- Revocar este consentimiento en cualquier momento, sin efectos retroactivos sobre las gestiones ya realizadas durante su vigencia.
En caso de revocar o negar su consentimiento, usted será responsable de presentar personalmente los documentos requeridos dentro de los plazos establecidos. El incumplimiento de esta obligación podría dar lugar a lo dispuesto en el artículo 43 de la Ley N°19.880, relativo al abandono del procedimiento.
Los datos personales serán tratados conforme a los principios de licitud, finalidad, proporcionalidad y seguridad establecidos en la Ley N° 19.628 y sus modificaciones. Se adoptarán las medidas técnicas y organizativas necesarias para garantizar la confidencialidad, integridad y disponibilidad de la información.
Para ejercer sus derechos o realizar consultas relacionadas con el tratamiento de sus datos personales, puede contactar a:
- Responsable del tratamiento: [Nombre del OAE]
- Correo electrónico: [correo@oae.cl]
- Dirección: [Dirección del OAE]
¿Autoriza expresamente a que las instituciones públicas que posean la información necesaria para tramitar este procedimiento administrativo la remitan digitalmente a [nombre del OAE]?
[ ] Sí, autorizo
[ ] No autorizo
¶ 6.2 Directorio de Datos - Campos mínimos
El Directorio de Datos contendrá el nombre del dato, su descripción y el órgano de la Administración del Estado, responsable del mismo. Cada dato deberá definir los siguientes metadatos:
- Nombre: nombre descriptivo del dato.
- Descripción: descripción del dato.
- Clasificación: clasificación del dato; sensible, estadístico, secreto, reservado u otros, según la ley N° 19.628 y el resto de la normativa vigente aplicable.clasificación del dato; sensible
- Ámbito: espacio designado por el OAE donde se desarrollan las acciones; económico, salud, educación, etc.
- Fecha ingreso: fecha de incorporación del dato al Directorio.
- Fecha última actualización: fecha de la última modificación en alguna característica del datos.
- Periodicidad: periodo con el que se actualiza el dato por parte del proveedor.: Funcionario designado como responsable del OAE mediante CTD.
- Vigencia del dato: los datos mantienen una vigencia, la que depende del tipo de dato, esta vigencia del dato es establecida por el propio OAE, por ejemplo, el dato dirección puede cambiar, no así el dato fecha de defunción o de nacimiento (en caso de existir un caso de borde, este debe ser validado por la OAE en conjunto con SGD).
- Órgano proveedor: código del OAE proveedor del dato acorde al Gestor de Códigos.
- Órgano(s) que consume(n) el dato: este dato se extrae desde el Catálogo de servicios, el cual posee la información de los OAE que consumen el dato, por lo tanto no es necesario que el OAE responsable lo ingrese.
- Ejemplo: Entrega de un ejemplo de la información contenida para entendimiento de los usuarios de dichos datos (XML, JSON, etc).
¶ 6.3 Mecanismos de Encriptado
Los mecanismos de encriptado son técnicas que protegen la información mediante la codificación de datos. El encriptado permite que solo las personas o sistemas autorizados puedan decodificar y entender la información.
Para la Red de interoperabilidad es necesario que todas las comunicaciones pasen encriptadas desde el origen hasta el destino y para ello se deben utilizar mecanismos de encriptado seguro que lo permitan.
Los mecanismos de encriptado del canal de comunicación permitidos deben ser del tipo de encriptado asimétrico en el cual se utilizan dos claves diferentes (pública y privada) que están vinculadas entre sí matemáticamente, el OAE que encriptando los datos mantiene en secreto la clave privada, mientras que la clave pública se comparte entre los receptores autorizados. También está permitido el encriptado simétrico solo si la llave utilizada para el encriptado fue calculada mediante métodos seguros para el intercambio de claves (por ejemplo Diffie-Hellman)
El encriptado simétrico puede ser utilizado opcional y adicionalmente para encriptar el contenido del mensaje lo cual no es parte del alcance de la presente guía ya que en la Red de interoperabilidad el contenido de los mensajes no está regulado.
¶ 6.4 Uso de TLS
El cifrado del canal de comunicación es obligatorio para todas las transacciones realizadas a través de la Red de Interoperabilidad. Para ello, los nodos y servicios centralizados deben utilizar TLS (Transport Layer Security) como mecanismo de protección de extremo a extremo. Versión mínima permitida:
- TLS 1.2 (solo para servicios heredados, como SOAP sobre PISEE 1).
- TLS 1.3 (requerido para MPGA-1, MPGA-File y MPGA-2).
Requisitos generales:
- El canal debe establecerse utilizando mutual TLS (mTLS), es decir, ambas partes deben autenticarse mediante certificados digitales válidos.
- Las suites criptográficas deben estar alineadas con las políticas de seguridad vigentes del Estado.
- El cifrado debe aplicarse desde el nodo emisor hasta el nodo receptor, sin tramos intermedios sin cifrar.
Cifrado asimétrico:
TLS utiliza un mecanismo basado en pares de claves (pública/privada) para negociar un canal seguro. La clave privada nunca debe salir del OAE propietario.
Cifrado simétrico:
Adicionalmente, los organismos pueden aplicar cifrado simétrico dentro del contenido del mensaje, siempre que la clave haya sido intercambiada mediante mecanismos seguros como Diffie-Hellman. Este cifrado opcional no sustituye al cifrado obligatorio del canal.
El uso de TLS asegura confidencialidad, integridad y autenticidad en toda comunicación dentro de la Red de Interoperabilidad.
¶ 6.5 Estructura JSON de trazabilidad
La siguiente estructura representa el formato JSON completo que los nodos deben enviar al Registro de Trazabilidad. Los campos marcados con (*) serán incorporados por la Secretaría de Gobierno Digital durante 2026.
Descripción general:
- id: Identificador único compuesto por el código del organismo y un ULID.
- tipo_traza:
1 = envío de consulta
2 = recepción de consulta
3 = envío de respuesta
4 = recepción de respuesta
- Los campos “run”, “gestión”, “plazo” y “token_autorizacion_sensible” aplican cuando se interoperan datos sensibles.
¶ 6.6 Especificación Protobuf del protocolo MPGA-2
El siguiente fragmento resume la estructura Protobuf utilizada por el protocolo MPGA-2 para transmisiones mediante streaming. Corresponde al archivo .proto definido en la guía.
(Nota: se presenta tal como debe implementarse, sin simplificaciones.)
Este anexo permite a los equipos de desarrollo implementar MPGA-2 correctamente, replicando el formato exacto esperado por la Red de Interoperabilidad.
¶ 6.7 Referencia al Gestor de Códigos
El Gestor de Códigos es el repositorio oficial que contiene los identificadores únicos de todos los Órganos de la Administración del Estado (OAE). Estos códigos se utilizan en:
- trazabilidad,
- permisos,
- certificados,
- definiciones de servicios,
- intercambio de mensajes.
Contenido del Gestor de Códigos:
- código del organismo,
- nombre oficial,
- sigla institucional (cuando corresponde),
- tipo de organismo (ministerio, servicio, municipalidad, superintendencia, etc.).
Uso en la Red de Interoperabilidad:
- El campo consumidor y proveedor del JSON de trazabilidad debe utilizar el código del organismo registrado en el Gestor.
- Los certificados institucionales también se indexan por código de organismo.
- La autorización MPGA-1 y MPGA-2 requiere estos códigos para identificar origen y destino.
- El Portal PISEE usa estos códigos internamente para identificar servicios publicados y consumidos.
Dónde obtenerlo:
El Gestor de Códigos se encuentra disponible como servicio centralizado administrado por la Secretaría de Gobierno Digital.
Los organismos deben consultarlo mediante el Punto de Conexión o a través de la Mesa de Servicios cuando requieran información actualizada.