Gap analysis
Cargando…
Cargando…
CTO · 138 de 138 controles esperados
| Control | Norma | Requisito | Aplicab. | Estado | Severidad | Owner | WP |
|---|---|---|---|---|---|---|---|
| EN 319 522-1 §5-01 | 522-qerds-protocol | La interfaz ERDS MSI (Message Submission) requiere autenticación (directa o por token de tercero) e implementa medidas de confidencialidad e integridad. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-1 §5-02 | 522-qerds-protocol | La interfaz ERDS MERI (Message and Evidence Retrieval) requiere autenticación e implementa medidas de confidencialidad e integridad. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-1 §5-03 | 522-qerds-protocol | La interfaz ERD-UA MEPI (Message and Evidence Push) implementa autenticación, confidencialidad e integridad. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-1 §5-04 | 522-qerds-protocol | La interfaz ERDS RI (Relay Interface) implementa autenticación, confidencialidad e integridad. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-1 §5-05 | 522-qerds-protocol | El ERDS debe implementar ERDS MSI y al menos una de ERDS MERI o ERD-UA MEPI (o ambas). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-1 §5-06 | 522-qerds-protocol | Un ERDS interoperable debe implementar ERDS RI; debería implementar ERDS RI conforme a EN 319 522-3, 4-1 y 4-2. | Obligatoria (interoperabilidad) / Recomendada (binding) | TBD | TBD | — | — |
| EN 319 522-1 §5-07 | 522-qerds-protocol | Un ERDS interoperable debería usar CSI (Common Service Interface). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.2-A.1/A.2 | 522-qerds-protocol | Eventos de submission: SubmissionAcceptance (A.1) o SubmissionRejection (A.2) — uno de los dos debe ocurrir; la evidencia asociada es obligatoria (M). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-1 §6.2.3-B.1/B.2/B.3 | 522-qerds-protocol | Eventos de relay entre ERDSs: RelayAcceptance / RelayRejection / RelayFailure — uno debe ocurrir cuando hay mensajería inter-ERDS; evidencia obligatoria (M). | Cond. (4-corner/extended) | TBD | TBD | — | — |
| EN 319 522-1 §6.2.4-C.1 | 522-qerds-protocol | Evento NotificationForAcceptance: opcional; si ocurre, evidencia recomendada (R). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.4-C.2 | 522-qerds-protocol | Evento NotificationForAcceptanceFailure: opcional; evidencia recomendada (R). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.4-C.3 | 522-qerds-protocol | Evento ConsignmentAcceptance: opcional; evidencia recomendada (R). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.4-C.4 | 522-qerds-protocol | Evento ConsignmentRejection: opcional; evidencia recomendada (R). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.4-C.5 | 522-qerds-protocol | Evento AcceptanceRejectionExpiry: opcional; evidencia recomendada (R). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.4-C.6 | 522-qerds-protocol | Evento NotificationDelivered: opcional; evidencia recomendada (R). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.5-D.1 | 522-qerds-protocol | Evento ContentConsignment: condicional (D.1 o D.2 o D.6 deben ocurrir si no han ocurrido E.1 ni E.2); evidencia obligatoria (M). | Condicional | TBD | TBD | — | — |
| EN 319 522-1 §6.2.5-D.2 | 522-qerds-protocol | Evento ContentConsignmentFailure: condicional; evidencia obligatoria (M). | Condicional | TBD | TBD | — | — |
| EN 319 522-1 §6.2.5-D.3 | 522-qerds-protocol | Evento ConsignmentNotification: opcional; evidencia opcional (O). | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.5-D.4 | 522-qerds-protocol | Evento ConsignmentNotificationFailure: opcional; evidencia opcional. | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.5-D.5 | 522-qerds-protocol | Evento NotificationAccessTracking: opcional; evidencia opcional. | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.5-D.6 | 522-qerds-protocol | Evento ContentAccessTracking: opcional; evidencia opcional. | Recomendada | TBD | TBD | — | — |
| EN 319 522-1 §6.2.6-E.1 | 522-qerds-protocol | Evento ContentHandover: condicional (E.1 o E.2 deben ocurrir si no han ocurrido D.1 ni D.2 ni D.6); evidencia condicional obligatoria (si no se generó evidencia D.1/D.2 debe generarse). | Condicional | TBD | TBD | — | — |
| EN 319 522-1 §6.2.6-E.2 | 522-qerds-protocol | Evento ContentHandoverFailure: condicional; evidencia condicional (igual condición que E.1). | Condicional | TBD | TBD | — | — |
| EN 319 522-1 §6.2.7-F.1 | 522-qerds-protocol | Evento RelayToNonERDS: opcional; evidencia recomendada. | Recomendada (si aplica gateway no-ERDS) | TBD | TBD | — | — |
| EN 319 522-1 §6.2.7-F.2 | 522-qerds-protocol | Evento RelayToNonERDSFailure: opcional; evidencia recomendada. | Recomendada (si aplica gateway no-ERDS) | TBD | TBD | — | — |
| EN 319 522-1 §6.2.7-F.3 | 522-qerds-protocol | Evento ReceivedFromNonERDS: opcional; evidencia recomendada (atestiguar que el origen no es de confianza per se). | Recomendada (si aplica recepción de no-ERDS) | TBD | TBD | — | — |
| EN 319 522-1 §6.1-01 | 522-qerds-protocol | Toda evidencia producida debe ser accesible al "primary target" (consumidor objetivo); no se exige push, pero sí almacenamiento accesible. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §5.2-01 | 522-qerds-protocol | Un identificador debe tener dos componentes: scheme name e identifier value coherente con el scheme; debe ser único dentro de la red de ERDSs interoperables. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §5.3.2-01 | 522-qerds-protocol | Para personas físicas debe usarse un subconjunto no vacío de atributos del eIDAS SAML attribute profile (Core Person Vocabulary). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §5.3.3-01 | 522-qerds-protocol | Para personas jurídicas debe usarse un subconjunto no vacío de atributos del eIDAS SAML attribute profile (Registered Organization Vocabulary). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §5.4-01 | 522-qerds-protocol | El nivel de assurance debe expresarse con: (1) atributo de registration/identity proofing con identificador URI del LoA y, opcionalmente, identificador y detalle de la política; (2) atributo de medios/mecanismos de autenticación con LoA URI y, opcionalmente, identificador/detalle de política. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §5.4-02 | 522-qerds-protocol | La información de assurance puede incluir detalles de la autenticación efectuada (assertion o secuencia con AuthenticationTime y AuthenticationMethod). | Recomendada | TBD | TBD | — | — |
| EN 319 522-2 §6.1-01 | 522-qerds-protocol | El ERDS relay metadata debe incluir los componentes con la cardinalidad indicada en la tabla 5. Algunos pueden replicarse en evidencias. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §6.2.1 (MD01) | 522-qerds-protocol | Componente Metadata version: cardinalidad 1 (siempre presente). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §6.2.3 (MD03) | 522-qerds-protocol | Expiry date and time: el R-ERDS no debe consignar/handover el user content si la fecha-hora actual es posterior al MD03; los I-ERDS deben propagarlo sin alterar. | Cond. (si presente) | TBD | TBD | — | — |
| EN 319 522-2 §6.2.4 (MD04) | 522-qerds-protocol | Recipient required level of assurance: el ERDS no debe relayar si el R-ERDS no soporta ese LoA; el R-ERDS no debe entregar si no alcanza el LoA requerido; los I-ERDS lo propagan. | Cond. (si presente) | TBD | TBD | — | — |
| EN 319 522-2 §6.2.5 (MD05) | 522-qerds-protocol | Applicable policy: el ERDS no debe relayar si el siguiente ERDS no soporta la política; debe rechazar si no puede soportarla; los I-ERDS la propagan. | Cond. (si presente) | TBD | TBD | — | — |
| EN 319 522-2 §6.2.6 (MD06) | 522-qerds-protocol | Mode of consignment (Basic / Consented / Consented signed / Other): no relayar si el R-ERDS no lo soporta; rechazar si no puede; consignar conforme al modo solicitado. | Cond. (si presente) | TBD | TBD | — | — |
| EN 319 522-2 §6.2.7 (MD07) | 522-qerds-protocol | Scheduled delivery: el user content no debe entregarse antes de la hora indicada; los ERDS deberían rechazar si no pueden retrasar la entrega. | Cond. (si presente) | TBD | TBD | — | — |
| EN 319 522-2 §6.2.8 (MD08) | 522-qerds-protocol | Sender's identifier: cardinalidad 1 (siempre presente). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §6.2.10 (MD10) | 522-qerds-protocol | Recipient's identifier: cardinalidad 1 (siempre presente). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §6.2.13 (MD13) | 522-qerds-protocol | ERD Message type: los ERDSs deben usar este componente para indicar el tipo (ERD payload, ERD dispatch, ERDS serviceInfo, ERDS receipt). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §6.2.14 (MD14) | 522-qerds-protocol | User content information: cardinalidad 1; debe describir estructura del user content (identificador app-layer, número de partes, tipo y digest por parte). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §7.1-01 | 522-qerds-protocol | Un ERDS debe firmar digitalmente todos los ERD messages; las firmas son internas al ERDS y deben verificarse al ingresar por la interfaz ERDS-RI. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §7.1-02 | 522-qerds-protocol | Cada evidencia debe firmarse digitalmente como documento individual por el ERDS emisor, incluso si va embebida en un ERD message firmado, para que la evidencia sea extraíble y verificable de forma autónoma. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §7.1-03 | 522-qerds-protocol | La cadena completa de certificados que sustenta la firma debe estar disponible y los estados de los certificados deben ser públicamente accesibles. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §7.2-01 | 522-qerds-protocol | La firma digital debería ser CAdES, XAdES o PAdES baseline (EN 319 122-1 / EN 319 132-1 / EN 319 142-1). | Recomendada | TBD | TBD | — | — |
| EN 319 522-2 §7.2-02 | 522-qerds-protocol | La firma digital debe usar algoritmos criptográficos de fortaleza suficiente, e.g. ETSI TS 119 312. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §7.2-03 | 522-qerds-protocol | La firma digital puede incluir la propiedad firmada con el identificador explícito de la signature policy. | Recomendada | TBD | TBD | — | — |
| EN 319 522-2 §7.2-04 | 522-qerds-protocol | Debería añadirse un signature time-stamp a la firma de evidencia; con CAdES/XAdES, debe usarse nivel B-T (este timestamp soporta los requisitos de timestamping del Reglamento (UE) 910/2014 art. 44 sobre la evidencia). | Recomendada (Obligatoria implícita por art. 44 eIDAS) | TBD | TBD | — | — |
| EN 319 522-2 §8.2.1 (G01) | 522-qerds-protocol | Toda evidencia debe contener Evidence identifier único. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.2 (G02) | 522-qerds-protocol | Toda evidencia debe contener Evidence version. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.3 (G03) | 522-qerds-protocol | Event identifier: URI del evento de la lista de §6.1 EN 319 522-1. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.4 (G04) | 522-qerds-protocol | Reason identifier: identificador URI de razón de la tabla §8.3.3; obligatorio en evidencia de evento "negativo" (failure/rejection); puede aparecer en evento "positivo". | Condicional | TBD | TBD | — | — |
| EN 319 522-2 §8.2.5 (G05) | 522-qerds-protocol | Event time: fecha y hora UTC del evento (mejor aproximación según la información disponible). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.6 (G06) | 522-qerds-protocol | Transaction log information: log de la transacción específico al protocolo subyacente. | Recomendada | TBD | TBD | — | — |
| EN 319 522-2 §8.2.7 (R01) | 522-qerds-protocol | Evidence issuer policy identifier: URI/OID; al menos un identificador. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.8 (R02) | 522-qerds-protocol | Evidence issuer details: detalles del ERDS que emite la evidencia conforme a §5.3. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.9 (R03) | 522-qerds-protocol | Signature by issuing ERDS: la firma de la evidencia debe cumplir §7.2. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.10 (I01) | 522-qerds-protocol | Sender's identity attributes: la fuente de información es S-ERDS; R-ERDS e intermedios deben tomarlos de la evidencia/relay metadata del S-ERDS si quieren incluirlos. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.11 (I02) | 522-qerds-protocol | Sender's identifier: igual que MD08; S-ERDS es la fuente. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.14 (I05) | 522-qerds-protocol | Recipient's identity attributes: R-ERDS es la fuente; S-ERDS y los I-ERDS lo toman de evidencia generada por R-ERDS. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.15 (I06) | 522-qerds-protocol | Recipient's identifier: idéntico a MD10; S-ERDS es la fuente. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.19 (I10) | 522-qerds-protocol | Sender's identity assurance level details: detalles del LoA conforme a §5.4 para los procesos de identificación y autenticación del remitente. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.21 (I12) | 522-qerds-protocol | Recipient's identity assurance level details: idem para destinatario. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.23 (M01) | 522-qerds-protocol | Message identifier: identificador único del ERD message. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.24 (M02) | 522-qerds-protocol | User content information: estructura/digest del original. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.2.25 (M03) | 522-qerds-protocol | Submission date and time: hora UTC del SubmitMessage(). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.4-01 | 522-qerds-protocol | Cada evidencia debe respetar las cardinalidades de la Tabla 13 para sus componentes en función del evento que la origina. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.3.1 | 522-qerds-protocol | El texto libre en evidencia debe redactarse en inglés UK; otros idiomas pueden añadirse. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §8.3.3 | 522-qerds-protocol | Cuando un componente G04 Reason aparezca, debe usar uno de los códigos URI de las tablas 7-12 (RA01-06, RB01-22, RC01-09, RD01-34, RE01-04, RF01-04) o, si no aplica ninguno, el código `RAXX/RBXX/RCXX/RDXX/REXX/RFXX` (Other/Extension). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.2-01 | 522-qerds-protocol | El S-ERDS debe poder identificar al R-ERDS del que el destinatario es suscriptor mediante CSI; en 4-corner, las interfaces ERDS-RI de ambos ERDSs deben identificarse. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.2-02 | 522-qerds-protocol | Antes de reenviar el ERD message, el S-ERDS debe establecer confianza en el ERDS destino (§9.3) y comprobar sus capacidades necesarias (§9.4). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.3-01 | 522-qerds-protocol | Un ERDS no debe reenviar un ERD message a otro ERDS salvo que pueda identificarlo y autenticarlo y confirmar que es de confianza. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.3-02 | 522-qerds-protocol | Un trust domain debe tener gobernanza, al menos para la política de admisión de un ERDS. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.3-03 | 522-qerds-protocol | La participación en un trust domain debería evaluarse mediante un certificado X.509 que represente al ERDS. | Recomendada | TBD | TBD | — | — |
| EN 319 522-2 §9.4.1-01 | 522-qerds-protocol | El capability management debe permitir resolver la identificación única de un destinatario en (1) identificación del R-ERDS, (2) metadata de capacidades del ERDS y (3) metadata de capacidades del destinatario. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.4.3-01 | 522-qerds-protocol | Cuando se usa recipient metadata, el ERDS debe asegurar que se almacena, mantiene y publica metadata suficiente sobre todos los suscriptores. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.4.4-01 | 522-qerds-protocol | Un ERDS no debe relayar un ERD message a otro ERDS salvo que pueda evaluar que el otro ERDS provee un servicio que respeta restricciones y opciones del ERD policy aplicable. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-2 §9.4.4-02 | 522-qerds-protocol | Capability metadata debe incluir (Tabla 14): ERDS identification, domain name, governing body, protocol/profile/binding (REM/no-REM), expiry date support, LoA soportados, modos de consignment, soporte de scheduled delivery; opcionalmente trust domains, política ERD soportada, ERDS metadata repository. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-3 §4.2-01 | 522-qerds-protocol | El mapping de ERDS metadata a IETF RFC 5322 debe seguir lo especificado en EN 319 532-3 (REM). | Cond. (REM) | TBD | TBD | — | — |
| EN 319 522-3 §4.3.3.5 | 522-qerds-protocol | Si se usa formato XML para metadata, el elemento raíz debe ser `RelayMetadata` y los documentos deben tener `version="EN319522v1.1.1"`. | Cond. (AS4 / XML) | TBD | TBD | — | — |
| EN 319 522-3 §4.3.4-§4.3.18 | 522-qerds-protocol | Cada elemento (`MessageIdentifier`, `ERDMessageType`, `InReplyTo`, `RelayTime`, `ExpirationTime`, `ScheduledDeliveryTime`, `SenderId`, `ReplyTo`, `RecipientId`, `UserContentInfo`, `RequiredAssuranceLevel`, `ApplicablePolicy`, `RequestedConsignmentMode`, `Extensions`, `ds:Signature`) debe ajustarse al esquema XML normativo definido en Annex A. | Cond. (AS4 / XML) | TBD | TBD | — | — |
| EN 319 522-3 §4.3.5 | 522-qerds-protocol | `ERDMessageType` debe ser uno de los 4 valores enumerados (`dispatch`, `receipt`, `serviceInfo`, `payload`). | Cond. (AS4 / XML) | TBD | TBD | — | — |
| EN 319 522-3 §4.3.16 | 522-qerds-protocol | `RequestedConsignmentMode` debe ser uno de los 4 valores enumerados (`basic`, `consent`, `signed`, `other`). | Cond. (AS4 / XML) | TBD | TBD | — | — |
| EN 319 522-3 §5.1-01 | 522-qerds-protocol | El ERDS puede generar evidencias en PDF, pero las evidencias destinadas a procesado automático deben usar XML. PDF queda fuera del alcance de la especificación. | Recomendada | TBD | TBD | — | — |
| EN 319 522-3 §5.2.2.3 | 522-qerds-protocol | El elemento raíz de la evidencia XML debe ser `Evidence` con atributo `version="EN319522v1.1.1"`. | Cond. (XML evidence) | TBD | TBD | — | — |
| EN 319 522-3 §5.2.2.5 | 522-qerds-protocol | El elemento `ERDSEventId` debe contener uno de los valores URI listados en la Tabla 2 (ej. `http://uri.etsi.org/19522/Event/SubmissionAcceptance`). | Cond. (XML evidence) | TBD | TBD | — | — |
| EN 319 522-3 §5.2.2.7 | 522-qerds-protocol | El elemento `EventReasons/EventReason/Code` debe ser un URI de las tablas de razones (cláusula 8.3.3 de EN 319 522-2). | Cond. (XML evidence) | TBD | TBD | — | — |
| EN 319 522-3 §5.2.2.10-§5.2.2.27 | 522-qerds-protocol | Los tipos `EntityDetailsType`, `Identity`, `CertificateDetailsType`, `EvidenceIssuerDetails`, `AssuranceLevelsDetailsType`, `UserDetailsType`, `SenderDetails`, `SenderDelegateDetails`, `RecipientDetails`, `RecipientsDelegateDetails`, `SubmissionTime`, `EvidenceRefersToRecipient`, `MessageIdentifier`, `UserContentInfo`, `ForwardedToExternalSystem`, `ExternalERDSDetails`, `TransactionLogInformation`, `Extensions` deben ajustarse al esquema XML normativo (Annex A). | Cond. (XML evidence) | TBD | TBD | — | — |
| EN 319 522-3 §5.2.2.11 | 522-qerds-protocol | Los `Identity`/`saml:Attribute` para personas físicas/jurídicas y direcciones postales deben ajustarse al "eIDAS SAML Attribute profile". | Cond. (XML evidence) | TBD | TBD | — | — |
| EN 319 522-3 §5.2.2.28 | 522-qerds-protocol | El `ds:Signature` envuelve la firma de la evidencia; debería ser XAdES baseline (B-B) y ampliarse a XAdES B-T añadiendo `xades:SignatureTimeStamp`; el certificado de firma debe cumplir EN 319 522-2 §7.2. | Recomendada (B-T efectivamente requerido para QERDS) | TBD | TBD | — | — |
| EN 319 522-3 §6.1-01 | 522-qerds-protocol | Si el R-ERDS no se identifica por la identificación del destinatario, debe recuperarse del CSI un `ServiceInformation` con `ServiceEndpointList` (cada `ServiceEndpoint` = ERDS RI identificado por URI). | Obligatoria (interoperabilidad) | TBD | TBD | — | — |
| EN 319 522-3 §6.2-01 | 522-qerds-protocol | Cada `ServiceEndpoint` (ERDS RI) en el `ServiceEndpointList` debe contener el certificado que el ERDS RI usa para firmas digitales. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-3 §6.3.1-01 | 522-qerds-protocol | El recipient metadata debe usar el formato OASIS Service Metadata Publisher (SMP) v1.0. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-3 §6.3.2-01 | 522-qerds-protocol | El `ERDSMetadata` debe definirse conforme al esquema (Annex A) y publicarse como extensión SMP con `ExtensionID="ERDSMetadata"`, `ExtensionAgencyID="ETSI"`, `ExtensionURI="http://uri.etsi.org/19522/v1#ERDSMetadata"`. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-1 §4-01 | 522-qerds-protocol | Los bindings deben soportar el intercambio de los 4 ERD messages (ERD dispatch, ERD payload, ERDS receipt, ERDS serviceInfo) por la interfaz ERDS-RI con los formatos definidos en EN 319 522-3. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-01 | 522-qerds-protocol | Al usar AS4, el ERDS debe cumplir la AS4 ebHandler Conformance Clause (sección 6.1 del Profile AS4). | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-02 | 522-qerds-protocol | El relay de un ERD message debe usar el patrón push (no pull). | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-03 | 522-qerds-protocol | Los ERD messages deben empaquetarse en User Messages; user content, ERDS relay metadata y ERDS evidence se incluyen como ebMS payloads/SOAP attachments (no SOAP Body). | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-04 | 522-qerds-protocol | Cada payload del AS4 message debe declarar su tipo mediante la propiedad `//PartInfo/Property` con nombre `http://uri.etsi.org/19522/v1#as4binding/PayloadType` y valor `UserContent` / `ERDSRelayMetadata` / `ERDSEvidence`. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-05 | 522-qerds-protocol | El AS4 message debe siempre incluir al menos un payload con la representación XML del relay metadata (EN 319 522-3 §4). | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-06 | 522-qerds-protocol | `PMode.Initiator/Responder` deben llevar identificadores de los ERDSs emisor/receptor; `PMode.Initiator.Role` y `PMode.Responder.Role` deben valer `http://uri.etsi.org/19522/v1#as4binding/Roles/ERDS`. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-07 | 522-qerds-protocol | `PMode[1].BusinessInfo.Service` debe ser `http://uri.etsi.org/19522/v1#as4binding/Relay`; `Service.type` no debe usarse. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-08 | 522-qerds-protocol | Deben usarse Signed Receipts: `PMode[1].Security.SendReceipt = true` y `PMode[1].Security.SendReceipt.NonRepudiation = true`. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-09 | 522-qerds-protocol | Receipt y Error Signal deben enviarse síncronamente: `PMode[1].Security.SendReceipt.ReplyPattern = true` y `PMode[1].ErrorHandling.Report.AsResponse = true`. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.2-10 | 522-qerds-protocol | Debería usarse el AS4 Reception Awareness Feature; el ERDS debería usar duplicate elimination. | Recomendada (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.3-01 | 522-qerds-protocol | Todos los AS4 messages intercambiados entre ERDSs deben firmarse y cifrarse por el ERDS emisor con los parámetros P-Mode de la Tabla 2: hash y firma según ETSI TS 119 312, X.509v3 token reference, AES-GCM128, RSA-OAEP, MGF1 con SHA256. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.4-01 | 522-qerds-protocol | Para relayar un ERD dispatch debe usarse `PMode[1].Action = http://uri.etsi.org/19522/v1#as4binding/Actions/ERDdispatch`; cada `PartInfo` con `UserContentPartId` cuyo valor coincida con el `Identifier` del metadata. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.5-01 | 522-qerds-protocol | El binding de ERDS receipt sigue lo especificado en EN 319 522-4-2 §5.3. | Cond. (AS4 + receipt detached) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.6-01 | 522-qerds-protocol | Para ERDS serviceInfo: `PMode[1].Action = http://uri.etsi.org/19522/v1#as4binding/Actions/ERDserviceInfo`; el mensaje no debe contener payloads adicionales aparte del relay metadata. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §5.7-01 | 522-qerds-protocol | Para ERD payload: `PMode[1].Action = http://uri.etsi.org/19522/v1#as4binding/Actions/ERDpayload`; cada `PartInfo` lleva `PayloadType=UserContentPart` y `UserContentPartId=identifier`. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-1 §6-01 | 522-qerds-protocol | El binding IETF RFC 5322 debe implementarse como define EN 319 532-3 (REM). | Cond. (REM) | TBD | TBD | — | — |
| EN 319 522-4-2 §4-01 | 522-qerds-protocol | Los bindings deben soportar el intercambio de ERDS receipts (evidencia/identificación desacoplada del user content) por ERDS-RI con los formatos de EN 319 522-3. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-2 §5.2-01 | 522-qerds-protocol | A los ERDS receipts AS4 se aplican los requisitos genéricos de EN 319 522-4-1 §5.2 (ebHandler, push, payloads, P-Mode, firma/cifrado). | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-2 §5.3-01 | 522-qerds-protocol | Para relayar un ERDS receipt en AS4: `PMode[1].Action = http://uri.etsi.org/19522/v1#as4binding/Actions/ERDSreceipt`; el mensaje incluye un payload con relay metadata y uno o más payloads con las ERDS evidences. | Cond. (AS4) | TBD | TBD | — | — |
| EN 319 522-4-2 §6-01 | 522-qerds-protocol | El binding RFC 5322 (REM) lo provee EN 319 532-3. | Cond. (REM) | TBD | TBD | — | — |
| EN 319 522-4-3 §4-01 | 522-qerds-protocol | El receiver identification service se vincula a OASIS BDXL; el capability discovery service a OASIS SMP; la trust evaluation a Trusted List o domain PKI. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-3 §5-01 | 522-qerds-protocol | El registro en BDXL y la formación de query strings debe seguir OASIS BDXL; la identidad del ERDS debería registrarse en BDXL por nombre de dominio. | Obligatoria (registro BDXL recomendado) | TBD | TBD | — | — |
| EN 319 522-4-3 §5-02 | 522-qerds-protocol | El registro BDXL debe resolver un participant identifier a un único URI hacia un SMP; cuando un destinatario está en varios ERDS/SMP, el registro debe (a) resolver a un SMP que apunte (redirect) a otros, o (b) acoplar la identificación con un dominio creando varios participant identifiers. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-3 §6-01 | 522-qerds-protocol | El SMP debe ser conforme a OASIS SMP v1.0 (XML schema, firmas SMP §3.6.2, ejecución §2.1, sintaxis y semántica §3, REST binding §3.2-3.5). | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-3 §6-02 | 522-qerds-protocol | El SMP debe usar firma DSIG envolvente conforme a SMP §3.6.2. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-3 §6-03 | 522-qerds-protocol | Cuando hay varios `ServiceMetadata`, la selección debe basarse en document identifier y/o process identifier. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-3 §6-04 | 522-qerds-protocol | Las capabilities del ERDS deben publicarse como extensión SMP (sin contradecir SMP); la extensión es común a todos los ERDS RI expuestos. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-3 §7.1-01 | 522-qerds-protocol | Para los bindings 7.2 y 7.3, debe verificarse que (a) el certificado es la service digital identity del ERDS en una TL relevante, o (b) tiene un path a un certificado CA que sea la service digital identity en la TL. | Obligatoria | TBD | TBD | — | — |
| EN 319 522-4-3 §7.2-01 | 522-qerds-protocol | Un ERDS cualificado eIDAS debe estar listado en la EU Trusted List según art. 22 con uno de los `ServiceTypeIdentifier` de la lista: `http://uri.etsi.org/TrstSvc/Svctype/EDS/Q` (no-REM) o `http://uri.etsi.org/TrstSvc/Svctype/EDS/REM/Q` (REM). | Obligatoria (QERDS) | TBD | TBD | — | — |
| EN 319 522-4-3 §7.2-02 | 522-qerds-protocol | El elemento `ServiceDigitalIdentity/DigitalId` del (Q)ERDS en la EU TL debe ser: (1) un único certificado de firma del ERDS, o (2) un certificado CA usado únicamente para emitir certificados a componentes del ERDS. | Obligatoria (QERDS) | TBD | TBD | — | — |
| EN 319 522-4-3 §7.2-03 | 522-qerds-protocol | Para evaluar la confianza basada en la TL, debe validarse la firma digital del ERDS en el ERD message/evidence, verificar que el cert puede enlazarse a la service digital identity, que el estado del servicio es "granted" y que el `ServiceTypeIdentifier` es del trust domain aplicable; al evaluar en el pasado, debe usarse la información válida en ese momento. | Obligatoria (QERDS) | TBD | TBD | — | — |
| EN 319 522-4-3 §7.3-01 | 522-qerds-protocol | Los Domain Trusted List deben formatearse según ETSI TS 119 612, definir un Trusted List scheme conforme a §7.2 con las modificaciones aquí indicadas y publicar como en §5.3 de TS 119 612. | Cond. (Domain TL) | TBD | TBD | — | — |
| EN 319 522-4-3 §7.4-01 | 522-qerds-protocol | En el modelo Domain PKI, los ERDSs participantes deben recibir certificados X.509 emitidos en el PKI; la política de certificados debe especificar requisitos para que un ERDS obtenga certificado y entre en el trust domain. | Cond. (Domain PKI) | TBD | TBD | — | — |
| EN 319 522-4-3 §7.4-02 | 522-qerds-protocol | Para establecer confianza en otro ERDS en modelo Domain PKI, debe verificarse que tiene un certificado válido emitido en el PKI y que posee la clave privada correspondiente. | Cond. (Domain PKI) | TBD | TBD | — | — |
| EN 319 522-4-3 §7.5-01 | 522-qerds-protocol | El trust bilateral entre ERDSs queda fuera de estandarización; involucra normalmente intercambio manual de certificados X.509. | Recomendada (si bilateral) | TBD | TBD | — | — |
| eIDAS §43.2 | eidas-legales | Garantizar presunción de integridad, identificación de remitente y destinatario, y exactitud temporal | Obligatoria | TBD | TBD | — | — |
| eIDAS §44.1.a | eidas-legales | Servicio prestado por uno o más QTSPs | Obligatoria | TBD | TBD | — | — |
| eIDAS §44.1.d | eidas-legales | Envío y recepción protegidos por firma o sello electrónico avanzado de QTSP | Obligatoria | TBD | TBD | — | — |
| eIDAS §44.1.e | eidas-legales | Indicar al emisor y destinatario cualquier modificación de los datos | Obligatoria | TBD | TBD | — | — |
| eIDAS §44.1.f | eidas-legales | Marcar mediante sello cualificado de tiempo fecha/hora de envío, recepción y modificación | Obligatoria | TBD | TBD | — | — |
| eIDAS §44.1 (final) | eidas-legales | Si datos pasan entre 2+ QTSPs, todos cumplen a-f | Obligatoria | TBD | TBD | — | — |