Page tree

Access Point specifications

eDelivery AS4 profile

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 ebMS 3.0 standard of OASIS.

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

Standardization organization: OASIS


OpenPEPPOL AS2 profile

The OpenPEPPOL AS2 profile is an open specification for the secure exchange of documents over the internet. It is based on RFC4130 HTTP Applicability Statement 2 (AS2). It was specifically designed by and for the OpenPEPPOL Community to exchange business messages in the context of public procurement over the OpenPEPPOL infrastructure. 

Standardization organization: OpenPEPPOL



eDocument FAQs 

SBDH Frequently Asked Questions

 What is SBDH?
SBDH is an acronym for the UN/CEFACT Standard Business Document Header. SBDH can be used in conjunction with eDelivery.

 What are the main benefits of using SBDH?
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.

 What are the main drawbacks of using SBDH?
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 Order document, 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

 Do we have to use SBDH if we are using eDelivery?
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.

 Does use of SBDH require us to change our document schemas?
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.  

 Does SBDH support the same metadata as the AS4 header?
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). 

ASiC Frequently Asked Questions

 What is ASiC?
ASiC is an acronym for Associated Signature Containers (ASiC). ASiC can be used in conjunction with eDelivery.

 What are the main benefits of using ASiC?
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. 

 What are the main drawbacks of using ASiC?
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.  

 Do we have to use ASiC if we are using eDelivery?
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.

 Do we have to use ASiC if we are exchanging multiple payloads in eDelivery?
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].