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] 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. Senderrequests 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 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.
Implementation guidelines
Anchor
ImplGuidelines
ImplGuidelines
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.
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 from query parameters set by the Access Point used 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.
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.
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.
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:
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, 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.
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 algorithmhttp://www.w3.org/2001/04/xmldsig-more#rsa-sha256.
For use in combination with the Split-Join optional profile enhancement, the values dxr-transport-ebms3-as4-split-join-v2p0-curve25519and bdxr-transport-ebms3-as4-split-join-v2p0-ecdsa are used instead of dxr-transport-ebms3-as4-v2p0-curve25519and bdxr-transport-ebms3-as4-v2p0-ecdsa
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.
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.
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.
When used in combination with eDelivery AS4 2.0, its value MUST be set to http://www.w3.org/2002/03/xkms#Exchange. This identifier identifies key exchange key usage.
When used with eDelivery AS4 versions prior to eDelivery AS4 2.0, its value MUST be set to http://www.w3.org/2002/03/xkms#Encryption. This identifier identifies encryption key usage.
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 Identifiers
When using SMP in conjunction with the OASIS ebCore Party Id Type specification [PARTYIDTYPEEBCOREP] as profiled in [eDelivery-EBCOREP], and using the ebCore party identifier syntax described in section 2.7 of the OASIS ebCore Party Id Type specification, 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.
Since there is no {identifier scheme} separate from this participant identifier, the corresponding URI path fragments in the SMP REST binding (see section 5 of [SMP-v2.0]) MUST include neither an {identifier scheme} nor the :: separator.
SMP documents MAY also use the option of using 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:
To retrieve SMP XML documents using this syntax, a semantically equivalent ebCore Party Identifier MUST be formed, by concatenating the value of the scheme attribute, the ":" separator and the content of the element, and the resulting value MUST be used as identifier in SMP REST URIs.
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], 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 prefix is assumed to have been obtained using a BDXL query as described in [eDelivery-BDXL].
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.
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.
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 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.
[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
[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/
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.11
Updated on 4.03.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.
Details about previous versions of the specifications can be consulted on the e-SENS website.