First draft WBCS on QeRDS AS4 from the QTSP group.

[alejandro-nieto-git]

This is a first draft of the QTSP group WBCS on QeRDS that was assigned to us as DigitelTS by @sander. We don't have that much experience with AS4 so any feedback is welcome.

[DavSanOl]

Looks good!

[kjorlaug]

Solid piece of work :)

Two overall questions (non-blocking, but worth settling before we merge):

• ETSI baseline. Anchoring to EN 319 522 V1.2.1 (2024-01) for parts 1–3 is the right call. But I'd suggest a short non-normative annex tracking the expected 522 deltas (especially the 4-3 discovery/trust binding) so our pilot findings feed the revision cleanly.
• AS4 2.0 crypto baseline. Mandating the eDelivery AS4 2.0 Common Profile (Ed25519 / X25519+HKDF, SEC-004/006/008) is coherent for a greenfield QERDS channel that stands up its own PKI — which is what this is — so no change to the SEC clauses is needed. The only thing that makes it incoherent is SCOPE-006 (see inline), which simultaneously demands Peppol-network conformance; Peppol runs CEF 1.14 + RSA on the Peppol PKI, so the two can't both hold. Drop the Peppol-conformance claim and the crypto choice stands as written.

The resolution gap in §2 lines up with the EDD CS proposed in #253 — I'd defer to that spec explicitly rather than restate discovery here, so the CS family has one clean producer/consumer seam (EDD produces endpoint + certs + trust status; this profile consumes them).

[kjorlaug]

Suggested change

**`AS4CONF-SCOPE-006`** [MUST]: Implementations MUST comply with the PEPPOL AS4 Profile where applicable, using [CEF-AS4-2.0] as the underlying AS4 implementation baseline instead of the version mandated within the PEPPOL Profile specification itself. This ensures PEPPOL interoperability while anchoring to the CEF AS4 2.0 security, cryptographic, and message-structure requirements specified in §7.

Recommend removing this requirement. It mandates Peppol-network conformance while §7.2 mandates the AS4 2.0 Common Profile crypto (Ed25519 / X25519). Those are mutually exclusive in practice: Peppol conformance is defined against CEF eDelivery AS4 1.14 and the Peppol PKI (RSA certificates, BST key reference), so an Ed25519-signed message on a non-Peppol certificate neither verifies at a Peppol AP nor chains to the Peppol PKI. Since we're explicitly not targeting Peppol-as-QERDS, the C2–C3 relay doesn't need to be Peppol-conformant at all.

The only place a Peppol relationship is in play is the "enhance Peppol with wallet" scenario (SC5 Scenario 5)...

[kjorlaug]

Putting discovery out of scope is fine, but as written the document then assumes, without stating it, that C2 already holds C3's endpoint URL and encryption certificate and trusts that cert, and those are load-bearing for in-scope normative clauses (SEC-005/006/008 can't be satisfied without C3's encryption cert; MSG-005 receipt verification can't be satisfied without C3's signing cert), in both directions.

This is exactly the seam the EDD conformance spec is being carved out to own (#253), whose "Connection" step is defined as retrieving the endpoint and security certificates for delivery, with QERDS named as one of the networks "Discovery" resolves. Suggest a sentence in the out-of-scope paragraph that names this dependency and defers to it, e.g.:

Resolution of C3 and its AS4 endpoint, encryption certificate, and trust status, is out of scope and is the responsibility of the European Digital Directory identification/discovery/connection layer (see EDD conformance specification). This profile assumes that resolution has already occurred and, for the pilot, that these values are statically provisioned. All AS4CONF-SEC-* and Receipt-verification requirements presuppose it.