Services
eDelivery SMP - 1.10
Status | eDelivery Specification |
Publication date |
|
Obsoletes | |
Obsoleted by | - |
1. Description
The eDelivery SMP (Service Metadata Publisher) profile provides a set of implementation guidelines for the OASIS SMP specification [SMP-v1.0]. It is designed to be used in eDelivery with the Dynamic Sender Profile Enhancement in the eDelivery AS4 Profile [eDelivery AS4], 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. 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 final 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-v1.0] is 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:
[SMP-v1.0] The OASIS SMP 1.0 Specification
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].
3. Implementation guidelines
3.1. General Guidelines
Implementations MUST produce and consume SMP XML content conformant with the OASIS SMP XML schema.
Section 3.4 of [SMP] defines the ServiceGroup and SignedServiceMetadata resource retrieval methodes. An SMP client MAY use either the ServiceGroup or SignedServiceMetadata resources (defined in section 3.4) to retrieve SMP service metadata. An SMP server MUST support both resource retrieval methods.
3.2. Use with eDelivery AS4
The eDelivery AS4 Profile 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 use to select data from the SMP SignedServiceMetadata XML:
| AS4 Processing Mode Parameter | Corresponding Structure in SMP 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) | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ ParticipantIdentifier | 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) | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ ParticipantIdentifier/ @scheme | |
| SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ Processlist/ Process/ ServiceEndpointList/ Endpoint [@transportProfile='bdxr-transport-ebms3-as4-v1p0'] | The SMP MAY contain bindings to other messaging protocol profiles than eDelivery AS4. To select only the eDelivery AS4 binding, searches are restricted to Endpoints using the specified bdxr-transport-ebms3-as4-v1p0 attribute value. | |
| PMode[].BusinessInfo.Service | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/Processlist/ Process/ ProcessIdentifier | |
| PMode[].BusinessInfo.Service @type | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/Processlist/ Process/ ProcessIdentifier/ @scheme | |
| PMode[].BusinessInfo.Action | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ DocumentIdentifier | If on DocumentIdentifier a scheme 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 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: SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ Processlist/ Process/ ServiceEndpointList/ 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 information (CN field) in the Certificate. (In point-to-point exchanges, the Receiver Party Identifier is known and matches the SMP ParticipantIdentifier. 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 a 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 | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ Processlist/ Process/ ServiceEndpointList/ Endpoint/ EndpointURI | |
| PMode[]. Security. X509. Encryption. Certificate | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ Processlist/ Process/ ServiceEndpointList/ Endpoint/ Certificate | OASIS SMP [SMP-v1.0] supports configuring exactly one certificate. While the specification defines it as the "signing certificate", it is also used for encryption. The KeyUsage of the certificate MUST therefore allow use as an encryption certificate (keyEncipherment). |
| PMode[][s]. Security. X509. Signature. Certificate | SignedServiceMetadata/ ServiceMetadata/ ServiceInformation/ Processlist/ Process/ ServiceEndpointList/ Endpoint/ Certificate | OASIS SMP [SMP-v1.0] only supports one certificate to be specified. It is defined as the "signing certificate", and therefore can be used by the Receiving MSH, with eDelivery AS4, to sign any synchronous receipts or errors. The KeyUsage of the certificate MUST allow use as a signing certificate (digitalSignature). |
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 [PARTYIDTYPE] 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 scheme attribute MUST NOT be present. The following XML fragment shows an occurrence of the ParticipantIdentifier element using an ebCore Party Identifier.
<ParticipantIdentifier>urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:4035811991021</ParticipantIdentifier>
Since there is no {identifier scheme} separate from this participant identifier, the corresponding URI path fragments in the SMP REST binding (see section 3.4.1 of [SMP-v1.0]) MUST include neither an {identifier scheme} nor the :: separator. For this situation, the two columns in the table in Figure 2, section 3.4.1, MUST be replaced with the following:
| Resource | URI |
|---|---|
| ServiceGroup | /{id} |
| SignedServiceMetadata | /{id}/services/ {docType} |
For discussion, also see https://issues.oasis-open.org/browse/BDXR-21. Example URIs for ebCore Party Identifiers are included in section 3.4.
3.4. Use with eDelivery BDXL
The OASIS SMP Specification specifies a REST interface to retrieve SMP content. The second column of the table in section 3.4.1 of [SMP-v1.0] defines URL path templates to request ServiceGroup and SignedServiceMetadata 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 SignedServiceMetadata 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].
https://www.anotherexample.com/smp/prod/urn%3Aoasis%3Anames%3Atc%3Aebcore%3Apartyid-type%3Aiso6523%3A0088%3A4035811991021 https://www.anotherexample.com/smp/prod/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.0a
4. Conformance
An implementation conforms to this version of the eDelivery SMP Profile if it:
- Is a conformant OASIS SMP 1.0 implementation, where conformance is defined in section 4 of [SMP-v1.0], as clarified in section 3.4 of this specification.
- Conforms to all normative statements in section 3 of this specification.
5. 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-v1.0] is Copyright © OASIS Open 2017. All Rights Reserved.
The SMP technical specification [SMP-v1.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. E-CODEX can be contacted as follows:
Ministry of Justice NRW, Martin-Luther-Platz 40 - 40212 Düsseldorf (GERMANY).
All other content 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 in the context of the CEF Programme. Information on governance and procedures for eDelivery is available from Governance and Procedures.
6. 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/
[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/
[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. D5.11 Concept of Implementation v2
[eDelivery AS4] eDelivery AS4 Profile Specification. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+AS4
[eDelivery BDXL]. eDelivery BDXL Profile Specification. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+BDXL
[eDelivery EBCOREP] Delivery ebCore Party Id Type Profile Specification. https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+ebCore+Party+Id
[PARTYIDTYPE] OASIS ebCore Party ID Type Technical Specification. September 2010. http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.pdf
[PEPPOL-SMP] PEPPOL SMP Specification
[RFC2119] A. Ramos. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119. January 1998. http://www.ietf.org/rfc/rfc2119.txt
[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/.
7. 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.
8. History
Ver. | Date | Changes made | Modified By |
|---|---|---|---|
| 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, |
| 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 |
Details about previous versions of the specifications can be consulted on the e-SENS website.