eDelivery Services
eDelivery SMP - 2.0 (2024 PR draft)
Status | eDelivery Community Draft |
Publication date |
|
Obsoletes | |
Obsoleted by | - |
1. Description
The 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].
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 of Party.)
- The Sender uses this URL in a HTTP GET operation to obtain the metadata relating to that recipient's capabilities
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].
2. Base Specification
This 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.
3. Implementation guidelines
3.1. General Guidelines
Implementations 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..n. When one document/service is used in many processes but is received through the same Endpoint, absence of any Process elements MUST be interpreted as "all processes", with the associated Endpoint as a default.
3.2. Use with eDelivery AS4
The 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/ Process/ ID |
|
PMode[].BusinessInfo.Service @type | ServiceMetadata/ ProcessMetadata/ Process/ ID/ @schemeID | |
PMode[].BusinessInfo.Action |
ServiceMetadata/ ID |
If on ID a 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:
|
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 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 use with eDelivery AS4 versions prior to eDelivery AS4 2.0, the bdxr-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-curve25519 and bdxr-transport-ebms3-as4-split-join-v2p0-ecdsa are used instead of bdxr-transport-ebms3-as4-v2p0-curve25519 and 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.
3.3. Use with eDelivery ebCore Party Identifiers
When using SMP in conjunction with the OASIS ebCore Party Id Type specification [EBCOREP] as profiled in [eDelivery-EBCOREP], SMP documents SHOULD 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:
<ParticipantID schemeID="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088">4035811991021</ParticipantID>
To retrieve SMP XML documents using this notation and the REST inter, 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 for eDelivery ebCore Party Identifiers.
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:
<ParticipantID>urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:4035811991021</ParticipantID>
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.
3.4. Use with eDelivery BDXL
The 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].
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 "Meta:SMP2", 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 no such "Meta:SMP2" record is returned, but a record is returned for the key with the service set to the value "Meta:SMP". 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.
4. Compatibility
As 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.
5. Conformance
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.
6. Ownership
OpenPeppol 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.
7. 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] eDelivery ebCore Party Id Type Profile Specification. 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, 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, 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/
8. Contributors
The eDelivery team is in charge of the maintaining the current version of the specification.
Details about contributors of previous versions of this specification can be consulted on the e-SENS website.
9. History
Ver. |
Date |
Changes made |
Modified By |
---|---|---|---|
2.0 (2024 PR draft) |
|
Changes:
|
Pim van der Eijk |
2.0 (2023 PR draft) |
|
Major update:
|
Pim van der Eijk |
1.11 |
|
Updated on 4.03.2019
|
|
1.10 |
|
General:
New Conformance section. Updates to match the updated eDelivery AS4 - 1.13.
Updates after CEF team meeting 21.11.2017
Updated after CEF team meeting 15.12.2017
Updated after CEF team meeting 25.12.2017
Updated on 7.5.2018
Updated on 30.5.2018
|
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:
|
Gianmarco Piva, |
Details about previous versions of the specifications can be consulted on the e-SENS website.