This XML schema is part of the OASIS CPPA3 specification developed by the OASIS ebCore TC.
Two elements defined in this schema can serve as root elements of CPPA3 XML documents:
A Collaboration Protocol Profile (CPP) defines the capabilities of a Party to engage in electronic business message exchange with other Parties. These capabilities include both technology and business capabilities, such as supported transport and messaging protocols, and what business collaborations the party can participate in.
Unlike the CPPA version 2.0 schema, only a single PartyInfo element is allowed in a CPP. The use case of a party that has different party identities, which may be associated with different service specifications or with different channels, transports etc. can be addressed by using different CPP documents for the party.
A CPP MAY be signed by by the party involved and/or by another party involved in the creation or distribution of the CPP.
The optional attributes allowed and denied in the acl_attributes attribute group MAY be attached at the CPP, ServiceBinding, or ActionBinding levels. These attributes control possibilities for CPA formation of the CPP with counterparty CPPs.
If no ServiceSpecification is present in the CPP, the party indicates that it is unable to participate in electronic business message exchange.
The CPPAExtension element can be used for extensibility of CPP elements.
The ProfileInfo element provides metadata about the Collaboration Protocol Profile.
In a CPP, the ProfileIdentifier element is used to provide an identifier for the profile. When used in a CPA, it identifies a profile that the collaboration protocol agreement relates to.
The combination of the type value and element content MUST be unique in the context of the party to which it relates.
The type attribute defines a namespace in which the content of the ProfileIdentifier element is to be interpreted.
An optional URL locating the referenced CPP. This attribute MAY be used in a CPA to express the location from which a referenced CPP was or can be retrieved.
This element defines a list of party identifiers or (recursively) references to lists of party identifiers. The list logically includes all PartyIds included as direct child elements of the PartyIdList element, as well as all PartyIds indirectly included as child elements of PartyIdLists referenced (possibly recursively) as PartyIdListRef child elements.
Party Id lists are used for white listing and black listing counterparties in CPPs, using the allowed and denied attributes.
Party Id list references MUST NOT be circular.
A Collaboration-Protocol Agreement (CPA) defines a set of specified services and roles that a Party and a CounterParty agree upon to deploy, acting in agreed roles, using particular Channels and Transports, to exchange particular profiled Payloads using particular Packaging. A CPA MAY be signed by the parties involved and/or by any other parties involved in the formation of the CPA.
Unlike the CPPA version 2.0 schema, only a single PartyInfo element is allowed in a CPA. A CPA also includes only a single CounterPartyInfo element.
The CPPAExtension element can be used for extensibility of CPA elements.
The AgreementInfo element provides metadata about the CPA.
The AgreementIdentifier element is used to provide an identifier for the agreement. The type value and element content of the element MUST be unique in the context of the pair of parties to which it relates.
Communities MAY adopt format conventions for the value of the AgreementIdentifier element. For example, the value MAY be derived from the values of two CPP ProfileIdentifiers (if the CPA is formed from CPP) or from the (Counter)PartyInfo/PartyId values in the CPA. CPA tooling MAY allow users to specify and apply specific conventions.
The element corresponds, for ebMS2, to the CPAId message header
For ebMS3, it naturally corresponds to the PMode.Agreement parameter and AgreementRef header. However, that parameter and header are sometimes used to specify adherence to multilateral, community agreements. In that case, they are then more like a CPPA3 ChannelProfile indicator.
The type attribute defines a namespace in which the value of AgreementIdentifier is to be interpreted.
When used in a CPP or CPA, this element defines the date and time from which the CPP or CPA is valid.
When used in a ServiceBinding, this element defines the date and time from which the ServiceBinding is valid.
When used in a CPP or CPA, this element defines the date and time at which a CPP or CPA expires.
When used in a ServiceBinding, this element defines the date and time from which a ServiceBinding expires.
This element defines the minimum interval needed to phase in an agreement created from a a collaboration protocol profile. This element MAY be useful if deployment of a CPA in a company involves a service management process that is not a (fully) automated process. When forming an agreement for two profiles, the longest of the intervals specified in the two profiles is to be used.
The PartyInfo element provides information about a Party. This element is used in CPP and CPA.
When used for ebMS3, this element encodes some information relating to the PMode.{Initiator/Responder}.Party parameters.
The CounterPartyInfo element provides information about a CounterParty. This element is only used in CPA.
When used for ebMS3, this element encodes some information relating to the PMode.{Initiator/Responder}.Party parameters.
For a Party or CounterParty, its Name IDs, Contact information, any certificates, trusted anchors, certificate policies and IDPs used by the party MAY be specified.
The semantics of presence of more than one PartyName is out of scope for this specification.
If more than one child PartyId element is used in a CPPA3 document for a party, any or all party identifiers MAY be used to identify the party. If more than one PartyId element is used in a CPPA3 document for a party, presence of any or all related headers in related messages configured using the CPPA3 document is dependent on the channel (which may or may not allow or require presence of multiple party identifiers), channel profile, and/or implementation used.
The PartyInfoExtension element can be used for extensibility of PartyInfo and CounterPartyInfo elements.
The href attribute provides a link, in the form of a URI, to additional information about the Party or CounterParty. Typically, this would be a URL from which the information can be obtained. The content and/or format of that information at that URI is outside of the scope of this specification.
This element indicates the common, human readable name of the organization. The value of each PartyName MUST identify the organization, entity, division or group of an organization described in the parent PartyInfo element in the CPP or CPA document.
The language of the name.
An optional reference to a resource about the named Party.
The PartyId element provides a party identifier for a (Counter)Party. This identifier is to be used to logically identify the Party. The value of the PartyId element is a non-empty string.
When using the ebMS2 or ebMS3 protocols, the values of PartyId MUST be used as eb:From/eb:PartyId and eb:To/eb:PartyId elements. Note that these protocols require the PartyId to be a URI if the type attribute is not present.
When using the AS2 or AS3 protocols, the values of PartyId MUST be used as AS2-From and AS2-To and AS3-From and AS3-To system identifier headers, respectively.
When using the AMQP protocol, the of PartyId SHOULD be used as the user-id and to message properties.
The type attribute defines a namespace in which the value of PartyId is to be interpreted. Use of the OASIS ebCore Party Id Type specification is RECOMMENDED.
A person or department that acts as a point of contact for a party.
The content of this element is derived from the UN/CEFACT Core Component Library.
An abstract Security Token
A abstract reference to a security token.
Type definition of an abstract reference to a security token.
This element specifies an X.509 Certificate.
A certificate can be specified in one of two ways:
While this schema uses an XKMS schema element, use of the XKMS protocol and the XKMS client and server software is NOT REQUIRED. Instead, the element is only used to specify requirements on the certificate such that a certificate that is not included in the CPP or CPA document can be located. In CPA formation, a matching certificate MAY be selected using either by executing a XKMS LocateRequest against an XKMS server, or using some other mechanism. Any certificate obtained from this SHOULD be matched against any specified applicable trust anchors. Any use the resulting certificate, if one is successfully retrieved in CPA formation, is left to implementations or usage profiles. For example, an implementation MAY include the retrieved certificate instead of the LocateRequest in the formed CPA.
In XKMS, the Service attribute is mandatory. If its value is non-empty, it MAY be set to the value of the URI to which an XKMS request locating the certificate is to be directed. Alternatively, the value MAY be used as a configuration parameter for locating the certificate. If the value is empty (as allowed by the anyURI data type), the source from which the certificate is to be retrieved is not expressed and its interpretation and use are implementation-dependent.
An abstract reference to a certificate.
Type definition of an abstract reference to a certificate.
The CertificateDefaults element expresses default certificates and default trust anchors for a Party in a CPP or CPA.
For Channels bound to send ActionBindings that can be secured using certificates:
For Channels bound to receive ActionBindings that can be secured using certificates:
For a Transport for which a Party acts as Server:
For a Transport for which a Party acts as Client:
For the purpose of forming a CPA from two CPPs, a definition in a CPP of a Channel for which a certificate or trust anchor for a Party for signing or encryption is explicitly specified at the level of a ChannelFeature for that Channel is equivalent to a Channel for which the certificate or trust anchor is not specified for the purpose at the level of a ChannelFeature for that Channel but is specified for the purpose in the CertificateDefaults for the Party .
An reference to a set of certificate policies.
A TrustAnchorSet is a collection of trusted certificate roots. The TrustAnchorSet element MAY contain one or more AnchorCertificateRef elements, each of which refers to a Certificate element (under PartyInfo or CounterPartyInfo) that represents a root certificate trusted by this Party. These trusted root certificates are used in the process of certificate path validation. If a certificate in question does not “chain” to one of this Party’s trust anchors, it is considered invalid.
A TrustAnchorSet MAY also contain such a root certificate as direct child element.
A TrustAnchorSet can be referenced using SigningTrustAnchorSetRef, EncryptionTrustAnchorSetRef, ClientTrustAnchorSetRef and ServerTrustAnchorSetRef elements in channel or transport binding definitions, and taken into account during CPA formation. In forming a CPA, a presented certificate MUST be matched against a referenced anchor. The TrustAnchorSet itself is not REQUIRED to be present in the generated CPA, as the selected certificate is trusted directly and specified in the CPA.
Unique identifier of the set of trusted anchor certificates
A set of accepted certificate policies, identified using OID in dotted string notation.
Unique identifier of the set of accepted certificate policies
The IDPRegistration element represents a registration of a Party with an Identity Service Provider. This element can be used by parties in conjunction with a channel that uses SAML tokens to select an IDP to obtain the token from.
The mandatory ProviderID is an Entity Identifier (see [SAML-CORE-2.0-OS], section 8.3.6) that uniquely identifies the identity provider
The optional Endpoint is the Endpoint URI of the identity provider.
The optional ReceiverID represents the identity under which a party is known by the IDP. It is REQUIRED for any party that receives messages using a channel that requires information from the IDP.
The element corresponds to /sp:SamlToken/sp:Issuer in WS-SecurityPolicy [WSSecurityPolicy13].
Unique identifier of the IDP registration
The mandatory ProviderID is an Entity Identifier (see [SAML-CORE-2.0-OS], section 8.3.6) that uniquely identifies the identity provider.
The mandatory ReceiverID is an Entity Identifier (see [SAML-CORE-2.0-OS], section 8.3.6) that specifies the identity under which a Party is registered with the identity provider.
The IDPRegistrationSet bundles a set of IDP registrations and provides an identifier that can be referenced by channels. Multiple registration sets MAY be specified, for example to support cases where different sets of registrations apply to different channels.
Unique identifier of the set of IDP registrations
A reference to a set of IDP registrations
Type definition of reference to a set of IDP registrations.
A Public Key for use with SSH2 [RFC4254]. The content of the public key MUST be included as a KeyInfo/KeyValue/DSAKeyValue or KeyInfo/KeyValue/RSAKeyValue element.
A reference to use of an SSH key for SSH client authentication.
A reference to use of an SSH key for SSH server authentication.
This element associates a party with a Service and a binding (or bindings) supporting the participation of the party in a particular role in one or multiple business collaborations, collaborating with other parties acting in another particular role.
In a CPP, PartyRole specifies the role of the party defined in PartyInfo. CounterPartyRole specifies the role of an unspecified party with whom the party MAY engage in message exchange.
In a CPA, PartyRole specifies the role of the party defined in PartyInfo and CounterPartyRole specifies the role of the party defined in CounterPartyInfo.
In a CPP or CPA document, for an ordered pair or <PartyRole, CounterPartyRole> all ServiceBindings for that pair MUST be contained within a single ServiceSpecification.
In CPPA2, the equivalent of this element was called CollaborationRole.
The element CounterPartyRole has no equivalent in CPPA2. It is added the CPPA3 schema to facilitate automated CPA formation in business processes involving more than two roles. For example: In a collaboration involving roles A, B and C, some message types may be exchanged between A and B, others between A and C and others between B and C. Therefore in CPPA3 a ServiceSpecifications specifies the involved role pair.
The ServiceSpecificationExtension element is provided to allow extensibility of ServiceSpecification elements.
This attribute kan be used to reference a business process definition document, for example an OASIS ebBP schema document [ebBP]. Any references to collaborations, transactions and roles in dependent ServiceBinding elements are to be interpreted relative to this schema.
This attribute serves the same purpose as the use of ProcessSpecification/ds:Reference in CPPA2.
This attribute uniquely identifies the business process associated with the ServiceSpecification. If an ebBP document is referenced using the base attribute, this value MUST match the UUID specified for a process contained in the referenced ebBP document.
This attribute is equivalent to the CPPA2 ProcessSpecification/@uuid attribute.
This attribute defines the name of the business process associated with the service collaboration. If an ebBP document is referenced using the base attribute, this value MUST match the name specified for a process contained in the referenced ebBP document.
This attribute defines the version of the business process associated with the service collaboration.
This element identifies the role of the party involved in the service collaboration in the sibling ServiceBinding elements.
With ebMS2 and ebMS3, this value is used in the eb:From/eb:Role or eb:To/Role headers.
With ebMS3, depending on the exchange binding, this element corresponds to one of the PMode.Initiator.Role or PMode.Responder.Role parameters.
This element identifies the role of the counterparty involved in the service collaboration in the sibling ServiceBinding elements.
With ebMS2 and ebMS3, this value is used in From/Role or To/Role headers.
With ebMS3, depending on the exchange binding, this element corresponds to one of the PMode.Initiator.Role or PMode.Responder.Role elements.
For ServiceBindings associated with a business process, the value of this attribute MUST match a defined role in the business process.
When used in combination with an ebBP process definition, the value of this attribute MUST match a BusinessCollaboration/Role/@name, BinaryCollaboration/Role/@name or MultiPartyCollaboration/Role/@name value.
A ServiceBinding specifies a Service and provides a binding of its actions. If a business process is referenced in the parent ServiceSpecification, this element establishes the requesting and responding business activities in a business process definition that describe the actions to be implemented.
It is possible to specify the ActivationDate for a ServiceBinding, if its value is later than the value of the ActivationDate of the containing CPP or CPA.
Similarly, it is possible to specify the ExpirationDate for a ServiceBinding, if its value is earlier than the value of the ExpirationDate of the containing CPP or CPA.
The ServiceBindingExtension element is provided to allow extensibility of ServiceBinding elements.
This element identifies the service that acts on the message. Its actual semantics is beyond the scope of this specification. Its value MUST be agreed and interpreted consistently by a party and its counterparties. The designer of a service may be a standards organization or industry, an individual or enterprise.
In ebMS3, this element corresponds to the PMode[1].BusinessInfo.Service parameter.
When used for a business process defined in ebBP, the value of this element SHOULD match a BusinessCollaboration/@name, BinaryCollaboration/@name or MultiPartyCollaboration/@name value in the context of the referenced ebBP document.
The attribute define a service type.
An ActionBinding defines a binding for an action in a service. Its actual semantics is beyond the scope of this specification. Like the ebMS3 concept of a processing mode, the binding controls the way messages are processed and provides a configuration that is common to a set of messages exchanged among parties.
This version of CPPA supports actions in One Way exchanges and pairs of actions in Two Way exchanges. An action in a One Way exchange is an action that is not followed by another action that explicitly relates to the One Way exchange action. In Two Way exchanges, one action is expected to be followed by another action that explicitly relates to it. This other action MUST reference the action it relates to using the replyTo attribute. The interpretation of situations in which there are multiple ActionBindings that are replies to the same ActionBinding, is outside the scope of this specification. They may constitute alternative responses. For example, a SubmitOrder action may be replied to by an AcceptOrder action or a RejectOrder action. When used for actions defined in an ebBP schema document, a One Way exchange corresponds to a RequestingBusinessActivity. A Two Way exchange corresponds to a RequestingBusinessActivity and the corresponding RespondingBusinessActivity
An ActionBinding corresponds with an ebMS3 One Way MEP (identified as http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay) if there is no other ActionBinding that refers to it using the replyTo attribute.
An ebMS3 Two Way MEP (identified as http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/twoWay) corresponds to a collection of at least two ActionBindings. Exactly one of these MUST NOT have a replyTo attribute. This constitutes the first leg in the MEP. All other ActionBindings in this collection relate to the second leg in the message exchange. They MUST have a replyTo reference to the ActionBinding corresponding to the first leg. For ebMS3, specification of alternative responses is an issue to possibly be addressed in a future errata.
ActionBinding elements with values send or receive for the sendOrReceive attribute correspond to the CPPA version 2.0 CanSend and CanReceive elements, respectively.
In a CPP, an ActionBinding is associated with one or multiple channels, identified using their ChannelId. If there is more than one reference to a channel, the presented channels are alternatives, with preferred bindings preceding less preferred alternatives. For example, a party may offer an ebMS3 channel that is preferred as well as an ebMS2 channel that is supported for legacy connections.
In a CPA, there MUST be exactly one ChannelID, covering the channel for both parties.
In a CPP, the CPPA3 schema associates an ActionBinding with zero or multiple payload profiles, identified using a PayloadProfileId. If there is more than one reference to a payload profile, the presented payload profiles are alternatives, with preferred bindings preceding less preferred alternatives. In the absence of any PayloadProfileId elements, there are no contraints on payloads that are exchanged.
In a CPA, there MUST be at most one PayloadProfileId, covering the payload profile that both parties agree to use. In the absence of any PayloadProfileId elements, there are no contraints on payloads that are exchanged.
When a CPA is used in combination with the ebMS2 or ebMS3 messaging protocols, the Service and Action message headers and the Service element content and the action attribute of ActionBinding in the CPA can be linked to infer the applicable ActionBinding, with its Channel and PayloadProfile. This mapping is unambiguous if, in the context of an ServiceBinding, only a single ActionBinding exists for any given pair of values for the action and sendOrReceive attributes.
An ActionBinding MAY contain Property elements that associate additional metadata with the messages. The semantics of these elements MAY depend on the Service context of the ActionBinding.
The use of Property elements MAY depend on the messaging protocol used. In ebMS3, the elements control the use of Message Properties. In AMQP, they map to AMQP Application Properties.
Sets of Property elements MAY also be referenced using the propertySetId attribute. If any Property elements are present, the propertySetId attribute MUST NOT be present.
The ActionBindingExtension element is provided to allow extensibility of ActionBinding elements.
The id attribute identifies an ActionBinding in the context of a CPPA3 document. This enables cross-references between actions using the replyTo attribute. The attribute can also serve a similar purpose to the ebMS3 PMode.ID parameter, however the ebMS3 parameter is common to the two legs in a Two Way MEP, whereas the CPPA3 attribute is specific to a particular leg.
When used for actions defined in an ebBP schema document, the value of this attribute SHOULD match a RequestingBusinessActivity/@name or RespondingBusinessActivity/@name value.
When used with ebMS3, the action attribute corresponds to the ebMS3 PMode[1].BusinessInfo.Action parameter.
When used for actions defined in an ebBP schema document, the value of this attribute MUST match ComplexBusinessTransactionActivity/@name or BusinessTransactionActivity/@name
When used for actions defined in an ebBP schema document, the value of this attribute MUST match a defined CollaborationActivity/@name.
When used for actions defined in an ebBP schema document, the value of this attribute MUST match a defined RequestingBusinessActivity/@name or the RespondingBusinessActivity/@name.
This attribute group specifies business quality of service attributes for the action.
This attribute specifies the directionality of the action, from the perspective of the Party. In a pair of actions in a Two Way exchange, if the value of sendOrReceive for the first action is send, the second action MUST have the value receive and vice versa.
This attribute MAY be used to express that an action is a response to some other action and to identify that action. When bound to ebMS2 or ebMS3, this attribute also expresses that on messages for this action a RefToMessageId element is REQUIRED.
If ActionBinding X references another ActionBinding Y using replyTo, then Y MUST NOT itself reference any other ActionBinding Z.
A referenced ActionBinding MUST be a sibling element, i.e. it MUST be contained in the same ServiceBinding. As a consequence, when used with ebMS2 or ebMS3, the value for the Service header field will be the same for both legs in a Two Way MEP. Also see https://issues.oasis-open.org/browse/EBXMLMSG-73.
When used for actions defined in an ebBP schema document, this attribute MUST be present on actions representing a RespondingBusinessActivity and MUST reference an ActionBinding/@id for the corresponding RequestingBusinessActivity.
This attribute MUST NOT be used in a CPA. It MAY be used in a CPP to express whether or not support for the action is required, in the context of a containing ServiceBinding. If a CPP specifies its use as optional, the other CPP does not have to provide an ActionBinding for the action for the match of the service binding to succeed.
If the other CPP does provide an ActionBinding for that action that does not specify its use to be optional, then the two ActionBindings MUST match for the ServiceBinding to match.
If the other CPP does provide an ActionBinding for that action that specifies its use to be optional, then the two ActionBindings are not REQUIRED to match. If there is a match, the result of the match MUST be included in the resulting ServiceBinding.
Absence of this attribute in a CPP is equivalent to it being present with value required, i.e. by default specified actions are required within the scope of a service binding.
A PayloadProfileId identifies a payload profile that MAY be used in the exchange of message for an ActionBinding.
In a CPP, multiple occurrences of PayloadProfileId MAY be specified in an ActionBinding. A sequence of two or more PayloadProfileId elements expresses alternative payload profiles which the party is willing to use for the ActionBinding. The semantics of the order corresponds to a preference. If PayloadProfileId X preceeds PayloadProfileId Y within the scope of an ActionBinding, then the Party prefers use of X over Y for the specified action.
In a CPA, at most one PayloadProfileId MUST be present. It identifies the payload profile that Party and CounterParty agree to bind the specified action to.
A ChannelId identifies a channel that MAY be used to exchange a message in the context of a CPPA3 document.
In a CPP, multiple occurrences of ChannelId MAY be specified in an ActionBinding. A sequence of two or more ChannelId elements expresses alternative channels which the party is willing to use for the message exchange. The semantics of the order corresponds to a preference. If ChannelId X preceeds ChannelId Y within the scope of an ActionBinding, then the Party prefers use of X over Y for the specified action.
In a CPA, exactly one ChannelId MUST be present in an ActionBinding. It identifies the channel that Party and CounterParty agree to bind the specified action to.
A CPPA3 Channel configures the use of a messaging protocol for the exchange of user messages and/or signal messages. A channel can be bound to particular business actions in service collaborations between parties. A channel MAY be a point-to-point channel or end-to-end, for messaging protocols that support the concept, like ebMS3 using the multihop advanced feature [EBMS3PART2]. This element is an abstract element. It is substituted by elements representing specific messaging protocols defined in this schema or in extensions of this schema.
A channel MAY relate to other channels. For example, the channel for ebMS3 user messages MAY specify the use of another channel for the exchange of errors related to that user message.
A channel MAY be associated with a particular transport using the transport attribute.
A channel MAY set the asResponse attribute to categorize a channel as a forward channel or as a backchannel. A forward channel is initiated by the sender. A backchannel is a channel that is associated with some other channel that may not be initiated by the sender and that allows communication in the reverse direction. The following list describes some common situations:
The transport and asResponse attributes are both absent in situations such as:
These situations are described more precisely in the documentation of non-abstract substitution elements.
Compared to CPPA2, in which the corresponding element was called DeliveryChannel, the CPPA3 Channel element combines the Sender and Receiver Protocol Bindings, which in CPPA2 were contained in the DocumentExchange element. As this element has no other children, CPPA3 uses the substitutions for Protocol Binding directly to simplify and flatten the structure of the CPP and CPA elements. The Transport is referenced from the Channel directly.
This is an abstract type covering channel bindings to message protocols.
The MaxSize Specifies the maximum size of the payloads of message using a particular protocol binding.
When used with ebMS3, the MaxSize element maps to PMode[1].BusinessInfo.PayloadProfile.maxSize. In CPPA3 it is specified at Channel level rather than at PayloadProfile level, because the size limits can be protocol-specific.
The transport attribute references a Transport to be used by the Channel. This attribute MUST NOT be present if asResponse is set to false. Otherwise, requirements for presence or absence of this attribute depend on specific channel bindings.
Specifies if the channel is to use the backchannel of an underlying transport set up by another channel. This feature is specified further for subtypes of the channel element.
The package attribute references a Package for a Channel.
This attribute MUST NOT be used for channels used for protocol message types that have a fixed and predictable format, such as receipts and erors.
This element identifies a particular profile of the messaging protocol. For example, the AS4 ebHandler Conformance Profile of ebMS3 is identified using the URI http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/cprofiles/200809/as4ebhandler.
In some communities using ebMS3, different profiles are used and selected using the AgreementRef header field and PMode.Agreement parameter. A potential use of ChannelProfile is to set this value.
The ChannelFeature element defines a reusable specification of a feature or aspect of a channel. It is to be instantiated to specific features such as security or reliable messaging. Channel features MAY be specific to specific types of Channels.
This is an abstract type covering channel features.
The Named Channel provides a Channel identified using a Named Channel and supplies any named Parameters. Specific named channels MAY associate with or require specific parameters. The CPPA3 schema does not constrain specific parameters and/or values. The Named Channel option assumes parties infer the protocol to be used and all or most configuration parameters for that protocol from a specified and mutually understood name. The type definition includes Signing and Encryption certification references, which are inherently partner specific. Other parameters can be specified using Param elements. NamedChannels MAY be interpreted (and hence used) in one of two ways:
This element defines an abstract EDIINT message channel. The element definition generalizes over the three EDIINT Application Statements for SMTP (AS1), HTTP (AS2) and FTP (AS3) [RFC3335, RFC4130, RFC4823]. Whether an EDIINT message is to be sent using AS1, AS2 or AS3 is selected by the choice of an AS1Channel, AS2Channel or AS3Channel element. This choice instructs the messaging application using the CPPA3 document to apply the applicable Applicability Statement.
The Signature element indicates that the EDIINT data is wrapped in a multipart/signed MIME structure.
The Encryption element indicates that the EDIINT data is wrapped in a multipart/encrypted MIME structure.
For EDIINT, the ReceiptHandling element configures the processing of EDIINT Message Disposition Notifications (MDNs). The configuration of receipt processing with EDIINT is specified in the documentation of the ReceiptHandling element.
This channel type definition generalizes over configurations of channels using EDIINT AS1, AS2 and AS3 [RFC3335, RFC4130, RFC4823].
For AS2 or AS3, the version of the protocol used. Version number 1.1 indicates support for the [RFC5402] compression feature. Version number 1.2 indicates support for the [RFC6017] features feature.
This element configures a channel using EDIINT AS1 [RFC3335].
As with any EDIINT channel, ReceiptHandling configures the processing of Message Disposition Notifications.
An AS1Channel MUST be bound to an SMTPTransport transport.
This element configures a channel using EDIINT AS2 [RFC4130].
When using an AS2 channel, the AS2-From and AS2-To headers MUST be set to a Party/CounterParty PartyId element content.
An AS2Channel carrying business data MUST be bound to an HTTPTransport transport.
An AS2Channel carrying an MDN MUST
As with any EDIINT channel, ReceiptHandling configures the processing of Message Disposition Notifications.
This element configures a channel using EDIINT AS3 [RFC4823].
When using an AS3 channel, the AS3-From and AS3-To headers MUST be set to a Party/CounterParty PartyId element content.
An AS3Channel MUST be bound to an FTPTransport transport.
This element configures a channel using Web Services. A Web Service Channel is a channel that uses SOAP 1.1 or SOAP 1.2 messaging.
A type definition of a Web Services channel.
If multiple security binding elements are present, these MUST target different SOAP actors or roles.
SOAPVersion is optional in situations where a ChannelProfile is specified that fixes the version to use. This is the case, for example, in AS4 conformance profiles.
The version of SOAP to be used for messaging.
In ebMS3, this corresponds to the PMode[].Protocol.SOAPVersion parameter
If the element is not present in the containing WSChannel element (or element that inherits from this element), it MUST be specified indirectly, via the definition of a ChannelProfile.
This element specifies the handling of faults.
Note that there are no PMode parameters defined in ebMS3 to configure fault handling.
This element is a cross-reference to the definition a of channel to be used to exchange SOAP Faults.
If WS-Addressing is used, the Endpoint of the referenced channel MUST be used for the wsa:FaultTo header.
This element indicates that the message is compressed using message layer compression. For EDIINT, when using encryption, the entire message is compressed. For AS4, compression applies to the MIME parts in the SOAP-with-attachments envelope.
This element configures the compression algorithm used. Its value identifies the compression algorithm or compressed data format that the sending MSH applies to ebmessage.
This element specifies, using a URI, a compression dictionary that parties can agree to use. This element MUST NOT be used in combination with compression algorithms that do not support the use of pre-agreed compression dictionaries.
This element defines the use of WS-Security.
If the SecurityPolicy element is present or referenced, it establishes the default security policy to be used, which can be overridden using the Signature, Encryption or UserAuthentication elements.
This element specifies the version of WS-Security to be used. In ebMS3, this corresponds to the PMode[1].Security.WSSVersion parameter
The value 1.1 also covers the 1.1.1 version, as that version is a maintenance update that does not provide additional or different functionality.
If the element is not present in the containing WSSecurityBinding element, it MUST be specified indirectly, via the definition of a ChannelProfile.
This element can be used to associate a security policy with the message exchange. The policy may be embedded in the CPPA3 document, or it may be referenced.
The Signature element configures message signing. The CPPA3 Signature element is modelled after the W3C XML Signature structure [XMLDSIG-CORE, XMLDSIG-CORE1] but is also used to configure EDIINT.
In ebMS3, this type corresponds to the PMode[1].Security.X509.* parameters.
In a CPP, SignatureAlgorithm, DigestAlgorithm and CanonicalizationMethod MAY occur more than once, expressing alternative options. In a CPA, they MUST occur at most once, expressing the agreed option.
For EDIINT protocols, the SignElements, SignAttachments, SignExternalPayloads and SAMLTokenRef elements MUST NOT be used.
If the SignatureAlgorithm and DigestAlgorithm elements are not present, they MUST be specified indirectly, via the definition of a ChannelProfile.
If one or more SigningCertificatePolicySetRef elements is present, Policy Certification Authority certificates and the issuing Certificate Authority certificate in the signing certificate chain MUST contain a certificatePolicies X.509 extension, the values of which MUST be within the set of referenced policies.
This element identifiers a format to be used for signatures. It MUST NOT be used in contexts where only a single signature format is used, or where it is not possible to select a specific format, or where it is not common to specify the format.
For EDIINT, a common value is pkcs7-signature.
The version number of the signature format.
This element defines the signature algorithm to be used for generating and validating the signature.
In ebMS3, this corresponds to the PMode[1].Security.X509.Signature.Algorithm parameter.
DigestAlgorithm is a REQUIRED element that identifies the digest algorithm to be applied to the signed object.
In ebMS3, this corresponds to the PMode[1].Security.X509.Signature.HashFunction parameter.
AS2 (RFC 4130) can use the values MD5 (defined in [RFC6931] as http://www.w3.org/2001/04/xmldsig-more#md5) or SHA-1 (defined in [XMLDSIG-CORE] as http://www.w3.org/2000/09/xmldsig#sha1. AS2 implementations also implement more recent algorithms.
The Canonicalization method to be applied in the creation of the signature.
This element does not correspond to any ebMS3 PMode parameter.
The Signature Transformation method to be applied in the creation of the signature.
This element does not correspond to any ebMS3 PMode parameter.
A reference to the leaf certificate that is to be used to sign the data.
In ebMS3, this corresponds to the PMode[1].Security.X509.Signature.Certificate parameter.
Requirements on presence or absence of this element in a CPP or CPA and use in CPA formation can be configured using the SigningCertificateRequired element.
In a CPP, this element can be used in a NamedChannel or Signature element by a receiving party to indicate whether a leaf signing certificate is to be provided by the sending (i.e. signing) party in the corresponding element in its CPP. If present with a true value in a CPP context for a receiver channel, a valid SigningCertificateRef element MUST be present in the CPP of the sending party for the channel. This referenced certificate MUST be included for specified signed CPA channel in a CPA derived from these CPPs for the channel.
This element MUST NOT be used in a CPA. If specified in a CPP for the sending (signing) party for the channel, its value is ignored in unification.
Specifies how the signing certificate is referenced in the WS-Security header
This elements specifies, as a sequence of Expression elements, the elements in the message that MUST be signed.
This element MUST NOT be present in a SignatureType content that is not SOAP or another XML-based message format. Furthermore, it MUST NOT be present in protocols or profiles that do not support configuration of elements that are to be signed. This is the case with AS4, which always signs a known set of SOAP parts, if the message is signed.
In ebMS3, this corresponds to the PMode[1].Security.X509.Sign.Element parameter.
This Boolean-valued element specifies if attachments are to be signed.
This element MUST NOT be present in message formats that do not support attachments or signing of attachments. Furthermore, it MUST NOT be present in protocols or profiles that do not support configuration of attachment signing. This is the case with AS4, which always signs all attachments if the message is signed.
In ebMS3, this corresponds to the PMode[1].Security.X509.Sign.Attachment parameter.
This element specifies if external payloads are to be signed.
This element MUST NOT be present in message formats that do not support external payloads or signing of external payloads.
There is no corresponding ebMS3 PMode parameter for this element.
A reference to a trust anchor that a signing certificate MUST chain to.
The Encryption element configures message encryption. The CPPA3 Encryption element is modelled after the W3C XML Encryption [XMLENC-CORE, XMLENC-CORE1] structure but is also used to configure encryption for channels that do not use XML Encryption.
In ebMS3, this structure corresponds to the PMode[1].Security.X509.Encryption.* parameters.
If one or more EncryptionCertificatePolicySetRef elements is present, Policy Certification Authority certificates and the issuing Certificate Authority certificate in the encryption certificate chain MUST contain a certificatePolicies X.509 extension, the values of which MUST be within the set of referenced policies.
The KeyTransport element supports the configuration of encryption key transport. It is designed to configure use of XML Encryption Key Transport and similar protocols.
This element specifies the use of a mask generation function.
The value is an identifier of a mask generation function like http://www.w3.org/2009/xmlenc11#mgf1sha256.
When using XML encryption, it specifies the value of xenc:EncryptedKey / xenc:EncryptionMethod / xenc11:MGF.
The element MUST NOT be used with protocols that have a fixed data format for encrypted content, such as WS-Security.
This element corresponds to the CPPA2 DigitalEnvelope element. When used with ebMS2, it can be used to select the digital envelope format to be used with the use of that protocol. The use of S/MIME is selected the value S/MIME. For S/MIME, the current version in 3.2, defined in [RFC5751]. Other versions MAY be selected using the version attribute. XML Encryption is selected used the value http://www.w3.org/2001/04/xmlenc#.
The version number of the encryption format.
This element can be used to specify the key transport algorithm and the data encryption algorithm.
Key Transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys. When using XML Encryption the value of this element can be used as value in KeyEncryption to determine xenc:EncryptedKey / xenc:EncryptionMethod / @Algorithm. The value is an identifier of an encryption algorithm like http://www.w3.org/2009/xmlenc11#rsa-oaep.
In ebMS3, see https://issues.oasis-open.org/browse/EBXMLMSG-45.
When using XML Encryption, the EncryptionAlgorithm element can also be used in DataEncryption to set the value of the xenc:EncryptedData / xenc:EncryptionMethod / @Algorithm attribute. The value is an identifier like http://www.w3.org/2009/xmlenc11#aes128-gcm
In ebMS3, this corresponds to the PMode[1].Security.X509.Encryption.Algorithm parameter.
This element expresses elements that MUST be encrypted.
This element MUST NOT be present in a DataEncryption element that is not SOAP or another XML-based message format. Furthermore, it MUST NOT be present in protocols or profiles that do not support configuration of elements that are to be signed. This is the case with AS4, which always signs a known set of SOAP parts if the message is signed.
In ebMS3, this corresponds to the PMode[1].Security.X509.Encrypt.Element parameter.
The element expresses whether or not attachments are encrypted.
This element MUST NOT be present in message formats that do not support attachments or encryption of attachments. Furthermore, it MUST NOT be present in protocols or profiles that do not support configuration of attachment encryption. This is the case with AS4, which always signs all attachments if the message is signed.
In ebMS3, this corresponds to the PMode[1].Security.X509.Encrypt.Attachment parameter.
The element expresses whether or not external payloads are encrypted.
This element MUST NOT be present in message formats that do not support external payloads or encryption of attachments. Furthermore, it MUST NOT be present in protocols or profiles that do not support configuration of external payload encryption. This is the case with AS4, which always encrypts all attachments if the message is signed.
There is no corresponding PMode parameter for this element.
For signing and encryption algorithms, the value of an element of type AlgorithmType MUST be an algorithm identifier defined in XML Signature [XMLDSIGCORE, XMLDSIGCORE1], XML Encryption [XMLENC-CORE, XMLENC-CORE1] or in RFC 6931.
Note that these algorithm identifier URIs specify the key size, e.g. http://www.w3.org/2009/xmlenc11#aes128-gcm and http://www.w3.org/2009/xmlenc11#aes256-gcm specify 128 and 256 bit sizes, respectively. Therefore this element also covers the CPPA2 minimumStrength attribute and the ebMS3 PMode[1].Security.X509.Encryption.MinimumStrength P-Mode parameter.
This element references a leaf certificate that is to be used for encryption.
With ebMS3, this element corresponds with the PMode[1].Security.X509.Encryption.Certificate parameter.
Requirements on presence or absence of this element in a CPP or CPA and use in CPA formation can be configured using the EncryptionCertificateRequired element.
In a CPP, this element can be used in a NamedChannel or Encryption element by a sending party to indicate whether a leaf encryption certificate is to be provided by the receiving (i.e. decrypting) party in the corresponding element in its CPP. If present with a true value in a CPP context for a receiver channel, or if the element is absent, a valid EncryptionCertificateRef element MUST be present in the CPP of the receiving party for the channel. This referenced certificate MUST be included for specified encrypted CPA channel in a CPA derived from these CPPs for the channel.
This element MUST NOT be used in a CPA. If specified in a CPP for the receiving (decrypting) party for the channel, its value is ignored in unification.
This element specifies how the encryption certificate is referenced in the WS-Security header
A reference to a trust anchor set that an encryption certificate MUST chain to.
This element is an abstract Security Assertion Markup Language (SAML) configuration element that controls the presence and processing of a SAML token in the WS-Security header. Details on use of SAML are to be provided by substitution elements. Support for the Security Assertion Markup Language (SAML) is in this version of CPPA limited to providing support for the ebMS3 SAML conformance clause [ebMS-saml-conformance].
A reference to a SAML token.
When used with ebMS3, this element defines support for the ebMS3 SAML conformance clause [ebMS-saml-conformance], which provides ebMS3 with an alternative way of obtaining and referencing a signing key. The SAML conformance clause is based on use of signed holder-of-key subject confirmations using either symmetric or asymmetric keys and to obtain attributes. The ebMS3 SAML conformance clause is designed to obviate the need for agreements such as CPA and of CPA formation. Parties MAY use partner CPP s directly to dynamically configure ebMS3 messaging. This element and its sub-elements correspond to the a superset of PMode[1].Security.SAML parameters defined in the ebMS3 SAML Conformance clause.
The mandatory IDPRegistrationSetRef element references a set of identity service providers that the party MUST register with. It corresponds to the PMode[1].Security.SAML.RegisteredIdPs parameter and can be used in both CPPs and CPAs.
In CPA formation, it MUST be verified that the intersection of IDP sets of Sender and Receiver is non-empty, as both Sender and Receiver MUST register with the same IDP. This IDP authenticates Sender and (if symmetric proof keys are used) encrypts the proof key for Receiver. The first matching shared IDP MAY be referenced in the formed CPA using the ProviderID element. However, this is only a hint as the Sender MAY use any shared IDP acceptable to Receiver. The ProviderID element MUST NOT be used in a CPP.
Optionally, Sender MAY reference a particular signing certificate for use as asymmetric proof key using the SigningCertificateRef element. This reference MAY be used by Sender to select the assymmetric key to include in the WS-Trust (or equivalent) request to the secure token service. Note that the purpose of the SAML conformance clause is to obviate the need for certificate exchange, so Receiver is NOT REQUIRED to validate this on incoming messages. This is a feature in CPPA3 that does not correspond to a parameter in the ebMS3 SAML conformance clause P-Mode. The SigningCertificateRef element MUST NOT be present when symmetric proof keys are used.
This element specifies the version of SAML that MUST be used for SAML Authentication.
In the ebMS3 SAML Conformance Clause, this corresponds to the PMode[].Security.SAML.Version parameter.
The values correspond to /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11 and /sp:SamlToken/wsp:Policy/sp:WssSamlV20Token in WS-SecurityPolicy [WSSecurityPolicy13].
The element specifies the type of the SAML proof key. The ebMS3 SAML Conformance Clause supports symmetric and asymmetric key types.
This element specifies the use of a SAML Attribute assertion in a SAML token.
This element, which can occur multiple times in the SAMLKeyConfirmedSubject element, corresponds to the PMode[1].Security.SAML.MandatoryAttributes PMode[1].Security.SAML.OptionalAttributes parameters. Whether an attribute is mandatory or optional is specified using the mandatory use attribute.
When used in a WS-Security header used to secure an ebMS3 PullRequest and targeted to the ebms role, occurrences of this element correspond to the PMode[1].Initiator.Authorization.SAML.AttributesAndValues parameter. In that case, the required values MUST be specified as content of the AttributeValue child element.
Apart from the use attribute, the definition of SAMLAttribute copies the element and attribute content definitions of the SAML 2.0 Core schema.
The set of mandatory attributes corresponds to /sp:SamlToken/wst:Claims in WS-SecurityPolicy [WSSecurityPolicy13].
This element configures user authentication. It can configure UsernameToken security in WS-Security or HTTP Authentication.
When used with ebMS3 for WS-Security, this element covers the PMode[1].Security.UsernameToken.username PMode[1].Security.UsernameToken.password PMode[1].Security.UsernameToken.Digest PMode[1].Security.UsernameToken.Nonce and PMode[1].Security.UsernameToken.Created parameters, when applied to the regular WS-Security header.
When used with ebMS3, this element also covers the combination of PMode[1].Security.PModeAuthorize and PMode.{Initiator/Responder).Authorization.* parameters that apply to the WS-Security header that is used for message authorization.
When used with the HTTP protocol, this element configures HTTP Authentication.
The Username and Password elements MUST NOT be set in a CPP but MUST be set in a CPA.
Type Definition for User Authentication.
A Username that MUST be used with UserAuthentication.
A Password that MUST be used with UserAuthentication. In CPA formation, the value of this element MUST be set to a sufficiently strong and unpredictable value.
This element expresses whether the UserAuthentication uses Digest Authentication. The algorithm used for digest generation depends on the context in which UserAuthentication is used. In HTTP, it is MD5 and in WS-Security, it is SHA1.
This element expresses whether a Nonce MUST or MUST NOT be included with a UserAuthentication.
Expresses whether a Created MUST or MUST NOT be included with a UserAuthentication.
The abstract element ReliableMessagingBinding specifies a binding of a channel to a reliable messaging protocol.
This element is a channel feature, so its instances can be reused by reference in multiple channel definitions.
The ReliableMessagingBindingType type is defined as an abstract type with no elements or attributes. It is an abstract type that can be specialized, in extensions of this schema, for reliable messaging protocols such as WS-ReliableMessaging and WS-Reliability. This schema includes support for AS4, and then configures duplicate handling, persistence and retransmission handling for AS4 messages.
The DuplicateHandling element specifies a feature used by various reliable messaging protocols. It specifies how received duplicates are to be detected and/or processed.
The type definition provides common parameters for duplicate handling. The logic for determining whether a message is a duplicate depends on the messaging protocol. Any ##other content may convey additional configuration parameters for duplicate handling.
When used with WSReliableMessagingBinding, this element corresponds to the PMode[1].Reliability.AtMostOnce.Contract parameter.
When used with AS4 reception awareness, this element corresponds to PMode[1].ReceptionAwareness.DuplicateDetection PMode[1].ReceptionAwareness.DetectDuplicates.Parameters
The DuplicateElimination element specifies if a receiving MSH MUST eliminate any received duplicates, if detected, thus implementing at most once delivery assurance.
The value of the PersistDuration element is the minimum length of time, expressed as an XML Schema duration, that data from a message that is sent reliably is kept in Persistent Storage by message service implementation that receives that message to facilitate the elimination of duplicates.
The RetryHandlingBase element specifies the handling of retransmission of messages until successful processing of the message by the recipient is confirmed, the number of retransmissions is exhausted or an unrecovereable error occurs. This mechanism supports at least once delivery assurance. This element is an abstract element, to support extensibility to other features for handling retries.
When used with AS4 reception awareness, this element corresponds to the PMode[1].ReceptionAwareness.Retry PMode[1].ReceptionAwareness.Retry.Parameters
This element defines a basic set of configuration elements.
If ExponentialBackoff is present, the element RetryInterval MUST occur at most once.
If ExponentialBackoff is not present, retryvalue is the value of Retries element, and retryintervalcount is the number of occurrences of the element RetryInterval, then retryintervalcount MUST NOT exceed retryvalue. If retryintervalcount is less than retryvalue, this is equivalant to up to retryvalue additional RetryInterval elements being present, with the same value as the last specified value for RetryInterval.
Any randomized adjustment of the timing of retransmissions (for example, to smooth out congestions) is implementation-dependent and not explicitly configured.
The duration between a transmission attempt and the next one.
Presence of this element specifies that the RetryInterval MUST be adjusted according to the exponential backoff algorithm.
The value of Ceiling MUST be less than Retries.
The maximum length of a retry interval. Once the retry interval has been incremented to a value equal to or higher than the ceiling, further increments MUST NOT be applied.
This element configures a channel using the ebXML Messaging version 2.0 protocol [ebMS2].
The ebMS2 Channel Type is a subtype of the Channel Type.
A Channel that is an ebMS2Channel MUST NOT be linked to a Transport element:
Presence of this element specifies the use of the ebMS version 2.0 Reliable Messaging protocol [ebMS2] for messages exchanged using this channel.
The actor attribute specifies the target of the ebMS2 AckRequested element.
This attribute specifies if the ebMS2 MessageOrder module is to be used.
Specifies the use of the ebMS2 security module.
This element configures a channel using the ebMS3 messaging protocol [EBMS3CORE,EBMS3PART2, AS4-Profile, ebMS-saml-conformance]. Both user messages and signal messages use ebMS3 channels. When bound to HTTP or another protocol that supports bidirectional communication, an ebMS3 channel MAY either use the forward channel (from the initiator to the responder) or the backchannel (which flows in the reverse direction).
The ebMS3 Channel Type is a subtype of the Web Service Channel Binding Type.
Use of an ebMS3Channel that is linked to a Transport obliges the user of the channel to initiate that Transport. The transport binding is referenced using the transport attribute.
An ebMS3Channel MUST NOT be linked to a Transport element in the following cases:
For these cases, the value of the ebMS3 PMode.MEPbinding parameter can therefore be derived from the presence or absence of the PullHandling element and the asResponse attribute..
Note that the list is non-exhaustive, because extensions of ebMS3 or CPPA3 may define additional cases.
The mpc attribute corresponds to the ebMS3 Core PMode[1].BusinessInfo.MPC parameter. Its absence is equivalent to presence with the value http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC.
Whereas MPC is a BusinessInfo parameter in ebMS3, it is defined at the channel level in CPPA. This allows alternative channels to specify alternative MPCs.
The mpc attribute MUST only be used by channels used by UserMessages.
The ErrorHandling element specifies how errors are handled for the exchange.
CPPA2 used the defaultMshChannelId attribute on PartyInfo to express the channel to use for asynchronous signals, such as errors. As a consequence, in CPPA2, either all errors are signed or none of them is. In CPPA3, the channel is referenced from the SenderErrorsReportChannelId and/or ReceiverErrorsReportChannelId elements. As a consequence, in CPPA3 whether errors are to be signed can be specified for each (synchronous or asynchronous) channel separately.
CPPA2 did not specify if synchronous errors are signed or not. In CPPA3, this can be specified for the referenced channel.
With ebMS2, ebMS3 and AS4, a reference to a signed channel expresses a recommendation on the MSH to sign messages using the specified channel. This is a best effort obligation, as it is not possible or desirable in all circumstances (for example, in case of errors) to sign the message.
The ebMS3 and AS4 specifications do not specify if errors are signed or not, and do not provide PMode parameters to control signing. With CPPA3, this can be configured.
Absence of the DeliveryFailuresNotifyProducer, ProcessErrorNotifyConsumer and ProcessErrorNotifyProducerelements is equivalent to being present with a value false.
CPPA3 does not provide a separate element for the PMode[1].ErrorHandling.Report.MissingReceiptNotifyProducer PMode parameter, as defined in the AS4 specification for its reception awareness feature [AS4-Profile]. If reception awareness is used with AS4, this parameter is assumed to be present with a true (or false, respectively) value if the CPPA3 the ProcessErrorNotifyProducer element is present with a true value (or true, respectively). Situations where one is true and the other false are not not supported [EBXMLMSG110].
This element corresponds to the ebMS3 PMode[1].ErrorHandling.Report.ProcessErrorNotifyConsumer parameter. Its definition is provided in the ebMS3 Core Specification. Absence of the element is equivalent to presence with a false value.
This element corresponds to the ebMS3 PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer parameter. Its definition is provided in the ebMS3 Core Specification. Absence of the element is equivalent to presence with a false value.
This element corresponds to the ebMS3 PMode[1].ErrorHandling.Report.ProcessErrorNotifyProducer parameter. Its definition is provided in the ebMS3 Core Specification. Absence of the element is equivalent to presence with a false value.
The ebMS3 PMode[1].ErrorHandling.Report.SenderErrorsTo parameter identifies the address to which to send ebMS errors generated by the MSH that was trying to send the message in error. In CPPA3, the SenderErrorsReportChannelId identifies this channel, which can be configured as any channel. To avoid errors-on-errors, the identified channel MUST NOT itself have ErrorHandling specified.
The ebMS3 PMode[1].ErrorHandling.Report.ReceiverErrorsTo parameter identifies the address 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. In CPPA3, the ReceiverErrorsReportChannelId identifies this channel, which can be configured as any channel. To avoid errors-on-errors, the identified channel MUST NOT itself have ErrorHandling specified.
The functionality of the ebMS3 PMode[1].ErrorHandling.Report.AsResponse is expressed by the presence of an asResponse attribute with value true and absence of a specified Transport for the referenced channel
For use with the multihop feature defined in [EBMS3PART3], the use of WS-Addressing as specified in the Pmode[1].Errorhandling.Report.SenderErrorsTo.Addressing parameter and its sub-parameters is specified with the referenced channel. Similarly, to specify, for the parameter Pmode[1].ErrorHandling.Report.ReceiverErrors.ReplyPattern, the value “pull” defined in section 6.5 of [EBMS3PART2], the referenced channel can specify a PullHandling element.
Presence of the ReceiptHandling element indicates that message receipts must be reported by a Receipt signal. Absence of the element indicates that no Receipt is to be transmitted.
For protocols like ebMS2 and EDIINT the sender is expected to indicate in the message whether or not a receipt is requested. The presence or absence of this element SHOULD be set in accordance with presence or absence of ReceiptHandling.
When used with EDIINT, the type of receipt (signed or unsigned) and the channel (synchronous or asynchronous) to be used can be requested by the sending MSH. In a CPA, the ReceiptHandling element expresses an agreement behaviour using the definition of the referenced ReceiptChannelId.
The ReceiptHandling element has two sub-elements:
For EDIINT, the ReceiptHandling element configures the processing of EDIINT Message Disposition Notifications (MDNs). In a CPP ReceiptHandling configures the receipt processing that a Party expects. In a CPA, it configures the receipt processing that a Party and its CounterParty have agreed to. If a ReceiptHandling element is present, an MDN SHOULD be requested. In EDIINT, such a request is made using the MDN-request-header Disposition-notification-to. If a ReceiptHandling element is not present, an MDN SHOULD NOT be requested and the MDN-request-header SHOULD NOT be present.
In CPPA3, the receipt channel identified using the ReceiptChannelId element in ReceiptHandling element in an EDIINT channel is the channel over which receipts are exchanged. For EDIINT, the identified channel MUST be of a subtype of EDIINTChannel. Note that AS2 allows MDNs to be returned using SMTP. In that case, the referring EDIINTChannel is an AS2Channel that includes ReceiptChannelId that actually identifies an AS2Channel bound to an SMTP transport.
In CPPA3, synchronous or asynchronous processing of EDIINT receipts is expressed by the asResponse and transport attributes.
AS1 only supports asynchronous MDNs. The Receiver is expected to return the MDN to the address specified in the Disposition-notification-to header on the message for which a receipt is requested. In CPPA3, the asResponse attribute on the referenced ReceiptChannelId MUST be absent or present with a false value. The transport attribute is REQUIRED and MUST specify an SMTP transport. Its value is the address the MDN is sent to.
AS2 supports synchronous and asynchronous MDNs:
AS3 only supports asynchronous MDNs.
For signed messages, AS2 and AS3 specify that the algorithm used to calculate the MIC MUST be the same as that used on the message that was signed. In CPPA3, this is a constraint on the SignatureAlgorithm element in Signature on the referenced ReceiptChannelId. If the message is not signed, then AS2 and AS3 specify that the SHA-1 algorithm SHOULD be used.
In EDIINT, a signed MDN can be requested by setting the signed-receipt-protocol and signed-receipt-micalg headers. If signing of EDIINT MDNs is expected to be requested, in CPPA3:
Note that in EDIINT, MDNs can be requested per message and the configuration can be set per message. This means that EDIINT software MAY override the CPPA3 configuration at runtime. In case an MDN is not requested by the sender but the Receiver is expecting a request, the expected behaviour is undefined in this specification.
In ebMS3 Core, receipt handling is considered part of the security processing mode parameters as it is closely linked to non-repudiation of receipt. CPPA3 defines receipt handling as a feature of the ebMS3Channel. This element provides the functionality of the ebMS3 PMode[1].Security.SendReceipt parameter.
The ReceiptFormat allows choice of the receipt format to be used for protocols like ebMS3 that support multiple receipt formats, which can be profiled in profiles such as AS4.
When used with AS4, the allowed values are NonRepudiationInformation for Non-Repudation of Receipt or UserMessage for Reception Awareness.
The ReceiptChannelId element references the channel over which a receipt is exchanged. As receipts themselves are not sent reliably, the referenced channel MUST NOT itself specify any ReceiptHandling.
The ebMS3 PMode[1].Security.SendReceipt.ReplyPattern parameter indicates whether the Receipt signal is to be sent as a callback (value "callback"), or synchronously in the back-channel response (value "response"). In CPPA3, this (and more) information is defined for the referenced channel. The referenced channel also specifies any Pmode[1].Security.SendReceipt.ReplyTo value. In [EBMS3PART2], an additional value pull is defined to allow pulling of receipts in a multihop context. This is achieved in CPPA3 by specifying a PullHandling element for the receipt channel.
When used with a Web Services Reliable Messaging protocol, the channel also covers the PMode[1].Reliability.AtLeastOnce.Contract.AcksTo, PMode[1].Reliability.AtLeastOnce.Contract.AckResponse and PMode[1].Reliability.AtLeastOnce.ReplyPattern parameters.
When used with EDIINT, if the referenced receipt channel is signed, the sending MSH MUST request a signed MDN. If the referenced receipt channel is not signed, the sending MSH MUST not request a signed MDN.
The ReceiptChannelId element replaces the functions of three CPPA2 elements and attributes:
This element configures the use of ebMS3 pulling to transfer user messages. It specifies the channel that the pull request MUST use.
Extension elements can be added to the content of this element to further configure pull handling. Such extensions could be product-specific or defined in profiles.
Note that the MPC to pull from is specified in the ebMS3Channel used by the (pulled) user message, not in the pull channel.
When using reliable messaging, the referenced channel MAY have its own specification on whether it uses reliable messaging. This means that the Pmode[1].Reliability.AtLeastOnce.Contract.ReliablePull parameter defined in [EBMS3PART2] is not needed, as the use of reliable messaging for the pull signal is specified independently of the use of reliable messaging for the user messages being pulled.
Similarly, the referenced channel MAY specify the use of WS-Addressing, thus covering the Pmode[1].Reliability.AtLeastOnce.Contract.AcksTo.Addressing and Pmode[1].Reliability.AtLeastOnce.Contract.AcksTo.Addressing.EPR parameters.
If the PullChannelId element is specified for a Channel associated with an action binding, the ebMS3Channel exchanges the ebMS3 message for this action using the Pull transport channel binding. The Pull request uses the referenced channel PullChannelId, which itself MUST have an associated Transport element. That channel provides an anonymous back-channel that this referring document exchange uses. The Channel for the action binding MUST NOT itself be linked to a Transport.
The referenced channel MUST be a channel of type ebMS3Channel. If the pull channel is to be authorized using a WS-Security header targeted to ebms actor or role (see ebMS3 Core, section 7.10), then the referenced channel MUST have a cppa3:WSSecurityBinding element with an ebms value for the attribute actorOrRole which has a UserAuthentication element. That element corresponds to the ebMS3 PMode.{Initiator/Reponder}Responder.Authorization.{username/password} parameters.
If the PullChannelId element is specified, then the asResponse attribute MUST NOT be specified with a value true and the transport attribute MUST be absent.
If the PullChannelId element is not specified for a Channel, and a transport attribute is specified, the message is exchanged using a Push transport channel binding. This Channel MUST be linked to a Transport that specifies the connection to be set up for the exchange.
The Addressing element supports presence and configuration of WS-Addressing headers in Web Services messaging.
The Endpoint element configures the wsa:To element.
The Address element configures the wsa:Action element.
The use of any of the sub-elements and the semantics of their presence or absence MAY be further specified in message protocols or profiles that use this element.
CPPA3 does not provide a separate FaultTo element to statically configure agreed fault channels. It can be specified using the Endpoint and reference parameter elements on a separate channel that is referenced using the FaultChannelId on a FaultHandling element on the channel.
CPPA3 does not provide a separate ReplyTo element to statically configure agreed response channels. In a Two Way message exchange, the ActionBinding for the response action has its own channel definition which can include its own WS-Addressing Endpoint and reference parameters.
The RelatesTo and MessageId elements are per-message elements and are not configured at the channel level.
This element allows a Channel to set the From header value in Web Services Addressing.
Note that message protocols or profiles MAY have conventions to derive the value of this header from other content in the CPPA3 document, such as the PartyId element. If that is the case, the element MUST NOT be used in the CPPA3 document.
This type definition defines a WS-Addressing EndpointReferenceType. In the CPPA3 schema it is only used for the From element as the FaultTo and ReplyTo endpoints are determined using the FaultHandling and ReceiptHandling elements.
No Metadata element is provided, as CPPA3 provides mechanisms to statically define behavior, policies and capabilities of the endpoint. This does not preclude Web Services-based message protocols or profiles described using CPPA3 to include dynamic metadata in SOAP messages.
The AbsReferenceParameter element is an abstract element that can be substituted by either a ReferenceParameter structure or by elements that describe how such parameters are to be constructed.
This element specifies a RoutingInput reference parameter as specified in the ebMS3 Part 2, Advanced Features specification, of which the content is derived from the content of a related ebMS3 UserMessage for use in multi-hop messaging. The specification distinguishes two situations:
Common to all inferred RoutingInput parameters is that:
This element specifies a string that MUST be appended to the value of the Action element in the user message from which the reference parameter is derived.
The value .pull is the value specified in the second of the last three bullets in section 2.6.1 of [EBMS3PART2].
The value .response is the value specified in the second bullet in the section 2.6.2 of [EBMS3PART2], item (4) section.
This element specifies a string that MUST be appended to the value of the mpc attribute in the user message from which the reference parameter is derived. The value .response is the value specified in the second bullet in the section 2.6.2 of [EBMS3PART2], item (4) section.
If no mpc attribute is present in the user message from which the reference parameter is derived, the reference parameter is to include an mpc attribute the value of which is the concatenation of the default MPC value http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC followed by the specified suffix.
This element enables support of a subset of the ebMS3 Part 2 Bundling feature, which allows multiple user messages to be transferred in a single ebMS3 message. In the Part 2 specification, Bundling is configured per P-Mode. Bundling of different types of messages is expressed as cross-references between P-Modes.
In this CPPA3 schema, Bundling is defined at the level of ebMS3 channels. If distinct actions are bound to a single ebMS3 channel with a Bundling element, then user messages for these actions MAY be bundled subject to the constraints specified in the element. This is similar to the Pmode[].bundling.compatibility.pmodelist parameter. However, it means that in CPPA3 bundling can only be defined for P-Modes that have the same values for the P-Mode parameters that are determined by the ebMS3Channel.
Presence of the Bundling element is equivalent to the Pmode[].bundling.policy with value optional.
Bundling can be configured using the following sub-elements:
This element configures the use of the ebMS3 Part 2 Split, Join, Compress Advanced Feature.
Presence of this element in an ebMS3Channel is equivalent to presence of the Pmode[].Splitting P-Mode parameter. The structure of the element reflects the P-Mode parameters defined for the feature:
The definition of the ebMS3Channel that contains the Splitting applies to fragment messages. The channel definition as it applies to the source (and hence target) message is configured using an ebMS3Channel referenced using the SourceChannelId element.
The JoinInterval encodes the Pmode[].Splitting.JoinInterval P-Mode parameter defined in [EBMS3PART2].
This element MAY be specified in a CPP for a Receiver transport. It SHOULD NOT be set for a Sender transport. In CPA formation, the value to be included in the CPA is the Receiver value, if present.
The SourceChannelId is a reference to a definition of the channel as it applies to the source message in case Splitting is used and the source message channel differs from the fragment channel.
This references an alternate channel that can be used by an MSH to make available messages that could not be exchanged using the channel that references it. Multiple occurrences of an AlternateChannelId express multiple alternative options.
This supports an advanced feature of ebMS3 Part 2, called Alternate MEP, which limits its use to offering a Pull-based access to response messages in a synchronous Two Way MEP that could not be delivered in time to be transmitted over the backchannel. That feature requires that at most one alternate channel is present.
The element configures the use of AS4 Reception Awareness.
The structure inherited from ReliableMessagingBinding provides structure to configure the parameters PMode[1].ReceptionAwareness, PMode[1].ReceptionAwareness.Retry, PMode[1].ReceptionAwareness.Retry.Parameters, PMode[1].ReceptionAwareness.DuplicateDetection and PMode[1].ReceptionAwareness.DetectDuplicates.Parameters.
The element configures the use of Web Services Reliable Messaging.
When used with WS-ReliableMessaging, the ReceiptHandling element MUST be included. When creating sequences, the wsa:AcksTo header value MUST be taken from the channel identified in the ReceiptChannelId element in ReceiptHandling.
This element corresponds to the PMode[1].Reliability.AtLeastOnce.Contract.AckOnDelivery parameter. This Boolean parameter indicates the semantics of acknowledgments that are generated by the reliability module. See section 8.2 of [EBMS3CORE] for specification.
This element corresponds to the PMode[1].Reliability.InOrder.Contract parameter. See section 8.2 of [EBMS3CORE] for specification.
This parameter is a Boolean that indicates if messages matching this P-Mode MUST be associated with a new reliability group or sequence. For example, a particular Service and Action may have the application semantics of initiating a new ordered sequence of messages.
PMode parameter PMode[1].Reliability.StartGroup.
This element maps to the ebMS3 PMode parameter PMode[1].Reliability.Correlationg.
In ebMS3 Core, the following definition is provided: This parameter tells how to correlate a message with an existing reliability group or sequence. It is a comma-separated list of XPath elements. Each one of these XPaths identifies an element or attribute inside an eb:UserMessage or eb:SignalMessage, and may include predicates.
The content is a list of XPath Expression element.
This parameter is a Boolean value that may be used to indicate if messages matching this P-Mode must cause the closure of the reliability group or sequence with which they correlate.
PMode parameter PMode[1].Reliability.TerminateGroup.
A TransportChannel represents a direct implementation of a Channel using a referenced Transport, i.e. there is no messaging protocol providing packaging or other features on top of the specified transport.
The TransportChannel is provided to support the following features:
A TransportChannel MUST NOT be linked to a Transport element using the transport attribute in case the channel uses a back-channel created by another channel. That other channel could be:
A RequestChannelId identifies a channel that does not serve to exchange any payload and is not bound to an action. It provides a backchannel to another channel that does carry any payload and is bound to an action.
The use of RequestChannelId is similar to the ebMS3 PullRequestId. The difference is that the PullRequestId also involves the use of an ebMS3 envelope containing a Pull signal, whereas a RequestChannelId only serves to specify the use of an transport channel request and involves no message protocol specific structures.
A TransportChannel that is used as a RequestChannelId for use in ebMS2 and ebMS3 MUST be bound to an HTTPTransport that is specified to use the HTTP GET method. This is different from all other current uses of channels for use with ebMS2, AS2, ebMS3 and AS4.
The Address URL that is used in the referenced transport MAY not be the complete URL. It may be that the external payload involves a href that adds a payload specific suffix.
An AMQPChannel configures a channel using the OASIS Advanced Message Queuing Protocol (AMQP) messaging protocol [amqp-core-messaging-v1.0] which uses the AMQP transport protocols [amqp-core-transport-v1.0]. In this CPPA3 schema, the AMQPChannel name is used for the element to indicat that the element is a member of the Channel substitution group, which in CPPA3 eis used for messaging protocols. In AMQP Transport, channels relate to a division of connections into a negotiated number of independent unidirectional channels [amqp-core-transport-v1.0]. This is a lower-level concept that is not to be confused with the CPPA3 concept of an AMQPChannel.
AMQP provides an Application Properties feature to allow routing or filtering of messages. This feature can be used to encode Property elements specified at ActionBinding level. Furthermore, usage profiles of AMQP for use with CPPA3 MAY use this feature to encode the CPPA3 Service and Action values in AMQP messages.
The OASIS AMQP Standard defines its own TCP-based transport protocol. A CPPA document that includes one or more AMQPChannel elements that use the AMQP transport protocol MUST include one or more AMQPTransport elements and reference them using the transport attribute value. Configuration of AMQP transport links bound to AMQP channels reflect the actions bound to the channel.
As any CPPA3 Channel, an AMQPChannel MAY specify a MaxSize. In AMQP link attachment, this value MUST be used as as value for the max-message-size parameter.
The type definition of an AMQPChannel supports configuration of some parameters used in AMQP performatives and setting the AMQP protocol version.
The AMQP protocol version supported by the container. If a party supports multiple AMQP protocol versions, its CPP can bind its actions to multiple distinct AMQPChannel elements that have different values for the version attribute, but that listen on the same TCP port. The actual version used is at run-time determined in AMQP version negotiation.
The DelegationChannel element supports the delegation of message processing by parties to third parties that act on their behalf. The element MAY be used in a CPP or CPA.
The legal meaning and implicationsof the use of messaging delegation are out of scope for this specification.
If a DelegationChannel is used in a CPP, that CPP is called the delegation source CPP. A DelegationChannel in a source CPP MUST specify a target a PartyId. It MAY also target a specific ProfileIdentifier that identifies a specific CPP for the Party identified using PartyId. The CPP for the target PartyId is the delegation target CPP. If a ProfileIdentifier is not explicitly specified in the source CPP, the reference target CPP MAY available as contextual information. Mechanisms for making that contextual information available to CPPA3 processing are out of scope for this specification. Note that any reference is unambiguous if there is only one known CPP for the target PartyId. Criteria for handling ambiguity, if there are multiple CPPs for the target PartyId, are out of scope for this specification.
If, in a source CPP for a Party P1, there is an ActionBinding that binds an Action in a ServiceBinding to a target CPP for a Party P3, then that target CPP MUST define an ActionBinding that has the same value for name and sendOrReceive in a ServiceBinding that has the same value for the Service element as the source Service. The values for any ebBP attributes in the source and CPPs MUST also match. The source CPP is invalid if these requirements is not met.
In a valid source CPP for a Party P1, a DelegationChannel element targeting a CPP for a Party P3 expresses that P3 MAY act as delegated Sender (if the value of the sendOrReceive attribute of the ActionBinding is send) or Receiver (if the value is receive) for the P1 action. Note that an ActionBinding in the target CPP MAY provide more than one alternative Channel for the action. The delegation feature decouples the channel binding for the target PartyId from the delegating Party.
As CPPA3 Channels are bound to individual actions in services using ActionBindings, Parties MAY use delegation channels for some communication but not for others. For example, a Party MAY outsource a specific Service to a particular service provider that operates its own messaging endpoint, distinct and separate from Party's endpoint. The Party MAY outsource other Services to other Parties and operate its own messaging endpoint for other communication.
In a CPA, a DelegationChannel MUST include a PartyId or a CounterPartyId element. A PartyId expresses a delegation from the Party identified in the PartyInfo element. If followed by a ProfileIdentifier element, this element identifies a CPP for the referenced PartyId. A CounterPartyId expresses a delegation from the Party identified in the CounterPartyInfo element. If followed by a ProfileIdentifier element, this element identifies a a CPP for the referenced CounterPartyId. A DelegationChannel in a CPA MAY include both a PartyId and a CounterPartyId element. This expresses delegations from both Parties in the CPA. Note that it is possible that both Parties delegate to the same third Party.
When using delegation, the delegated Party acts as Sender or Receiver for messages for the delegating Party using its own identifier. This is different from impersonation, where the third party uses the impersonated Party's identifier. The difference can be seen when used with protocols like ebMS2, ebMS3 and EDIINT:
If third Parties exchange messages on behalf of other Parties, the relation of those messages to the Parties on whose behalf the third party operate is to be encoded in different ways, e.g. at the payload content level (for example using the UN/CEFACT Standard Business Document Header [SBDH]) or (for protocols that support it, like ebMS3 and AS4), using message properties.
The CPPA3 delegation features supports authorization and routing:
A CounterPartyId element MAY be used in a DelegationChannel in a CPA. It identifies the third Party to which the Party identified in the CounterPartyInfo element delegates message processing.
An abstract element to configure a transport.
This is an abstract type that can be substituted to cover particular transport protocols.
An abstract element to represent transport protocols based on Transmission Control Protocol (TCP), such as HTTP, SMTP and FTP.
An abstract type to represent configuration information common to TCP-based transport protocols.
If the attribute supportsIPv4 is present with a false value, then the elements ClientIPv4 and ServerIPv4 MUST NOT be present.
If the attribute supportsIPv6 is present with a false value, then the elements ClientIPv6 and ServerIPv6 MUST NOT be present.
If the server supports IPv4, and DNS is used for endpoint resolution, then any domains named in the Endpoint element MUST be discoverable using DNS A records.
If the server supports IPv6, and DNS is used for endpoint resolution, then any domains named in the Endpoint element MUST be discoverable using DNS AAAA records.
This element specifies a transport using the Hypertext Transfer Protocol (HTTP) application protocol. It covers both HTTP 1.1 [RFC7230] and HTTP/2 [RFC7540].
Note that HTTP/2 enables using a single origin connection for any server. This means that exchanges using Channels that are bound to HTTP/2 transports SHOULD initiate new streamss on the existing HTTP/2 connection, if such an existing connection is available.
This element specificies if chunked Transfer Coding is used for the transport. Chunking is an HTTP 1.1 feature, specified in [RFC7230], section 4.1. It MUST NOT be used when configuring an HTTP 2.0 transport [RFC7540].
This element specifies a Content Coding that MAY be used for the transport.
The content of the element MUST be a valid Content Coding parameter, the values of which are specified in the IANA Content Coding Registry [IANA-HTTP].
This element specificies use of an HTTP 1.1 feature in which multiple requests using the transpors MAY be pipelined. The element MUST NOT be used with HTTP/2.
Absence of the element is equivalent to it being present with a false value.
Of the messaging protocols covered in this version of CPPA3, only [EBMS3PART2], sections 6.3.1 and 6.3.2, specifies a use of HTTP pipelining.
The SMTPTransport element defines a transport using the (SMTP) application protocol [RFC5321]. It can be used with e.g. ebMS2, ebMS3 (but not AS4) or for AS1.
Additional configuration elements for SMTP are the following:
When using SMTP, transport data is restricted to 7bit US-ASCII with lines no longer than 1000 characters including any trailing CRLF line separator, the encoding rules of section 6 of RFC 2045 apply, meaning application of appropriate content-transfer-encoding.
Transport using the File Transfer Protocol [RFC0959].
The method attribute MAY be set to either PUT or GET, correspondonding to sender-initiated or receiver-oriented transfer, respectively, and reflecting the FTP command to be used. Absence of the attribute is equivalent to presence with the value PUT.
When used with PUT transfer, the receiver party is expected to provide the server-related sub-elements. When used with GET, these elements are expected to be provided by the sender.
To specify use of TLS, users MUST provide a TransportLayerSecurity subelement. The reason is that no official IANA ftps scheme exists, unlike https which refers to TLS-secured HTTP. In practice, many networking software implementations understand the ftps URI scheme as referring to TLS-secured file transfer.
Transport using the SSH File Transfer Protocol (SFTP) subsystem of the Secure Shell (SSH) Connection Protocol [RFC4254]. As for the FTPTransport, the method attribute can be used to indicate the direction of transfer and the commands to be used.
This transport MUST not be used with a TransportLayerSecurity subelement, as SSH2 provides security natively.
To configure use of compression, a Compression element MUST be provided. The only algorithm currently supported in SSH2 is application/gzip.
To specify use of particular SSH public keys, a SSHClientKeyRef (for client authentication) or a SSHServerKeyRef (for server authentication) MUST be used.
An SSH cipher that MAY be used for the SSH connection using the notation used in the SSH specifications. For example, aes256-gcm@openssh.com.
Transport using the Web Socket Protocol [RFC6455]. Since Web Socket is a bidirectional protocol, either sender or receiver can provide the initial endpoint to be used to set up the Web Socket Transport between two parties. Note that Web Socket connections are persistent and can be reused for multiple transfers, in either direction.
To specify use of TLS, users MUST provide a TransportLayerSecurity subelement, and use the wss scheme in the endpoint address.
Transport using the native TCP transport mode defined in the AMQP Transport protocol [amqp-core-transport-v1.0].
In a CPP, if an ActionBinding binds an sending action in a service to an AMQPChannel that uses an AMQPTransport, then the AMQP transport is a potential AMQP link source for the party. If the binding is of a receiving action, then the channel is a potential AMQP link target for the party.
In a CPA, an ActionBinding that is bound to an AMQPChannel that uses an AMQPTransport configures a link to be used to exchange data using AMQP messaging from the sender party as link source to the receiver party as link target.
In AMQP, links are named so that they can be recovered when communication is interrupted. AMQP link names MUST uniquely identify the link amongst all links of the same direction between the two participating containers. It is RECOMMENDED to adopt a consistent naming convention for link names. As an AgreementIdentifier value is unique and shared between two parties, and the value of the id attribute of an ActionBinding element is unique within a CPA, it is RECOMMENDED to use the concatenation of these two values, using the # character as separator, to name the AMQP link.
In AMQP, links are attached to sessions, which begin on channels on connections.. Full specification of the details of the mapping of CPPA3 elements to these AMQP constructs is out of scope for this specification. However, it is RECOMMENDED that ActionBindings in a CPA that use the same AMQPChannel reuse a single AMQP session.
To specify use of TLS as a pure TLS tunnel through which the standard AMQP protocol flows, users MUST provide a TransportLayerSecurity subelement. This is called the alternative establishment in section 5.2.1 of [amqp-core-transport-v1.0].
In a CPP, one or multiple SenderSettleMode and one or ReceiverSettleMode elements MAY be present. These elements encode the sender or receiver settle modes that the AMQP transport MAY deploy. In a CPA, at most one of either type of elements MAY be present, reflecting the mode that the transport MUST deploy. Absence of any of the two elements means the default specified in [amqp-core-transport-v1.0] apply.
AMQP messaging is secured using Simple Authentication and Security Layer (SASL) mechanism [RFC4422]. AMQP clients and servers negotiate a security mechanism in the SASL handshake. CPPA3 allows parties to express and negotiate supported mechanisms. As with TLS, CPPA3 negotiation does not replace the protocol handshaking. Rather, it provides an ahead of time compatibility check.
If the sending peer does not require its partner to authenticate with it, then it SHOULD send a list of one element with its value as the SASL mechanism ANONYMOUS.
To specify the use of TLSs as an in-place upgrade, in which case the transition to TLS occurs after the AMQP protocol handshake, users MUST provide a TransportLayerSecurity subelement.
The max-frame-size parameter as defined in section 2.7.1 of [amqp-core-transport-v1.0] expresses a proposed maximum frame size
The channel-max parameter as defined in section 2.7.1 of [amqp-core-transport-v1.0] expresses the maximum channel number that can be used on the connection
The idle-time-out parameter as defined in section 2.7.1 of [amqp-core-transport-v1.0] expresses the maximum channel number that can be used on the connection
The ConnectionProperties element allows configuration of connection properties as defined in section 2.7.1 of [amqp-core-transport-v1.0].
The SessionProperties element allows configuration of connection properties as defined in section 2.7.2 of [amqp-core-transport-v1.0].
The LinkProperties element allows configuration of connection properties as defined in section 2.7.3 of [amqp-core-transport-v1.0].
This element defines an IP address (belonging to the IPv4 address family) or address range which the client MAY use for the transport.
An address range can be specified using common notations such as the * wildcard character, the - separator and the CIDR /n syntax to select the number of matching bits.
This element defines an IPv6 address literal or address range which the client MAY use for the transport.
An address range can be specified using common notations such as the * wildcard character, the - separator and the CIDR /n syntax to select the number of matching bits.
This element defines an IP address (belonging to the IPv4 address family) which the server MAY use for the transport. If present, when using IPv4 and DNS, an Internet name used in the Endpoint MUST be published as a DNS A record.
This element defines an IPv6 address literal which the server MAY use for the transport. If present, when using IPv6 and DNS, an Internet name used in the Endpoint MUST be published as a DNS AAAA record.
This element specifies a URI value that MUST be used as endpoint address.
In ebMS3, this corresponds to the PMode[1].Protocol.Address parameter.
This elements specifies use of configuration for Transport Layer Security. Note that, while some URI schemes like https already imply use of a TLS protocol, this is not the case for other schemes, such as ftp. Therefore, the element is REQUIRED in all situations where use of TLS is expected. Subelements of the element can be used to further configure how the TLS protocol is used.
If one or more ClientCertificatePolicySetRef elements is present, Policy Certification Authority certificates and the issuing Certificate Authority certificate in the client certificate chain MUST contain a certificatePolicies X.509 extension, the values of which MUST be within the set of referenced policies.
If one or more ServerCertificatePolicySetRef elements is present, Policy Certification Authority certificates and the issuing Certificate Authority certificate in the server certificate chain MUST contain a certificatePolicies X.509 extension, the values of which MUST be within the set of referenced policies.
This element can be used to indicate the ability to use an extension to use of plain text communication protocols, which offers a way to upgrade a plain text connection to an encrypted TLS connection instead of using a separate port for encrypted communication.
The element configures the protocol to be used for TransportLayerSecurity.
If not present, this element is to be interpreted as being present with the value TLS.
When used with secure Transport elements used for ebMS3Channel elements, this element corresponds to the Pmode[1].Protocol.Security.Protocol parameter defined in ebMS3 Part 2 and the attribute version corresponds to the Pmode[1].Protocol.Security.ProtocolVersion parameter.
This attribute defines the version of the Transport Layer Security protocol.
This element can be used by the server to indicate that the client MUST implement the TLS Server Name Indication feature [RFC6066]. This would be the case if the server hosts multiple 'virtual' servers at a single underlying network address and needs to know which one the client intends to connect to.
Note that this feature is only available in TLS version from TLS 1.2.
A TLS cipher suite that may be used for the TLS connection using the alphanumeric notation used in the TLS specifications. For example, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
In ebMS3 Part 2, a corresponding parameter called Pmode[1].Protocol.Security.SecurityAlgorithm is defined.
A reference to a leaf certificate that MUST be used for TLS client authentication.
In ebMS3 Part 2, a corresponding parameter called Pmode[1].Protocol.Security.Client.Certificate is defined
In a CPP, this element can be used in a TransportLayerSecurity element by a server party to indicate whether a leaf signing certificate is to be provided by the client party in the corresponding element in its CPP. If present with a true value in a CPP context for a receiver channel, a valid ClientCertificateRef element MUST be present in the CPP of the sending party for the channel. This referenced certificate MUST be included for specified CPA transport in a CPA derived from these CPPs. Client authentication is REQUIRED to use the agreed transport.
This element MUST NOT be used in a CPA. If specified in a CPP for the clien party for the transport, its value is ignored in unification.
A reference to a trust anchor containing a set of Certificate Authorities that a client certificate MUST chain to.
A reference to a leaf certificate that MUST used for TLS server authentication.
In ebMS3 Part 2, a corresponding parameter called Pmode[1].Protocol.Security.Server.Certificate is defined
In a CPP, this element can be used in a TransportLayerSecurity element by a client party to indicate whether a leaf signing certificate is to be provided by the server party in the corresponding element in its CPP. If present with a true value in a CPP context for a receiver channel, a valid ServerCertificateRef element MUST be present in the CPP of the server party for the channel. This referenced certificate MUST be included for specified CPA transport in a CPA derived from these CPPs. Server authentication is REQUIRED to use the agreed transport.
This element MUST NOT be used in a CPA. If specified in a CPP for the clien party for the transport, its value is ignored in unification.
A reference to a trust anchor containing a set of Certificate Authorities that a server certificate MUST chain to.
The TransportRestart element specifies and configures the use of a restart protocol. A restart transport protocol allows clients to check if previous partial transmissions exist and (if so) resume from the last known position in the data stream.
This element specifies a specific sub-protocol for transport protocol restarts.
The value AS2-Restart identifies the protocol specified in [as2-restart]. Since this protocol is specific to HTTP, it MUST NOT be used with transports other than HTTPTransport. Since it depends on some AS2-specific features, it SHOULD NOT be used with HTTP transports not bound to an AS2Channel.
This element corresponds to the Pmode[1].Protocol.Restart.Protocol P-Mode parameter defined in [EBMS3PART2].
This element specifies the expresses the maximum amount of time the recipient of a message SHOULD cache a temporary incomplete copy of the message, for a particular message transfer.
This element corresponds to the Pmode[1].Protocol.Restart.Interval P-Mode parameter defined in [EBMS3PART2].
This element MAY be specified in a CPP for a Receiver transport. It SHOULD NOT be set for a Sender transport. In CPA formation, the value to be included in the CPA is the Receiver value, if present.
In some messaging protocols including ebMS3, messages and payload parts can carry arbitrary named properties, with values constrained to be simple values.
In ebMS3, a message property can be configured as an item on the PMode[1].BusinessInfo.Properties list.
The property CompressionType MUST NOT be set for AS4 as it is reserved for use by the AS4 compression feature (see issue https://issues.oasis-open.org/browse/EBXMLMSG-75).
The PropertySet element defines a set of Property elements. It supports definitions of property sets that are reusable.
The PayloadProfile element provides the logical definition of the expected message content as one or multiple payload parts. The complementary Packaging element provides a mapping to physical packaging constructs. This mapping is done by shared values of PayloadPart/PartName elements and PayloadPart attributes on Packaging elements.
The PayloadProfile elements implements the ebMS3 concept of payload profiles. When used with ebMS3, the mapping to ebMS3 PMode parameters is as follows:
However, CPPA3 uses PayloadProfile as a general concept, and does not limit its use to ebMS3 channels.
Payload part definitions are referenced. Multiple payload profiles may reuse payload part definitions.
The PayloadPart element provides a logical definition of a payload part. A PayloadPart MAY be referenced from a PayloadProfile and from a Packaging element.
A PayloadPart MAY be signed at payload-level. A Signature element MAY be provided to record any relevant constraints on payload signatures, such as constraints on certificates or algorithms to be used. Note that processing such signatures is not functionality of the Channel and does not have to be provided by the Message Service handling that channel, but by business applications or other components that produce or consume payloads.
Similarly, a PayloadPart MAY be encrypted at payload-level. If this is the case, an Encryption element MAY be provided to provide any relevant constraints. As with payload signing, this encryption is not functionality of the Channel and the responsible Message Service Handler.
Presence of the Signature and Encryption element defines constraints on, respectively, signing and encryption. Absence of these elements specifies that no constraints are set. Whether payload level signing and encryption is required can be expressed using the requireSignature requireEncryption attributes.
In CPPA3, the Signature and Encryption elements and the requireSignature and requireEncryption attributes provide functionality similar to the CPPA2 ApplicationCertificateRef and ApplicationCertificateDetails elements. A difference is that CPPA2 defined these at CollaborationRole level, whereas CPPA3 defines them at PayloadPart level.
Note that use of the Signature and Encryption elements and the requireSignature and requireEncryption attributes is not required when messaging is used in a payload-content agnostic way. In that situation, messaging products MAY ignore the values of these elements. However, in those situations CPPA3 may still be useful. For example, any distribution mechanisms for CPPA3 could be leveraged to distribute keys to applications.
In ebMS3, a PayloadPart corresponds to an item on a PMode[1].BusinessInfo.PayloadProfile[] list.
A PayloadPart MAY be associated with one or multiple Schema elements. If more than one Schema element is specified, the part MUST conform to all specified schemas. For example, an XML document may have to conform to both a generic XML document schema and to a set of transaction-specific business rules expressed in another schema language.
For ebMS3, these elements in this type map to the payload properties defined for PayloadProfile[] items, as defined in D.3.3. of ebMS3 CORE.
This element specifies a name for the payload part. This element is used to map parts defined in a payload profile to package definitions.
Specifies the MIME content type of the part.
The Schema element can be used to associate a PayloadPart with a particular schema. For example, parts of type application/xml can be associated with an XML schema.
The location of the schema as a URI.
If not specified in a located schema, the schema version can be specified using this attribute.
For XML parts, this attribute specifies the namespace of the root element.
For XML parts, this attribute specifies the name of an XML element that MUST be used as the root of the part.
If this attribute is used, for schemas that use namespaces the namespace attribute MUST be set as well.
The Packaging element supports configuration of the physical packaging of the message and its payloads. It complements the PayloadProfile element that provides a logical definition. This element can be substituted by specialized elements, subject to any constraints imposed by the message protocol. This version of CPPA provides support for SOAP with Attachments, MTOM, MIME and simple SOAP packaging, but supports extensibility to other container types.
The MIMEEnvelope element supports packaging using the IETF MIME RFC 2045 specification for multipart envelopers. It also supports protocols in which some parts are external to the envelope but logically part of it.
Defines an individual abstract MIME envelope part. Substitutions are defined for simple MIME parts, Multipart/Related MIME parts and compressed variants of these. Additional substitutions could be defined for other containers that could be transported as MIME envelope content.
A MIME part type.
Note that there is no MIMEContentType element in this type, as this is specified for the referenced PayloadPart. For compressed MIME parts, the MIME type follows from the compression algorithm used.
This attribute specifies a MIME Content-Transfer-Encoding that is to be applied to the MIME part.
This attribute indicates whether the it is possible to process a filename parameter for the Content-Disposition MIME part header as specified in [ediint-fn].
The SOAPBodyPart and MIME parts.
This attribute identifies a PayloadPart using its PartName. The PayloadPart must be a part defined in the PayloadProfile associated with the action that links to the package that contains this part.
A simple MIME part, i.e. a part that is not itself a multipart part.
A Multipart/Related MIME part.
AS2 supports multiple payloads as a Multipart/Related structure [RFC6362]. A sending MSH that uses this feature MUST set the "MA" feature. The Version of the AS2Channel MUST be set to 1.2.
A Simple SOAP Envelope is an Envelope structured as defined in the SOAP 1.1 or 1.2 specifications, i.e. not an envelope packaged using the W3C SOAP with Attachments or MTOM specifications.
Payload packaging that uses the SOAP Body.
The identified PayloadPart must be a part defined in the PayloadProfile associated with the action that links to the SOAPWithAttachmentsEnvelope package that contains this SOAPBodyPart. The MIME Content Type of that PayloadPart MUST be application/xml.
The SOAPWithAttachmentsEnvelope element supports packaging using the W3C SOAP with Attachements specification.
When used with the ebMS2 protocol or other protocols that use the SOAP Body to store protocol-dependent data, the SOAPBodyPart MUST NOT be used.
When used with the ebMS3 protocol or other protocols that allow payload content to be transported in the SOAP Body, the SOAPBodyPart element MAY be used to identify a particular PayloadPart that SHOULD be packaged in the SOAP Body. Note that ebMS3 does not have any PMode parameters to control the placement of payloads.
For interoperability, at most one XML element MAY be included in the SOAP Body. If the maxOccurs for the identified PayloadPart is greater than 1, only one of these MAY be included in the SOAP Body, meaning all others MUST be transported as MIME parts or as external payloads.
Note that the ebMS3 protocol allows an MSH to use a simple SOAP envelope (not using MIME) for messages that consist of at most a single XML payload, carried in the SOAP Body. Since there are no PMode parameters to control whether content is placed in the Body or as an attachment, this means that an MSH MAY use a simple SOAP if there is just a single uncompressed XML payload.
An external payload is a payload that is not transported in the message, but is logically part of it. The external payload instead is referenced. The receiving MSH is responsible for dereferencing the reference, obtaining the payload (e.g. via a secure download) and processing it.
The channel that is to be used to retrieve the external payload is identified in the child ChannelID element, which is connected to a transport. Specified transport configuration for processing the referenced payload will be available for the Transport associated with that channel. This could configure, for example, use of IP addresses, client and server certificates, and user authentication, to be used.
Protocols supporting external payloads constrain the channels that can be used to retrieve the external payloads. In the case of ebMS2 or ebMS3, the payload content is not included as a MIME part or as the SOAP Body in the ebMS3 message. Instead, it is referenced using the href attribute:
In this case, the value of the hrefattribute is a URI, and the mechanism to access the payload is not an ebMS mechanism, but uses the transports associated with the URI. For example, in the case of an http(s) URI, it is expected to be retrieved using an HTTP GET request. In CPPA3, this mechanism is supported by associating the external payload with a TransportChannel. Future (or other) protocols not currently considered for CPPA3 may use other channel types for external payloads.
In Enterprise Integration terminology, the ExternalPayload feature is an instance of the Claim Check pattern.
An MTOM Envelope structured as defined in the MTOM specification [SOAP12-MTOM].
An MTOM Envelop uses XOP [XOP] to transfer parts of the SOAP message as MIME parts. However, from an XML infoset point of view, and in submission or delivery, there is only one structure.
This element expresses an XPath expression.
If namespaces are used, XPath expressions MUST use namespaces in Clark notation ({ns}name) to obviate the need for shared values and definitions of prefixes.
The Description element provides a natural language description related to a CPPA3 structure. Since its content is restricted to the non-empty-string type, it is not suited to contain structured technical documentation. If deemed useful, the href attribute MAY be used to reference external descriptions.
The allowed and denied attributes in a CPP control which counterparty or counterparties can participate in an exchange with the CPP's Party.
Define the maximum value for some size aspect of a message or message part.
Defines a size in octets. If the unit attribute is not present, the value of the attribute MUST be a positive integer. If the unit attribute is present with a value U for an element E of type SizeType, the value V of the attribute is equivalent to the attribute being absent on E and the value V multiplied by the BIPM interpretation of the unit prefix.