ebMS 3.0 / AS4 Message Service Handler Validator

SOAP 1.2 envelope validator for ebMS 3.0 messages (UserMessage, SignalMessage Receipt / Error / PullRequest). Recognises AS4 Action URIs, ebCore PartyId types and the EBMS:0001-0202 error catalogue. 100 % client-side.

How it works

ebMS 3.0 is the third generation of the OASIS Message Service Handler for asynchronous B2B messaging. Its AS4 profile (OASIS ebMS-3 Part 2) narrows its usage and is now mandated on several major operational networks across Europe:

• CEF eDelivery — the EU's official infrastructure for cross-government messaging.
• ENTSO-E — European electricity TSOs (Master Data, balancing, forecasts).
• eHealth Network — cross-border patient summaries and e-prescriptions.
• e-CODEX — cross-border judicial proceedings.
• OpenPEPPOL AS4 — e-invoicing Access Points.

The wire format is a SOAP 1.2 envelope whose header carries an <eb:Messaging> element (namespace http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/) that contains:

• An <eb:UserMessage> — the business-document channel (Submit, Forward…): MessageInfo, PartyInfo (From / To), CollaborationInfo (Service / Action / ConversationId), MessageProperties, PayloadInfo (PartInfo with a cid: href pointing to a MIME attachment).
• Or an <eb:SignalMessage> — for signals: Receipt (non-repudiation acknowledgement, NRR), Error (with category, severity, EBMS code), PullRequest (AS4 pull mode).

Validator pipeline:

1. If the input starts with MIME headers (multipart/related), extract part 0 (the SOAP envelope).
2. Parse XML (DOMParser in the browser, fast-xml-parser fallback).
3. Find the <soap:Envelope> root and detect the SOAP version via its namespace.
4. Locate <eb:Messaging> inside the SOAP header and discriminate UserMessage / SignalMessage.
5. Extract the sub-elements, look up the codelists (PartyId types, AS4 actions, EBMS error codes), detect WS-Security (ds:Signature, xenc:EncryptedData).
6. Apply the rules below.

Why an AS4 validator?

A typical AS4 Access Point (Axway, IBM, Holodeck B2B, Domibus…) tends to reject incoming messages with a generic EBMS:NNNN response, without surfacing which envelope field is malformed. This validator aims to:

• Quickly verify the structure of a captured production message before replaying it.
• Recognise the 30 most frequent EBMS codes from Annex C (category, severity, short label).
• Distinguish a Receipt NRR from a PullRequest and an Error without firing up Domibus.
• Detect the presence — not the cryptographic validity — of a WSSE signature or an EncryptedKey.
• Unwrap a multipart MIME body to check that cid: references in PayloadInfo match the actual MIME parts.

Rules checked

• SOAP version: the envelope must declare the http://www.w3.org/2003/05/soap-envelope namespace (SOAP 1.2). A SOAP 1.1 envelope raises a warning (ebMS 3.0 / AS4 explicitly mandates SOAP 1.2 on the wire).
• eb:Messaging: present in <soap:Header>, with soap:mustUnderstand="true" (warning otherwise).
• UserMessage — MessageInfo/Timestamp (xsd:dateTime), MessageInfo/MessageId (RFC 2822 format, warning otherwise), PartyInfo/From/PartyId and PartyInfo/To/PartyId, CollaborationInfo/Service and CollaborationInfo/Action. A missing ConversationId raises a warning.
• SignalMessage — MessageInfo mandatory, at least one of Receipt / Error / PullRequest. RefToMessageId is recommended on a Receipt.
• PayloadInfo: every PartInfo must carry an href attribute in cid: or #fragment form. A missing or non-conforming href raises a warning.
• Errors: an EBMS:NNNN code outside the bundled catalogue raises a warning; a category outside {Content, ProcessingMode, Communication, Unpackaging, InternalError} also raises a warning.
• PartyId types: an ebCore URN that is not in the bundled list raises an info-level diagnostic — useful in integration to flag a non-standard identifier type.

EBMS error catalogue (Annex C)

The validator recognises the 30 most frequent codes from Annex C of the AS4 profile. An unrecognised code is not a blocker: a custom Access Point error is surfaced with a W_UNKNOWN_AS4_ERROR warning.

AS4 actions recognised

The validator recognises 20 common <eb:Action> values covering the main European operational networks. An unrecognised action raises an info diagnostic.

• Acceptance — e-CODEX — Acceptance (e-CODEX)
• Delivery — e-CODEX — Delivery (e-CODEX)
• Forward — eHealth Network — Forward (eHealth Network)
• GenerationForecast — ENTSO-E — Generation Forecast (ENTSO-E)
• http://docs.oasis-open.org/ebxml-msg/as4/200902/action — AS4 conformance action (default) (OASIS AS4)
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay.receive — ebMS 3.0 One-Way Receive (OASIS ebMS 3.0)
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay.submit — ebMS 3.0 One-Way Submit (OASIS ebMS 3.0)
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/twoWay.submit — ebMS 3.0 Two-Way Submit (OASIS ebMS 3.0)
• http://docs.peppol.eu/edelivery/as4/action — PEPPOL AS4 — default action (OpenPEPPOL)
• ImbalancePrice — ENTSO-E — Imbalance Price (ENTSO-E)
• MasterDataReport — ENTSO-E — Master Data Report (ENTSO-E)
• Notify — EU CEF eDelivery — Notify (CEF eDelivery)
• Receive — EU CEF eDelivery — Receive (CEF eDelivery)
• RelayREMMDAcceptanceRejection — e-CODEX — Relay REMMD Acceptance / Rejection (e-CODEX)
• Retrieval — e-CODEX — Retrieval (e-CODEX)
• Submit — EU CEF eDelivery — Submit (CEF eDelivery)
• TC1Leg1 — AS4 conformance — TC1 Leg 1 (OASIS AS4 conformance)
• TC2Leg1 — AS4 conformance — TC2 Leg 1 (OASIS AS4 conformance)
• TransmissionRights — ENTSO-E — Transmission Rights (ENTSO-E)
• urn:oasis:names:tc:ebcore:test:01:01 — ebCore conformance test action (OASIS ebCore)

Limits

• No full XSD validation of the envelope — only the rules above. The official ebms-header-3_0-200704.xsd and ebbp-signals-2.0.xsd schemas are strict on a few secondary cardinalities we do not cover.
• No cryptographic verification — the validator detects the presence of a ds:Signature or an xenc:EncryptedData, but verifies neither the signature nor the certificate chain. Use your enterprise PKI or a tool like Domibus / Holodeck for that.
• No PMode validation — the mapping to the Processing Mode configured on your Access Point is not checked. A Service / Action compliant with OASIS may still not be accepted by your gateway.
• No payload validation — if the wrapped content is a UBL invoice, run it through UBL 2.1 Validator or PEPPOL Validator downstream.

Privacy

Related documentation

• OASIS ebMS 3.0 Core (PDF) — the reference spec (sections 5 message structure, 6 security, 6.7 error reporting).
• OASIS AS4 Profile v1.0 (PDF) — the restrictive AS4 profile and its Annex C (EBMS:0001-0202 error catalogue).
• CEF eDelivery (European Commission) — official documentation of the CEF AS4 infrastructure.
• PEPPOL AS4 Specification — the AS4 profile used on the OpenPEPPOL network.