Repository navigation
Glossary
Philip Helger edited this page Oct 8, 2026
·
12 revisions
One line per term, ordered alphabetically by term, ignoring case — keep new entries in order. Anything not
verified against a specification or against source code in this ecosystem is marked TODO(verify) for review.
| Term | Definition |
|---|---|
| AP — Access Point | A service provider's software endpoint that sends and receives business documents on behalf of participants over AS4. |
| BDXL | OASIS "Business Document Metadata Service Location Version 1.0" — the DNS-based service-location design the Peppol discovery process builds on. Referenced normatively by SML 1.3.0. |
| BDXR | The OASIS specification family for business document metadata services, including OASIS BDXR SMP 1.0 and 2.0. Listed only because the term appears in the libraries: Peppol SMP 1.4.0 is its own specification in the busdox.org namespace and does not reference BDXR SMP — the two are parallel, not layered. BDXR-based deployments are out of scope, see ADR-007. |
| Business card | The structured description of a participant — names, country, geographic info, contacts, additional identifiers — published by the participant's own SMP at {smpHostURI}businesscard/{participantId}, from where the Directory indexer fetches it (verified in phoss-directory's SMPBusinessCardProvider). Three schema versions exist (v1/v2/v3). Note this resource is a phoss-SMP/Directory convention, not part of Peppol SMP 1.4.0. > TODO(verify): whether an OpenPeppol specification defines the business card format and this endpoint, or whether the implementation is the only reference.
|
| Customization ID | The part of a document type identifier that names the specific business rule set a document claims to conform to; the CLI uses it to pick the validation artefact. |
| ddd | The library that determines a document's syntax, Customization ID and derived VESID from its content, including unwrapping SBDH and XHE envelopes. (Verified in the ddd repository.) |
| Document type identifier | Identifies the kind of document a participant can receive, including its customization and version. In an SMP URL the form is {scheme}::{value}, percent-encoded. Two schemes are in use: busdox-docid-qns and peppol-doctype-wildcard. > TODO(verify): which scheme is currently mandated for new registrations, from Peppol Policy for use of Identifiers 4.4.0
|
| Main ID | The 6-digit core of both the Seat ID and the SPID, assigned by OpenPeppol, range 000001–999999 with leading zeroes. It must identify a Service Provider, a Peppol Authority or OpenPeppol, is unique across all Service Providers, and must never be reused for a different entity. This — not the Seat ID — is the stable identifier to key anything off. |
| Migration key | The out-of-band secret that controls moving a participant from one SMP to another: the old SMP calls PrepareToMigrate() with it, the new SMP calls Migrate() with the same key. Rules: 8–24 characters, at least two each of lowercase, uppercase, digits and specials, no whitespace. |
| MLS — Message Level Status | A status reported back about a received message, distinct from the transport-level AS4 receipt. The expansion is confirmed from peppol-commons' peppol-mls module (PeppolMLSBuilder, EPeppolMLSResponseCode), which is UBL-based and Schematron-validated. Supersedes the older Message Level Response (MLR), which is end of life and out of scope here. > TODO(verify): the MLS specification name and version.
|
| NAPTR | The DNS record type that maps a name to a service and a URI rather than to an address. Peppol uses the U-NAPTR profile of it (below); a query may return several NAPTR records, of which only the Meta:SMP one locates the SMP. |
| OCSP / CRL | The two mechanisms for checking whether a certificate has been revoked — an online status query and a published revocation list respectively. |
| Participant identifier | Identifies a sender or receiver, as an issuing scheme plus a value within it. Each participant is registered with exactly one SMP. In an SMP URL the form is {meta scheme}::{scheme}:{value}, e.g. iso6523-actorid-upis::0010:5798000000001. The authoritative rules are in Peppol Policy for use of Identifiers 4.4.0, to which both the SML and SMP specs defer. |
| Peppol Directory | The central, searchable index of participants and their published business cards. |
| Peppol Use Case ID | The optional middle part of a SPID, constraining a Service Provider to a specific process context — the spec's own example is distinguishing the capability to receive Reporting MLS messages from regular business-document MLS. 3–12 characters of A-Z a-z 0-9 _. The eDEC-maintained list is bundled as a Peppol code list and exposed as EPredefinedSPISUseCaseIdentifier, listable like any other kind. Note SPIS 1.0.0's example Rprtng_MLS is illustrative syntax, not a registered value. |
| phive | The open source validation engine that executes validation artefacts; the engine behind Phorm. |
| Phorm | A standalone, API-only document validation service built on the phive validation engine and the phive-rules rule sets; peppol-cli sends documents to a configured instance. (Verified against the phorm README.) |
| PKI — Public Key Infrastructure | Here: the Peppol certificate hierarchy, the CAs that issue AP and SMP certificates, and the trust chains used to verify them. |
| Process identifier | Identifies the business process in which a document type is exchanged; in the SMP data model each process carries the list of endpoints that support it. > TODO(verify): canonical form and current scheme identifier, from Peppol Policy for use of Identifiers 4.4.0
|
| SBDH — Standard Business Document Header | The envelope wrapped around a business document, carrying sender, receiver, document type, process, COUNTRY_C1 and the MLS routing scopes. A UN/CEFACT standard — confirmed by the schema namespace http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader in ph-sbdh — profiled for Peppol by the Peppol Business Message Envelope 2.0 specification, per the PeppolSBDHData documentation. Peppol expects HeaderVersion 1.0 (CPeppolSBDH.HEADER_VERSION). See SBDH. > TODO(verify): the version number of the UN/CEFACT SBDH standard itself — the bundled schema carries none
|
| Seat ID | The current identifier of a Peppol Service Provider, carried in the Subject CN of its AP and SMP X.509 certificates. Per SPIS 1.0.0: P (for Peppol) + the 2-letter abbreviation of the Peppol Authority the SP has its agreement with + the 6-digit unique number with leading zeroes, e.g. POP000270 (OpenPeppol). It is not a country code. It is also not stable: if the SP moves to another Peppol Authority the Seat ID changes — POP000270 would become PBE000270 under the Belgian PA — while the 6-digit part stays the same. |
| Service group | The SMP resource at /{participantId}, returning a <ServiceGroup> that holds the participant identifier plus references to each of its ServiceMetadata resources. One of exactly two resources the SMP REST interface defines. |
| Service metadata | The SMP resource at /{participantId}/services/{docTypeId}, returning a <SignedServiceMetadata> — the service description for one participant and document type (processes, endpoints, transport profiles, certificates, validity window) wrapped with the SMP's XML signature. It may instead return a Redirect to another SMP. |
| ServiceMetadataPublisherID | The unique identifier of an SMP in the SML, assigned out of band. Every SML management call is scoped to it, and it is therefore configuration rather than something a tool can discover. |
| SignedServiceMetadata | The signed wrapper around ServiceMetadata. The signature is an enveloped XML signature using inclusive c14n, rsa-sha256 and a sha256 digest, carrying the signer's certificate in KeyInfo/X509Data/X509Certificate. |
| SML — Service Metadata Locator | The service that provides controlled access to creating and updating DNS entries, so that a participant's SMP can be found by a DNS lookup. Per SML 1.3.0 it exposes three interfaces: a DNS-based discovery mechanism for senders, and two authenticated SOAP management interfaces for SMPs. Deliberately DNS-based so discovery has no single central point of failure. |
| SMP — Service Metadata Publisher | A service that publishes, per participant, which document types and processes that participant can receive, and at which endpoint. |
| SMP redirect | The mechanism letting one participant use different SMPs for different document types: a ServiceMetadata resource returns a Redirect to another SMP instead of the metadata. Only one degree of redirect is allowed, and the client should check that the destination SMP's signing certificate matches the identifier the redirecting SMP published for it. |
| SPID — Service Provider ID | The identifier defined by SPIS 1.0.0: a mandatory 6-digit Main ID, an optional Peppol Use Case ID (- separated), and an optional Service Provider Suffix (. separated, only valid together with a Use Case ID). Canonical case-insensitive regex [0-9]{6}(-[0-9A-Z_]{3,12}(\.[0-9A-Z\-\._~]{3,24})?)?, maximum length 44. Examples: 000270, 000001-Rprtng_MLS, 000270-Rprtng_MLS.Japan.123. Handled by SPIDHelper in peppol-id. |
| SPIS | OpenPeppol Service Provider Identification Scheme — participant identifier scheme with ICD 0242, active since code list 9.3, used to identify service providers as participants. |
| Test / production network | Peppol runs a separate test and production environment, each with its own SML DNS zone, Directory and certificate hierarchy. Selected with --network. |
| TLS certificate vs Peppol certificate | Two unrelated certificates on the same endpoint. The TLS certificate secures the transport and is a normal public WebPKI certificate from a third-party CA — OpenPeppol does not issue it, and the Peppol Policy for Transport Security 1.1.0 requires it to chain to a root in the Mozilla NSS list, forbids self-signed, and requires an SSL Labs grade of at least A. The Peppol certificate is the AP or SMP certificate from the Peppol PKI, used at application level, and carries the Seat ID in its Subject CN. Confusing the two is a common source of "but the certificate is valid" arguments. |
| Transport profile | The @transportProfile attribute on an SMP endpoint, identifying the transport protocol and profile so a sender knows how to deliver. SMP 1.4.0 gives peppol-transport-as4-v2_0 as the example value, consistent with code list v9.7 where AS4 profile 2.0 is the only active transport profile and START, AS2 1.0/2.0 and AS4 1.0 are all removed. |
| TSR / EUSR | Transaction Statistics Report and End User Statistics Report — periodic statistics a service provider submits about its own traffic. Out of scope; see ADR-002. > TODO(verify): exact names and current versions
|
| U-NAPTR | The NAPTR profile that resolves a name directly to a URI, defined in RFC 4848 ("Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)"). SML 1.3.0 requires the service name Meta:SMP, and requires the resolved URI to use https with no userinfo, query or fragment. The service field is case-insensitive per RFC 4848. |
U-NAPTR service name Meta:SMP |
The only NAPTR service name that may be used to locate an SMP. Other names may appear in the same DNS response for unrelated purposes. |
| VESID / DVR Coordinate | The identifier of a validation artefact set, written groupId:artifactId:version[:classifier], where the version may be a pseudo-version such as latest or latest-active. Originally "Validation Executor Set ID", renamed to DVR Coordinate. (Verified in ph-diver.) |
peppol-cli — licensed under the Apache License, Version 2.0.
Not an official OpenPeppol tool. This is an independent open source project and is neither endorsed by nor affiliated with OpenPeppol AISBL. "Peppol" is a trademark of OpenPeppol AISBL.
Status: planning
Overview
Design
Decisions
Reference