Formato de intercambio

1- Antecedentes

El Formato de Intercambio de Documentos se basa fuertemente en dos estándares de amplia adopción:

PDF (Norma ISO 32000-1), específicamente en la definición de PDF/A para el almacenamiento de documentos electrónicos a largo plazo, plasmado originalmente en la
Norma ISO 19005-1:2005
XML meta-lenguaje desarrollado por el World Wide Web Consortium (W3C).

Un expediente consiste en un documento XML, que contiene:

Una sección para los metadatos, compuesta de un elemento <Metadatos> que a su vez contiene cada uno de los metadatos generales del expediente.
Una sección para las carátulas, compuesta de un elemento <Caratulas> que a su vez contiene:
- La carátula original en un PDF codificado base64.
- La(s) firma(s) correspondiente(s).
- (Opcional) Las carátulas generadas a partir de los sucesivos cambios de carátula, cada una de ellas con la(s) firma(s) correspondiente(s).
Una sección para cada actuación, compuesta de un elemento <Actuaciones> que a su vez contiene:
- La actuación propiamente dicha en un PDF codificado base64.
- Una sección para los adjuntos, compuesta por un elemento <Adjuntos> que a su vez contiene la información de cada uno de los Adjuntos que conforman la actuación.
- La(s) firma(s) correspondiente(s).
- La firma digital de la firma de la carátula vigente y de las firmas a las modificaciones de la carátula que existieran, así como de todas las firmas de las actuaciones, firmado con la clave del funcionario actuante.
Una sección para los expedientes acordonados (en caso de que el expediente los tenga), compuesta de un elemento <Acordonados> que contiene a su vez la información de referencia a cada expediente acordonado.

Dado que las firmas se realizan siempre en el cliente, para reducir el tiempo de transferencia siempre se firma un hash SHA256 del objeto a firmar. En todo el documento cuando se indica “se firma el objeto” quiere decir “se realiza un hash del objeto con el algoritmo SHA256 y se firma el hash”.

Cuando un expediente en formato FIDO se almacena en un archivo, este deberá llevar la extensión .fido.

2- Diagráma esquemático de expediente sin acordonados

Esta es la estructura básica XML de un expediente electrónico sin acordonados:

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Caratula>

</Caratulas>

</Firmas>

</Actuacion>

</Actuaciones>

</Expediente>

</FIDO>

3- Diagrama esquemático de expediente con acordonados

La estructura básica XML de un expediente electrónico con acordonados es la siguiente:

En cada elemento <Acordonado> de la colección de <Acordonados> se incluye la información de referencia al expediente electrónico que se acordonó.

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Caratula>

</Caratulas>

</Firmas>

</Actuacion>

</Actuaciones>

</Acordonados>

</Expediente>

</FIDO>

4- Diagrama esquemático de expediente con acordonados

4.1- Expedientes originales

Imaginemos un escenario donde tenemos tres expedientes electrónicos:

Expediente 2017-67-001-000043 (principal):

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratula>

</Caratulas>

</Firmas>

</Actuacion>

</Actuaciones>

</Expediente>

</FIDO>

Expediente electrónico 2017-67-001-000065:

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratula>

</Caratulas>

</Firmas>

</Actuacion>

</Actuaciones>

</Expediente>

</FIDO>

Expediente electrónico 2017-67-001-000076:

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratula>

</Caratulas>

</Firmas>

</Actuacion>

</Actuaciones>

</Expediente>

</FIDO>

4.2- Acordonar expedientes

Luego de acordonar los expedientes 2017-67-001-000065 y 2017-67-001-000076 al expediente 2017-67-001-000043 la estructura de los expedientes quedaría de la siguiente forma:

Expediente 2017-67-001-000043 (principal):

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratulas>

</Actuacion>

<Contenido ee-involucrados="[2017-67-001-000065,2017-67-001-000076]"

resultado-acordonado="[2017-67-001-000065,2017-67-001-000076]">

</Contenido>

</Actuacion>

</Actuaciones>

<![CDATA[https://servidor/2017-67-001-000065.fiee]]>

</Datos>

</Acordonado>

<![CDATA[https://servidor/2017-67-001-000076.fiee]]>

</Datos>

</Acordonado>

</Acordonados>

</Expediente>

</FIDO>

Expediente electrónico 2017-67-001-000065:

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratulas>

</Actuacion>

</Actuacion>

</Actuaciones>

</Expediente>

<TipoAsociacion>Acordonado</TipoAsociacion>

</Asociacion>

</FIDO>

Expediente electrónico 2017-67-001-000076:

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratulas>

</Actuacion>

</Actuacion>

</Actuaciones>

</Expediente>

<TipoAsociacion>Acordonado</TipoAsociacion>

</Asociacion>

</FIDO>

4.3- Desacordonar expedientes

Luego de desacordonar el expediente 2017-67-001-000076 la estructura de los expedientes quedaría de la siguiente forma:

Expediente 2017-67-001-000043 (principal):

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratulas>

</Actuacion>

<Contenido ee-involucrados="[2017-67-001-000065,2017-67-001-000076]"

resultado-acordonado="[2017-67-001-000065,2017-67-001-000076]">

</Contenido>

</Actuacion>

<Contenido ee-involucrados="[2017-67-001-000076]"

resultado-acordonado="[2017-67-001-000065]">

</Contenido>

</Actuacion>

</Actuaciones>

<![CDATA[https://servidor/2017-67-001-000065.fiee]]>

</Datos>

</Acordonado>

</Acordonados>

</Expediente>

</FIDO>

Expediente electrónico 2017-67-001-000065:

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratulas>

</Actuacion>

</Contenido>

</Actuacion>

</Actuaciones>

</Expediente>

<TipoAsociacion>Acordonado</TipoAsociacion>

</Asociacion>

</FIDO>

Expediente electrónico 2017-67-001-000076:

<?xml version="1.0" encoding="UTF-8"?>

<FIDO>

</Metadatos>

</Caratulas>

</Actuacion>

</Contenido>

</Actuacion>

</Contenido>

</Actuacion>

</Actuaciones>

</Expediente>

</FIDO>

5- Ejemplo de expediente sin acordonados en FIDO

Este ejemplo se puede observar en el archivo Ej_FIDO_sin_acordonado.xml que puede descargarse del site de Agesic.

6- Ejemplo de expediente acordonado en FIDO

Este ejemplo se puede observar en el archivo Ejemplos_FIDO.zip que puede descargarse del site de Agesic.

7- Descripción detallada

A continuación se describen los elementos que componen el expediente.

7.1- Elemento FIDO

El elemento <FIDO> es el elemento principal de la estructura XML, contiene al elemento <Metadatos>, al elemento <Expediente> y al elemento <Asociacion> (en caso de que el expediente esté asociado a otro).

<?xml version="1.0" encoding="UTF-8"?>

<FIDO xmlns="http://www.datos.gub.uy/def/vocabulario/core/documentoelectronico"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.datos.gub.uy/def/vocabulario/core/documentoelectronico FIDO.xsd">

</FIDO>

7.2- Metadatos

7.2.1- Elemento Metadatos

El elemento <Metadatos> es el contenedor de cada metadato del expediente electrónico.

<Titulo>Expediente Electrónico</Titulo>

<Hash content-type="text/plain" name="hashmeta" content-transfer-encoding="base64"

filename="hashmeta">

<![CDATA[

df9aeb3a59d1e1d3f80e1c127a9d2c8ddb5b668850fda5cbb31676a99bfc5309

]]>

</Hash>

</Metadatos>

Estos Metadatos son:

<Identificador>: Número asignado por el organismo para el expediente, preferiblemente, pero no obligatoriamente, en el formato aaaa-ii-uuu-nnnnnn donde aaaa corresponde al año, ii al inciso, uuu a la unidad ejecutora y nnnnnn al número de expediente. (obligatorio).
<Version>: Versión del FIDO que se está utilizando (obligatorio).
<Titulo>: Asunto del expediente electrónico (obligatorio).
<Autor>: Identificación del organismo público/ciudadano/empresa autor/a del documento electrónico (opcional).
<FechaCreacion>: Fecha de creación del contenido del expediente electrónico (obligatorio).
<Estado>: Estado del expediente electrónico (opcional).
<TipoDocumental>: Código de objeto UNAOID. Para Expediente electrónico es el número 66570 (obligatorio).
<Hash>: Hash de los metadatos obligatorios que no se modifican a lo largo de la vida del Expediente. Estos son: Identificador, Versión, Fecha de creación y Tipo de forma documental. Se genera utilizando el algoritmo SHA256.
El FIDO permite además que se puedan incluir metadatos complementarios no especificados en el esquema. Los metadatos complementarios atienden a necesidades de descripción específicas de nuevos requerimientos del negocio y son dependientes del tipo del expediente. De esta manera el tipo del expediente define los metadatos complementarios requeridos a ser incluidos en el Expediente Electrónico.

7.3- Expediente

7.3.1- Elemento Expediente

Es el elemento contenedor de las colecciones de <Caratulas>, <Actuaciones>, <Adjuntos> y <Acordonados> (en caso de que existan).

7.4- Carátula

7.4.1- Elemento Carátula

El elemento <Caratulas> es el contenedor de cada <Caratula> que a su vez es el contenedor de la información de la carátula, el <Contenido>, el <Hash> y la <Firma>

7.4.2- Carátula original

Todo expediente en formato FIDO tiene obligatoriamente una carátula original, que es la primera que aparece en la colección de carátulas del XML. La carátula original está firmada por el(los) funcionario(s) actuante(s) pero no contiene la firma de las firmas anteriores.

7.4.3- Contenido de la Carátula

Es el PDF que representa la caratula codificado en base64. Por medio del atributo tipo-dato del elemento <Datos> se puede saber dónde ubicar el contenido de PDF:

Si el valor es Binario: El CDATA contiene la información del PDF.
Si el valor es Referencia: El CDATA contiene el enlace a la ubicación del archivo PDF.

<Contenido content-type="application/pdf" name="car0.pdf"

content-transfer-encoding="base64" filename="car0.pdf"

caratula-version="0" caratula-nropaginas="1"

fecha="2017-02-25T13:37:17-03:00" id-organismo="11-003"

oid-organismo="2.16.858.0.0.0.1.1.12.0.1"

asunto="Información importante" clasificacion="1"

email-organismo="correo@organismo.com"

domicilio-electronico-organismo="Domicilio Organismo">

<![CDATA[

JVBERi0xLjQKJeLjMiAwIG9iaiA8PC9JbnRlbnQvUGVyY2VwdHVhbC9EZWNvZGVQYXJtczw8

L0NvbG9ycyAzL1ByY3RvciAxNS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sdW1ucyAzMTE+Pi9U

eXBlL1hPYmplY3Qvsb3JTcGFjZVsvQ2FsUkdCPDwvTWF0cml4WzAuNDEyMzkgMC4yMTI2NCA

]]>

</Datos>

</Contenido>

Se describen los atributos propios de la carátula:

caratula-version: número de versión de la carátula. El valor 0 es obligatorio para la original, que va siempre en primer lugar, y 1, 2, 3, etc. para las subsiguientes.
caratula-nropaginas: número de páginas que ocupa la carátula. La numeración de la carátula es independiente de la numeración de las actuaciones.
fecha: fecha de la creación de la carátula, que en el caso de la carátula original coincide con la creación del expediente, en formato aaaa-MM-ddTHH:mm:ss donde T indica el inicio de la definición del tiempo.
id-organismo: número de identificación del organismo conformado por el Inciso y la Unidad ejecutora. (Dato incorporado para cumplir el decreto 276/013)
oid-organismo: OID del organismo (Dato incorporado para cumplir el decreto 276/013)
asunto: Asunto (Dato incorporado para cumplir el decreto 276/013)
clasificacion: la clasificación viene dada por las siguientes opciones: 1 para Público, 2 para Reservado, 3 para Confidencial o 4 para Secreto (Dato incorporado para cumplir el decreto 276/013)
email-organismo: correo electrónico del organismo actuante. (Dato incorporado para cumplir el decreto 276/013)
domicilio-electronico-organismo: domicilio electrónico del organismo actuante. (Dato incorporado para cumplir el decreto 276/013)

7.4.4- Hash de la Carátula

A continuación del PDF con la carátula, sigue el hash de la misma. El mismo debe generarse utilizando el algoritmo SHA256.

<Hash content-type="text/plain" name="hashcar0"

content-transfer-encoding="base64" filename="hashcar0">

<![CDATA[

df9aeb3a59d1e1d3f80e1c127a9d2c8ddb5b668850fda5cbb31676a99bfc5309

]]>

</Hash>

7.4.5- Firma de la Carátula

A continuación del hash, sigue la firma. La firma no es la firma del PDF en base64 propiamente dicho sino de un hash del mismo generado con el algoritmo SHA256, especificado anteriormente. La firma deberá incluir el certificado del firmante.

<Firma content-type="application/pkcs7-signature" name="car0.p7s"

content-transfer-encoding="base64" filename="car0.p7s">

<![CDATA[

MIIIKwYJKoZIhvcNoIIIHDCCCBgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBf0w

ggX5MIIE4aADAgECgd0VAAAAAB/qMA0GCSqGSIb3DQEBBQUAMGIxEzARBgoJkiaJk/IsZAEZ

FgNjb20xEjAQBgoJk/IsZAEZFgJzdDEbMBkGCgmSJomT8ixkARkWC2V4cGVkaWVudGVzMRow

]]>

</Firma>

7.4.6- Modificaciones a la Carátula (opcional)

Si se realizan modificaciones a la carátula, las carátulas subsiguientes se agregan como nuevas partes a continuación de la original, tal como se muestra en el código de ejemplo (véase apartado
15 Ejemplo de FIDO).

Al igual que la carátula original, las modificaciones están firmadas por el funcionario actuante, pero a diferencia de las actuaciones, no contienen la firma de las firmas anteriores

7.5 Actuación

7.5.1- Elemento Actuación

El elemento <Actuaciones> es el contenedor de cada <Actuacion> que a su vez es el contenedor de la información de la actuación, el <Contenido>, el <Hash>, las <Firmas> y la <FirmaFirmas>.

<Actuacion id-actuacion="1" tipo="Genérica"

protocol="application/pkcs7-signature" micalg="sha256">

Los atributos de la actuación son:

id-actuacion: Es el identificador de la actuación.
tipo: Especifica el tipo de la actuación.

7.5.2- Contenido de la Actuación

Es el PDF que representa la actuación codificado en base64. Por medio del atributo tipo-dato del elemento <Datos> se puede saber dónde ubicar el contenido de PDF:

Si el valor es Binario: El CDATA contiene la información del PDF.
Si el valor es Referencia: El CDATA contiene el enlace a la ubicación del archivo PDF.

<Contenido content-type="application/pdf" name="act1.pdf"

content-transfer-encoding="base64"

filename="act1.pdf" caratula-version="0"

pagina-inicio="1" pagina-fin="2"

fecha="2017-02-26T11:41:43-03:00">

<![CDATA[

JVBERi0xLjQKJeLjz9AwIG9iajw8L0Jhc2VGb250L1RpbWVzLUJvbGRJdGFsaWMvVHlwZS9G

b250L0VuY29kaW5nL1Fuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjIgMCBv

Ymo8PC9CYXNlRm9udC1lcy1Cb2xkL1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2Rp

]]>

</Datos>

</Contenido>

Se describen los atributos propios del contenido la actuación:

caratula-version: indica la carátula que estaba vigente en el momento de la actuación. Este dato puede ser redundante, pero facilita enormemente la verificación de la cadena de firmas.
pagina-inicio: página inicial de la actuación. En la primera actuación debe ser obligatoriamente 1, en las actuaciones subsiguientes debe ser el final de la actuación anterior más 1.
pagina-fin: número de la última página de la actuación. Debe ser mayor o igual que la página inicial.
fecha: fecha de la actuación en formato aaaa-MM-ddTHH:mm:ss donde T indica el inicio de la definición del tiempo.

7.5.3- Hash de la Actuación

A continuación del PDF de la actuación, sigue el hash de la misma. Dicho hash debe generarse utilizando el algoritmo SHA256. Puede verse el ejemplo seguidamente.

<Hash content-type="text/plain" name="hashact1"

content-transfer-encoding="base64"

filename="hashact1">

<![CDATA[

a2913beb8ba2b2ff44fa200fb640e19634fce0c813876cf089bb31bf9521d108

]]>

</Hash>

7.5.4- Adjuntos de la Actuación

El elemento <Adjuntos> es el contenedor de cada <Adjunto> que forma parte de la Actuación. El CDATA contiene el enlace a la ubicación del archivo adjunto seguido por el hash que debe generarse utilizando el algoritmo SHA256.

<![CDATA[https://servidor/Información adicional.doc]]>

</Datos>

<Hash content-type="text/plain" name="hashadj0"

content-transfer-encoding="base64" filename="hashadj0">

<![CDATA[

df9aeb3a59d1e1d3f80e1c127a9d2c8ddb5b668850fda5cbb31676a99bfc5309

]]>

</Hash>

</Adjunto>

</Adjuntos>

7.5.5- Firmas de la Actuación

A continuación del PDF de la actuación, sigue la firma. La firma no es la firma del PDF en base64 propiamente dicho sino de un hash del mismo generado con el algoritmo SHA256 concatenado con los hash de cada uno de los adjuntos de la actuación. La firma deberá incluir el certificado del firmante.

La actuación puede ser firmada más de una vez (n veces), cada firma tiene la misma estructura y firma el mismo hash original de la actuación.

<Firma content-type="application/pkcs7-signature"

name="act1fir1.p7s" content-transfer-encoding="base64"

filename="act1fir1.p7s">

<![CDATA[

MIIIKwYJKoZIhvcNAQIIHDCCCBgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBf0w

ggX5MIIE4aADAgECAg0VAAAAAB/qMA0GCSqGSIb3DQEBBQUAMGIxEzARBgoJkiaJk/IsZAEZ

FgNjb20xEjAQBgoJkiIsZAEZFgJzdDEbMBkGCgmSJomT8ixkARkWC2V4cGVkaWVudGVzMRow

]]>

</Firma>

</Firmas>

7.6- Firma de las Carátulas y Actuaciones anteriores

Esta última parte de la actuación contiene la firma digital de todas las firmas (firmas de pdfs), de la carátula original y de las firmas de las modificaciones a la carátula, si existieran, así como de las firmas de todas las actuaciones anteriores del expediente. No debe incluir la firma de la actuación actual o última actuación.

Para generar el contenido a firmar se concatenan todas las firmas anteriores, luego se genera un hash con el algoritmo SHA256 y se realiza la firma de ese hash.

En el caso de múltiples actuantes, el estándar requiere que sólo uno de ellos firme la firma de las actuaciones anteriores, procedimiento que habitualmente se realiza en el momento del pase del expediente. La firma deberá incluir el certificado del firmante.

<FirmaFirmas content-type="application/pkcs7-mime"

name="act1firs.p7m" content-transfer-encoding="base64"

filename="act1firs.p7m">

<![CDATA[

MIIIKwYJKoZIhvcNAQIIHDCCCBgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBf0w

ggX5MIIE4aADAgECAg0VAAAAAB/qMA0GCSqGSIb3DQEBBQUAMGIxEzARBgoJkiaJk/IsZAEZ

FgNjb20xEjAQBgoJkiIsZAEZFgJzdDEbMBkGCgmSJomT8ixkARkWC2V4cGVkaWVudGVzMRow

]]>

</FirmaFirmas>

Etiquetas

Programa de Gestión Administrativa Digital Herramientas para organismos

Agencia de Gobierno Electrónico y Sociedad de la Información y del Conocimiento