eDelivery
PMode Configuration for EU-CEG
Version 0.05
Published 10/03/2016
Glossary
Term / DescriptionABB / Architectural Building Block
Access Point / An AS4 Gateway is referred to as an Access Point.
An Access Point can send messages to some other Access Points, and receive messages from some other Access Points.
In a PMode file an Access Point is identified as a party.
When we define the Initiator and Responder flows between parties, we define the topology of the PMode.
AS4 / Applicability Statement 4
AS4 is a Conformance Profile of the OASIS ebMS 3.0 specification, and represents an open standard for the secure and payload-agnostic exchange of Business-to-business documents using web services.
DES / Data Encryption Standard
Endpoint / A party which receives messages is an endpoint. While it's theoretically possible that a party was never an endpoint, this would mean that that party never received a message from any other party. Therefore, in practice, each party is always an endpoint for one or more other parties.
MC / Message Consumer
The Message Consumer is an entity that interacts with a Receiving MSH (i.e. an MSH in the Receiving role) to consume data from a received user message.
Some examples are:
- An application.
- A queuing system.
- Another SOAP processor.
MEP / Message Exchange Pattern
This is an AS4 term.
MP / Message Producer
The Message Producer is an entity that interacts with a Sending MSH (i.e. an MSH in the Sending role) to initiate the sending of a user message.
Some examples are:
- An application.
- A queuing system.
- Another SOAP processor.
The Producer is always an MSHendpoint.
MPC / Message Partition Channel.
DifferentMPCs can exist, each defined as a Container.
An MPC allows the flow of messages from a Sending MSH to a Receiving MSHto be partitioned into several flows, each of which is controlled separately.
An MPC also allows flows from several Sending MSHsto be merged into a single unique flow that will be treated as such by a Receiving MSH.
MSH / Message Service Handler
The MSH is an entity that is able to generate or process messages that conform to the ebMS specification, and which act in at least one of the two ebMS roles: Sender and Receiver.
In terms of SOAP processing, an MSH is either a SOAP processor or a chain of SOAP processors. In either case, an MSHhas to be able to understand the eb:Messaging header (qualified with the ebMS namespace).
An MSH must not include more than onePartyIdelement in theUserMessage/PartyInfo/FromandUserMessage/PartyInfo/To elements.
OASIS / Advancing open standards for the information society
Non-profit, international consortium creating interoperable industry specifications based on public standards.
PMode / Processing Mode
SOAP / Simple Object Access Protocol
URL / Uniform Resource Locator
WSS / Web Server Software
WSSE / WSSEis a family of open security specifications for SOAP web services. The basic premise ofWSSEis that a request header is checked for encrypted credentials, verified using a timestamp and nonce, and authenticated for the requested user using a password digest.
X.509 / Cryptographystandard for PKI.
XML / eXtensibleMarkup Language
XMLENC / XML Encryption
N.B.Now deprecated.
Document Print Date:22 December 2018Page 1 of 16
eDelivery
PMode Configuration for EU-CEG
Version 0.05
Published 10/03/2016
PMode Parameters
The following table summarises the PMode settings for EU-CEG:
PMode Parameter / Description / Value in EU-CEG ProfilePMode.ID : optional / Identifier for the PMode. e.g. the name of the business transaction. / No restriction on chosen value.
Chosen value: EU_CEG
PMode.Agreement : optional / The MEPs which the message exchanges will conform to. / No restriction on chosen value.
PMode.MEP: required / Message Exchange Pattern:
- One-Way MEPgoverns the exchange of a single User Message Unit unrelated to other User Messages.
- Two-Way MEPgoverns the exchange of two User Message Units in opposite directions.
- Two-Way MEP
or
- One-Way MEP
PMode.MEPBinding: required / A Binding is the transport channel binding URL assigned to the MEP:
- push
- push-and-push
- push-and-push
Used withTwo-Way MEP.
or
- 2 x push
Used withOne-Way MEP.
PMode.Initiator.Party :optional if PMode.Responder is present. / Qualifies the party initiating the MEP.
Specifies an identifier (and possibly a type attribute value) compliant with theeSENS Addressing ABB.[2] / Chosen value: EU_CEG_EC
PMode.Initiator.Role / The Message Producer carries out the initiator role, which is the role of the party sending the first message of the MEP. / No restriction on chosen value.
Chosen value:
=> Sender
PMode.Initiator.Authorization.username / Describe authorisation information for messages sent by Initiator. These parameters need to be matched by a wsse:UsernameToken element in a message (in a security header only intended for authorisation) for this message to be processed successfully on receiver side: here by the Responder MSH. / Not used
PMode.Initiator.Authorization.password / Not used
PMode.Responder.Party :optional if PMode.Initiator is present. / Qualifies the party responding to the initiator party in the MEP.
Specifies an identifier (and possibly a type attribute value) compliant with eSENS Addressing ABB.2 / Chosen value: EU_CEG_EC
PMode.Responder.Role / The Message Consumer carries out the responderrole. / No restriction on chosen value.
Chosen value:
=> Recipient
PMode.Responder.Authorization.username / Describe authorisation information for messages sent by Responder. These parameters need to be matched by a wsse:UsernameToken element in a message (in a security header only intended for authorisation) for this message to be processed successfully on receiver side: here by the Responder MSH. / Not used
PMode.Responder.Authorization.password / Not used
PMode[1].Protocol.Address: required / Endpoint URL of the Receiver MSH (or Receiver Party) to which Messages under the PMode leg are to be sent. / tbc
PMode[1].Protocol.SOAPVersion / The SOAP version to be used (1.1 or 1.2). / Chosen value: 1.2
PMode[1].BusinessInfo.Service / Name of the service to which the User message is intended to be delivered. It identifies a set of related business transactions or other message exchanges in the context of a business process or use case.
The standard format of a service name in eDelivery will be:
where ServiceName is replaced by the name of the particular service. The name of the service will contain no whitespace and will concisely and unambiguously identify the service.
This service is for EU-CEG Tobacco and eCIG products submission.
Its service name will be tobaccoreporting / Chosen value:
PMode[1].BusinessInfo.Action / Name of the action(s) the User message is intended to invoke.
Identifies the different types of business transactions or other message exchanges in the context of an Identified Service.This may be an identifier of a document type,if the exchange of a document of that type unambiguously identifies the purpose and requested action in the context of the Service. / Chosen value:
- Submit Success Message
- Submit Error Message
- Submit Product Message
- Submit Attachment Message
- Submit InitiatorDetails Message
PMode[1].BusinessInfo.Properties / A list of properties.
A property is a data structure that consists of four values within the User message:
- The property name, which can be used as an identifier of the property.
- The property description.
- The property data type.
- Boolean parameter indicating(if true)thatthe property is mandatory. Otherwise (if false) the property isoptional.
PMode[1].BusinessInfo.MPC / Identifier of the MPC (Message Partition Channel) to which the message is assigned. / No restriction on chosen value.
PMode[1].BusinessInfo.PayloadProfile / A list of payload parts.
A payload part is a data structure that consists of five properties:
- name (or Content-ID) that is the part identifier, and can be used as an index in the notation PayloadProfile[];
- MIME data type (text/XML, application/PDF, etc.);
- name of the applicable XML Schema file if the MIME data type is text/XML;
- maximum size in kilobytes;
- Boolean parameter indicating(if true)that – within the User message – the part is mandatory. Otherwise (if false) the part is optional.
Chosen value:
- One XML payload named message.
- MIME data type application/XML
- n/a
- maximum size of 100,000KB
- TRUE
PMode[1].Errorhandling.Report.SenderErrorsTo / The address – or comma-separated list of addresses – to which to send errors generated by the MSH that was trying to send the message in error. / Not used
PMode[1].Errorhandling.Report.ReceiverErrorsTo / The address– or comma-separated list of addresses – to which to send ebMS errors generated by the MSH that receives the message in error.
e.g.This may be the address of the MSH sending the message in error. / Not used
PMode[1].Errorhandling.Report.AsResponse / Boolean parameter indicating(if true)that errors generated from receiving a message in error are sent over the backchannel of the underlying protocol associated with the message in error. / Chosen value: TRUE
PMode[1].Errorhandling.Report.ProcessErrorNotifyConsumer / Boolean parameter indicating(if true)that the Consumer (application/party) of a User Message matching the PMode should be notified when an error occurs in the Receiving MSH. / Chosen value: TRUE
PMode[1].Errorhandling.DeliveryFailuresNotifyProducter / Boolean parameter indicating(if true)that– during processing of the User Message to be sent – the Producer (application/party) of a User Message matching the PMode should be notified when an error occurs in the Sending MSH. / Chosen value: TRUE
PMode[1].Reliability / Reliability contracts – or references to them – that will govern the reliability of messages exchanged. / Not used
PMode[1].Security.WSSversion / The value represents the version of WS-Security to be used, and it has two possible values[3]:
- 1.0
- 1.1
PMode[1].Security.X509.Sign / Boolean parameter indicating(if true)thatthe message is to be signed. / Chosen value: TRUE
PMode[1].Security.X509.Signature.Certificate / Public certificate to use when verifying signed data. / Signing Certificate of the Sender
PMode[1].Security.X509.Signature.HashFunction / Algorithm used to compute the digest of the message being signed.
The definitions for these values are in the [XMLDSIG] specification. /
PMode[1].Security.X509.Signature.Algorithm / Identifies the algorithm to compute the value of the digital signature.
The definitions for these values are found in the [XMLDSIG] or [XMLENC] specifications. /
PMode[1].Security.X509.Encryption.Encrypt / Boolean parameter indicating (if true) thatthe MSH will encrypt:
- All payload parts:
- Any SOAP Body will also be encrypted.
- Attachments.
If confidentiality of data in theMessagingheader is required, this can be achieved throughtransport level security. / Chosen value: TRUE
PMode[1].Security.X509.Encryption.Certificate / Public certificate to use when encrypting data. / Encryption Certificate of the Receiver
PMode[1].Security.X509.Encryption.Algorithm / Encryption algorithm to be used. The definitions for these values are found in the [XMLENC]specification. / Chosen value:
=> AES-GCM
PMode[1].Security.X509.Encryption.MinimumStrength / Integer value for the effective strength which the encryption algorithm must provide in terms of effective or random bits.
The value is less than the key length in bits when check bits are used in the key.
e.g.The 8 check bits of a 64-bit DES key would not be included in the count.
Setting MinimumStrength to 56 is requiredin order to havea minimum strength equal to that supplied by DES. / Chosen value: 128
PMode[1].Security.UsernameToken.username / Username to include in a WSSUsername Token. / Not used
PMode[1].Security.UsernameToken.password / Password to use inside a WSS Username Token. / Not used
PMode[1].Security.UsernameToken.Digest / Indicates whether a password digest will be included in the WSSUsernameTokenelement. / Not used
PMode[1].Security.UsernameToken.Nonce / Indicates whether the WSSUsernameToken element will contain a Nonce element.
Nonce => A number or bit string used only once in security engineering. / Not used
PMode[1].Security.UsernameToken.Created / Indicates whether the WSSUsernameToken element will have a Created timestamp element. / Not used
PMode[1].Security.PModeAuthorize / Boolean parameter indicating(if true)that a message on the MEP leg has to be authorised for processing under the PMode.
If the parameter is true this implies that the following has to be used for this purpose:
- PMode.Responder.Authorization.{username/password}, if the message is sent by Responder.
- PMode.Initiator.Authorization, if the message is sent by Initiator.
- the MPC is the same as specified in the PMode leg for the pushed message;
- the signal contains valid credentials (i.e. username/password).
PMode[1].Security.SendReceipt / Boolean parameter indicating(if true)that a signed receipt (Receipt ebMS signal) containing a digest of the message has to be sent back. / Chosen value: TRUE
PMode[1].Security.SendReceipt.NonRepudiation / Boolean parameter indicating (if true) that non-repudiation of receipt is required. Otherwise (if false) only reception awareness is required.
Non-repudiation prevents a recipient from denying receipt of a message.
Non-repudiation receipts have to be sent synchronously for each message type.
N.B.Non-repudiation is onlyper hop in the case of the four-corner-model, in particular the hop from corner two to corner three. / Chosen value: TRUE
PMode[1].Security.SendReceipt.ReplyPattern / Indicates whether the Receipt signal is to be sent:
- as a callbackon a separate connection.(value "callback");
- synchronouslyon the HTTP response or back-channel (value "response").
PMode[1].PayloadService.CompressionType / Type of compression used in the payload. / Chosen value: application/gzip
PMode[1].ReceptionAwareness / Boolean parameter indicating(if true)that steps must be taken to seek to ensure reception of a message. / Chosen value: TRUE
PMode[1].ReceptionAwareness.Retry / Boolean parameter indicating(if true)that the steps taken to seek to ensure reception of a message will be repeated if necessary. / Chosen value: TRUE
PMode[1].ReceptionAwareness.Retry.Parameters / A composite string showing:
- retryTimeout: timeout in seconds
e.g. 1 - retryCount: total number of retries
e.g. 5 - strategy: frequency of retries
The only strategy valuecurrently available is CONSTANT. - duplicateDetection: check for duplicates in order to prevent receiving the same messagetwice.
The only duplicateDetectionvaluecurrently available is true.
Chosen value:
- 5 for retry timeout[IK1]
- 5 for retry count
- CONSTANTfor strategy
- TRUEfor duplicate detection
PMode[1].ReceptionAwareness.DuplicateDetection / Boolean parameter indicating(if true)that duplicate messages are to be detected. / Chosen value: TRUE
PMode[1].ReceptionAwareness.DetectDuplicates.Parameters / A composite string showing (for example):
- Maximum size of message log over which duplicate detection is supported.
- Maximum time window over which duplicate detection is supported.
e.g.“maxsize=10Mb,checkwindow=7D”, if the duplicate check window is guaranteed of 7 days minimum.
To determine if a message is a duplicate,only the message identifier is checked. / No restriction on chosen value.
PMode[1].BusinessInfo.subMPCext / Sub-channel extension to be used.
e.g.If PMode[1].BusinessInfo.MPCis “
and
subMPCextis “subc42”
then
the sub-channel is:
and
the sub-channel extension is:
subc42 / Not used
Document Print Date:22 December 2018Page 1 of 16
[1]Each message of an MEP instance refers to a previous message of the same instance, unless it is the first one to occur. Messages are associated with a label (e.g. request, reply) that precisely identifies their direction between the parties involved and their role in the choreography.
[2] See
[3]Subordinate maintenance releases can be acknowledged in the value.e.g. a version number 1.1.1 would indicate that maintenance release 1 of version 1.1 was being used.
[IK1]5 seconds okay for retry timeout?