Peppol Specifics

Peppol Specifics

This page lists all aspects of phoss-ap that are specific to the Peppol network. If the AP were to be adapted for a different e-delivery network, these are the areas that would need review and likely modification.

---

1. Identifier Scheme

Peppol defines its own participant identifier scheme (iso6523-actorid-upis) with specific format rules.

Identifier	Peppol format	Used in
Participant ID (sender/receiver)	Scheme + value, e.g. 0088:1234567890	Outbound submission, SMP lookup, SBDH, reporting
Document Type ID	Peppol-defined URN scheme	SMP lookup, SBDH, reporting
Process ID	Peppol-defined URN scheme	SMP lookup, SBDH, reporting
Seat ID	AP registration ID, e.g. POP000000	Configuration, inbound metadata

Difference in other networks: Identifier formats, schemes, and registries would differ entirely.

---

2. SBDH / SBD Envelope

Peppol mandates the use of a Standard Business Document Header (SBDH) as the envelope around the business document. The combined package (SBDH + payload) is the Standard Business Document (SBD).

• The AP creates the SBDH when the Sender Backend submits a raw document + metadata
• The AP extracts metadata from the SBDH when receiving a pre-built SBD
• SBDH extensions carry Peppol-specific fields (e.g., MLS_TO, C1 country code)
• The SBDH Instance Identifier is the primary correlation key across MLS, reporting, and duplicate detection

Difference in other networks: Different envelope formats (or none). SBDH extensions are Peppol-specific.

---

3. SMP / SML Discovery

Peppol uses a two-tier discovery mechanism:

• SML (Service Metadata Locator): DNS-based lookup to find which SMP hosts a given participant
• SMP (Service Metadata Publisher): REST service that returns the AS4 endpoint URL, certificate, and supported document types for a participant

The AP queries the SMP before each outbound send to resolve the C3 endpoint. The receiver verification step (IReceiverCheck) may also query the AP's own SMP registration.

Configuration: smpclient.truststore.*, peppol.stage (test vs. prod determines SML endpoint).

Difference in other networks: Different or no discovery protocol. Endpoint resolution may be static, registry-based, or use a completely different mechanism.

---

4. AS4 Profile

Peppol defines a specific AS4 profile on top of the OASIS ebMS3/AS4 standard, including:

• Specific PMode parameters (agreement, service, action values)
• One-way push MEP (Message Exchange Pattern)
• Mandatory message signing and encryption
• Synchronous AS4 Receipt expected
• Specific error codes, e.g. EBMS:0004 with errorDetail = PEPPOL:NOT_SERVICED

The phase4 library (phase4-peppol-client, phase4-peppol-servlet) implements this Peppol-specific AS4 profile.

Difference in other networks: Different AS4 profile, different PMode parameters, or a completely different transport protocol.

---

5. PKI and Certificates

Peppol operates its own Public Key Infrastructure (PKI) with separate trust hierarchies for test and production:

• AP keystore: Contains the AP's Peppol-issued certificate and private key for AS4 signing/decryption
• AP truststore: Contains the Peppol root/intermediate CA certificates for validating remote AP signatures
• SMP client truststore: For validating SMP server TLS certificates
• peppol.stage (test or prod) selects which PKI chain is active
• CRL (Certificate Revocation List) downloads are Peppol-specific

Configuration: org.apache.wss4j.crypto.merlin.keystore.*, org.apache.wss4j.crypto.merlin.truststore.*

Difference in other networks: Different CA hierarchy, different certificate issuance process, potentially different crypto requirements.

---

6. Message Level Status (MLS)

MLS is a Peppol-defined asynchronous feedback mechanism:

• C3 sends an MLS response back to C2 after processing an inbound document
• MLS is itself sent as a regular Peppol AS4 message (reusing the sending infrastructure)
• Three response codes: RE (Rejection), AP (Approved), AB (Accepted Blind)
• MLS_TO: Alternative participant ID for MLS routing (per-transaction, from SBDH extension)
• MLS_TYPE: Controls when MLS is sent — FAILURE_ONLY or ALWAYS_SEND (per AP instance)

MLS SLA Milestones

The Peppol Network Policy defines timing requirements based on AS4 timestamps:

Milestone	Definition
M1	AS4 Timestamp when business document is sent at C2
M2	AS4 Timestamp when MLS message is sent at C3
M3	Date/time when MLS is received at C2

SLR	Requirement
MLS-1	99.5%: M2 - M1 <= 20 minutes
MLS-2	99.5%: M3 - M1 <= 25 minutes

Difference in other networks: MLS is entirely Peppol-specific. Other networks may have no delivery status mechanism, or use a different protocol (e.g., MDNs, polling).

---

7. Peppol Reporting (TSR / EUSR)

Peppol requires APs to submit periodic Transaction Status Reports (TSR) and End User Statistics Reports (EUSR):

• Reports are generated using the peppol-reporting library
• Submission is scheduled (configurable day/hour/minute)
• Each reported transaction needs: sender ID, receiver ID, document type ID, process ID, C1 country code (outbound) or C4 country code (inbound)
• Reporting status is tracked per transaction (pending / reported)
• The reporting sender ID is a Peppol Participant ID configured via peppol.reporting.senderid

Difference in other networks: Different or no reporting requirements. Report formats, submission schedules, and required data points would differ.

---

8. Country Codes (C1 / C4)

Peppol requires country codes for reporting purposes:

• C1 country code: Country of the original sender. Provided by the Sender Backend at submission time (or extracted from SBDH). Stored in outbound_transaction.
• C4 country code: Country of the final receiver. Provided by the Receiver Backend either synchronously (HTTP response) or asynchronously (reporting API call). Stored in inbound_transaction.

Difference in other networks: These are Peppol reporting requirements. Other networks may not need corner-specific country tracking.

---

9. Receiver Verification

Peppol requires that a receiving AP (C3) verifies it actually services the addressed receiver participant before accepting a document. If not, the specific AS4 error EBMS:0004 / PEPPOL:NOT_SERVICED must be returned.

Implementations: SMP self-query, local participant registry, or other pluggable mechanism (IReceiverCheck SPI).

Difference in other networks: Different error codes, different verification requirements, or no receiver check at all.

---

10. Duplicate Detection Levels

Peppol duplicate detection operates at two levels:

Level	What it checks
AS4 Message ID	Exact AS4 message retransmission
SBDH Instance Identifier	Same Peppol envelope resent with a different AS4 Message ID

Both levels are Peppol-relevant because the SBDH Instance Identifier is a Peppol concept.

Difference in other networks: Different envelope identifiers, potentially different duplicate detection granularity.

---

11. 4-Corner Model Terminology

phoss-ap uses the Peppol 4-corner model throughout:

Term	Meaning
C1	Sender (business entity)
C2	Sender Access Point
C3	Receiver Access Point
C4	Receiver (business entity)
Sender Backend	System at C1/C2 that submits documents to the AP
Receiver Backend	System at C3/C4 that receives documents from the AP

Difference in other networks: Different terminology (e.g., "gateway", "connector", "node"), potentially a different number of corners (3-corner, 2-corner).

---

12. Transaction Type: mls_response

The outbound_transaction table has a transaction_type field distinguishing business_document from mls_response. MLS responses are tracked as outbound transactions with a link back to the originating inbound transaction.

Difference in other networks: Without MLS, there is no secondary transaction type. The outbound table would only contain business documents.

---

13. phase4-Peppol Library Dependencies

The following Maven dependencies are Peppol-specific:

Dependency	Purpose
phase4-peppol-client	Peppol AS4 profile for sending
phase4-peppol-servlet	Peppol AS4 profile for receiving
peppol-commons	Peppol identifier handling, SBDH, SMP client
peppol-reporting	TSR/EUSR report generation and submission

Difference in other networks: Would require different phase4 profile modules (or a different AS4 library entirely) and different reporting libraries.

---

14. Configuration Properties (Peppol-specific)

Property	Purpose
peppol.stage	test or prod (selects PKI and SML)
peppol.seatid	This AP's Peppol Seat ID
peppol.owner.countrycode	Country code of the AP operator
peppol.sending.enabled	Enable/disable outbound sending
peppol.receiving.enabled	Enable/disable inbound receiving
peppol.reporting.senderid	Participant ID for reporting submission
peppol.reporting.scheduled	Enable scheduled reporting
peppol.reporting.schedule.*	Reporting schedule (day, hour, minute)
mls.type	MLS sending strategy
phase4.endpoint.address	Public AS4 endpoint URL
smpclient.truststore.*	SMP client TLS trust

Difference in other networks: Entirely different configuration namespace and semantics.