The eDelivery AS4 profile is an open specification for the secure and payload-agnostic exchange of data using web services. It is based on the ebMS3 (ebXML Messaging version 3.0) standard of OASIS and its AS4 (Applicability Statement 4) Conformance Profile.
ETSI also identified AS4 as meeting the requirements for Electronic Registered Delivery Services introduced by the eIDAS Regulation (see EN 319 522-4-1).
Key characteristics of the profile are:
It has provisions for use in 4-corner network topologies, but can also be used in point-to-point exchanges
It is designed to support both One Way and Two Ways (Request-Response) exchanges
It is payload-agnostic, meaning that the service is not aware of the content it is serving and therefore can be used for all types of documents/messages (e.g. purchase order, invoice, claim, etc.)
It is secure in that it supports the use of digital certificates for signing and encryption
SBDH provides a standard way to encode some message metadata. This can be used to simplify delivery and routing of payload, and to control the way content is processed (e.g. transformed).
The SBDH is a payload, it is not part of the eDelivery AS4 (or other) message header and therefore not dependent on any features or aspects of eDelivery AS4. This means that, when used with eDelivery AS4 in a Four Corner Topology, it can be used as an “end-to-end” header in all legs: from C1 to C2, from C2 to C3 and from C3 to C4. The information is preserved and is available to the Consumer.
There may be an impact on the XML schemas of exchanged XML payloads.
The SBDH can be argued to be redundant. Some or all of its content may already be present in another part of an XML document or in the eDelivery header, e.g. the SBDH Sender party may, when used with a UBL Orderdocument, be the same as the BuyerCustomerParty and as the originalSender message property of the eDelivery AS4 header.
While SBDH has some extensibility features, it may not support all requirements and use cases for message metadata
No, eDelivery is payload-neutral and intended to be used with arbitrary content. From the eDelivery point of view, SBDH is considered part of the content that is exchanged. Constraints on exchanged content are to be agreed within specific user communities.
If a domain uses the SBDH as a header in one of more of its XML business documents, the XML schema for that business document needs to allow the SBDH to be used as a header element.
However, the SBDH can also be used as a separate, standalone XML payload that only provides metadata about (an) other payload(s). In that case, there is no impact on the XML schema for that (those) payload(s). In fact, there is no requirement that the payload(s) are XML. This situation is well supported in eDelivery AS4.
No, some features of the AS4 header have no counterpart in SBDH, in particular the AgreementRef, party Role headers and payload part properties. Some headers are similar but have strictly speaking different semantics (e.g. ProcessIdentifier and Service).
Using ASiC, it is possible to package and sign any payload (or multiple payloads) in a single file container.
Unlike AS4 message signatures, ASiC signatures are part of payload and can therefore be preserved “end-to-end”, across multiple legs, even in four-corner topologies.
End-to-end signing and encryption is often not feasible because of PKI incompatibilities and functional or technical limitations of backend applications. Messaging protocols have added and are providing signing and encryption features precisely for this reason.
End-to-end signature assumes payloads are exchanged without modifications, whereas often intermediaries perform payload transformation or other processing.
No, eDelivery is payload-neutral and intended to be used with arbitrary content. From the eDelivery point of view, ASiC is considered part of the content that is exchanged. Constraints on exchanged content are to be agreed within specific user communities.
Some users find it convenient to wrap all payloads of a message in a ZIP archive or other container before exchanging it using eDelivery. However, eDelivery AS4 does not pose any limit on the number of payloads in message, so you can exchange any number of payloads in a single message. In this aspect, AS4 is just as flexible as email or AS2 [RFC6362].
