1. Description

This document descibes how to implement AS4 in the PEPPOL network. AS4 implementations must follow [CEFeDeliveryAS4] (CEF eDelivery AS4 Profile v1.13) 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 discovery.

2. Changelog

2.1. 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

2.2. Version 0.9.2

This is the final delivery by the workgroup after feedback from CEF.

Contributors:

  • Erlend Klakegg Bergheim, Difi

  • Jerry Dimitriou, University of Pireus

  • Bård Langöy, Pagero

  • Philip Helger, BRZ

  • 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 asyncronous 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 descibed in [CEFeDeliveryAS4].

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

  • Receiving access points MUST configure TLS on port 443.

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

TLS MUST use a valid certificate issued by a trusted issuing agency. The issuing agency MUST be trusted by Oracle (Java) and Microsoft (.NET).

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 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 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. In case the addressed participant is not serviced by the Access Points, 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 Value

PMode.Initiator.Party

One PartyId with value the Subject CNAME of the PEPPOL Access Point Certificate issued to the Access Point, e.g. APP_1000000100
Fixed value for PartyId.type: urn:fdc:peppol.eu:2017:identifiers:ap

PMode.Initiator.Role

Fixed value: urn:fdc:peppol.eu:2017:roles:ap:sender

PMode.Responder.Party

One PartyId with value the Subject CNAME of the PEPPOL Access Point Certificate issued to the Access Point, e.g. APP_1000000100
Fixed value for PartyId.type: urn:fdc:peppol.eu:2017:identifiers:ap

PMode.Responder.Role

Fixed value: urn:fdc:peppol.eu:2017:roles:ap:receiver

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 in the PEPPOL BIS. The PMode[1].BusinessInfo.Service.type MUST be set to the PEPPOL process identifier schema as specified in the PEPPOL BIS (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 in the PEPPOL BIS (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 Value

PMode[1].BusinessInfo.Service

The PEPPOL Process identifier of the business document.

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

PMode[1].BusinessInfo.Service.type

The PEPPOL process identifier schema of the buiness 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.

Table 5. P-Modes for OpenPEPPOL
P-Mode 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
Processing 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 [PEPPOLEnvelope], 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.

Table 7. Changed P-modes for OpenPEPPOL
Processing 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

Please see Party Identification

PMode.Initiator.Party.type

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

PMode.Initiator.Role

Fixed value: urn:fdc:peppol.eu:2017:roles:ap:as4

PMode.Responder.Party

Please see Party Identification

PMode.Responder.Party.type

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

PMode.Responder.Role

Fixed value: urn:fdc:peppol.eu:2017:roles:ap:as4

PMode[].BusinessInfo.Service

Please see Service, Action and Role

PMode[].BusinessInfo.Service.type

Fixed value: urn:fdc:peppol.eu:2017:identifiers:proc-id

PMode[].BusinessInfo.Action

Please 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.1. Capability Lookup

Related to CEF eDelivery AS4 4.3 and 4.4.

Lookup functionalities in the PEPPOL network use Busdox SMP and Busdox 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. SMP transport profile identifier

Related to CEF eDelivery AS4 4.4.

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-v1_0) that they have registered in the SMP.

Note that 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