ADAPTACIONES NECESARIAS EN LAS APLICACIONES DE REGISTRO INTEGRADAS EN LA PLATAFORMA SIR FIRMA, METADATOS Y REFERENCIACIÓN ÚNICA DE DOCUMENTACIÓN

Transcripción

1 SECRETARÍA DE ESTADO DE FUNCIÓN PÚBLICA SECRETARÍA GENERAL DE ADMINISTRACIÓN DIGITAL ADAPTACIONES NECESARIAS EN LAS APLICACIONES DE REGISTRO INTEGRADAS EN LA PLATAFORMA SIR FIRMA, METADATOS Y REFERENCIACIÓN ÚNICA DE DOCUMENTACIÓN Enero 2019 Edición 1.1

2 CUADRO RESUMEN DEL DOCUMENTO Documento: Fichero: Autor: Revisado por: ADAPTACIONES NECESARIAS EN LAS APLICACIONES DE REGISTRO INTEGRADAS EN LA PLATAFORMA SIR FIRMA, METADATADO Y REFERENCIA ÚNICA DE DOCUMENTACIÓN Adaptaciones SIR Firma Metadatado y Referencia Unica 1.0.docx SGAD SGAD CONTROL DE CAMBIOS Edición Fecha Descripción de la Modificación Visado por v1.0 Diciembre 2018 V1.1 Enero 2019 V1.2 Enero 2019 Versión inicial del documento. Se incluye una primera versión del XSD del Fichero Técnico de Metadatos. Se incluye el contenido de los documentos incrustados en la V1.1, en Anexos separados. SGAD SGAD SGAD Página 2

3 ÍNDICE DE CONTENIDO 1 Introducción Alternativas de integración en SIR Adaptaciones en las Aplicaciones de Registro integradas en SIR Libro único de registro Firma de Documentos Adjuntos Metadatado Repositorio único de documentación Envío de documentación adjunta por referencia Escenarios de envío de asientos registrales Escenarios de reenvíos de asientos registrales Escenarios de recepción de asientos registrales Acceso al repositorio de documentación FAQ Cómo se determinan los metadatos variables? Es posible integrarse con la Referencia Única de documentación de forma progresiva? Necesito algún Acuerdo/Convenio para el uso de CSV Storage como repositorio de documentación? El uso de CSV Storage conlleva algún coste? Anexo I: XSD del fichero técnico de Metadatos FicheroTecnico.xsd metadatosdocumentoseni.xsd Anexo II: Sistema de referenciación de documentos INTRODUCCIÓN ESQUEMA DE REFERENCIA A DOCUMENTACIÓN EN UN REPOSITORIO Por qué es necesario el Esquema Nacional de Interoperabilidad? Esquema XSD de la referencia de documentos INTERFAZ DE CONSULTA DE DOCUMENTO GESTIÓN DE DOCUMENTOS DE GRAN TAMAÑO ACCESO A DOCUMENTOS POR PARTE DE VARIAS APLICACIONES DIFERENCIA CON CSV BROKER Y CSV STORAGE COMPATIBILIDAD DEL SISTEMA DE REFERENCIAS CON INSIDE Y REMISIÓN EN LA NUBE 30 7 Anexo III: Repositorios de confianza y directorio de repositorios de confianza Introducción Requisitos que debe cumplir todo repositorio Requisitos recomendados Tipos de repositorios Página 3

4 7.5 Política de borrados Directorio de Repositorios de Confianza Archivo electrónico: repositorio de confianza por excelencia Anexo IV: XSD de Referencia Única Página 4

5 1 Introducción El objetivo de este documento es determinar las adaptaciones que deben realizar las aplicaciones de registro conectadas a la Plataforma SIR como consecuencia de su evolución, en relación a: La simplificación de firmas Metadatado: inclusión de metadatos tanto a nivel de asiento registral como de documentación adjunta. Referenciación Única de la documentación: los documentos anexos dejan de viajar embebidos por la Plataforma SIR y se intercambian a través de repositorios de documentación. 2 Alternativas de integración en SIR Las aplicaciones de registro que se quieran certificar para conectarse a la Plataforma SIR tienen las siguientes opciones: Utilizar la Librería de Intercambio SIR proporcionada por la SGAD para gestionar el intercambio registral y dar solución al metadatado y la referenciación única de los documentos. Implementar los cambios de manera implícita en la propia aplicación de registro. A partir del 01 de Enero de 2019 sólo se certificarán aplicaciones integradas con la Librería de Intercambio SIR. Las aplicaciones que estén cursando su certificación y aquellas ya certificadas que se adapten a la evolución de la Plataforma SIR podrán implementar los cambios por ellas mismas o integrarse con la Librería de Intercambio SIR. 3 Adaptaciones en las Aplicaciones de Registro integradas en SIR 3.1 Libro único de registro De acuerdo a la Ley 39/2015 cada Administración debe anotar sus asientos registrales en un libro único de registro. La SGAD proporciona para ello el Registro Electrónico General de la AGE (REGAGE). Las aplicaciones de registro de otras Administraciones diferentes a la Administración General del Estado podrán anotar en REGAGE o es su propio libro de registro, siempre que cumplan los siguientes requisitos: El número de registro debe ser único y ascendente para registros de Entrada/Salida. Deben generar un justificante de registro con al menos los siguientes datos: o Número de Registro de Entrada/Salida o Fecha y hora de presentación o Origen y Destino o Interesado/Representante o Asunto o Relación de documentos presentados: Hash de cada documento adjunto. El algoritmo hash recomendado es SHA Validez del documento Página 5

6 El hash se debe calcular sobre el documento original, que puede estar firmado o no antes de aplicar la firma por parte de la aplicación de registro. Las aplicaciones integradas con la Librería de Intercambio SIR podrán de igual forma anotar en REGAGE o en su propio libro de registro. La Librería de Intercambio SIR proporciona un método para registrar devolviendo el número de registro y el justificante de registro si se solicita. 3.2 Firma de Documentos Adjuntos La firma de los documentos adjuntos es responsabilidad de la aplicación de registro, incluso para aquellas que utilizan la Librería de Intercambio SIR. De acuerdo a la simplificación de firmas adoptada para toda la AGE y extensible para el resto de Administraciones Públicas, en las aplicaciones de registro integradas en la plataforma SIR se considerarán válidos los siguientes tipos de firma: Ficheros < 8MB: o XADES (Internally Detached): se debe firmar el contenido del documento en Base 64. o XADES-Manifest: se firma el hash del documento. o PADES para ficheros PDF (aunque los ficheros PDF también se pueden firmar XADES, por ejemplo los que se generan al digitalizar la documentación). o CSV Ficheros > 8MB: o XADES-Manifest: se firma el hash del documento. o CSV Durante el periodo de transición en el que convivan aplicaciones integradas en SIR adaptadas y no adaptadas a la simplificación de firmas, todas las aplicaciones deberán aceptar los registros cuya documentación adjunta esté firmada de acuerdo a las condiciones actuales de firma de la Plataforma SIR: Condiciones de Firma de la Plataforma SIR 3.3 Metadatado Para facilitar la tramitación de una forma más automatizada, se hace necesario incluir una serie de datos al registro y a su documentación adjunta. Debido a que la incorporación de nuevos datos en el mensaje SICRES de intercambio implica una nueva versión de la norma SICRES 3.0 que, aunque ya se está trabajando en ella, todavía no está disponible, la incorporación de estos nuevos datos se realizará mediante la generación de un fichero técnico de Metadatado que se incluirá en el mensaje SICRES intercambiado. Los metadatos se clasifican de la siguiente manera: Metadatos Generales: son aquellos de interés general para todos los organismos integrados en la Plataforma SIR. Metadatos Particulares: son aquellos metadatos que cada organismo puede definir para intercambiar determinada información entre sus oficinas o con las oficinas de otro u otros organismos. Además los metadatos (Generales y Particulares) se definen en estos niveles: Metadatos del Asiento Registral: son aquellos asociados al propio registro. Metadatos del Documento Anexo: son aquellos asociados al documento adjunto al registro. Página 6

7 En los metadatos del Documento Anexo se incluyen además los específicos del documento ENI, de manera que todos los documentos intercambiados a través de la Plataforma SIR serán documentos ENI. El fichero técnico de metadatos contendrá la siguiente estructura: Fichero Técnico de Metadatos: Metadatos del Asiento: o Metadatos Generales o Metadatos Particulares Metadatos del Anexo 1: o Metadatos ENI o Metadatos Generales o Metadatos Particulares Metadatos del Anexo 2: o Metadatos ENI o Metadatos Generales o Metadatos Particulares.. Metadatos del Anexo n: o Metadatos ENI o Metadatos Generales o Metadatos Particulares Tanto los metadatos Generales como los Particulares son una lista Atributo-Valor. Para los metadatos Generales el nombre del Atributo estará predefinido para que todas las aplicaciones de registro lo interpreten de la misma manera. Por el momento, se han definido los siguientes Atributos Generales: Atributos Generales del Asientos Registral: o Código SIA: código del trámite administrativo correspondiente al asiento registral. o Código Dire: código del Directorio de Entidades o Presencial/No Presencial: indica si el asiento se ha realizado de forma presencial en una oficina de registro/unidad de tramitación, o ha sido realizado a través de una Sede Electrónica u otra aplicación informática. o Tipo de Envío de la Documentación: indica si la documentación adjunta al registro se envía embebida en el propio mensaje SICRES o a través del Sistema de Referencia Única de Documentación. Atributos Generales del Documento Anexo: o Hash: código hash del documento o Algoritmo de Generación del Hash: algoritmo con el que se ha generado el hash anterior o CSV: código de verificación seguro del documento En el Anexo I: XSD del fichero técnico de Metadatos, se puede consultar el modelo de datos para el fichero técnico de Metadatos 3.4 Repositorio único de documentación La documentación adjunta a los asientos registrales deja de viajar embebida en el mensaje de intercambio. En su lugar, se almacenará en un repositorio de documentación y en el mensaje intercambiado se incluirá una referencia al documento y al repositorio donde se almacena. De esta forma se eliminan los límites de la plataforma en cuanto a número de ficheros adjuntos y su tamaño. Página 7

8 La SGAD proporciona el repositorio CSV Storage como repositorio único. Las aplicaciones de registro pueden utilizar este repositorio o uno propio, siempre que cumpla los siguientes requisitos: Todos los documentos intercambiados a través de la Plataforma SIR deben ser documentos ENI. Esto significa que el repositorio de documentación debe devolver siempre el documento en formato ENI (aunque internamente lo almacene en otro formato). El repositorio de documentación debe implementar una interfaz de consulta y un proxy de consulta que funcionará de cliente de esa misma interfaz, para poder consultar la documentación de otros repositorios. Es decir, cada repositorio funcionará a la vez de cliente y servidor de la interfaz de consulta de documentación. Esta información se encuentra detallada en el Anexo II: Sistema de referenciación de documentos. Los requisitos obligatorios y recomendados de los repositorios de documentación se especifican en el Anexo II: Repositorio de confianza y directorio de repositorios de confianza. NOTA: ambos documentos se encuentran en estado Borrador. Las aplicaciones de registro NO integradas con la Librería de Intercambio SIR deberán implementar: La conversión a formato ENI de todos los documentos adjuntos al asiento registral, incluido el justificante de registro. o Para firmas XADES (Internally Detached). Se mete la firma en el segmento de Contenido (la firma incluye el Base 64 del documento). En el segmento de Firma se incluye una referencia al segmento de Contenido. o Para firmas XADES-Manifest: Se mete el Base 64 del documento en el segmento de Contenido, y la firma (sólo incluye el hash del documento) en el segmento de Firma. o Para firmas PADES. En el segmento Contenido se mete el Base 64 del documento firmado, y en el segmento de Firma se incluye una referencia al segmento de contenido. o Para firmas CSV. En el segmento Contenido se mete el Base 64 del documento y en el segmento de Firma se mete el CSV. La implementación de un repositorio propio de documentación de acuerdo a los requisitos anteriores, en caso de utilizar un repositorio propio. La subida de la documentación al repositorio. Cada documento debe tener un identificador único con el cual poder recuperarlo del repositorio (puede ser su código CSV o un identificador interno de cada organismo). o Si la aplicación utiliza un repositorio propio, puede decidir en qué formato almacena la documentación, pero cuando desde otra aplicación se recupere un documento siempre lo debe devolver en formato ENI. o Si la aplicación utiliza CSV Storage, todos los documentos almacenados deben ser documentos ENI. Las aplicaciones de registro deben disponer de un mecanismo de reintento de almacenamiento de la documentación en su repositorio o en CSV Storage, en el caso de que dicho repositorio no esté disponible. En las aplicaciones integradas con la Librería de Intercambio SIR: La Librería de Intercambio proporciona un método para convertir un documento a ENI (sólo se admitirán documentos firmados Xades Internally Detached, Xades-Manifest, PADES y CSV). La Librería de Intercambio proporciona un método para subir la documentación a CSV Storage (convertida a ENI). La aplicación de registro debe generar previamente el código CSV del documento, que servirá de identificador único para este repositorio (la Librería de Intercambio proporciona un método para generar el código CSV). 3.5 Envío de documentación adjunta por referencia Durante un periodo de tiempo y hasta que todas las aplicaciones de registro integradas en la Plataforma SIR puedan acometer estos cambios, tendrán que convivir diferentes versiones de aplicaciones, unas Página 8

9 que utilicen la referencia única de la documentación y otras que continúen enviando los documentos adjuntos embebidos en el mensaje de intercambio. Antes de realizar el envío de un registro por la Plataforma SIR, la aplicación de registro debe comprobar lo siguiente: Si el destino al que va a enviar el registro está integrado con la Referencia Única. Para ello, en el Directorio Común DIR3 se incluirá un nuevo campo asociado a las unidades de tramitación que indique si ese destino está o no en una aplicación de registro que utiliza la referencia única de documentación. Las aplicaciones de registro deberán leer este dato en su proceso de sincronización con DIR3. El tamaño de cada fichero a adjuntar: o Si el destino está integrado con la Referencia Única, no es necesaria esta comprobación. o Si el destino no está integrado con la Referencia Única: Si los documentos adjuntos no superan el límite de tamaño de la plataforma SIR, se puede enviar el registro. Si los documentos adjuntos superan el límite de tamaño de la plataforma SIR, el registro se tiene que enviar en Rojo sin documentación adjunta o mediante registros consecutivos con la documentación distribuida en envíos parciales (tal como se está procediendo actualmente). El mensaje SICRES de intercambio será diferente en función de si el registro se envía a una aplicación integrada con la Referencia Única o no: Si el destino al que va a enviar el registro NO está integrado con la Referencia Única, en los segmentos Anexo del SICRES se incluirá el contenido del documento adjunto en Base 64 y su firma. Si el destino al que va a enviar el registro está integrado con la Referencia Única, en el segmento Anexo del SICRES se incluirá, por cada documento adjunto, el xml definido como Referencia Única de Documentación. En el Anexo IV: XSD de Referencia Única El xml de referencia del documento adjunto debe contener al menos la siguiente información: El identificador único del documento con el que se almaceno en el repositorio, que puede ser el código CSV o cualquier identificador que identifique unívocamente al documento. Si se utiliza Storage como repositorio de documentación, será siempre el código CSV. Los permisos del documento La url del repositorio Para indicar si el mensaje de intercambio SICRES lleva la documentación embebida o no en el segmento Anexo, todas las aplicaciones de registro deben incluir un fichero técnico de metadatos que incluye un campo para indicar esta condición (Ver apartado Metadatado). En las aplicaciones de registro integradas con la Librería de Intercambio SIR: La Librería de Intercambio proporciona un método para enviar el registro al que se le pasará un objeto cumplimentado de una forma u otra dependiendo de si el destino está integrado o no con la Referencia Única. Este objeto incluye todos los campos para componer los datos propios del SICRES, la Referenciación Única de la documentación y el Metadatado (Ver apartado Metadatado). Página 9

10 3.6 Escenarios de envío de asientos registrales Para una aplicación de registro que NO está integrada con la Librería de Intercambio SIR los posibles escenarios de envío de un asiento registral son los siguientes: Origen y Destino integrados con la Referencia Única: o La aplicación de registro debe comprobar si el destino está integrado Destino integrado o La aplicación de registro debe componer el xml de referencia por cada documento anexo, incluyendo el identificador del documento, la url del repositorio y los permisos. o La aplicación de registro debe componer el mensaje SICRES: Cumplimenta todos los campos del SICRES Incluye un fichero técnico de metadatos con al menos el metadato que indica que la documentación se envía por referencia. Incluye el xml de referencia de cada anexo en el segmento Anexo del SICRES. o Envía el mensaje SICRES al destino. Origen integrado con la Referencia Única y Destino no integrado: o La aplicación de registro debe comprobar si el destino está integrado Destino no integrado o La aplicación de registro debe comprobar el tamaño de los anexos: Si superan el límite de la plataforma, sólo permitirá enviar el asiento en Rojo sin documentación adjunta o mediante registros consecutivos con la documentación distribuida en envíos parciales (tal como se está procediendo actualmente). Si no superan el límite de la plataforma, la aplicación de registro debe componer el mensaje SICRES: Se debe cumplimentar el metadato que indica que la documentación va embebida en el mensaje. Se debe incluir el contenido de los anexos en Base 64 y su firma en los segmentos Anexo (para los asientos en verde, cuando la documentación se envía digitalizada). Envía el mensaje SICRES al destino. Origen no integrado con la Referencia Única y Destino integrado: o El envío se realiza como hasta ahora, con la documentación embebida. Origen y Destino no integrados con la Referencia Única: o El envío se realiza como hasta ahora, con la documentación embebida. Para una aplicación de registro integrada con la Librería de Intercambio SIR los posibles escenarios de envío de un asiento registral son los siguientes: Origen y Destino integrados con la Referencia Única: o La aplicación de registro debe comprobar si el destino está integrado Destino integrado o La aplicación de registro debe componer el objeto para pasar al método de la Librería que realiza el envío, teniendo en cuenta que: Debe cumplimentar la url de su repositorio. Debe cumplimentar el dato que indica que la documentación viaja por referencia. Debe generar y cumplimentar el identificador único de cada documento anexo Debe cumplimentar los permisos asociados a cada documento anexo La Librería de Intercambio compone el mensaje SICRES y realiza el envío a la Plataforma SIR. Origen integrado con la Referencia Única y Destino no integrado: o La aplicación de registro debe comprobar si el destino está integrado Destino no integrado o La aplicación de registro debe comprobar el tamaño de los anexos: Si superan el límite de la plataforma, sólo permitirá enviar el asiento en Rojo sin documentación adjunta o mediante registros consecutivos con la documentación distribuida en envíos parciales (tal como se está procediendo actualmente). Página 10

11 Si no superan el límite de la plataforma, la aplicación de registro debe componer el objeto para pasar al método de la Librería que realiza el envío, teniendo en cuenta que: Debe cumplimentar vacío el dato de la url de su repositorio de documentación. Debe cumplimentar el dato que indica que la documentación va embebida en el mensaje. La Librería de Intercambio compone el mensaje SICRES y realiza el envío a la Plataforma SIR. Origen no integrado con la Referencia Única y Destino integrado: o El envío se realiza como hasta ahora, con la documentación embebida Origen y Destino no integrados con la Referencia Única: o El envío se realiza como hasta ahora, con la documentación embebida NOTA: está pendiente definir la estructura definitiva del objeto AsientoBean de la Librería de Intercambio para el envío de asientos registrales incluyendo Metadatado y Referencia Única de Documentación. 3.7 Escenarios de reenvíos de asientos registrales Es preciso tener en cuenta que los asientos registrales se pueden reenviar entre aplicaciones integradas con la Referencia Única y no integradas. Los posibles escenarios de reenvío son los siguientes: SI: integrado con Referencia Única NO: no integrado con Referencia Única 1 SI 2 SI 3 SI: se pasan siempre los documentos por referencia. o 1: sube la documentación a su repositorio y envía la referencia o 2: recupera la documentación del repositorio 1 o 2: reenvía el asiento sin modificar al 3. No se queda con la documentación. o 3: recupera la documentación del repositorio 1 1 SI 2 SI 3 NO: o 1: sube la documentación a su repositorio y envía la referencia o 2: recupera la documentación del repositorio 1 o 2: comprueba el tamaño de la documentación Si no supera el máximo de la plataforma: Modifica el SICRES para cambiar el valor del metadato general del asiento indicando que la documentación se envía embebida. Modifica el SICRES para incluir en el segmento Anexo el contenido y firma de cada documento. o Si supera el máximo de la plataforma, se debe rechazar el registro, poniendo como motivo de rechazo que el límite se ha superado. La aplicación origen deberá volver a hacer un nuevo registro enviando en papel al destino correcto, o realizar varios registros parciales hasta completar la documentación. o 3: recibe el asiento con los documentos embebidos 1 SI 2 NO 3 SI: o 1: envía la documentación embebida o 2: reenvía el asiento con la documentación embebida o 3: recibe la documentación embebida 1 SI 2 NO 3 NO: o 1: envía la documentación embebida o 2: reenvía el asiento con la documentación embebida o 3: recibe la documentación embebida 1 NO 2 SI 2 SI: o 1: envía la documentación embebida o 2: reenvía el asiento con la documentación embebida o 3: recibe la documentación embebida 1 NO 2 SI 3 NO o 1: envía la documentación embebida o 2: reenvía el asiento con la documentación embebida Página 11

12 o 3: recibe la documentación embebida 1 NO 2 NO 3 SI o 1: envía la documentación embebida o 2: reenvía el asiento con la documentación embebida o 3: recibe la documentación embebida 1 NO 2 NO 3 NO o 1: envía la documentación embebida o 2: reenvía el asiento con la documentación embebida o 3: recibe la documentación embebida 3.8 Escenarios de recepción de asientos registrales Los posibles escenarios de recepción de un registro son los siguientes: Recepción en una aplicación no integrada con la referencia única: o Se leen los documentos adjuntos embebidos en el SICRES Recepción en una aplicación integrada con la referencia única: o La aplicación debe comprobar si en el mensaje SICRES viene el fichero técnico de Metadatos. Si el fichero de Metadatos existe y está bien formado: Si el metadato general del asiento indica que se pasa la documentación por referencia: o La aplicación de registro debe validar el contenido del Anexo contra el XSD de Referencia Si no valida debe devolver un código de ERROR a la aplicación origen. Si valida, la aplicación de registro debe descargar la documentación del repositorio origen. Si el metadato general del asiento indica que se pasa la documentación embebida: o La aplicación de registro leerá el contenido de los documentos embebidos en el SICRES. Si el fichero de Metadatos existe, pero no se puede leer porque no está bien formado: La aplicación de registro debe validar el contenido del Anexo contra el XSD de Referencia: o Si no valida debe devolver un código de ERROR a la aplicación origen. o Si valida, la aplicación de registro debe descargar la documentación del repositorio origen. Si el fichero de Metadatos no existe, significa que la aplicación origen no está integrada ni con metadatos ni con referencia única: La aplicación de registro leerá el contenido de los documentos embebidos en el SICRES. Para las aplicaciones de registro integradas con la Librería de Intercambio SIR estos escenarios son transparentes. La librería proporciona un método para recibir los asientos registrales y actúa de acuerdo a los escenarios anteriores, recuperando la documentación de los anexos embebidos o por referencia en función de la aplicación origen del asiento. 3.9 Acceso al repositorio de documentación Para acceder a los repositorios de documentación de otras aplicaciones de registro, cada aplicación de registro debe implementar el cliente de consulta. Página 12

13 Las aplicaciones de registro deben leer del segmento Anexo el xml de referencia de cada documento adjunto, y a través del cliente consultarán en la url del repositorio por el identificador único del documento. Todos los repositorios de documentación debe devolver el documento en formato ENI. Las aplicaciones de registro deben descomponer el documento ENI en su Contenido, Firma y Metadatos, para poder presentar el documento al usuario. Es necesario tener en cuenta que el formato del documento ENI depende de la firma: Para firmas XADES (Internally Detached). Se mete la firma en el segmento de Contenido (la firma incluye el Base 64 del documento). En el segmento de Firma se incluye una referencia al segmento de Contenido. Para firmas XADES-Manifest: Se mete el Base 64 del documento en el segmento de Contenido, y la firma (sólo incluye el hash del documento) en el segmento de Firma. Para firmas PADES. En el segmento Contenido se mete el Base 64 del documento firmado, y en el segmento de Firma se incluye una referencia al segmento de contenido. Para firmas CSV. En el segmento Contenido se mete el Base 64 del documento y en el segmento de Firma se mete el CSV. Para las aplicaciones integradas con la Librería de Intercambio SIR, la librería proporciona un método para descomponer el documento ENI en función de su firma. 4 FAQ 4.1 Cómo se determinan los metadatos variables? Los metadatos variables se acuerdan entre organismos. A nivel de aplicación de registro, la solución más sencilla es implementar una lista Atributo/Valor dinámica en el formulario de creación del asiento registral donde se puedan añadir estos metadatos. 4.2 Es posible integrarse con la Referencia Única de documentación de forma progresiva? La adaptación a la Referencia Única de documentación se puede realizar en una primera fase sólo para recepción e incluir en una segunda fase la implementación del repositorio propio permitiendo también el envío de la documentación a través del sistema de Referencia Única. 4.3 Necesito algún Acuerdo/Convenio para el uso de CSV Storage como repositorio de documentación? La consulta se debe realizar al equipo de la Suite Inside para la Gestión Integral de documentación electrónica de la SGAD: El uso de CSV Storage conlleva algún coste? La consulta se debe realizar al equipo de la Suite Inside para la Gestión Integral de documentación electrónica de la SGAD: Página 13

14 Página 14

15 5 Anexo I: XSD del fichero técnico de Metadatos 5.1 FicheroTecnico.xsd <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" xmlns:tns=" xmlns:enidocmeta=" targetnamespace=" <xsd:import namespace=" schemalocation="./xsd/metadatosdocumentoeni.xsd" /> <!-- <xsd:annotation> <xsd:appinfo> <jaxb:globalbindings> <jaxb:javatype name="java.lang.string" xmltype="xsd:string" parsemethod="es.minhafp.sgad.metadatado.adaptador.cdataadapter.parse" printmethod="es.minhafp.sgad.metadatado.adaptador.cdataadapter.print" /> </jaxb:globalbindings> </xsd:appinfo> </xsd:annotation> --> <xsd:element name="ficherotecnico"> <xsd:complextype> type="tns:metadatosregistro" /> <xsd:element name="metadatosregistro" <xsd:element name="metadatosanexo" type="tns:metadatosanexo" minoccurs="0" maxoccurs="unbounded" /> </xsd:element> <xsd:complextype name="metadatosregistro"> /> <xsd:element name="metadatosgenerales" type="tns:metadatosgenerales" <xsd:element name="metadatosadicionales" type="tns:metadatosadicionales" minoccurs="0" maxoccurs="1" /> <xsd:complextype name="metadatosanexo"> Página 15

16 <xsd:element ref="enidocmeta:metadatos" /> <xsd:element name="metadatosgenerales" type="tns:metadatosgeneralesanexo" /> <xsd:element name="metadatosadicionales" type="tns:metadatosadicionales" minoccurs="0" maxoccurs="1" /> <xsd:complextype name="metadatosgenerales"> minoccurs="2" /> <xsd:element name="atributo" type="tns:atributogeneral" maxoccurs="2" <xsd:complextype name="metadatosgeneralesanexo"> maxoccurs="2" minoccurs="2" /> <xsd:element name="atributo" type="tns:atributogeneralanexo" <xsd:complextype name="metadatosadicionales"> <xsd:element name="atributo" type="tns:atributoadicional" maxoccurs="unbounded" minoccurs="0" /> <!-- atributos generales y adicionales --> <xsd:complextype name="atributoadicional"> <xsd:complextype name="atributogeneral"> <xsd:element name="campo" type="xsd:string"></xsd:element> <xsd:element name="valor" type="xsd:string"></xsd:element> Página 16

17 <xsd:element name="campo" type="tns:campo"></xsd:element> <xsd:element name="valor" type="xsd:string"></xsd:element> <xsd:complextype name="atributogeneralanexo"> <xsd:element name="campo" type="tns:campoanexo"></xsd:element> <xsd:element name="valor" type="xsd:string"></xsd:element> <!-- enumeracion de los campos fijos --> <xsd:simpletype name="campo"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="codigosia" /> <xsd:enumeration value="codigodire" /> <xsd:enumeration value="p/np" /> <xsd:enumeration value="anexosconreferenciaunica" /> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="campoanexo"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="csv" /> <xsd:enumeration value="codigohash" /> </xsd:restriction> </xsd:simpletype> </xsd:schema> 5.2 metadatosdocumentoseni.xsd <?xml version="1.0" encoding="utf-8"?> <xsd:schema Página 17

18 xmlns:xsd=" xmlns:enidocmeta=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:annotation> <xsd:documentation xml:lang="es">xsd METADATOS DOCUMENTO ENI (v1.0)</xsd:documentation> </xsd:annotation> <xsd:element name="metadatos" type="enidocmeta:tipometadatos"/> <xsd:complextype name="tipometadatos"> <xsd:element name="versionnti" type="xsd:anyuri"/> <xsd:element name="identificador" type="xsd:string"/> maxoccurs="unbounded"/> <xsd:element name="organo" type="xsd:string" minoccurs="1" <xsd:element name="fechacaptura" type="xsd:datetime"/> type="xsd:boolean"/> <xsd:element name="origenciudadanoadministracion" <xsd:element name="estadoelaboracion" type="enidocmeta:tipoestadoelaboracion"> <xsd:annotation> Original. <xsd:documentation xml:lang="es">- EE EE02 - Copia electrónica auténtica con cambio de formato. - EE03 - Copia electrónica auténtica de documento papel. - EE04 - Copia electrónica parcial auténtica. - EE99 - Otros. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="tipodocumental" type="enidocmeta:tipodocumental"> <xsd:annotation> xml:lang="es">/*documentos de decisión*/ <xsd:documentation Página 18

19 - TD01 - Resolución. - TD02 - Acuerdo. - TD03 - Contrato. - TD04 - Convenio. - TD05 - Declaración. /*Documentos de transmisión*/ - TD06 - Comunicación. - TD07 - Notificación. - TD08 - Publicación. - TD09 - Acuse de recibo. /*Documentos de constancia*/ - TD10 - Acta. - TD11 - Certificado. - TD12 - Diligencia. /*Documentos de juicio*/ - TD13 - Informe. /*Documentos de ciudadano*/ - TD14 - Solicitud. - TD15 - Denuncia. - TD16 - Alegación. - TD17 - Recursos. - TD18 - Comunicación ciudadano. - TD19 - Factura. - TD20 - Otros incautados. /*Otros*/ - TD99 - Otros.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:attribute name="id" type="xsd:id" use="optional"/> Página 19

20 <xsd:complextype name="tipoestadoelaboracion"> <xsd:element name="valorestadoelaboracion" type="enidocmeta:enumeracionestadoelaboracion"/> minoccurs="0" maxoccurs="1"/> <xsd:element name="identificadordocumentoorigen" type="xsd:string" <!-- Enumeración de estados de elaboracion --> <xsd:simpletype name="enumeracionestadoelaboracion"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="ee01"/> <xsd:enumeration value="ee02"/> <xsd:enumeration value="ee03"/> <xsd:enumeration value="ee04"/> <xsd:enumeration value="ee99"/> </xsd:restriction> </xsd:simpletype> <!-- Enumeración de tipos documentales --> <xsd:simpletype name="tipodocumental"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="td01"/> <xsd:enumeration value="td02"/> <xsd:enumeration value="td03"/> <xsd:enumeration value="td04"/> <xsd:enumeration value="td05"/> <xsd:enumeration value="td06"/> <xsd:enumeration value="td07"/> <xsd:enumeration value="td08"/> <xsd:enumeration value="td09"/> Página 20

21 <xsd:enumeration value="td10"/> <xsd:enumeration value="td11"/> <xsd:enumeration value="td12"/> <xsd:enumeration value="td13"/> <xsd:enumeration value="td14"/> <xsd:enumeration value="td15"/> <xsd:enumeration value="td16"/> <xsd:enumeration value="td17"/> <xsd:enumeration value="td18"/> <xsd:enumeration value="td19"/> <xsd:enumeration value="td20"/> <xsd:enumeration value="td99"/> </xsd:restriction> </xsd:simpletype> </xsd:schema> Página 21

22 6 Anexo II: Sistema de referenciación de documentos 6.1 INTRODUCCIÓN El presente documento contiene la especificación del sistema de referencias a documentos de las Administraciones Públicas. El trasiego de documentación de unas aplicaciones a otras penaliza el rendimiento de las mismas. El objetivo de este sistema de referencia a documentos es evitar el intercambio de documentación sustituyéndolo por un sistema de intercambio de referencias. Este intercambio de referencias debe normalizarse para que pueda ser interpretado y utilizado de manera correcta por parte de cualquier organismo o aplicación interviniente en el proceso. Además, se especifica un sistema para poder intercambiar/referenciar documentos de gran tamaño, salvando las actuales limitaciones existentes en las aplicaciones. Además, también tiene como objetivo habilitar que pueda haber expedientes con documentos propios y con documentos referenciados a. Cada uno es libre de disponer de una copia o de mantener la referencia b. Podríamos pensar, más adelante, en repositorios que entre sí tengan algún tipo de relación de confianza Por tanto, el esquema de funcionamiento sería el siguiente: 1. La aplicación generadora del documento ha de disponer de información de acceso al mismo: a. Identificador del documento b. Información de Permisos c. URL del web service de acceso al mismo. 2. La aplicación generadora del documento enviaría la información (a) y (c) a la aplicación destinataria. 3. La aplicación destino deberá llamar a (c) con la información de (a) y aportando Información de permisos (b), en su caso. a. Es importante hacer notar que en ocasiones, como en el intercambio de registros, existe una plataforma que intermedia (en este caso, el SIR), que podría aportar en este caso, credenciales extra a la aplicación de destino del documento para dar permisos por defecto. 4. La aplicación generadora del documento contrastará que dispone del documento referenciado, y en su caso, que las credenciales aportadas son válidas para acceder al mismo. Página 22

23 Ilustración 1. Esquema general de intercambio de referencias Todos aquellos repositorios que quieran formar parte del sistema de referencias deberán implementar una interfaz de consulta común (detallada en el apartado 3) así como un proxy de consulta que funcionaría de cliente de esa misma interfaz para poder consultar documentos en otros repositorios. Es decir, cada gestor documental/repositorio integrado funcionará a la vez de cliente y servidor de la interfaz de consulta planteada. El sistema propuesto da solución a algunas limitaciones y agiliza la interactuación en algunas operaciones, por lo que es recomendable su uso siempre que sea posible. En cualquier caso, será decisión de cada organismo u aplicación decidir integrarse en él. 6.2 ESQUEMA DE REFERENCIA A DOCUMENTACIÓN EN UN REPOSITORIO La documentación será generada y almacenada en un repositorio concreto y, siempre que sea posible será referenciada en lugar de descargarse en cada transmisión. La referencia a documentos requiere de ciertos datos que la identifiquen en cuanto a permisos de acceso al documento, trazabilidad, ubicación, etc. A continuación se indican los diferentes datos que se incluirán en cada referencia: Identificación del documento referenciado eemgde Valor del CSV eemgde2.1 - Secuencia de identificador (Identificador de documento ENI) Permisos de acceso al documento: o Público: Basta con tener el CSV o ID ENI para acceder al documento. Página 23

24 o Privado: Sólo puede obtener el documento la aplicación que lo almacenó. o Restringido: o Acceso con identificador: Es necesario que el usuario se haya identificado con alguno de los tipos admitidos. o Restringido por NIF: Documento restringido a los usuarios por su NIF. o Restringido a empleados públicos: Documento restringido a empleados públicos. o Aplicaciones concretas: Documento restringido a algunas aplicaciones concretas, mediante su ID de aplicación. Estas aplicaciones deberán estar integradas con el repositorio en cuestión. eemgde.firma.tipofirma.formatofirma del documento: o XADES Para documentos grandes, XADES Manifest, según se explica en el apartado 2.1 o CADES o PADES o CSV URL del repositorio/ubicación del documento: en concreto, URL del wsdl de la interfaz de consulta. Hash: resumen del documento referenciado utilizando el algoritmo SHA256. Emisor: DIR3 del organismo emisor de la referencia Receptor: DIR3 del organismo receptor de la referencia Metadatos: etiqueta que permite incluir metadatos con formato nombre/valor, pudiendo ser estos los mínimos obligatorios ENI o cualesquiera otros. URL visible: si existe, URL de acceso directo a una versión visible o interpretación del documento. eemgde21 - TRAZABILIDAD: etiqueta abierta para incluir toda aquella información que pudiera ser necesaria en el futuro o para acuerdos bilaterales específicos. 6.3 Por qué es necesario el Esquema Nacional de Interoperabilidad? La interoperabilidad resulta necesaria fundamentalmente para la realización de principios y derechos de los ciudadanos, singularmente el derecho recogido en el artículo 28 de la Ley 39/2015, a no aportar documentos elaborados por la Administración o entregados anteriormente por el interesado a cualquier Administración; para la automatización y la innovación; para la cooperación en el despliegue y prestación de servicios por las Administraciones Públicas; para la ejecución de las diversas políticas públicas; para la dinámica de compartir, reutilizar y colaborar en beneficio de una mejor eficiencia; y todo ello para facilitar, en definitiva, el desarrollo de la administración electrónica, en particular, y de la sociedad de la información en general. Por todas estas razones, la Ley 40/2015 se refiere a la interoperabilidad de los medios electrónicos y sistemas de la administración y a la prestación conjunta de servicios a los ciudadanos que hace posible, como un nuevo principio de actuación de las administraciones públicas. 6.4 Esquema XSD de la referencia de documentos Para facilitar la implantación del sistema de referencia se establece un esquema normalizado que recoge todos los datos anteriormente mencionados. Esquema general de referencia a documento Página 24

25 Tipos complejos Página 25

26 6.5 INTERFAZ DE CONSULTA DE DOCUMENTO Los sistemas o repositorios que se integren en el Sistema de Referencia a documentos deberán implementar el acceso a sus documentos siguiendo la especificación del servicio CSVQueryDocument ya implementada por CSV Storage (servicio de Productor de CSV Broker). El sistema CSV Storage, ofrecido por la SGAD, ya implementa este servicio por lo que por defecto formaría parte del Sistema de Referencia a documentos, junto con todos aquellos otros repositorios o sistemas que también se integren. Página 26

27 6.6 GESTIÓN DE DOCUMENTOS DE GRAN TAMAÑO La gestión de documentos de gran tamaño tiene ciertas limitaciones técnicas para poder dar cumplimiento a la normativa de gestión de documentos general Problemas existentes a la hora de gestionar documentos de gran tamaño Limitación del tamaño de las firmas en el sistema de validación Existe una limitación del tamaño de las firmas de 10Mb, debido a la necesidad de repartir los recursos disponibles entre todos los usuarios en un servicio compartido, por lo que el documento original sin firma deberá ser como máximo de unos 8Mb. Necesidad de un gran espacio de memoria en servidores para calcular resúmenes/hash de documentos grandes. Limitación del tamaño permitido en peticiones SOAP en servicios web, en las que iría el documento grande completo Soluciones propuestas Para poder dar una solución alternativa que permita su gestión se propone un sistema de gestión de documentos grandes que consiste en dos líneas de trabajo esenciales: Firma electrónica de documentos grandes con XADES Manifest Integración de aplicaciones remisoras con repositorios mediante librerías de envío de particiones del documento en lugar de uso de servicios web Implementación de firma XADES Manifest Para la generación de las firmas XADES Manifest se realizarán las siguientes actuaciones: Generación de firmas XADES Detached (XADES Manifest) acorde a la Resolución de la Secretaría General de Administración Digital, por la que se aprueban los criterios técnicos de creación de las firmas y sellos electrónicos avanzados o cualificados, y la generación de códigos seguros de verificación en la administración general del estado para ficheros mayores de 8Mb (obligatorio). En ficheros menores el usuario podrá realizar firmas en los formatos generales. Generación del hash con SHA256, que permite la carga en memoria del documento por partes, evitando tener que cargar el documento entero. En la firmas XADES Manifest lo que se enviará a validar es el hash firmado, en lugar del fichero entero, por lo que se salvaría la limitación de tamaño máximo para firmas Implementación del intercambio de documentos grandes entre aplicaciones Como solución alternativa al envío de documentos grandes a través de peticiones SOAP se propone el uso de librerías de integración que permiten la generación de paquetes de partes del documento que serán particionados en origen y reconstruidos en destino. Actualmente existe una librería de integración con CSV Storage que permite esta funcionalidad. Todas aquellas aplicaciones integradas en el sistema de referencia planteado en este documento deberían disponer de esta misma librería para poder intercambiar documentos grandes, llegado el momento. La descarga efectiva de documentos debería evitarse siempre que sea posible, usando como alternativa el sistema de referencia objeto de este documento, de forma que pueda minimizarse lo máximo posible el trasiego de documentación entre aplicaciones. Se está estudiando un sistema alternativo basado en MTOM/XOP (Message Transmision Optimization Mechanism / Xml-binarey Optimized Packaging), que podría facilitar el intercambio de dichos ficheros. Página 27

28 6.7 ACCESO A DOCUMENTOS POR PARTE DE VARIAS APLICACIONES El uso del sistema de referencias permite evitar que un documento tenga que ser enviado entre varias aplicaciones y almacenado varias veces. Para que este acceso pueda ser efectivo se pueden dar dos casos: Establecer para el documento a intercambiar permisos públicos, es decir, todo aquel que tenga la referencia podrá acceder al mismo. o Ejemplo: GEISER, podría establecer para todos los anexos permisos públicos de acceso, de modo que todas las aplicaciones de registro integradas en SIR podrían recuperar el documento llegado el caso. Establecer para el documento a intercambiar permisos restrictivos por aplicación. La aplicación con permisos en cada momento podrá modificar los mismos para dar acceso a otras aplicaciones. o Ejemplo: Portafirmas envía un documento firmado a la aplicación de Extranjería. Portafirmas crearía el documento y le añadiría permisos para la aplicación Extranjería. En este caso se debe tener conocimiento de qué aplicación va a acceder. Página 28

29 6.8 DIFERENCIA CON CSV BROKER Y CSV STORAGE Diferencias con CSV Broker: a. No hay sistema de permisos entre aplicaciones (sólo Carpeta es consumidora) b. Un mismo CSV puede asociarse a varios documentos. No son referencias únicas. c. No todos los repositorios están integrados. Diferencias con CSV Storage: a. Uno almacena y el sistema de intercambio de referencias intercambia. b. Es imposible unificar en un único repositorio documental a día de hoy, pero a efectos prácticos, se están dando pasos en esta dirección. Página 29

30 6.9 COMPATIBILIDAD DEL SISTEMA DE REFERENCIAS CON INSIDE Y REMISIÓN EN LA NUBE Ilustración 2. Sistema de referencia en INSIDE En el sistema INSIDE, se podrán almacenar, de forma opcional, documentos ENI que incluyan a su vez una referencia en lugar de un contenido de documento completo. De igual forma, si se intercambia un expediente con documentos mediante el protocolo de Remisión en la Nube, se podrán intercambiar documentos ENI que en realidad incluyan referencias a documentos. Esto permitiría al destino disponer del expediente intercambiado y posteriormente poder hacer las consultas necesarias al repositorio custodio de los contenidos del documento para descargarse los documentos referenciados. Es decir, en este sistema, una referencia se considera un documento electrónico como otro cualesquiera. Página 30

31 7 Anexo III: Repositorios de confianza y directorio de repositorios de confianza 7.1 Introducción El presente documento contiene la relación de requisitos que deberían cumplir los repositorios que custodien documentos que vayan a ser objeto de referencia, según la especificación del Sistema de Referencia de Documentos de las AAPP. Este sistema, se detalla en el documento Sistema de referencia de documentos en las AAPP y se resume en la imagen siguiente: Ilustración 1. Esquema general de intercambio de referencias 7.2 Requisitos que debe cumplir todo repositorio Todo repositorio que forme parte del sistema de referencia de documentos debe cumplir unos requisitos mínimos para garantizar su interoperabilidad con el resto. Estos requisitos son: 1. Adaptación a Documento ENI: Implementar la conversión a Documento ENI de cualquier documento que vaya a ser intercambiado. 2. Publicación de servicio web de consulta: Publicar un servicio web que acceda a su repositorio para recuperar un documento que siga la especificación publicada en V%2 0Broker%20-%20Productor.pdf?idIniciativa=323&idElemento= Alta de aplicaciones: Dar de alta para acceder al servicio web anterior a TODAS las aplicaciones del ecosistema o grupo (por ejemplo, todas las aplicaciones de registro, sería parte del proceso de certificación). Página 31

32 7.3 Requisitos recomendados Adaptaciones Plataforma SIR: Firma, Metadatado y Referencia Única 2018 A parte de los requisitos mínimos descritos en el apartado anterior, se recomiendan los siguientes: 1. Recomendado. Concepto de grupo de aplicaciones: Implementar en su repositorio el concepto de permisos por grupo, en el que se integrarán todas las aplicaciones dadas de alta en el punto anterior, de forma que todos los documentos almacenados por una de ellas sea accesible para el resto. 7.4 Tipos de repositorios Hay que tener en cuenta que los escenarios en los que pueden utilizarse referencias clasifican a los repositorios en tres tipos, cada uno de ellos deberá tener unas consideraciones diferentes en cuanto a las políticas de borrados a utilizar. Repositorios de paso o tránsito: estos repositorios generarán referencias de forma temporal, independientemente de los expedientes que puedan llegar a referenciar los documentos. Esto quiere decir que se generarán referencias temporales y las aplicaciones que reciban la referencia deberán EN TODO CASO descargar el documento en cuestión y almacenarlo en sus propios repositorios. Un ejemplo de este tipo de repositorios serían: Portafirmas, Geiser, Orve Página 32

33 Repositorios de tramitación: estos repositorios generarán referencias de forma estable en el tiempo cumpliendo con su política de borrados elegida (se describe en el apartado siguiente). Ejemplos de este tipo serían las aplicaciones de gestión correspondientes, como podrían ser Extranjería, Becas, etc. Repositorios híbridos: estos repositorios deberán gestionar los dos escenarios anteriores, aplicando lo indicado en el apartado siguiente. Un ejemplo de este tipo sería CSV Storage. 7.5 Política de borrados Los repositorios que permitan referencias y por tanto formen parte del Sistema de Referencia de Documentos, deberán tener en cuenta la política de borrados a aplicar en función del tipo de repositorio al que pertenezcan Borrados en repositorios de Tránsito Los repositorios identificados como de paso o tránsito generarán referencias a los documentos que contienen y aplicarán una política de borrados de 1 año en todo caso. Toda aplicación que necesite el documento referenciado deberá descargarlo y almacenarlo en su repositorio de tramitación correspondiente. NOTA: Si el repositorio es híbrido, éste deberá aplicar las políticas de borrado de repositorios en tramitación pasado el año de tránsito Borrados en repositorios de Tramitación Esta política de borrados debería controlar que si hay una referencia generada para un documento no pueda eliminarse de forma unilateral. Podrían darse 2 casos: Sin referencia: Que el documento no haya salido del repositorio, es decir, no se ha generado ninguna referencia a él. Con referencia: Que el documento haya sido referenciado por otro sistema informático Documentos sin referencia Cada repositorio deberá tener una Política de Borrados por defecto, estable, de forma que este dato sea conocido y fiable y será reportado al Directorio de Repositorios de Confianza, descrito en el Apartado 6. En este caso, el documento podría ser eliminado en el momento en que el organismo propietario del repositorio lo decida siempre que corresponda con el dato reportado al Directorio de Repositorios de Confianza Documentos con referencia En el caso de documentos a los cuales se les haya generado, al menos, una referencia, la política de borrados a aplicar deberá ampliarse ya que esta referencia puede haberse incluido en un expediente en trámite y éste requiera mantenerlo durante un plazo más amplio que el definido en la Política de Borrados por defecto. En ese caso habría la aplicación tramitadora que contenga la referencia en uno de sus expedientes, dispone de dos opciones, al menos: Que se haga una copia previa a la desvinculación del documento del repositorio original. Que la aplicación confíe en el repositorio en el cual está el documento y éste se comprometa a implementar la lógica siguiente: o Cada vez que se genere una referencia a un documento el repositorio incrementará un contador, de forma que sea posible saber en todo momento cuántas aplicaciones están usando ese documento. o Las aplicaciones tramitadoras deberán comprometerse a notificar al repositorio cuando ya no necesiten el documento, es decir, pueda ser desvinculado por su parte. Para esto se utilizará un servicio web estándar de solicitud de desvinculación. borrado. Página 33

34 o Si el documento a desvincular tiene más referencias, se decrementará el contador. Sin embargo, si esta fuera la última referencia, el documento podría borrarse finalmente si así lo decide el repositorio propietario. En la siguiente figura se describe la lógica que aplicaría a la vinculación y desvinculación de un documento por parte de varias aplicaciones. NOTA: Las políticas de conservación de eliminación de expedientes administrativos comienzan a contar desde la entrada en Archivo por lo que no sería un factor a tener en cuenta en los repositorios de tramitación. 7.6 Directorio de Repositorios de Confianza Todos los repositorios de confianza que quieran tener esa distinción y que formen parte del Sistema de Referencia de Documentos deberán solicitar el alta en el Directorio de Repositorios de Confianza para poner a disposición unos datos mínimos sobre el mismo así como sus políticas de borrado. Esta información estará disponible para todas las aplicaciones de forma que puedan garantizar el uso que pueden dar (o no) a las referencias a documentos que manejen. Así, el Directorio de Repositorios de Confianza contendrá los siguientes datos para cada repositorio: Identificador del repositorio Público (AAPP)/Privado Política borrados por defecto Tipo de repositorio URL servicio de consulta DIR3 o DIRe responsable CSV Storage Público 1 año + N años hasta contador=0 Colegio de abogados Híbrido s/csvstorage/services/csvqu erydocumentwsservice?wsd l Privado N años Trámite.. /CSVQueryDocumentW SService?wsdl E Página 34