Catálogo de controles para cualificación QERDS y TSA
13 controles agrupados por marco normativo
13 controles coinciden con los filtros aplicados.
ETSI-EN-319-522
ETSI EN 319 522 – Arquitectura, semántica, formatos y bindings ERDS
Referencia bibliográfica
ETSI EN 319 522-1/2/3/4 V1.1.1 (2018-12). Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services. Parts 1-4. European Telecommunications Standards Institute. https://www.etsi.org/deliver/etsi_en/319500_319599/
| Código | Cláusula | Control | Nivel | Crit. | Aplica | Responsable | Evid. |
|---|---|---|---|---|---|---|---|
| REQ-522-1-A | EN 319 522-1 – Arquitectura mapeada al modelo del estándar | El TSP debe documentar la arquitectura del servicio identificando los componentes definidos por EN 319 522-1 y sus interacciones. | NC | Media | Sí | — | 0 |
| REQ-522-1-B | EN 319 522-1 – Roles del servicio identificados | Los roles previstos en el estándar (Sender, Recipient, ERDS Service Provider) deben estar identificados en la arquitectura y en el ERDS-PS. | NC | Media | Sí | — | 0 |
| REQ-522-1-C | EN 319 522-1 – Modelo de prestación declarado | El TSP debe declarar el modelo de prestación que adopta (Style 1: Bilateral, Style 2: Hub & Spoke, Style 3: Multi-provider Federation) y sus implicaciones. | NC | Media | Sí | — | 0 |
| REQ-522-1-D | EN 319 522-1 – Capability Document publicado | El TSP debe publicar un descriptor de capacidades del servicio accesible en un endpoint estándar, describiendo los niveles de identificación, formatos y protoco… | NC | Media | Sí | — | 0 |
| REQ-522-2-A | EN 319 522-2 – Contenido semántico de cada tipo de evidencia | El contenido semántico de cada tipo de evidencia (Submission, Delivery, Acceptance, Rejection, Expiry) debe ajustarse al esquema de EN 319 522-2. | NC | Media | Sí | — | 0 |
| REQ-522-2-B | EN 319 522-2 – Identificadores únicos (Message-ID, Evidence-ID) | Cada evidencia debe contener identificadores únicos (Message-ID, Evidence-ID, Transaction-ID) que permitan trazabilidad cruzada entre evidencias de un mismo env… | NC | Media | Sí | — | 0 |
| REQ-522-2-C | EN 319 522-2 – Marcas temporales semánticas completas | Las evidencias deben incluir todas las marcas temporales semánticas requeridas (submission time, delivery time, acceptance time, etc.) con sello cualificado. | NC | Alta | Sí | — | 0 |
| REQ-522-3-A | EN 319 522-3 – Evidencias en formato estándar (XML/ASN.1) | Las evidencias deben emitirse en uno de los formatos técnicos estandarizados (XML o ASN.1) conforme EN 319 522-3, validables contra esquemas oficiales. | NC | Media | Sí | — | 0 |
| REQ-522-3-B | EN 319 522-3 – Firmas de evidencias con perfiles AdES (XAdES, CAdES, PAdES) | Las evidencias firmadas deben seguir perfiles AdES (XAdES, CAdES o PAdES) conforme a los estándares ETSI correspondientes, con nivel LTV o LTA. | NC | Alta | Sí | — | 0 |
| REQ-522-3-C | EN 319 522-3 – Empaquetado estándar de conjuntos de evidencias | Cuando se entreguen múltiples evidencias como paquete, debe usarse un formato de empaquetado estándar (ASiC o equivalente). | NC | Media | Sí | — | 0 |
| REQ-522-4-A | EN 319 522-4 – Common Service Interface para interoperabilidad | Si el TSP expone un API para interoperabilidad con otros ERDS o partes confiantes, debe ajustarse al Common Service Interface de EN 319 522-4-1. | NC | Media | Cond. | — | 0 |
| REQ-522-4-B | EN 319 522-4 – Binding REST conforme al estándar | Si el servicio QERDS se expone como API REST, debe seguirse el binding REST de EN 319 522-4, con las URLs, verbos y payloads definidos. | NC | Media | Cond. | — | 0 |
| REQ-522-4-C | EN 319 522-4 – Binding REM para email certificado europeo | Si el TSP ofrece compatibilidad con REM (Registered Electronic Mail), debe seguir el perfil REM de EN 319 522-4 para interoperabilidad con otros prestadores REM… | NC | Baja | Cond. | — | 0 |