DescriptionThe eDelivery SMP (Service Metadata Publisher) profile provides a set of implementation guidelines for the OASIS SMP version 2.0 specification [SMP-v2.0]. It is designed to be used in eDelivery with the Dynamic Sender Profile Enhancement in the eDelivery AS4 Profile version 2.0 [eDelivery-AS4-v2.0], the eDelivery BDXL profile [eDelivery-BDXL-v2.0] and the eDelivery ebCore Party Id profile [eDelivery-EBCOREP-v2]. The SMP specification defines an XML-based service metadata data model and a REST binding to retrieve service metadata: - The Service Metadata Publisher hosts service metadata for each party at a predefined URL. (Note that SMP uses the term Participant as a synonym ofParty.)
- The Sender uses this URL in a HTTP GET operation to obtain the metadata relating to that recipient's capabilities
 Image Added Image Removed
Figure 1. Sender requests Service Metadata to configure Message Exchange
A party can retrieve data to dynamically configure its systems for message exchange with its counterparties using eDelivery. The Service Metadata Publisher can store service metadata representing receiving capabilities of parties. SMP service metadata is a combination of information on: - the recipient (its identifier, supported business documents and processes in which it accepts those documents)
- the Access Point (metadata which includes technical configuration information on the receiving endpoint, such as the transport protocol and its address) used by the end entity recipient.
Every community participant is registered in one and only one SMP registry. The OASIS SMP specification [SMP-v2.0] is independent from, but designed to be used in conjunction with the OASIS BDX Location specification [BDX-Location-v1.0]. Base SpecificationThis specification is based on the following OASIS specification: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] ([RFC2119] and [RFC8174]) when, and only when, they appear in all capitals, as shown here. Implementation guidelines| Anchor |
|---|
| ImplGuidelines |
|---|
| ImplGuidelines |
|---|
|
General GuidelinesImplementations MUST produce and consume SMP XML content conformant with the OASIS SMP 2.0 XML schema. Section 5.4 of [SMP-v2.0] defines the ServiceGroup and ServiceMetadata resource retrieval methods. An SMP client MAY use either the ServiceGroup or ServiceMetadata resources to retrieve SMP service metadata. An eDelivery SMP server MUST support both resource retrieval methods. In [SMP-v2.0], the cardinality of the Process element in ProcessMetadata instance is 0..1. The semantics of collection is not defined and therefore should be defined in a usage profile, such as the eDelivery one. When one document/service is used in many processes but is n. When one document/service is used in many processes but is received through the same Endpoint, absence of any Process elements elements in a ProcessMetadata MUST be interpreted as "all processes for which no other specific ProcessMetadata is defined", with the associated Endpoint as a default. There MUST be at most one ProcessMetadata element with an empty list of processes. Use with eDelivery AS4The eDelivery AS4 2.0 profile [eDelivery-AS4-v2.0] consists of a Common Profile and a set of Profile Enhancements. One of these enhancements is the Dynamic Sender Profile Enhancement, which specifies how an AS4 MSH can be used to send user messages to Receiver parties that have not been pre-configured. This enhancement assumes a discovery infrastructure that can be queried using a number of input parameters, obtained as metadata in message submission and/or from a configured P-Mode template, to obtain additional Receiver-specific P-Mode parameters. This eDelivery SMP profile can be used as part of such a dynamic discovery infrastructure. Another Profile Enhancement is the Four Corner Topology Enhancement. This eDelivery SMP profile can be used in conjunction with both point-to-point messaging (involving a Sender and Receiver) and the Four Corner Topology Enhancement (involving an Original Sender, a Sender, a Receiver and a Final Recipient). The following table summarizes the mapping of the AS4 parameters required to select data from the SMP ServiceMetadata XML: | AS4 Processing Mode Parameter | Corresponding Structure in SMP 2.0 XML | Note |
|---|
In four corner exchanges: PMode[].BusinessInfo.Properties[finalRecipient] (N.B. the PMode only specifies the use of the attribute, not its value.) In point-to-point exchanges: PMode.Responder.Party (For One Way exchanges and for the first leg of a Two Way Exchange) PMode.Initiator.Party (For the second leg of a Two Way Exchange) | ServiceMetadata/ ParticipantID | To indicate use of the Four Corner Topology Enhancement, the AS4 P-Mode MUST mandate the use of the finalRecipient message property. The actual value for the parameter is not specified in the P-Mode, it is supplied dynamically to the MSH by the Producer in the Submit operation. In point-to-point exchanges, the dynamically supplied party identifier is the AS4 MSH Receiver identifier.
| In four corner exchanges: PMode[].BusinessInfo.Properties[finalRecipient] @type In point-to-point exchanges: PMode.Responder.Party @type (For One Way exchanges and for the first leg of a Two Way Exchange) PMode.Initiator.Party @type (For the second leg of a Two Way Exchange) | ServiceMetadata/ ParticipantID/ @schemeID |
| | PMode[].BusinessInfo.Service | ServiceMetadata/ ProcessMetadata/ EndpointProcess/ TransportProfileIDID |
| | PMode[].BusinessInfo.Service @type | ServiceMetadata/ ProcessMetadata/ Process/ ID/ @schemeID |
| | PMode[].BusinessInfo.Action | ServiceMetadata/ ID | If on IDa schemeID attribute is present with value bdx-docid-qns, the value of PMode[].BusinessInfo.Action is created by prefixing the string bdx-docid-qns:: to the value of the DocumentIdentifier element. |
| ServiceMetadata/ ProcessMetadata/ Endpoint/ TransportProfileID | The SMP MAY contain bindings to multiple messaging protocol profiles: To select only the eDelivery AS4 1.* binding, searches are restricted to Endpoints using the specified bdxr-transport-ebms3-as4-v1p0 element value.The SMP MAY contain bindings to multiple messaging protocol profiles: | - To select only the eDelivery AS4
| 2 | 0 binding with the use of algorithms based on Curve25519 for signing (Ed25519) and encryption (X25519)- * binding, searches are restricted to Endpoints using the specified bdxr-transport-ebms3-as4-
| v2p0-curve25519 element - v1p0 element value.
- To select only the eDelivery AS4 2.0 binding with the use of algorithms based on Curve25519 for signing (Ed25519) and encryption (X25519), searches are restricted to Endpoints using the specified bdxr-transport-ebms3-as4-v2p0-curve25519 element value.
- To select only the eDelivery AS4 2.0 binding with the use of ECDSA as defined in section 4.8, searches are restricted to Endpoints using the specified bdxr-transport-ebms3-as4-v2p0-ecdsa element value.
| PMode[].BusinessInfo.Service | ServiceMetadata/ ProcessMetadata/ Process/ ID | PMode[].BusinessInfo.Service @type | ServiceMetadata/ ProcessMetadata/ Process/ ID/ @schemeID | PMode[].BusinessInfo.Action | ServiceMetadata/ ID | If on IDa schemeID attribute is present with value bdx-docid-qns, the value of PMode[].BusinessInfo.Action is created by prefixing the string bdx-docid-qns:: to the value of the DocumentIdentifier element.
From a matching structure in the response SMP XML document, the following AS4 P-Mode parameters can be obtained for use by the Sending AS4 MSH: From a matching structure in the response SMP XML document, the following AS4 P-Mode parameters can be obtained for use by the Sending AS4 MSH: | AS4 Processing Mode Parameter | Corresponding Structure in SMP 2.0 XML | Notes |
|---|
In four corner exchanges only: PMode.Responder.Party (For One Way exchange and for the first leg of a Two Way Exchange) PMode.Initiator.Party (For the second leg of a Two Way Exchange)
| In four corner exchanges only: ServiceMetadata/ ProcessMetadata/ Endpoint/ Certificate | In four corner exchanges, the Party Identifier of the C3 corner has to be | | AS4 Processing Mode Parameter | Corresponding Structure in SMP 2.0 XML | Notes |
|---|
In four corner exchanges only: PMode.Responder.Party (For One Way exchange and for the first leg of a Two Way Exchange) PMode.Initiator.Party (For the second leg of a Two Way Exchange) In four corner exchanges only: ServiceMetadata/ ProcessMetadata/ Endpoint/ Certificate | In four corner exchanges, the Party Identifier of the C3 corner has to be determined, as the C2 Access Point only has been provided with information on the final recipient party C4. The value of the SMP XML structure is a Base64 encoded Access Point Certificate. The Party Identifier is to be obtained from subject fields in the Certificate. In case different certificates with different type codes have different subject field values, the value used in the signing certificate shall be used. (In point-to-point exchanges, the Receiver Party Identifier is known and matches the SMP ParticipantID. It is provided by the Producer in submission). | In four corner exchanges only: Fixed URI value for: PMode.Responder.Party @type (For One Way exchange and for the first leg of a Two Way Exchange) PMode.Initiator.Party @type (For the second leg of a Two Way Exchange) |
| An X.509 certificate does not provide a separate Party identifier type attribute. As in AS4 the type attribute is required if the identifier is not an URI (see section 5.2.2.4 of [EBMS3]), a fixed valued type attribute MUST be added in AS4. Unless otherwise specified for specific domain profiles, the urn:oasis:names:tc:ebcore:partyid-type:unregistered value SHOULD be used. | | PMode[].Protocol.Address | ServiceMetadata/ ProcessMetadata/ Endpoint/ AddressURI | The HTTPS URL of the recipient's AS4 Access Point. | PMode[]. Security. X509. Signature. Algorithm PMode[s]. Security. X509. Signature. Algorithm | ServiceMetadata/ ProcessMetadata/ Endpoint/ TransportProfileID | The signature algorithm is set depending on the value of the transport profile identifier: - For bdxr-transport-ebms3-as4-v2p0-curve25519: the signature algorithm is http://www.w3.org/2021/04/xmldsig-more#eddsa-ed25519.
- For bdxr-transport-ebms3-as4-v2p0-ecdsa: the signature algorithm is http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256.
For use with eDelivery AS4 versions prior to eDelivery AS4 2.0, thebdxr-transport-ebms3-as4-v1p0 transport identifier specifies the use of the signature algorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256. For use in combination with the Split-Join optional profile enhancement, the values bdxr-transport-ebms3-as4-split-join-v2p0-curve25519and bdxr-transport-ebms3-as4-split-join-v2p0-ecdsa are used instead of bdxr-transport-ebms3-as4-v2p0-curve25519and bdxr-transport-ebms3-as4-v2p0-ecdsa. | | PMode[][s]. Security. X509. Signature. Certificate | ServiceMetadata/ ProcessMetadata/ Endpoint/ Certificate | The element MUST contain the certificate used by the receiver to sign AS4 receipts or errors. The KeyUsage of the certificate MUST allow use for signing. When used in combination with the eDelivery 2.0 Common Profile, its value MUST be set to a certificate that contains a public key of the recipient. The public key MUST be of a type consistent with the signature algorithm. |
| ServiceMetadata/ ProcessMetadata/ Endpoint/ Certificate/ TypeCode | This element is REQUIRED. When used in combination with the eDelivery AS4 2.0, its value MUST be set to http://www.w3.org/2002/03/xkms#Signature. This identifier (reused from XKMS 2.0) identifies signature key usage. | | PMode[]. Security. X509. Encryption. Certificate | ServiceMetadata/ ProcessMetadata/ Endpoint/ Certificate | The element must contain a certificate used to provide AS4 message confidentiality. The KeyUsage of the certificate MUST allow use for key agreement. The certificate MUST contains a static public key of the recipient. The public key MUST be of a type consistent with the key agreement algorithm and curve names. |
| ServiceMetadata/ ProcessMetadata/ Endpoint/ Certificate/ TypeCode | This element is REQUIRED. The URI identifiers for key usage are defined in XKMS 2.0. |
Note that the SMP data model does not contain counterparts to the ebMS3 PMode.Initiator.Role and PMode.Responder.Role elements. Any profiling of these parameters is out of scope for this document. Use with eDelivery ebCore Party IdentifiersWhen using SMP in conjunction with the OASIS ebCore Party Id Type specification [EBCOREP] as profiled in [eDelivery-EBCOREP-v2], SMP documents SHOULD MUST use a separate ebCore Party Identifier type as the value of the schemeID attribute of the ParticipantID element. An example of this notation is the following: | Code Block |
|---|
| language | xml |
|---|
| title | Participant Identifier |
|---|
| <ParticipantID schemeID="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088">4035811991021</ParticipantID>
|
To retrieve SMP XML documents using this notation and the SMP 2.0 REST interinterface, an eDelivery SMP 2.0 server MUST support queries that use either of the following notations: - A semantically equivalent ebCore Party Identifier is formed by concatenating the value of the schemeID attribute, the ":" separator and the content of the element .
- A concatenated notation is formed using the '::' separator a specified section 5.4 of [SMP-v2.0].
An eDelivery SMP 2.0 client may use any of the two notations. In case the ebCore party identifier syntax described in section 2.7 of [EBCOREP] is used, the party identifier type and the identifier value MUST be separated using a single ":" colon character. The optional schemeID attribute MUST NOT be present. The following XML fragment shows an occurrence of the ParticipantID element using an ebCore Party Identifier: | Code Block |
|---|
| language | xml |
|---|
| title | Participant Identifier |
|---|
| <ParticipantID>urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:4035811991021</ParticipantID>
|
- as defined in section 2.7 of [EBCOREP].
- A concatenated notation formed using the '::' separator as specified in section 5.4 of [SMP-v2.0].
When using the REST interface of SMP 2.0, an eDelivery SMP 2.0 client may use any of the two notations for eDelivery ebCore Party Identifiers.Since there is no {identifier scheme} separate from this participant identifier, the corresponding URI path fragments in the SMP REST binding MUST include neither an {identifier scheme} nor the :: separator. Use with eDelivery BDXLThe OASIS SMP Specification specifies a REST interface to retrieve SMP content. The table in section 5.4 of [SMP-v2.0] defines URL path templates to request ServiceGroup and ServiceMetadata resources using HTTP GET requests. When using this specification in conjunction with the eDelivery BDXL profile [eDelivery-BDXL-v2.0], the requesting SMP client MUST append the URI path values defined in the SMP Specification to the URI retrieved from the BDX Location U-NAPTR record. The following non-normative example shows two URLs, the first of which requests the ServiceGroup of a party with ebCore Party Identifier urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:4035811991021 and the second of which requests the ServiceMetadata for the UBL 2.0 Invoice for that same party. The https://www.anotherexample.com/smp/prod prefix is assumed to have been obtained using a BDXL query as described in [eDelivery-BDXL-v2.0].
| Code Block |
|---|
| language | bash |
|---|
| title | Sample URIs |
|---|
| https://www.anotherexample.com/smp/prod/bdxr-smp-2/urn%3Aoasis%3Anames%3Atc%3Aebcore%3Apartyid-type%3Aiso6523%3A0088%3A4035811991021
https://www.anotherexample.com/smp/prod/bdxr-smp-2/urn%3Aoasis%3Anames%3Atc%3Aebcore%3Apartyid-type%3Aiso6523%3A0088%3A4035811991021/services/bdx-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3AInvoice-2%3A%3AInvoice%23%23UBL-2.0
|
To retrieve BDXL records for this version of eDelivery SMP, which is based on OASIS SMP 2.0, a client, for a given search key: - MUST use the record with the service set to "metaMeta:smp2SMP2", if such a record exists and is returned for the key.
- MAY attempt to use the SMP 2.0 REST interface on the retrieved metadata service URL, If if no such such "metaMeta:smp2SMP2" record is returned, but a record is returned for the key with the service set to the value "metaMeta:smpSMP". This behavior would benefit a community in transition from prior use of OASIS SMP 1.0 to use of OASIS SMP 2.0, where the community for operational or other reasons prefers to not (yet) create separate records for SMP 1.0 and SMP 2.0.
CompatibilityAs this version of eDelivery SMP is based on OASIS SMP version 2.0 [SMP-v2.0], it is not compatible with the version 1.0 of SMP [SMP-v1.0]. An implementation MAY also support, using different endpoints, different versions of eDelivery SMP and/or other metadata protocols. An implementation conforms to this version of the eDelivery SMP Profile if it: - Is a conformant OASIS SMP 2.0 implementation, where conformance is defined in section 6 of [SMP-v2.0], as clarified in section 3.4 of this specification.
- Conforms to all normative statements in section 3 of this specification.
OwnershipOpenPeppol uses an earlier version of SMP [PEPPOL-SMP] for resolving which PEPPOL BIS/CEN BII profiles to use. The SMP is also being used for Change- and Release management of communication protocols. The PEPPOL version of SMP [PEPPOL-SMP] was generalized and standardized by OASIS [SMP-v1.0]. The SMP technical specification [SMP-v2.0] is Copyright © OASIS Open 2017. All Rights Reserved. The SMP technical specification [SMP-v2.0] is created by by the OASIS BDXR Technical Committee which operates under the Non-Assertion Mode of the OASIS IPR Policy. OASIS is not aware of any statements or declarations regarding IPR related to the work of this technical committee. Part of this specification is an evolution of work done in the EU e-CODEX project [ECODEXD5.11], which specifies the use of ebMS3/AS4 with the BDX Metadata Service Location and SMP specifications for dynamic discovery. The initial version of this specification was created in the former EU e-SENS project. The e-SENS project completed in March 2017. The EU e-SENS project formally transferred ownership of its specifications to the European Commission, which accepted it for further maintenance initially in the context of the CEF Programme and then of the Digital Europe Programme. Information on governance and procedures for eDelivery is available from Governance and Procedures. References[AS4] AS4 Profile of ebMS 3.0 Version 1.0. OASIS Standard, 23 January 2013. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/ [BCP14] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels and Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. https://www.rfc-editor.org/info/bcp14 [BDX-Location-v1.0] Business Document Metadata Service Location Version 1.0. OASIS Standard, 01 August 2017. http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/ [EBCOREP] D. Moberg and P. van der Eijk. OASIS ebCore Party Id Type Technical Specification Version 1.0. OASIS Committee Specification, 28 September 2010. http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/ [EBMS3] OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features. OASIS Standard. 1 October 2007. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ [ECODEXD5.11] e-CODEX D5.11: Concept of Implementation. [eDelivery-AS4-v2.0] eDelivery AS4 Profile Specification version 2. 0. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+AS4 [eDelivery-BDXL-v2.0] eDelivery BDXL Profile Specification version 2. 0. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+BDXL [eDelivery-EBCOREP-v2] eDelivery ebCore Party Id Type Profile Specification version 2. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+ebCore+Party+Id [PEPPOL-SMP] Peppol Transport Infrastructure Service Metadata Publishing (SMP). https://docs.peppol.eu/edelivery/ [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, January 1998. https://www.rfc-editor.org/rfc/rfc2119.html [RFC8174] B. Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. IETF RFC 8174, May 2017. https://www.rfc-editor.org/rfc/rfc8174.html [SMP-v1.0] Service Metadata Publishing (SMP) Version 1.0. OASIS Standard, 01 August 2017. http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/ [SMP-v2.0] Service Metadata Publishing (SMP) Version 2.0. OASIS Standard, 14 February 2021. https://docs.oasis-open.org/bdxr/bdx-smp/v2.0/ [XKMS-v2.0] XML Key Management Specification (XKMS 2.0) Version 2.0. W3C Recommendation 28 June 2005. https://www.w3.org/TR/xkms2/ ContributorsThe eDelivery team is in charge of the maintaining the current version of the specification. Details about contributors of previous versions of this specification prior to version 1.9 can be consulted on the e-SENS website. HistoryVer. | Date | Changes made | Modified By |
|---|
| 2.0 (2024 PR draft) | | Changes: - Clarified the mapping table in section 3.2.
- Updated the section on eDelivery ebCore Party Identifiers to recommend mandate the use of the schemeID attribute of the ParticipantID element in SMP 2.0 documents.
- Editorial.
- Profile the use of the Process element in ProcessMetadata.
| Pim van der Eijk Bogdan Dumitriu Joze Rihtarsic | | 2.0 (2023 PR draft) | | Major update: - Switch to OASIS SMP vv2.0.20
- Support for eDelivery AS4 v2.0.
| Pim van der Eijk | | 1.11 | | 033.2019 - Added note that ebCore Party Identifier types may be used as value of the scheme attribute. For the REST interface, these are to be normalized to an ebCore Party Identifiers.
| Pim van der Eijk | | 1.10 | | General: - Version number set to 1.10.
- Terminology "gateway" → "Access Point".
- Renamed BDEN_SMP to PEPPOL-SMP
- Coverage extended to also include point-to-point exchanges. No longer hardwired to four-corner topology.
- Removed the PEPPOL SML legacy reference, as there is no user requirement to use OASIS SMP with PEPPOL SML.
New Conformance section. Updates to match the updated eDelivery AS4 - 1.13. - Removed content that is now covered by the Dynamic Receiver and Dynamic Sender Profile Enhancements in eDelivery AS4 - 1.13.
- Rather than just explaining which values must correlate between AS4 P-Mode data model and SMP, also explain explicity which information is obtained from SMP.
- Explain that the SMP certificate is used for both encryption and signing. SMP is only about receiving capabilities, but the signing use can be used to determine which certificate will be used to sign the synchronous AS4 receipts.
Updates after CEF team meeting 21.11.2017 - Minor editorial.
- Clarify that information required in the Submit operation has to be provided by the Producer.
- BDXL profile reference updated to 1.6.
Updated after CEF team meeting 15.12.2017 - Renamed to eDelivery SMP
- Added explanation of RFC2119 keywords.
- Added link to eDelivery governance.
- Updated ebCore Party Id section and coverage of participant identifiers without scheme attribute.
Updated after CEF team meeting 25.12.2017 - Changed status to eDelivery Community Draft
Updated on 7.5.2018 - Added specification for mapping of DocumentIdentifier/@scheme with busdox-docid-qns scheme.
Updated on 30.5.2018 - Status changed to eDelivery Specification
| Pim van der Eijk | | 1.9 | | Minor update as part of the migration of the specification to CEF Digital, not requiring external review. Layout adapted to CEF Digital Content copied from e-SENS architecture, with the following editorial changes and bibliographic updates: - Set the version number to 1.9
- Switched from e-SENS specification metadata to the CEF eDelivery specification metadata: Publication Date, Obsoletes, Obsoleted by
- Removed the Standardization and Sustainability Assessment section.
- Updated the Contributor section, historical contribution information is left to the last referenced e-SENS project version.
- Updated the Ownership section to include the handover of the ownership of content from the e-SENS project to CEF Digital.
- Started with a clean history table (the e-SENS history is still available in the 1.8 version).
- Updated the BDXL and SMP bibliographic references to reflect their current OASIS Standard status and to use their recommended citation formats.
- Updated the reference for e-CODEX to the public D5.11.
- Fixed broken link for PEPPOL SMP
- Changed some references to e-SENS ABBs to references to the PR- specifications that implement them.
- The content of the former "domain specific profiles" section is moved to other sections and the section is removed.
- Implementation Guidelines is now a single section without subsections.
- Renamed the section "Specifications" to "Base Specification".
| Gianmarco Piva, Pim van der Eijk |
Details about previous versions of the specifications can be consulted on the e-SENS website.
| 