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.
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.
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.
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.
A optional reference to additional description material for the
structure.
xml:lang
union of(xs:language, restriction of xs:string)
required
lang (as an attribute name)
denotes an attribute whose value
is a language code for the natural language of the content of
any element; its value is inherited. This name is reserved
by virtue of its definition in the XML specification.
Notes
Attempting to install the relevant ISO 2- and 3-letter
codes as the enumerated possible values is probably never
going to be a realistic possibility.
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
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.
An optional reference to a resource about the named Party.
xml:lang
union of(xs:language, restriction of xs:string)
optional
lang (as an attribute name)
denotes an attribute whose value
is a language code for the natural language of the content of
any element; its value is inherited. This name is reserved
by virtue of its definition in the XML specification.
Notes
Attempting to install the relevant ISO 2- and 3-letter
codes as the enumerated possible values is probably never
going to be a realistic possibility.
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.
A certificate can be specified in one of two ways:
The certificate can be included in the
CPP or
CPA using an XML Signature
KeyInfo element.
The certificate can be referenced, using an XML Key Management Service (XKMS)
2.0
LocateRequest. In some use cases, this request obviates the need
to include the certificate in
the
CPP or
CPA document.
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.
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.
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 .
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.
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.
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].
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.
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.
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 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.
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 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 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.
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.
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.
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.
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.
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
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.
isAuthorizationRequired
xsd:boolean
optional
When a party uses isAuthorizationRequired on a Requesting
and/or a Responding activity accordingly, the result that [the activity]
will only be processed as valid if the party interpreting it successfully
matches the stated identity of the activity's [Role] to a list of allowed values
previously supplied by that party. Authorization typically relates to a signed
business document and the association to the role identity of the party expected
for that activity.
isIntelligibleCheckRequired
xsd:boolean
optional
Allows partners to agree that a message is confirmed by a
Receipt Acknowledgement only if it is also legible. Legible means that it has
passed structure/schema validity check. The content of the receipt and the
legibility of a business message (if required) are reviewed prior to the
processing of the Business Document or the evaluation of Condition Expressions
in the business message's Business Documents or Document Envelope.
isNonRepudiationReceiptRequired
xsd:boolean
optional
Both parties agree to mutually verify receipt of a Requesting
Business Document and that the receipt is non-repudiable.
isNonRepudiationRequired
xsd:boolean
optional
If non-repudiation of origin and content is required, then the
Business Activity stores the business document in its original form for the
duration mutually agreed to in an agreement.
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.
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.
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.
retryCount
xsd:int
optional
The business retry for a RequestingBusinessActivity identifies
the number of retries allowed in addition to the initial request while the Time
To Perform has not been exceeded.
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.
timeToAcknowledgeAcceptance
xsd:duration
optional
The time a Requesting and Responding role has to
non-substantively acknowledge business acceptance of a Business
Document.
timeToAcknowledgeReceipt
xsd:duration
optional
The time a Responding or Requesting role has to acknowledge
receipt of a Business Document.
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
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
ChannelIdX
preceeds
ChannelIdY 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.
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
PayloadProfileIdX
preceeds
PayloadProfileIdY 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.
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).
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 attribute is present and the
asResponse
attribute is either absent or present with a false value.
This expresses that the exchange uses the specified transport.
The
transport attribute is absent and the
asResponse attribute
is present with a true value.
This expresses that the exchange uses a backchannel of some other channel.
Examples are synchronous responses or exchanges
that use a channel created by a polling mechanism.
The
transport and
asResponse attributes
are both absent in situations such as:
End-to-end channels that consist of multiple hops across a chain of
store-and-forward messaging intermediaries. The transport differs for
each hop and therefore cannot be expressed for the end-to-end channel.
Situations where the transport is computed dynamically.
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.
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
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.
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 optional
unit attribute aims to facilitate
human-readable size specification using
BIPM (International Bureau of Weights and Measures) symbol prefix, e.g.
use
k for 10
3 or
G for 10
9 sizes.
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.
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:
The sequence of
PayloadPart elements maps to the
PMode[1].BusinessInfo.PayloadProfile[] P-Mode
parameter list.
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.
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
requireSignaturerequireEncryption 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.
To express that payload level encryption is REQUIRED,
the
requireEncryption attribute MUST be set to the value true.
If the
requireEncryption attribute
is set to false or is absent, then the payload is not constrained to be encrypted.
To express that payload level signing is REQUIRED,
the
requireSignature attribute MUST be set to the value true.
If the
requireSignature attribute
is set to false or is absent, then the payload is not constrained to be signed.
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
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.
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.
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.
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.
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.
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.
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.
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 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
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 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.
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.
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.
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.
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.
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 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
CPPProfileIdentifiers (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
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.
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:
As a
macro facility, to simplify the management of CPPs and CPAs that have
many largely identical protocol bindings. The named binding MAY be mapped to a a more
complete
binding that defines additional configurations.
The semantics of the element is defined in terms of the semantics of that binding.
To identify a particular configuration of some protocol that can be
mapped to particular configurations in CPPA3 aware software. This can even be used
for
protocols for which the CPPA3 schema does not specify 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
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.
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.
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
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.
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.
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.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.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.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
ReceiptFormat MUST NOT be used in protocols that
have a single pre-defined receipt
format. In EDIINT, the receipt format is fixed to be a MIME multipart/report with
a report-type of
disposition-notification. The
ReceiptFormat
element therefore MUST NOT be used.
As AS4 supports two types of receipts,
the
ReceiptFormat element MUST be provided for each
AS4
ebMS3Channel.
The
ReceiptChannelId element specifies the channel
to use to exchange receipts.
EDIINT
For EDIINT, the
ReceiptHandling element configures the
processing of EDIINT Message Disposition
Notifications (MDNs).
In a
CPPReceiptHandling 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:
If the
asResponse attribute is present on the receipt channel with the
value
true, the channel
is a synchronous channel, which uses the backchannel offered by the
AS2Channel on which the
ReceiptHandling element occurs.
In this case, the
transport attribute MUST NOT be present.
If the
asReponse attribute is absent, or present with a value
false,
the channel is an
asynchronous channel. It uses a separate transport connection that is identified using
the value of the
transport attribute, which MUST be present and which MUST reference an
EDIINT transport.
The value of the
Endpoint element in the referenced transport
SHOULD be used as value for the
Receipt-Delivery-Option.
Note that AS2 allows MDNs to use other transports than HTTP.
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:
This
Signature element MAY contain a
SignatureFormat.
For AS2 and AS3, the only accepted value is
pkcs7-signature. This selects the
S/MIME detached signature format.
For AS1, the accepted values are
pkcs7-signature and
pgp-signature.
This
Signature element MUST also contain one of
more
SignatureAlgorithm elements.
To select one of the two supported values for MIC algorithm, the value of the
SignatureAlgorithm
element or elements MAY be set to
http://www.w3.org/2000/09/xmldsig#sha1 or
http://www.w3.org/2001/04/xmldsig-more#md5. These values translate to
the
sha1 and
md5 <micalg> values. Note that, while RFC4130 only supports SHA1 and MD5,
EDIINT
implementations support more modern algorithm like sha-224, sha-256, sha-384 and sha-512.
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.
ebMS3 Core
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.
ebMS3
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.
EDIINT
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.
CPPA2
The
ReceiptChannelId element replaces the functions of three
CPPA2 elements
and attributes:
The
syncReplyMode attribute on
MessagingCharacteristics in CPPA2 can be
used to
specify whether receipts are expected synchronously or asynchronously. In CPPA3, this
is a
characteristic of the referenced receipt channel.
CPPA2 used the
defaultMshChannelId attribute on
PartyInfo to express the
channel to use for asynchronous signals, such as receipts. In CPPA3, the channel is
referenced
from an
ebMS2ReliableMessaging element.
In CPPA2, either all receipts are signed or none. In CPPA3, this can be specified
for
each (synchronous or asynchronous) channel separately.
In CPPA2, the
ackSignatureRequested attribute on
MessagingCharacteristics
expressed whether the receipt message is to be signed. Whereas this can be specified
for
each channel, only one asynchronous channel could be specified for receipts, which
can only be
signed or unsigned.
In CPPA3 it is possible to specify that some asynchronous receipts are to be signed
and
others not.
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.
For the AS4 protocol, the only allowed value is
application/gzip.
For the AS2 protocol, the only value is
application/pkcs7-mime as
described in [RFC5402, RFC3851] which uses
ZLIB compression [RFC1950].
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.
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
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.
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.
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
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.
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.
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
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.
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.
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
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.
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.
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.
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.
The optional
actorOrRole attribute identifies
the
actor (SOAP 1.1) or
role (SOAP 1.2) that the security header
targets. Specific values MAY be associated with specific processing.
For example, the value
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh
indicates the use of the ebMS3 Part 2 multihop feature.
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.
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].
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.usernamePMode[1].Security.UsernameToken.passwordPMode[1].Security.UsernameToken.DigestPMode[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.
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.
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.DuplicateDetectionPMode[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.RetryPMode[1].ReceptionAwareness.Retry.Parameters
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].
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.MandatoryAttributesPMode[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].
If
true, the attribute is a
PMode[1].Security.SAML.MandatoryAttributes attribute.
If
false, it is a
PMode[1].Security.SAML.OptionalAttributes
attribute.
Wildcard: ANY attribute from ANY namespace OTHER than 'http://docs.oasis-open.org/ebcore/ns/cppa/v3.0'
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 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.
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
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.
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).
This attribute can be used to target the ebMS
Messaging
header to a particular actor or role.
The value
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh
indicates that the message
is processed as defined in the Multi-Hop Messaging feature of the ebMS3,
Part 2 Advanced Features specification [EBMS3PART2].
This attribute does not control the actor/role on
other SOAP headers, such as the the WS-Security header. It relates to the
P-Mode parameter
Pmode[1].Protocol.AddActorOrRoleAttribute.
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.
This attribute can be used to specify if a
pmode attribute
is to be included in an ebMS3 message. If the value for
includeAgreementRef is
false, this attribute MUST NOT be
set to
true.
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
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.
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.
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:
The element
MaxSize expresses the maximum size for the bundle. It encodes the
Pmode[].bundling.maxsize P-Mode parameter. This parameter defines the maximum size of a
message resulting from bundling. It includes the size of the SOAP envelope and any
payloads in
MIME attachments.
The element
MaxDelay encodes the
Pmode[].bundling.maxdelay P-Mode
parameter. This parameter (of type duration) defines the maximum time between the
oldest message
unit and the newest message unit in a bundle, based on the
eb3:MessageInfo/eb3:Timestamp
values of the message units. A receiving MSH SHOULD validate that the bundles satisfies
this requirement. A sending MSH MAY use this parameter to determine, for a submitted
message
unit, to bundle it with other submitted messages , to send it by itself (as an unbundled
message) or to defer sending it (as other message units may be submitted later
that it could be bundled with).
The
Policy element encodes the
Pmode[].bundling.ordering.policy parameter.
In [EBMS3PART2], this element is defined to have three values for
Policy. Absence of
the CPPA3
Ordering element is equivalent to the ebMS3 P-Mode being present with
value
undefined for
Policy.
If the
Ordering element is present, the
Policy element MUST be present with a
value that indicates which of the other two policies applies to the channel.
The
Scope element encodes the
Pmode[].bundling.ordering.scope
P-Mode parameter.
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
FragmentSize element encodes
the
Pmode[].Splitting.FragmentSize P-Mode
parameter.
The optional list of
Property elements
encodes the
Pmode[].Splitting.RoutingProperties
P-Mode parameter. Alternatively, a set of properties can be
referenced using the
propertySetId attribute.
The
JoinInterval encodes
the
Pmode[].Splitting.JoinInterval parameter.
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 optional
unit attribute aims to facilitate
human-readable size specification using
BIPM (International Bureau of Weights and Measures) symbol prefix, e.g.
use
k for 10
3 or
G for 10
9 sizes.
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.
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:
RoutingInput attached to an ebMS3 initiating signal message, in
particular to
a
Pull signal message. The content of the
RoutingInput is
specified in section 2.6.1 of [EBMS3PART], item (2) of the numbered list,
second option,
The EPR for the request signal to pull a user message can be inferred from the
P-Mode as follows ...
.
RoutingInput attached to response messages, in particular to
ebMS3 response signals such as errors and receipts.
The content of the reference parameter is generated as
specified in section 2.6.2 of [EBMS3PART], item (4) of the numbered list,
Inferred RoutingInput for the reverse path.
Common to all inferred
RoutingInput parameters is that:
The content of the
From and
To elements is swapped.
The value of the
Service element and its
type attribute are copied.
The content of the
Action element and
mpc attribute
are set to
the values of the related user message, concatenated with optional suffixes specified
in
ActionSuffix and
MPCSuffix element respectively.
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.
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 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.
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.
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:
To support payload exchange using REST. In this case a reference MUST be provided
using the
transport attribute to a
Transport that is an HTTP POST.
To support the external payload feature, as used in ebMS2 and ebMS3. In this case
there are
two
TransportChannels involved:
One
TransportChannel that is a back-channel,
used to transport the
payload data. This channel can be bound to an action.
A separate
TransportChannel that creates
the back-channel. This channel
is to be defined separately and is referenced using
using
RequestChannelId.
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:
The request
TransportChannel used by the first leg
in a Two Way exchange
that is referenced by a
replyTo attribute on the response action that uses
the back-channel. The response
TransportChannel
MUST have
an
asResponse attribute present with a true value.
An ad hoc
TransportChannel that is used purely to
provide the back-channel.
This channel is identified using the
RequestChannelId.
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
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.
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.
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
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.
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
sourceCPP.
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.
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:
In case of
delegation, the third party that acts
as Sender or Receiver is identified in the message headers identifying Sender or Receiver
party.
The third party uses its own X.509 or other security tokens to secure communication.
In case of
impersonation, the third party is anonymous or even not noticeable.
Its messaging software processes messages using the impersonated Party's identifier
and
MAY even use a security token linked to the impersonated Party.
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 Party P2 that receives messages from a third Party P3 that suggests it acts on behalf
of another
Party P1
SHOULD use delegation information in relevant
CPPs or
CPAs as
information to determine whether this P3 is in fact
authorized to send on
behalf of P1.
A Party P1 that intends to sends data to a Party P2 SHOULD use the delegation information
in relevant
CPPs or
CPAs to determine if the message
is instead expected to be sent to a third Party P3 that P2 delegates messaging receiving
to.
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
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.
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 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.
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 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.
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.
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.
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.
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:
The
From element can be used to configure a value for the
SMTP
From header.
The
To element can be used to configure a value for
the SMTP
To header.
The
Subject element can be used to configure a value for
the SMTP
Subject header.
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.
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.
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
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 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.
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 the case of ebMS2, using
Manifest/Reference/@href.
In the case of ebMS3, using
PayloadInfo/PartInfo/@href.
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.
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.
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.
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].
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.
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.
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.
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.
For a Party or CounterParty, its
NameIDs,
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
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.
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 reference to a list of party identifiers. This list can be referenced
using an ID reference, if it is included in the
CPP, or using a absolute URI,
if it is located using a Uniform Resource Locator and is located outside the
CPP.
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.
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
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.
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.
The optional
unit attribute aims to facilitate
human-readable size specification using
BIPM (International Bureau of Weights and Measures) symbol prefix, e.g.
use
k for 10
3 or
G for 10
9 sizes.
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.
The WS-Security X.509 Token Profile distinguishes three type of mechanisms to
reference security token. This type definition provides identifiers for these three
values.
XML Signature 1.1 deprecates
X509IssuerSerial and suggests that instead
X509Digest be used. This value is provided for potential future use.
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
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.
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.
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.
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
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.
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.
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.
The optional
actorOrRole attribute identifies
the
actor (SOAP 1.1) or
role (SOAP 1.2) that the security header
targets. Specific values MAY be associated with specific processing.
For example, the value
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh
indicates the use of the ebMS3 Part 2 multihop feature.
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.
If
true, the attribute is a
PMode[1].Security.SAML.MandatoryAttributes attribute.
If
false, it is a
PMode[1].Security.SAML.OptionalAttributes
attribute.
Wildcard: ANY attribute from ANY namespace OTHER than 'http://docs.oasis-open.org/ebcore/ns/cppa/v3.0'
In case of a
Sync transport channel binding for the response in a Two Way
exchange, which is indicated by the
asResponse attribute being present
with a true value, and the channel being used by an
ActionBinding that
has a
replyTo attribute linking the action to a request actions. That
request action then MUST be bound to a channel to provides a backchannel for
the synchronous response.
In case of a synchronous standalone ebMS2 error or receipt signal, also
indicated by the
asResponse attribute being present with a
true value.
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
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.
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.
In case of a
Pull transport channel binding, which is indicated by
presence of a
PullHandling child element.
In case of a
Sync transport channel binding for the response in a Two Way
exchange, which is indicated by the
asResponse attribute being present
with a true value, and the channel being used by an
ActionBinding that
has a
replyTo attribute linking the action to a request actions. That
request action then MUST be bound to a channel that provides a backchannel for
the synchronous response.
In case of a synchronous standalone ebMS3 error or receipt signal, also
indicated by the
asResponse attribute being present with a true value.
In case of a multi-hop message, which is expressed using the value
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh
for the
actorOrRole attribute.
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.
This attribute can be used to target the ebMS
Messaging
header to a particular actor or role.
The value
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh
indicates that the message
is processed as defined in the Multi-Hop Messaging feature of the ebMS3,
Part 2 Advanced Features specification [EBMS3PART2].
This attribute does not control the actor/role on
other SOAP headers, such as the the WS-Security header. It relates to the
P-Mode parameter
Pmode[1].Protocol.AddActorOrRoleAttribute.
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.
This attribute can be used to specify if a
pmode attribute
is to be included in an ebMS3 message. If the value for
includeAgreementRef is
false, this attribute MUST NOT be
set to
true.
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
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
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.
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.
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
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.
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.
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.
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 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.
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.
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].
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 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.
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.
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.
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
RequestingBusinessActivity/@name
or the
RespondingBusinessActivity/@name.
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.
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.
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.
The optional
unit attribute aims to facilitate
human-readable size specification using
BIPM (International Bureau of Weights and Measures) symbol prefix, e.g.
use
k for 10
3 or
G for 10
9 sizes.
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.
To express that payload level signing is REQUIRED,
the
requireSignature attribute MUST be set to the value true.
If the
requireSignature attribute
is set to false or is absent, then the payload is not constrained to be signed.
To express that payload level encryption is REQUIRED,
the
requireEncryption attribute MUST be set to the value true.
If the
requireEncryption attribute
is set to false or is absent, then the payload is not constrained to be encrypted.
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.
The optional
actorOrRole attribute identifies
the
actor (SOAP 1.1) or
role (SOAP 1.2) that the security header
targets. Specific values MAY be associated with specific processing.
For example, the value
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh
indicates the use of the ebMS3 Part 2 multihop feature.
If
true, the attribute is a
PMode[1].Security.SAML.MandatoryAttributes attribute.
If
false, it is a
PMode[1].Security.SAML.OptionalAttributes
attribute.
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.
This attribute can be used to target the ebMS
Messaging
header to a particular actor or role.
The value
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/nextmsh
indicates that the message
is processed as defined in the Multi-Hop Messaging feature of the ebMS3,
Part 2 Advanced Features specification [EBMS3PART2].
This attribute does not control the actor/role on
other SOAP headers, such as the the WS-Security header. It relates to the
P-Mode parameter
Pmode[1].Protocol.AddActorOrRoleAttribute.
This attribute can be used to specify if a
pmode attribute
is to be included in an ebMS3 message. If the value for
includeAgreementRef is
false, this attribute MUST NOT be
set to
true.
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.
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.
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].
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.
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].
xml.xsd
xmldsig-core-schema.xsd
