1. Description

This document describes how to implement AS4 in the Peppol network. AS4 implementations must follow [CEFeDeliveryAS4] (CEF eDelivery AS4 Profile v1.14) and aspects described in this document that further define and restrict features and attributes that are either not profiled in the CEF specification, or are optional and not used in the Peppol network.

In short, AS4 is used in the Peppol network for transmission of asynchronous messages between corner 2 and corner 3 in a Four Corner Topology using the Peppol PKI for signature and encryption on AS4 message level and SMP/SML for dynamic discovery.

2. Changelog

Version 2.0.3 (2024-04-22)

  • Renamed "OpenPEPPOL" to "OpenPeppol"

  • Fixed broken links inside the document and in the references

  • Updated versions of eDEC References

  • Added missing references to RFC 2119, RFC 7230 and Peppol Policy for Transport Security

  • Unified table headings and layouts

  • Added a clarification on the exact usage of Binary Security Token ValueType attribute

Version 2.0.2 (2021-04-13)

  • Added a statement that "Binary Security Token" must be used

  • Updated the references to the latest versions

  • Changed "PEPPOL" to "Peppol"

  • Replaced the "fixed value cenbii-procid-ubl" in chapter 5 with a link

Version 2.0.1 (2019-08-23)

Release version 2.0.1.

  • Fixing inconsistency in "service type" usage. The correct value is cenbii-procid-ubl.

Version 2.0.0 (2018-11-16)

Release version 2.0.0.

  • Aligning MSH Roles to use default values of AS2 specification.

Version 2.0.0 RC2

  • Based on CEF eDelivery AS4 Profile v1.14

  • Added missing references

  • Updated MSH Roles

  • Updated TLS Ports and TLS Usage

  • Added a subsection on Dynamic Discovery

Contributors

  • OpenPeppol TICC CMB

  • Erlend Klakegg Bergheim, Difi

  • Jerry Dimitriou, OpenPeppol Operating Office

Version 2.0.0 RC1

Changes:

  • Changing SMP transport profile identifier from peppol-transport-as4-v1_0 to peppol-transport-as4-v2_0.

  • Adding missing references.

  • Changing value for MPC from a link to text to avoid misunderstandings.

Contributors:

  • OpenPeppol TICC CMB

Version 2.0.0 B1

This is the final delivery by the workgroup after feedback from CEF. Major changes from v1.0.0:

  • Completely based on CEF eDelivery AS4 profile v1.13

  • Mandatory TLS usage

  • New value for the SMP “transportProfile”

Contributors:

  • Erlend Klakegg Bergheim, Difi

  • Jerry Dimitriou, OpenPeppol Operating Office

  • Bård Langöy, Pagero

  • Even Østvold, Difi

  • Rune Kjørlaug, Difi

3. Base Specification

Related to CEF eDelivery AS4 2.1.

The table below contains a high level overview of changed features in OpenPeppol AS4 specification compared to the table of features in [CEFeDeliveryAS4].

Table 1. Changed functionality for OpenPeppol
Functionality OpenPeppol AS4 [CEFeDeliveryAS4]

Exchange Patterns

One Way

One Way or Two Way (*)

Exchange Pattern Bindings

Push

Push, Pull and Sync (*)

Message Correlation

ebMS 3.0 "ConversationId"

ebMS 3.0 "RefToMessageId" and "ConversationId"

3.1. Notation

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

4. Implementation in OpenPeppol

4.1. Exchange Patterns

Related to CEF eDelivery AS4 3.2.1, 3.2.2 and 3.4.2.

One-Way/Push is the only exchange pattern currently supported by OpenPeppol and MUST be used for all transmissions in the Peppol network.

One-Way/Pull is an optional MEP of the [CEFeDeliveryAS4]. OpenPeppol has no requirements that are covered by the specific MEP and thus the One-Way/Pull MEP SHALL NOT be used.

Two-Way/Push-and-Push is mandatory to support according to [CEFeDeliveryAS4], however it SHALL NOT be used in the Peppol network. (This results in eb:RefToMessageId not being used.)

Two-Way/Sync is, due to asynchronous transmission in the Peppol network, excluded and SHALL NOT be used in the Peppol network.

4.2. Configuration of Transport Level Security (TLS)

Related to CEF eDelivery AS4 3.2.6 and 3.4.5.

Access Points that are part of the Peppol network do not exchange information related to IPs and ports upfront of transmitting messages as described in [CEFeDeliveryAS4].

In the Peppol network the access point MUST be configured according to the following:

  • Receiving access points MUST support TLS according to section 3.2.6 of CEF eDelivery AS4. Versions newer than TLS v1.2 might be used upon mutual agreement via the TLS handshake.

  • Port 443 MUST be used for TLS.

  • Sending access points need only to allow outbound transmissions to port 443.

TLS MUST use a valid certificate compliant with the Peppol Policy for Transport Security (see [PEPPOL-TS-POL]).

4.3. Agreement

Related to CEF eDelivery AS4 3.2.2.

As the message exchange between two Access Points in the Peppol eDelivery Network is based on the [TIA-AP-PROV] the PMode.Agreement parameter which is used to indicate the business agreement that governs the message exchange MUST have value urn:fdc:peppol.eu:2017:agreements:tia:ap_provider without type attribute. The reference to the agreement is included in the eb3:AgreementRef element of the ebMS messaging header.

The eb3:AgreementRef element also includes an optional attribute pmode which can be used to include the PMode.ID. This attribute MUST NOT be used as Access Points may use just one generic P-Mode for receiving messages.

Table 2. P-Modes for OpenPeppol
P-Mode Parameter Value

PMode.Agreement

Fixed value:

urn:fdc:peppol.eu:2017:agreements:tia:ap_provider

4.4. Feedback when receiver is not serviced

When an Access Point receives a business document, it SHOULD check whether it services the addressed participant for the specific document type id and process id, in order to be able to deliver the message. If a MSH is able to execute custom validations of the payload of a User Message during the ebMS message processing, it is RECOMMENDED that the Access Point includes the check on the addressee, document type id and process id. In case the addressed participant is not serviced for the specific document type and process by the Access Point, it MUST generate and send back an ebMS Error.

The errorCode attribute of the generated Error MUST be set to EBMS:0004 (Other error) and its severity attribute MUST be set to failure. Furthermore the errorDetail attribute MUST have value PEPPOL:NOT_SERVICED to indicate that the addressed participant is not serviced by the Access Point.

4.5. Party Identification

Related to CEF eDelivery AS4 3.4.1 and 4.1.2.

Table 3. P-Modes for OpenPeppol
P-Mode Parameter Value

PMode.Initiator.Party

One PartyId with value the Subject CNAME of the Peppol Access Point Certificate issued to the Access Point, e.g. POP000000
Fixed value for Party.type [1]:

urn:fdc:peppol.eu:2017:identifiers:ap

PMode.Initiator.Role

Fixed value:

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/initiator

PMode.Responder.Party

One PartyId with value the Subject CNAME of the Peppol Access Point Certificate issued to the Access Point, e.g. POP000000
Fixed value for Party.type [1]:

urn:fdc:peppol.eu:2017:identifiers:ap

PMode.Responder.Role

Fixed value:

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/responder

Use of trackingIdentifier is not specified by OpenPeppol and MUST NOT be used.

4.6. Service, Action and Role

Related to CEF eDelivery AS4 3.4.4.

When sending the business document the Access Point MUST set PMode[1].BusinessInfo.Service to the Peppol process identifier as specified for the business document. The PMode[1].BusinessInfo.Service.type MUST be set to the Peppol process identifier schema as specified for the business document (cenbii-procid-ubl as default when not specified). The values for scheme and process identifier SHALL NOT use URL percent encoding.

PMode[1].BusinessInfo.Action MUST be set to business document’s encoded document type identifier as defined for the business document (busdox-docid-qns as default when document type identifier scheme is not specified). The document type identifiers MUST be formatted as specified in [PEPPOL-ID-POL].

Table 4. P-Modes for OpenPeppol
P-Mode Parameter Value

PMode[1].BusinessInfo.Service

The Peppol Process Identifier Value of the business document.

Example:
urn:www.cenbii.eu:profile:bii01:ver2.0

PMode[1].BusinessInfo.Service.type

The Peppol Process Identifier Scheme of the business document.

Example:
cenbii-procid-ubl

PMode[1].BusinessInfo.Action

The Peppol Document Type Identifier of the business document formatted as follows:
«scheme id»::«document type id value»

Example:
busdox-docid-qns::urn:oasis:names:specification:ubl:schema: xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction: biitrns010:ver2.0:extended:urn:www.peppol.eu:bis: peppol5a:ver2.0::2.1

4.7. Use of Peppol PKI

Related to CEF eDelivery AS4 3.2.6 and 3.4.5.

All communication in the Peppol network uses the Peppol PKI. Certificates MUST be verified upon fetching from the SMP. Certificates not issued by OpenPeppol MUST NOT be used.

Because of the dynamic nature of certificate exchange in the Peppol network, the type "Binary Security Token" (BST) MUST be used as the key identifier type. The ValueType attribute of the BST MUST have the value

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3

Table 5. P-Modes for OpenPeppol
P-Mode Parameter Value

PMode[].Security.X509.Signature.Certificate

Peppol certificate of sending AP.

PMode[].Security.X509.Encryption.Certificate

Peppol certificate of receiving AP fetched from SMP.

4.8. Use of default MPC

The message partition channel feature as defined in [ebMS3CORE] is not needed for the message exchanges between the Access Points in the Peppol eDelivery Network. Therefore the default MPC is used, i.e. PMode[1].BusinessInfo.MPC MUST be set to:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC

Because the default MPC is used the eb3:UserMessage/@mpc attribute MAY be omitted in the ebMS message header.
Table 6. Changed P-modes for OpenPeppol
P-Mode Parameter Value in the eDelivery Common Profile

PMode[].BusinessInfo.MPC

Fixed value:

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC

4.9. Use of SBDH

Related to CEF eDelivery AS4 4.2.

All transmissions in the Peppol network MUST package content as an integrated part using SBDH according to [PEPPOL-Envelope], rendering 4.2.7 out of scope as SBDH is mandatory.

Standalone SBDH as described by [CEFeDeliveryAS4] is not supported and MUST NOT be used, rendering 4.2.2, 4.2.3, 4.2.4 out of scope.

For transmissions in the Peppol network is [CEFeDeliveryAS4] 4.2.1, 4.2.5, 4.2.6 relevant, including use of originalSender and finalRecipient.

The SBDH containing a business message MUST be found in the first MIME attachment after the MIME attachment containing the AS4 header.

4.10. Message packaging

Related to CEF eDelivery AS4 3.4.6.

As defined in section 5 of [ebMS3CORE] the payloads of an ebMS User Message may be contained in either the SOAP Body or separate MIME attachments. Since this profile however uses the AS4 Compression Feature (see below) which applies only to payloads packaged in attachments the Access Point MUST include all payloads as MIME attachments.

When sending large messages an Access Point MAY use the http chunked transfer encoding to enable more streamlined processing. As specified in section 4.1 of [RFC7230] Access Points MUST support this encoding when receiving messages.

The "Content-Disposition" MIME header as described in section 5.1.9 of [AS4-Profile] SHALL NOT be used to exchange the filename of an attached payload. AS4 implementations not supporting removal of the MIME header MUST use payload.xml as filename.

5. P-Mode Parameters

Related to CEF eDelivery AS4 3.5.

The following table lists the PMode parameters that are profiled in the Peppol AS4 Specification. Parameters not listed, inherit the default values of CEF AS4 Specification and ultimately the default values of the OASIS AS4 Specification.

Table 7. Changed P-modes for OpenPeppol
P-Mode Parameter Value in the eDelivery Common Profile

PMode.Agreement

Fixed value:

urn:fdc:peppol.eu:2017:agreements:tia:ap_provider

PMode.MEP

Fixed value:

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay

PMode.MEPBinding

Fixed value:

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/push

PMode.Initiator.Party

see Party Identification

PMode.Initiator.Party.type

Fixed value:

urn:fdc:peppol.eu:2017:identifiers:ap

PMode.Responder.Party

see Party Identification

PMode.Responder.Party.type

Fixed value:

urn:fdc:peppol.eu:2017:identifiers:ap

PMode[].BusinessInfo.Service

see Service, Action and Role

PMode[].BusinessInfo.Service.type

see Service, Action and Role

PMode[].BusinessInfo.Action

see Service, Action and Role

PMode[].BusinessInfo.MPC

Fixed value:

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC

6. Non-AS4 related aspects

6.1. Capability Lookup

Related to CEF eDelivery AS4 4.3 and 4.4.

Lookup functionalities in the Peppol network use Peppol SMP and Peppol SML according to [PEPPOL-SML] and [PEPPOL-SMP].

OpenPeppol will upgrade to OASIS BDXL and OASIS BDXR SMP as part of a later migration project.

6.2. Peppol Dynamic Discovery using SMP

Related to CEF eDelivery AS4 4.3 and 4.4.

6.2.1. Transport Profile Identifier

Receiving Access Points MUST ensure that they have configured one or more P-Modes so they can receive messages for all combinations of document type and process (including scheme) identifiers referenced by AS4 endpoints (i.e. transportProfile attribute has value peppol-transport-as4-v2_0) that they have registered in the SMP.

6.2.2. Peppol Dynamic Discovery

Sending Access Point

The sending Access Point MUST follow the Dynamic Sender Profile enhancement. According to the profile enhancement, the sender MUST be able to create a FULL P-Mode using the dynamic discovery infrastructure. Peppol uses a combination of parameters found in SMP Signed Service Metadata Records (see [PEPPOL-SMP]) to fill in the required P-Mode parameters.

The following table depicts the P-Mode Parameters that must be fetched from the SMP Record

Table 8. P-Mode Parameter Mapping for Dynamic Sender
P-Mode Parameter SMP Record Object

PMode[1].BusinessInfo.Action

SignedServiceMetadata/ServiceMetadata/ServiceInformation/DocumentIdentifier

PMode[1].BusinessInfo.Service

SignedServiceMetadata/ServiceMetadata/ServiceInformation/Processlist/Process/ProcessIdentifier

PMode[1].BusinessInfo.Service@type

SignedServiceMetadata/ServiceMetadata/ServiceInformation/Processlist/Process/ProcessIdentifier@type

PMode[].Protocol.Address

SignedServiceMetadata/ServiceMetadata/ServiceInformation/Processlist/Process/ServiceEndpointList/Endpoint[@transportProfile="peppol-transport-as4-v2_0"]/EndpointReference/Address

PMode[1].Security.Encryption.Certificate

SignedServiceMetadata/ServiceMetadata/ServiceInformation/Processlist/Process/ServiceEndpointList/Endpoint[@transportProfile="peppol-transport-as4-v2_0"]/Certificate
Receiving Access Point

Following the guidelines provided in CEF eDelivery AS4 4.5, an Access Point MAY use a "generic" P-Mode to receive the registered business documents. Such a generic P-Mode only defines the parameters related to the Access Point itself but no business document specific ones.

7. Conformance

In order for an AS4 implementation to conform to the Peppol AS4 Profile, it MUST:

  • Support 6.1. eDelivery AS4 Common Profile Conformance Clause in CEF eDelivery AS4 specification.

  • Support 6.2. eDelivery AS4 Four Corner Topology Conformance Clause in CEF eDelivery AS4 specification.

  • Support 6.3. eDelivery AS4 SBDH Conformance Clause in CEF eDelivery AS4 specification.

  • Support 6.4. eDelivery AS4 Dynamic Receiver Conformance Clause in CEF eDelivery AS4 specification.

  • Support 6.6. eDelivery AS4 Dynamic Sender in Four Corner Exchanges Conformance Clause in CEF eDelivery AS4 specification.

  • Conform to all normative statements and requirements in chapter 3 in this document.

  • Conform to all normative statements and requirements in chapter 5 in this document.

References

1. The "type" attribute is not part of the original AS4 Xml Schema Definition (XSD). OASIS has acknowledged the issue and there is a corrected version of the XSD is available.