EDelivery - Revision history

Mpttfp eduardo.moreno: updated wiki references

2023-03-15T09:05:37Z

updated wiki references

Mpttfp eduardo.moreno: added missing images in EDelivery section

2023-03-15T08:49:29Z

added missing images in EDelivery section

Show changes

Mpttfp eduardo.moreno: /* Values of the parameters for the SMP query process */

2023-03-10T12:15:44Z

Values of the parameters for the SMP query process

Mpttfp eduardo.moreno: /* SML query process in DE4A */

2023-03-10T12:04:01Z

SML query process in DE4A

Mpttfp eduardo.moreno: /* SML query process in DE4A */

2023-03-10T12:03:08Z

SML query process in DE4A

Mpttfp eduardo.moreno: /* SML query process in DE4A */

2023-03-10T12:02:29Z

SML query process in DE4A

Mpttfp eduardo.moreno: added information to EDelivery AS4

2023-03-10T09:30:45Z

added information to EDelivery AS4

Mpttfp eduardo.moreno: added references in EDelivery

2023-03-10T09:23:31Z

added references in EDelivery

Mpttfp eduardo.moreno: changed headings of Edelivery SMP

2023-03-10T09:16:52Z

changed headings of Edelivery SMP

Mpttfp eduardo.moreno: updated EDelivery SMP information

2023-03-10T09:15:21Z

updated EDelivery SMP information

@@ Line 38: / Line 38: @@
 The SML is operated centrally by the European Commission. Its service is gratefully offered free of charge to the DE4A project.
-The SML creates DNS records for each SMP itself (see [[EDelivery#SMP|SMP]]) and for each Participant (aka Service Group; see [[SMP]]) pointing to the owning SMP. These DNS NAPTR records need to be read by the sending party (the DE4A Connector), to determine the URL of the SMP that needs to be queried.
+The SML creates DNS records for each SMP itself (see [[EDelivery#Big Picture for SMP Registration|Big Picture for SMP Registration]]) and for each Participant (aka Service Group; see [[EDelivery#Big Picture for Participant Registration|Big Picture for Participant Registration]]) pointing to the owning SMP. These DNS NAPTR records need to be read by the sending party (the DE4A Connector), to determine the URL of the SMP that needs to be queried.
 The SML and the DNS are centralized third-party components for DE4A. For the SMPs to be able to communicate with the SML, a Client Certificate is needed (see [[Certificates]]), so only legitimate requestors can create DE4A participants in the SML.
@@ Line 45: / Line 45: @@
 DE4A only uses the production SML and the dedicated domain <code>de4a.edelivery.tech.ec.europa.eu.</code> for its purposes.
-The lookup process from the Connector solely requires the Participant Identifier (see [[EDelivery|Identification of components]]) of the receiver. Using a SHA-256 hash value of the Participant Identifier, a unique domain name is created, which will be looked up from the DNS using the “NAPTR” record query type. This NAPTR record then contains the base path of the SMP to be queried. The details of the SMP query are described in chapter 3.1.4.5.
+The lookup process from the Connector solely requires the Participant Identifier (see [[EDelivery#Identification of components|Identification of components]]) of the receiver. Using a SHA-256 hash value of the Participant Identifier, a unique domain name is created, which will be looked up from the DNS using the “NAPTR” record query type. This NAPTR record then contains the base path of the SMP to be queried. The details of the SMP query are described in chapter 3.1.4.5.
-The structure of the Participant IDs used in DE4A is described in chapter 3.1.3.2.
+The structure of the Participant IDs used in DE4A is described in [[EDelivery#Domains and types of Participant IDs used in DE4A|Domains and types of Participant IDs used in DE4A]].
 A real-life example for looking up the Participant Identifier <code>iso6523-actorid-upis::9915:de4atest</code> looks like this:
@@ Line 58: / Line 58: @@
 [[File:DNS_NAPTR_record_query_result.png|alt=]]
 *The relevant part of the response is <code>"!.*!<nowiki>https://de4a-smp.usp.gv.at</nowiki>!"</code> that contains the link to the SMP of this particular Participant Identifier that can be queried for the details, embedded into a regular expression as defied by the NAPTR record specification.
-*Using the extracted URL <code><nowiki>https://de4a-smp.usp.gv.at</nowiki></code> the regular SMP query process, as described in chapter 3.1.4.5, can be performed.
+*Using the extracted URL <code><nowiki>https://de4a-smp.usp.gv.at</nowiki></code> the regular SMP query process, as described in chapter [[EDelivery#SMP Query Process|SMP Query Process]], can be performed.
 As can be seen from this description, the SML system itself is not invoked in the lookup – only the DNS system is involved. Because the DNS system is inherently replicated, a fast and fail-safe operation is guaranteed.
@@ Line 136: / Line 136: @@
 All SMPs MUST provide the two REST APIs mandated by the specification, identified as <code>/{participantID}</code> and <code>/{participantID}/services/{docTypeID}</code>. The first API returns a list of all document types the participant is capable to receive (which may be an empty list) and the second API returns the details on the receiving “Endpoints” including the endpoint URL and the X.509 certificate of the receiver. Both APIs can only return XML content, and only the second API response is digitally signed with the SMP certificate of the SMP maintainer. Each of the response data structures contain an optional Extension element that could be used for additional content.
-Each SMP MUST have one Certificate from the SMP PKI configured (see [[Certificates]]), independent of the number of Participants it manages. This certificate is used as a client certificate for the communication with the SML (see [[SML/DNS]]), as a client certificate for the communication with the DE4A Directory and as an XML signing certificate for its REST responses.
+Each SMP MUST have one Certificate from the SMP PKI configured (see [[Certificates]]), independent of the number of Participants it manages. This certificate is used as a client certificate for the communication with the SML (see [[EDelivery#SML/DNS|SML/DNS]]), as a client certificate for the communication with the DE4A Directory and as an XML signing certificate for its REST responses.
 An SMP MUST be registered once in the SML before it can be used in the network.
@@ Line 214: / Line 214: @@
 === Values of the parameters for the SMP query process ===
-This section specifies the general values of the Participant ID, Document Type ID and Process ID parameters when querying the SMPs for the three main types of DE4A messages. Remember that, in DE4A, the Transport Protocol ID value is always the same (see [[EDelivery#SMP query process|SMP Query Process]]). The complete set of values for the following ''evidenceID'' and ''catalogueID'' variables are available at [https://github.com/de4a-eu/de4a-codelists/tree/main/code%20lists GitHub].
+This section specifies the general values of the Participant ID, Document Type ID and Process ID parameters when querying the SMPs for the three main types of DE4A messages. Remember that, in DE4A, the Transport Protocol ID value is always the same (see [[EDelivery#SMP Query Process|SMP Query Process]]). The complete set of values for the following ''evidenceID'' and ''catalogueID'' variables are available at [https://github.com/de4a-eu/de4a-codelists/tree/main/code%20lists GitHub].
 ==== Evidence Request ====
 When a Data Consumer wants to send an evidence request message based on the IM, USI or LU patterns, or when it wants to send subscription request based on the S&N pattern, its DE4A Connector will query the SMP of the recipient Data Provider about this data:

@@ Line 210: / Line 210: @@
 === Values of the parameters for the SMP query process ===
 This section specifies the general values of the Participant ID, Document Type ID and Process ID parameters when querying the SMPs for the three main types of DE4A messages. Remember that, in DE4A, the Transport Protocol ID value is always the same (see [[EDelivery#SMP query process|SMP Query Process]]). The complete set of values for the following ''evidenceID'' and ''catalogueID'' variables are available at Annex I. Lists of codes.
 ==== Evidence Request ====

@@ Line 56: / Line 56: @@
 *The created domain name is: <code>54VMPCQA26DNZS74VHQOKJ7U6IRBBI5KPMQ6AO3KVCQC3F6YR2YA.iso6523-actorid-upis.de4a.edelivery.tech.ec.europa.eu</code>
 *The look up can be done with the “dig” tool on the command line:
-[[File:DNS NAPTR record query result.png|left]]
+[[File:DNS_NAPTR_record_query_result.png|alt=]]
 *The relevant part of the response is <code>"!.*!<nowiki>https://de4a-smp.usp.gv.at</nowiki>!"</code> that contains the link to the SMP of this particular Participant Identifier that can be queried for the details, embedded into a regular expression as defied by the NAPTR record specification.
 *Using the extracted URL <code><nowiki>https://de4a-smp.usp.gv.at</nowiki></code> the regular SMP query process, as described in chapter 3.1.4.5, can be performed.

← Older revision		Revision as of 12:03, 10 March 2023
Line 57:		Line 57:
	*The look up can be done with the “dig” tool on the command line:		*The look up can be done with the “dig” tool on the command line:
	[[File:DNS NAPTR record query result.png\|left]]		[[File:DNS NAPTR record query result.png\|left]]
		+

@@ Line 56: / Line 56: @@
 *The created domain name is: <code>54VMPCQA26DNZS74VHQOKJ7U6IRBBI5KPMQ6AO3KVCQC3F6YR2YA.iso6523-actorid-upis.de4a.edelivery.tech.ec.europa.eu</code>
 *The look up can be done with the “dig” tool on the command line:
 *The relevant part of the response is <code>"!.*!<nowiki>https://de4a-smp.usp.gv.at</nowiki>!"</code> that contains the link to the SMP of this particular Participant Identifier that can be queried for the details, embedded into a regular expression as defied by the NAPTR record specification.
 *Using the extracted URL <code><nowiki>https://de4a-smp.usp.gv.at</nowiki></code> the regular SMP query process, as described in chapter 3.1.4.5, can be performed.

← Older revision		Revision as of 09:30, 10 March 2023
Line 267:		Line 267:

	==AS4==		==AS4==
		+	AS4 is the corner stone of the eDelivery document exchange. It ensures that messages are transmitted in a secure, reliable, standardised and interchangeable manner. AS4 1.0 is an OASIS Standard and defines a subset of [http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.html OASIS ebMS 3.0]. The technology builds on top of SOAP messages and the usage of SOAP with attachments. The security specifications used are WS Security and WS Reliable Messaging.
		+
		+	The usage of AS4 is mandatory when using eDelivery: every message that is exchanged between a DE and a DO, independent of its direction, must be sent via AS4. The sending DE4A Connector acting as the DR and receiving Connector acting as the DT are the only components that directly deal with AS4. Neither DE nor DO need to know the details of the protocol.
		+
		+	AS4 messages are encrypted and signed on the protocol level (leveraging the WS-Security 1.1.1 specification) and by governance the usage of TLS 1.2 or later on the transport layer (with strong cipher suites only) is required – see the CEF eDelivery specification for details.
		+
		+	Messages sent from C2 to C3 are encrypted with the public key of C3 and signed with the private key of C2. The public key of C2 is transmitted as a BST as part of the message to C3. Each AS4 installation needs exactly one X.509 certificate (see [[Certificates]]) independent of the number of Participants for which it exchanges messages.
		+
		+	Each AS4 message exchange matches one HTTP exchange – it always consists of one request and one response. The message exchange pattern used by DE4A is the “One Way Push” pattern and that means that the requestor always sends a so called “User Message” with a payload to the receiver who has to respond with a so called “Signal Message” that contains either an Error or a Receipt with the non-repudiation of receipt information. In case of a successful message transmission and a positive response, no further payload besides the pure acceptance information is allowed.
		+
		+	In DE4A each request from a DR to a DT contains a RegRep document (see [[RegRep]]) that contains the DE4A Core Data Model (e.g. an Evidence Request). The response from DT back to DR contains also a RegRep document containing the DE4A Code Data Model (e.g. an Evidence Response) but also the main evidences as so called “attachments”. Depending on the number of pieces of evidence requested and the number of formats provided, the number of AS4 attachments in the response may vary.
		+
		+	The above figure shows the structural parts of an AS4 message. The figure depicts a DE4A evidence response that only contains the Canonical Evidence but no other evidence formats. A DE4A evidence request looks very similar – just without the Canonical Evidence.

@@ Line 188: / Line 188: @@
 === SMP Query Process ===
-After the base URL of the SMP was determined using the DNS lookup (see chapter [[EDelivery#SML query process in DE4A|SML query process in DE4A]]), the regular SMP lookup can take place. This action is performed by the DE4A Connector using the specified query API <code>/{participantID}/services/{docTypeID}</code>. The parameters to this query API are the Participant ID (that is already required for the DNS lookup) and Document Type ID. The Document Type ID defines what kind of document should be received and needs to be taken from the DE4A Code List (see chapter [[EDelivery#Identification of components|Identification of Components]]).
+After the base URL of the SMP was determined using the DNS lookup (see [[EDelivery#SML query process in DE4A|SML query process in DE4A]]), the regular SMP lookup can take place. This action is performed by the DE4A Connector using the specified query API <code>/{participantID}/services/{docTypeID}</code>. The parameters to this query API are the Participant ID (that is already required for the DNS lookup) and Document Type ID. The Document Type ID defines what kind of document should be received and needs to be taken from the DE4A Code List (see [[EDelivery#Identification of components|Identification of Components]]).
 For the Participant ID <code>iso6523-actorid-upis::9915:de4atest</code> and the Document Type ID <code><nowiki>urn:de4a-eu:CanonicalEvidenceType::CompanyRegistration:1.0</nowiki></code> (used to identify company registration data from the DBA pilot) the following query URL is built:
@@ Line 196: / Line 196: @@
 The result of this SMP HTTP GET query is an XML document that contains a list of all Processes and for each Process the list of Endpoints.
-The structure and values for the Participant IDs, Document Type IDs and Process IDs used during the SMP query process is described in chapter 3.1.4.6.
+The structure and values for the Participant IDs, Document Type IDs and Process IDs used during the SMP query process is described in [[EDelivery#Values of the parameters for the SMP query process|Values of the parameters for the SMP query process]].
 Inside each Process returned by the SMP query is a list of so called “Endpoints”. Each endpoint represents the connection details for one particular transport protocol. In DE4A we are only supporting the AS4 transport protocol with the identifier <code>bdxr-transport-ebms3-as4-v1p0</code> – so each returned Process may only contain a single Endpoint.
@@ Line 213: / Line 214: @@
 * ParticipantId:
-** Identifier of the '''Data Owner to request''' (see chapter 3.1.3.2).
+** Identifier of the '''Data Owner to request''' (see [[EDelivery#Domains and types of Participant IDs used in DE4A|Domains and types of Participant IDs used in DE4A]]).
 * DocumentTypeId:
 ** Identifier of the required item, depending on whether it is a '''canonical evidence type''' or a '''canonical event catalogue''', and whether it is a multi-item request or not.
@@ Line 233: / Line 234: @@
 * ParticipantId:
-** Identifier of the '''Data Evaluator to respond''' (see chapter 3.1.3.2).
+** Identifier of the '''Data Evaluator to respond''' (see [[EDelivery#Domains and types of Participant IDs used in DE4A|Domains and types of Participant IDs used in DE4A]]).
 * DocumentTypeId:
 ** Identifier of the required item, depending on whether it is a '''canonical evidence type''' or a '''canonical event catalogue''', and whether it is a multi-item request or not.
@@ Line 253: / Line 254: @@
 * ParticipantId:
-** Identifier of the '''Data Evaluator to notify''' (see chapter 3.1.3.2).
+** Identifier of the '''Data Evaluator to notify''' (see [[EDelivery#Domains and types of Participant IDs used in DE4A|Domains and types of Participant IDs used in DE4A]]).
 * DocumentTypeId:
 ** Identifier of the involved '''canonical event catalogue''', depending on whether it is a multi-item request or not.

@@ Line 209: / Line 209: @@
 This section specifies the general values of the Participant ID, Document Type ID and Process ID parameters when querying the SMPs for the three main types of DE4A messages. Remember that, in DE4A, the Transport Protocol ID value is always the same (see [[EDelivery#SMP query process|SMP Query Process]]). The complete set of values for the following ''evidenceID'' and ''catalogueID'' variables are available at Annex I. Lists of codes.
-=== Evidence Request ===
+==== Evidence Request ====
 When a Data Consumer wants to send an evidence request message based on the IM, USI or LU patterns, or when it wants to send subscription request based on the S&N pattern, its DE4A Connector will query the SMP of the recipient Data Provider about this data:
@@ Line 229: / Line 229: @@
 Data Provider’s SMP will reply with the endpoint and the certificate of the Data Transferor’s AS4 Gateway.
-=== Evidence Response ===
+==== Evidence Response ====
 When a Data Provider wants to send an evidence response message based on the IM, USI or LU patterns, or a subscription confirmation message based on the S&N pattern, or a redirection user message based on the USI pattern, its DE4A Connector will query the SMP of the recipient Data Consumer about this data:
@@ Line 249: / Line 249: @@
 Data Consumer’s SMP will reply with the endpoint and the certificate of the Data Requestor’s AS4 Gateway.
-=== Notification ===
+==== Notification ====
 When a Data Provider wants to send an event notification message based on the S&N pattern, its DE4A Connector will query the SMP of the recipient Data Consumer about this data:

← Older revision		Revision as of 09:15, 10 March 2023
Line 138:		Line 138:

	An SMP MUST be registered once in the SML before it can be used in the network.		An SMP MUST be registered once in the SML before it can be used in the network.
		+
		+	===Big Picture for SMP Registration===
		+	The initial registration of an SMP to the SML is depicted in the above figure. This process needs to be triggered manually by the SMP Administrator. It requires a trusted SMP certificate which is used as a client certificate when invoking the SML’s API.
		+
		+	Input parameters to the SML registration are:
		+
		+	*The SMP ID
		+	*The public IP address of the SMP server (which is a legacy parameter)
		+	*The public hostname of the SMP server
		+
		+	The results of this registration process are:
		+
		+	*The SMP ID is linked inside the SML with the SMP certificate.
		+	*The creation of the “Publisher DNS entry”, which is a generated DNS CNAME entry based on the SMP’s “SMP ID” and the base DNS zone the SML is operating in. The target is the public hostname of the SMP server.
		+
		+	Note: every time an SMP certificate is updated it MUST be updated in the SMP and the SML.
		+
		+	===Big Picture for Participant Registration===
		+	The above picture shows the Participant registration process – and it looks exactly the same as the figure above because the involved components are the same. It requires a trusted SMP certificate which is used as a client certificate when invoking the SML’s API.
		+
		+	Each Participant Registration in the SML performs the following actions:
		+
		+	*Link the Participant ID with the owning SMP. This implicitly checks that the Participant ID is unique and not already registered.
		+	*Create a new DNS record of type [https://www.ietf.org/rfc/rfc2915.txt “NAPTR”] that links the Participant ID with the owning SMP. NAPTR is a special DNS record type, different from the usual “A” or “CNAME” record types, and is able to store absolute URLs. The domain name is created using a hash algorithm and the target of the DNS entry is the public domain name of the SMP.
		+
		+	Note: Of course, an SMP should be able to handle multiple participants.
		+
		+	===Business Card Extension===
		+	As an addition to the routing information, an SMP must also support the “Business Card” API as specified by the Peppol Directory specification. It adds non-routing information to a “Participant Identifier”. The data model of the Business Cards is depicted in the following figure.
		+
		+	All the “Business Cards” will be collected in the DE4A Directory and made available centrally for querying. The SMP is responsible for keeping the data in the Directory up to date.
		+
		+	The API to query the business cards from an SMP is <code>/businesscard/{participantID}</code> and returns XML only. The supported XML Schemas are available on [https://github.com/phax/phoss-directory/tree/master/phoss-directory-businesscard/src/main/resources/schemas GitHub]- any of these versions may be returned from an SMP.
		+
		+	The SMP itself triggers the DE4A Directory via a REST API to indicate that the data of a Participant needs to be re-indexed. This API only takes the participant ID and the Directory will perform a DNS lookup with the participant ID (see [[EDelivery#SML/DNS\|SML/DNS]]) to determine the owning SMP, and query the Business Card via the previously mentioned REST API from that SMP. The reason why the SMP is not sending the full Business Card is to avoid that somebody else than the data owner can publish data into the Directory.
		+
		+	The phoss SMP, provided in [https://github.com/phax/phoss-smp GitHub], is the only open source SMP known to the author that supports the Business Card extension out of the box.
		+
		+	===Big Picture for Message Transmission===
		+	The figure above shows the big picture of a message exchange. It includes the following steps. Error handling is purposely left out.
		+
		+	*Step 1: C1 submits the document anyhow to C2. “Anyhow” from an eDelivery perspective means, that it is not specified by the eDelivery components – any protocol, payload and addressing mechanisms can be used here. In DE4A this communication is defined by a DE4A Connector interface.
		+	*Step 2: C2 requires the Participant ID of C4, calculate the DNS name (as outlined in [[#Big Picture for Participant Registration\|Big Picture for Participant Registration]]) and perform a DNS lookup for the “NAPTR” record. The outcome is the public URL of the SMP. The DNS is a distributed system itself and is one of the corner stones of the Internet as we know it.
		+	*Step 3: Perform the SMP client lookup with the public URL from step 2. The response XML format is described in the OASIS SMP specification. Select the best matching SMP Endpoint, based on the business requirements, which results in an “Endpoint URL” and the X.509 Certificate to be used in the AS4 transmission. The specific SMP Endpoint selection rules may vary from pilot to pilot. Access to the SMP SHOULD be transport layer secured(since the response of an SMP is digitally signed, authenticity can be verified anyway.).
		+	*Step4: Create the AS4 message, encrypt it with the certificate from Step 3 and sign it with your AS4 certificate. Transmit the document via AS4 to the URL retrieved from Step 3. The transmission MUST be transport-layer secured.
		+	*Step 5: C3 submits the document anyhow to C4. In DE4A this communication is defined by a DE4A Connector interface.
		+
		+	The list of these steps is complete, and no central, single-instance components are involved in the transmission.
		+
		+	=== SMP Query Process ===
		+	After the base URL of the SMP was determined using the DNS lookup (see chapter [[EDelivery#SML query process in DE4A\|SML query process in DE4A]]), the regular SMP lookup can take place. This action is performed by the DE4A Connector using the specified query API <code>/{participantID}/services/{docTypeID}</code>. The parameters to this query API are the Participant ID (that is already required for the DNS lookup) and Document Type ID. The Document Type ID defines what kind of document should be received and needs to be taken from the DE4A Code List (see chapter [[EDelivery#Identification of components\|Identification of Components]]).
		+
		+	For the Participant ID <code>iso6523-actorid-upis::9915:de4atest</code> and the Document Type ID <code><nowiki>urn:de4a-eu:CanonicalEvidenceType::CompanyRegistration:1.0</nowiki></code> (used to identify company registration data from the DBA pilot) the following query URL is built:
		+
		+	<code>/iso6523-actorid-upis::9915:de4atest/services/<nowiki>urn:de4a-eu:CanonicalEvidenceType::CompanyRegistration:1.0</nowiki></code>
		+
		+	The result of this SMP HTTP GET query is an XML document that contains a list of all Processes and for each Process the list of Endpoints.
		+
		+	The structure and values for the Participant IDs, Document Type IDs and Process IDs used during the SMP query process is described in chapter 3.1.4.6.
		+	Inside each Process returned by the SMP query is a list of so called “Endpoints”. Each endpoint represents the connection details for one particular transport protocol. In DE4A we are only supporting the AS4 transport protocol with the identifier <code>bdxr-transport-ebms3-as4-v1p0</code> – so each returned Process may only contain a single Endpoint.
		+
		+	The above figure shows the technical content of an SMP Endpoint. Inside an SMP Endpoint the two main elements that are of interest are the contents of:
		+
		+	* element <code>EndpointURI</code> containing the URL of the Connector where this Participant can retrieve the queried Document Type and
		+	* element <code>Certificate</code> containing the public X.509 certificate of the receiving Connector, so that the message can be digitally encrypted for that specific receiver.
		+
		+	With these information elements at hand, the message can be encrypted for the specific receiver and send to the correct URL. The main message exchange via AS4 can start now.
		+
		+	=== Values of the parameters for the SMP query process ===
		+	This section specifies the general values of the Participant ID, Document Type ID and Process ID parameters when querying the SMPs for the three main types of DE4A messages. Remember that, in DE4A, the Transport Protocol ID value is always the same (see [[EDelivery#SMP query process\|SMP Query Process]]). The complete set of values for the following ''evidenceID'' and ''catalogueID'' variables are available at Annex I. Lists of codes.
		+
		+	=== Evidence Request ===
		+	When a Data Consumer wants to send an evidence request message based on the IM, USI or LU patterns, or when it wants to send subscription request based on the S&N pattern, its DE4A Connector will query the SMP of the recipient Data Provider about this data:
		+
		+	* ParticipantId:
		+	** Identifier of the '''Data Owner to request''' (see chapter 3.1.3.2).
		+	* DocumentTypeId:
		+	** Identifier of the required item, depending on whether it is a '''canonical evidence type''' or a '''canonical event catalogue''', and whether it is a multi-item request or not.
		+	** For a single piece of evidence:
		+	*** <nowiki>urn:de4a-eu:CanonicalEvidenceType</nowiki>::''evidenceID''
		+	** For multiple pieces of evidence:
		+	*** <nowiki>urn:de4a-eu:CanonicalEvidenceType::MultiItem</nowiki>
		+	** For a single subscription:
		+	*** <nowiki>urn:de4a-eu:CanonicalEventCatalogueType</nowiki>::''catalogueID''
		+	** For multiple subscriptions:
		+	*** <nowiki>urn:de4a-eu:CanonicalEventCatalogueType::MultiItem</nowiki>
		+	* ProcessId:
		+	** <nowiki>urn:dea4-eu:MessageType</nowiki>::'''request'''
		+
		+	Data Provider’s SMP will reply with the endpoint and the certificate of the Data Transferor’s AS4 Gateway.
		+
		+	=== Evidence Response ===
		+	When a Data Provider wants to send an evidence response message based on the IM, USI or LU patterns, or a subscription confirmation message based on the S&N pattern, or a redirection user message based on the USI pattern, its DE4A Connector will query the SMP of the recipient Data Consumer about this data:
		+
		+	* ParticipantId:
		+	** Identifier of the '''Data Evaluator to respond''' (see chapter 3.1.3.2).
		+	* DocumentTypeId:
		+	** Identifier of the required item, depending on whether it is a '''canonical evidence type''' or a '''canonical event catalogue''', and whether it is a multi-item request or not.
		+	** For a single piece of evidence:
		+	*** <nowiki>urn:de4a-eu:CanonicalEvidenceType</nowiki>::''evidenceID''
		+	** For multiple pieces of evidence:
		+	*** <nowiki>urn:de4a-eu:CanonicalEvidenceType::MultiItem</nowiki>
		+	** For a single subscription:
		+	*** <nowiki>urn:de4a-eu:CanonicalEventCatalogueType</nowiki>::''catalogueID''
		+	** For multiple subscriptions:
		+	*** <nowiki>urn:de4a-eu:CanonicalEventCatalogueType::MultiItem</nowiki>
		+	* ProcessId:
		+	** <nowiki>urn:dea4-eu:MessageType</nowiki>::'''response'''
		+
		+	Data Consumer’s SMP will reply with the endpoint and the certificate of the Data Requestor’s AS4 Gateway.
		+
		+	=== Notification ===
		+	When a Data Provider wants to send an event notification message based on the S&N pattern, its DE4A Connector will query the SMP of the recipient Data Consumer about this data:
		+
		+	* ParticipantId:
		+	** Identifier of the '''Data Evaluator to notify''' (see chapter 3.1.3.2).
		+	* DocumentTypeId:
		+	** Identifier of the involved '''canonical event catalogue''', depending on whether it is a multi-item request or not.
		+	** For a single event notification:
		+	*** <nowiki>urn:de4a-eu:CanonicalEventCatalogueType</nowiki>::''catalogueID''
		+	** For multiple event notifications:
		+	*** <nowiki>urn:de4a-eu:CanonicalEventCatalogueType::MultiItem</nowiki>
		+	* ProcessId:
		+	** <nowiki>urn:dea4-eu:MessageType</nowiki>::'''notification'''
		+
		+	Data Consumer’s SMP will reply with the endpoint and the certificate of the Data Requestor’s AS4 Gateway.

	==AS4==		==AS4==