Showing:

Annotations
Attributes
Diagrams
Facets
Properties

Table of Contents

Group by:

http://docs.oasis-open.org/ebcore/ns/cppa/v3.0

Elements
Complex Types

Resource hierarchy:

Main schema cppa3.xsd
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This XML schema is part of the OASIS CPPA3 specification developed by the OASIS ebCore TC.

Two elements defined in this schema can serve as root elements of CPPA3 XML documents:

  1. The CPP element defines a Collaboration Protocol Profile.
  2. The CPA element defines a Collaboration-Protocol Agreement.
Properties
attribute form default unqualified
element form default qualified
version 3.0
[ top ]
Element cppa:CPP
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#acl_attributes cppa3.tmp#ProfileInfo cppa3.tmp#PartyInfo cppa3.tmp#ServiceSpecification cppa3.tmp#PropertySet cppa3.tmp#Channel cppa3.tmp#ChannelFeature cppa3.tmp#Transport cppa3.tmp#PayloadProfile cppa3.tmp#Packaging cppa3.tmp#PartyIdList cppa3.tmp#CPPAExtension
Properties
content complex
Children cppa:CPPAExtension, cppa:Channel, cppa:ChannelFeature, cppa:Packaging, cppa:PartyIdList, cppa:PartyInfo, cppa:PayloadProfile, cppa:ProfileInfo, cppa:PropertySet, cppa:ServiceSpecification, cppa:Transport, ds:Signature
Attributes
QName Type Use Annotation
allowed cppa:party_id_list_ref_type optional
A reference to a list of allowed party identifiers.
denied cppa:party_id_list_ref_type optional
A reference to a list of denied party identifiers.
[ top ]
Element cppa:ProfileInfo
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The ProfileInfo element provides metadata about the Collaboration Protocol Profile.

Diagram
Diagram cppa3.tmp#ProfileIdentifier cppa3.tmp#Description cppa3.tmp#ActivationDate cppa3.tmp#ExpirationDate cppa3.tmp#PhaseIn
Properties
content complex
Children cppa:ActivationDate, cppa:Description, cppa:ExpirationDate, cppa:PhaseIn, cppa:ProfileIdentifier
[ top ]
Element cppa:ProfileIdentifier
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#ProfileIdentifier_type cppa3.tmp#ProfileIdentifier_href
Type extension of cppa:non-empty-string
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
href xs:anyURI optional

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.

type xs:anyURI optional

The type attribute defines a namespace in which the content of the ProfileIdentifier element is to be interpreted.

[ top ]
Element cppa:Description
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#Description_href
Type extension of cppa:non-empty-string
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
href xs:anyURI optional
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.

See BCP 47 at http://www.rfc-editor.org/rfc/bcp/bcp47.txt and the IANA language subtag registry at http://www.iana.org/assignments/language-subtag-registry for further information.

The union allows for the 'un-declaration' of xml:lang with the empty string.

[ top ]
Element cppa:ActivationDate
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

When used in a CPP or CPA, this element defines the date and time from which the CPP or CPA is valid.

When used in a ServiceBinding, this element defines the date and time from which the ServiceBinding is valid.

Diagram
Diagram
Type xs:dateTime
Properties
content simple
[ top ]
Element cppa:ExpirationDate
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

When used in a CPP or CPA, this element defines the date and time at which a CPP or CPA expires.

When used in a ServiceBinding, this element defines the date and time from which a ServiceBinding expires.

Diagram
Diagram
Type xs:dateTime
Properties
content simple
[ top ]
Element cppa:PhaseIn
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:duration
Properties
content simple
[ top ]
Element cppa:PartyInfo
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The PartyInfo element provides information about a Party. This element is used in CPP and CPA.

When used for ebMS3, this element encodes some information relating to the PMode.{Initiator/Responder}.Party parameters.

Diagram
Diagram cppa3.tmp#PartyInfoType_href cppa3.tmp#PartyName cppa3.tmp#PartyId cppa3.tmp#PartyContact cppa3.tmp#Certificate cppa3.tmp#TrustAnchorSet cppa3.tmp#CertificatePolicySet cppa3.tmp#CertificateDefaults cppa3.tmp#IDPRegistration cppa3.tmp#IDPRegistrationSet cppa3.tmp#SSHKey cppa3.tmp#PartyInfoExtension cppa3.tmp#PartyInfoType
Type cppa:PartyInfoType
Properties
content complex
Children cppa:Certificate, cppa:CertificateDefaults, cppa:CertificatePolicySet, cppa:IDPRegistration, cppa:IDPRegistrationSet, cppa:PartyContact, cppa:PartyId, cppa:PartyInfoExtension, cppa:PartyName, cppa:SSHKey, cppa:TrustAnchorSet
Attributes
QName Type Use Annotation
href xs:anyURI optional

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.

[ top ]
Element cppa:PartyName
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#PartyName_href
Type extension of cppa:non-empty-string
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
href xs:anyURI optional

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.

See BCP 47 at http://www.rfc-editor.org/rfc/bcp/bcp47.txt and the IANA language subtag registry at http://www.iana.org/assignments/language-subtag-registry for further information.

The union allows for the 'un-declaration' of xml:lang with the empty string.

[ top ]
Element cppa:PartyId
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#PartyIdType_type cppa3.tmp#PartyIdType
Type cppa:PartyIdType
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
type xs:anyURI optional

The type attribute defines a namespace in which the value of PartyId is to be interpreted. Use of the OASIS ebCore Party Id Type specification is RECOMMENDED.

[ top ]
Element cppa:PartyContact
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A person or department that acts as a point of contact for a party.

The content of this element is derived from the UN/CEFACT Core Component Library.

Diagram
Diagram cppa3.tmp#PartyContact_id cppa3.tmp#PartyContact_ContactType cppa3.tmp#PartyContact_DepartmentName cppa3.tmp#PartyContact_PersonName cppa3.tmp#PartyContact_JobTitle cppa3.tmp#PartyContact_DirectTelephone cppa3.tmp#PartyContact_MobileTelephone cppa3.tmp#PartyContact_Fax cppa3.tmp#PartyContact_Email cppa3.tmp#PartyContact_URICommunication
Properties
content complex
Children cppa:ContactType, cppa:DepartmentName, cppa:DirectTelephone, cppa:Email, cppa:Fax, cppa:JobTitle, cppa:MobileTelephone, cppa:PersonName, cppa:URICommunication
Attributes
QName Type Use Annotation
id optional
The unique identifier of this party contact.
[ top ]
Element cppa:PartyContact / cppa:ContactType
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The type of contact, e.g. business contact, technical contact, security contact, administrative contact
Diagram
Diagram cppa3.tmp#PartyContactType
Type cppa:PartyContactType
Properties
content simple
minOccurs 0
maxOccurs 1
[ top ]
Element cppa:PartyContact / cppa:DepartmentName
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The name, expressed as text, of the department to which this party contact belongs.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
Facets
minLength 1
[ top ]
Element cppa:PartyContact / cppa:PersonName
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The name, expressed as text, of the person for this party contact.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
Facets
minLength 1
[ top ]
Element cppa:PartyContact / cppa:JobTitle
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The job title, expressed as text, for this party contact.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
Facets
minLength 1
[ top ]
Element cppa:PartyContact / cppa:DirectTelephone
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The direct unstructured telephone communication information for this party contact.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
Facets
minLength 1
[ top ]
Element cppa:PartyContact / cppa:MobileTelephone
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The mobile unstructured telephone communication information for this party contact.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
Facets
minLength 1
[ top ]
Element cppa:PartyContact / cppa:Fax
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The fax unstructured telecommunication information for this party contact.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
Facets
minLength 1
[ top ]
Element cppa:PartyContact / cppa:Email
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The email communication information for this party contact.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
Facets
minLength 1
[ top ]
Element cppa:PartyContact / cppa:URICommunication
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
Uniform Resource Identifier (URI) communication information for this party contact.
Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
minOccurs 0
maxOccurs unbounded
Facets
minLength 1
[ top ]
Element cppa:Certificate
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element specifies an X.509 Certificate.

A certificate can be specified in one of two ways:

  1. The certificate can be included in the CPP or CPA using an XML Signature KeyInfo element.
  2. 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.

Diagram
Diagram cppa3.tmp#SecurityTokenType_id cppa3.tmp#SecurityTokenType cppa3.tmp#SecurityToken
Type extension of cppa:SecurityTokenType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Children ds:KeyInfo, xkms:LocateRequest
Attributes
QName Type Use Annotation
id xs:ID optional
A unique identifier for the security token.
[ top ]
Element cppa:TrustAnchorSet
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A TrustAnchorSet is a collection of trusted certificate roots. The TrustAnchorSet element MAY contain one or more AnchorCertificateRef elements, each of which refers to a Certificate element (under PartyInfo or CounterPartyInfo) that represents a root certificate trusted by this Party. These trusted root certificates are used in the process of certificate path validation. If a certificate in question does not “chain” to one of this Party’s trust anchors, it is considered invalid.

A TrustAnchorSet MAY also contain such a root certificate as direct child element.

A TrustAnchorSet can be referenced using SigningTrustAnchorSetRef, EncryptionTrustAnchorSetRef, ClientTrustAnchorSetRef and ServerTrustAnchorSetRef elements in channel or transport binding definitions, and taken into account during CPA formation. In forming a CPA, a presented certificate MUST be matched against a referenced anchor. The TrustAnchorSet itself is not REQUIRED to be present in the generated CPA, as the selected certificate is trusted directly and specified in the CPA.

Diagram
Diagram cppa3.tmp#TrustAnchorSet_id cppa3.tmp#AnchorCertificateRef cppa3.tmp#Certificate
Properties
content complex
Children cppa:AnchorCertificateRef, cppa:Certificate
Attributes
QName Type Use Annotation
id xs:ID required

Unique identifier of the set of trusted anchor certificates

[ top ]
Element cppa:AnchorCertificateRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
A reference to a trusted Certification Authority.
Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType cppa3.tmp#CertificateRef
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:CertificatePolicySet
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A set of accepted certificate policies, identified using OID in dotted string notation.

Diagram
Diagram cppa3.tmp#CertificatePolicySet_id cppa3.tmp#CertificatePolicySet_CertificatePolicy
Properties
content complex
Children cppa:CertificatePolicy
Attributes
QName Type Use Annotation
id xs:ID required

Unique identifier of the set of accepted certificate policies

[ top ]
Element cppa:CertificatePolicySet / cppa:CertificatePolicy
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Diagram
Diagram
Type restriction of xs:string
Properties
content simple
minOccurs 1
maxOccurs unbounded
Facets
pattern ([0-9]+\.)*[0-9]+
[ top ]
Element cppa:CertificateDefaults
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The CertificateDefaults element expresses default certificates and default trust anchors for a Party in a CPP or CPA.

For Channels bound to send ActionBindings that can be secured using certificates:

For Channels bound to receive ActionBindings that can be secured using certificates:

For a Transport for which a Party acts as Server:

For a Transport for which a Party acts as Client:

For the purpose of forming a CPA from two CPPs, a definition in a CPP of a Channel for which a certificate or trust anchor for a Party for signing or encryption is explicitly specified at the level of a ChannelFeature for that Channel is equivalent to a Channel for which the certificate or trust anchor is not specified for the purpose at the level of a ChannelFeature for that Channel but is specified for the purpose in the CertificateDefaults for the Party .

Diagram
Diagram cppa3.tmp#SigningCertificateRef cppa3.tmp#SigningTrustAnchorSetRef cppa3.tmp#SigningCertificatePolicySetRef cppa3.tmp#EncryptionCertificateRef cppa3.tmp#EncryptionTrustAnchorSetRef cppa3.tmp#EncryptionCertificatePolicySetRef cppa3.tmp#ClientCertificateRef cppa3.tmp#ClientTrustAnchorSetRef cppa3.tmp#ClientCertificatePolicySetRef cppa3.tmp#ServerCertificateRef cppa3.tmp#ServerTrustAnchorSetRef cppa3.tmp#ServerCertificatePolicySetRef
Properties
content complex
Children cppa:ClientCertificatePolicySetRef, cppa:ClientCertificateRef, cppa:ClientTrustAnchorSetRef, cppa:EncryptionCertificatePolicySetRef, cppa:EncryptionCertificateRef, cppa:EncryptionTrustAnchorSetRef, cppa:ServerCertificatePolicySetRef, cppa:ServerCertificateRef, cppa:ServerTrustAnchorSetRef, cppa:SigningCertificatePolicySetRef, cppa:SigningCertificateRef, cppa:SigningTrustAnchorSetRef
[ top ]
Element cppa:SigningCertificateRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType cppa3.tmp#CertificateRef
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:SigningTrustAnchorSetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A reference to a trust anchor that a signing certificate MUST chain to.

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:SigningCertificatePolicySetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
A reference to an X.509 certificate policy set to be used for a signing certificate.
Diagram
Diagram cppa3.tmp#CertificatePolicySetReferenceType_setId cppa3.tmp#CertificatePolicySetReferenceType
Type cppa:CertificatePolicySetReferenceType
Properties
content complex
Attributes
QName Type Use Annotation
setId xs:IDREF optional
A referenced identifier of a set of CertificatePolicies.
[ top ]
Element cppa:EncryptionCertificateRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType cppa3.tmp#CertificateRef
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:EncryptionTrustAnchorSetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A reference to a trust anchor set that an encryption certificate MUST chain to.

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:EncryptionCertificatePolicySetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
A reference to an X.509 certificate policy set to be used for an encryption certificate.
Diagram
Diagram cppa3.tmp#CertificatePolicySetReferenceType_setId cppa3.tmp#CertificatePolicySetReferenceType
Type cppa:CertificatePolicySetReferenceType
Properties
content complex
Attributes
QName Type Use Annotation
setId xs:IDREF optional
A referenced identifier of a set of CertificatePolicies.
[ top ]
Element cppa:ClientCertificateRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A reference to a leaf certificate that MUST be used for TLS client authentication.

In ebMS3 Part 2, a corresponding parameter called Pmode[1].Protocol.Security.Client.Certificate is defined

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:ClientTrustAnchorSetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A reference to a trust anchor containing a set of Certificate Authorities that a client certificate MUST chain to.

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType cppa3.tmp#CertificateRef
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:ClientCertificatePolicySetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
A reference to an X.509 certificate policy set to be used for a client certificate.
Diagram
Diagram cppa3.tmp#CertificatePolicySetReferenceType_setId cppa3.tmp#CertificatePolicySetReferenceType
Type cppa:CertificatePolicySetReferenceType
Properties
content complex
Attributes
QName Type Use Annotation
setId xs:IDREF optional
A referenced identifier of a set of CertificatePolicies.
[ top ]
Element cppa:ServerCertificateRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A reference to a leaf certificate that MUST used for TLS server authentication.

In ebMS3 Part 2, a corresponding parameter called Pmode[1].Protocol.Security.Server.Certificate is defined

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:ServerTrustAnchorSetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A reference to a trust anchor containing a set of Certificate Authorities that a server certificate MUST chain to.

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#CertificateRefType_certId cppa3.tmp#CertificateRefType cppa3.tmp#CertificateRef
Type cppa:CertificateRefType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Attributes
QName Type Use
certId xs:IDREF required
[ top ]
Element cppa:ServerCertificatePolicySetRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
A reference to an X.509 certificate policy set to be used for a server certificate.
Diagram
Diagram cppa3.tmp#CertificatePolicySetReferenceType_setId cppa3.tmp#CertificatePolicySetReferenceType
Type cppa:CertificatePolicySetReferenceType
Properties
content complex
Attributes
QName Type Use Annotation
setId xs:IDREF optional
A referenced identifier of a set of CertificatePolicies.
[ top ]
Element cppa:IDPRegistration
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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].

Diagram
Diagram cppa3.tmp#IDPRegistration_id cppa3.tmp#ProviderID cppa3.tmp#IDPName cppa3.tmp#Endpoint cppa3.tmp#ReceiverID
Properties
content complex
Children cppa:Endpoint, cppa:IDPName, cppa:ProviderID, cppa:ReceiverID
Attributes
QName Type Use Annotation
id xs:ID required

Unique identifier of the IDP registration

[ top ]
Element cppa:ProviderID
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The mandatory ProviderID is an Entity Identifier (see [SAML-CORE-2.0-OS], section 8.3.6) that uniquely identifies the identity provider.

Diagram
Diagram
Type xs:anyURI
Properties
content simple
[ top ]
Element cppa:IDPName
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
The IDPName provides a human-readable name for an identity provider.
Diagram
Diagram
Type xs:string
Properties
content simple
[ top ]
Element cppa:Endpoint
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element specifies a URI value that MUST be used as endpoint address.

In ebMS3, this corresponds to the PMode[1].Protocol.Address parameter.

Diagram
Diagram
Type xs:anyURI
Properties
content simple
[ top ]
Element cppa:ReceiverID
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:anyURI
Properties
content simple
[ top ]
Element cppa:IDPRegistrationSet
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#IDPRegistrationSet_id cppa3.tmp#IDPRegistrationRef
Properties
content complex
Children cppa:IDPRegistrationRef
Attributes
QName Type Use Annotation
id xs:ID required

Unique identifier of the set of IDP registrations

[ top ]
Element cppa:IDPRegistrationRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
A reference to a trusted Identity Provider.
Diagram
Diagram cppa3.tmp#IDPRegistrationRef_idp
Properties
content complex
Attributes
QName Type Use
idp xs:IDREF required
[ top ]
Element cppa:SSHKey
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#SecurityTokenType_id cppa3.tmp#SecurityTokenType cppa3.tmp#SecurityToken
Type extension of cppa:SecurityTokenType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Children ds:KeyInfo
Attributes
QName Type Use Annotation
id xs:ID optional
A unique identifier for the security token.
[ top ]
Element cppa:PartyInfoExtension
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
An abstract PartyInfo Extension element
Diagram
Diagram cppa3.tmp#PartyInfoExtensionType
Type cppa:PartyInfoExtensionType
Properties
content complex
abstract true
[ top ]
Element cppa:ServiceSpecification
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element associates a party with a Service and a binding (or bindings) supporting the participation of the party in a particular role in one or multiple business collaborations, collaborating with other parties acting in another particular role.

In a CPP, PartyRole specifies the role of the party defined in PartyInfo. CounterPartyRole specifies the role of an unspecified party with whom the party MAY engage in message exchange.

In a CPA, PartyRole specifies the role of the party defined in PartyInfo and CounterPartyRole specifies the role of the party defined in CounterPartyInfo.

In a CPP or CPA document, for an ordered pair or < PartyRole, CounterPartyRole> all ServiceBindings for that pair MUST be contained within a single ServiceSpecification.

In CPPA2, the equivalent of this element was called CollaborationRole.

The element CounterPartyRole has no equivalent in CPPA2. It is added the CPPA3 schema to facilitate automated CPA formation in business processes involving more than two roles. For example: In a collaboration involving roles A, B and C, some message types may be exchanged between A and B, others between A and C and others between B and C. Therefore in CPPA3 a ServiceSpecifications specifies the involved role pair.

The ServiceSpecificationExtension element is provided to allow extensibility of ServiceSpecification elements.

Diagram
Diagram cppa3.tmp#ServiceSpecification_base cppa3.tmp#ServiceSpecification_uuid cppa3.tmp#ServiceSpecification_name cppa3.tmp#ServiceSpecification_version cppa3.tmp#acl_attributes cppa3.tmp#Description cppa3.tmp#PartyRole cppa3.tmp#CounterPartyRole cppa3.tmp#ServiceBinding cppa3.tmp#ServiceSpecificationExtension
Properties
content complex
Children cppa:CounterPartyRole, cppa:Description, cppa:PartyRole, cppa:ServiceBinding, cppa:ServiceSpecificationExtension
Attributes
QName Type Use Annotation
allowed cppa:party_id_list_ref_type optional
A reference to a list of allowed party identifiers.
base xs:anyURI optional

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.

denied cppa:party_id_list_ref_type optional
A reference to a list of denied party identifiers.
name cppa:non-empty-string optional

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.

uuid cppa:non-empty-string optional

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.

version cppa:non-empty-string optional

This attribute defines the version of the business process associated with the service collaboration.

[ top ]
Element cppa:PartyRole
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element identifies the role of the party involved in the service collaboration in the sibling ServiceBinding elements.

With ebMS2 and ebMS3, this value is used in the eb:From/eb:Role or eb:To/Role headers.

With ebMS3, depending on the exchange binding, this element corresponds to one of the PMode.Initiator.Role or PMode.Responder.Role parameters.

Diagram
Diagram cppa3.tmp#RoleType_name cppa3.tmp#RoleType
Type cppa:RoleType
Properties
content complex
Attributes
QName Type Use Annotation
name cppa:non-empty-string required

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.

[ top ]
Element cppa:CounterPartyRole
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element identifies the role of the counterparty involved in the service collaboration in the sibling ServiceBinding elements.

With ebMS2 and ebMS3, this value is used in From/Role or To/Role headers.

With ebMS3, depending on the exchange binding, this element corresponds to one of the PMode.Initiator.Role or PMode.Responder.Role elements.

Diagram
Diagram cppa3.tmp#RoleType_name cppa3.tmp#RoleType
Type cppa:RoleType
Properties
content complex
Attributes
QName Type Use Annotation
name cppa:non-empty-string required

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.

[ top ]
Element cppa:ServiceBinding
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Diagram
Diagram cppa3.tmp#acl_attributes cppa3.tmp#Description cppa3.tmp#Service cppa3.tmp#ActivationDate cppa3.tmp#ExpirationDate cppa3.tmp#ActionBinding cppa3.tmp#ServiceBindingExtension
Properties
content complex
Children cppa:ActionBinding, cppa:ActivationDate, cppa:Description, cppa:ExpirationDate, cppa:Service, cppa:ServiceBindingExtension
Attributes
QName Type Use Annotation
allowed cppa:party_id_list_ref_type optional
A reference to a list of allowed party identifiers.
denied cppa:party_id_list_ref_type optional
A reference to a list of denied party identifiers.
[ top ]
Element cppa:Service
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#Service_type
Type extension of cppa:non-empty-string
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
type cppa:non-empty-string optional

The attribute define a service type.

[ top ]
Element cppa:ActionBinding
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

An ActionBinding defines a binding for an action in a service. Its actual semantics is beyond the scope of this specification. Like the ebMS3 concept of a processing mode, the binding controls the way messages are processed and provides a configuration that is common to a set of messages exchanged among parties.

This version of CPPA supports actions in One Way exchanges and pairs of actions in Two Way exchanges. An action in a One Way exchange is an action that is not followed by another action that explicitly relates to the One Way exchange action. In Two Way exchanges, one action is expected to be followed by another action that explicitly relates to it. This other action MUST reference the action it relates to using the replyTo attribute. The interpretation of situations in which there are multiple ActionBindings that are replies to the same ActionBinding, is outside the scope of this specification. They may constitute alternative responses. For example, a SubmitOrder action may be replied to by an AcceptOrder action or a RejectOrder action. When used for actions defined in an ebBP schema document, a One Way exchange corresponds to a RequestingBusinessActivity. A Two Way exchange corresponds to a RequestingBusinessActivity and the corresponding RespondingBusinessActivity

An ActionBinding corresponds with an ebMS3 One Way MEP (identified as http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay) if there is no other ActionBinding that refers to it using the replyTo attribute.

An ebMS3 Two Way MEP (identified as http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/twoWay) corresponds to a collection of at least two ActionBindings. Exactly one of these MUST NOT have a replyTo attribute. This constitutes the first leg in the MEP. All other ActionBindings in this collection relate to the second leg in the message exchange. They MUST have a replyTo reference to the ActionBinding corresponding to the first leg. For ebMS3, specification of alternative responses is an issue to possibly be addressed in a future errata.

ActionBinding elements with values send or receive for the sendOrReceive attribute correspond to the CPPA version 2.0 CanSend and CanReceive elements, respectively.

In a CPP, an ActionBinding is associated with one or multiple channels, identified using their ChannelId. If there is more than one reference to a channel, the presented channels are alternatives, with preferred bindings preceding less preferred alternatives. For example, a party may offer an ebMS3 channel that is preferred as well as an ebMS2 channel that is supported for legacy connections.

In a CPA, there MUST be exactly one ChannelID, covering the channel for both parties.

In a CPP, the CPPA3 schema associates an ActionBinding with zero or multiple payload profiles, identified using a PayloadProfileId. If there is more than one reference to a payload profile, the presented payload profiles are alternatives, with preferred bindings preceding less preferred alternatives. In the absence of any PayloadProfileId elements, there are no contraints on payloads that are exchanged.

In a CPA, there MUST be at most one PayloadProfileId, covering the payload profile that both parties agree to use. In the absence of any PayloadProfileId elements, there are no contraints on payloads that are exchanged.

When a CPA is used in combination with the ebMS2 or ebMS3 messaging protocols, the Service and Action message headers and the Service element content and the action attribute of ActionBinding in the CPA can be linked to infer the applicable ActionBinding, with its Channel and PayloadProfile. This mapping is unambiguous if, in the context of an ServiceBinding, only a single ActionBinding exists for any given pair of values for the action and sendOrReceive attributes.

An ActionBinding MAY contain Property elements that associate additional metadata with the messages. The semantics of these elements MAY depend on the Service context of the ActionBinding.

The use of Property elements MAY depend on the messaging protocol used. In ebMS3, the elements control the use of Message Properties. In AMQP, they map to AMQP Application Properties.

Sets of Property elements MAY also be referenced using the propertySetId attribute. If any Property elements are present, the propertySetId attribute MUST NOT be present.

The ActionBindingExtension element is provided to allow extensibility of ActionBinding elements.

Diagram
Diagram cppa3.tmp#ActionBinding_id cppa3.tmp#ActionBinding_action cppa3.tmp#ActionBinding_businessTransactionActivity cppa3.tmp#ActionBinding_collaborationActivity cppa3.tmp#ActionBinding_requestOrResponseAction cppa3.tmp#ActionBinding_sendOrReceive cppa3.tmp#ActionBinding_replyTo cppa3.tmp#ActionBinding_use cppa3.tmp#ActionBinding_propertySetId cppa3.tmp#acl_attributes cppa3.tmp#ChannelId cppa3.tmp#PayloadProfileId cppa3.tmp#Property cppa3.tmp#ActionBindingExtension
Properties
content complex
Children cppa:ActionBindingExtension, cppa:ChannelId, cppa:PayloadProfileId, cppa:Property
Attributes
QName Type Default Use Annotation
action xs:anyURI required

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.

allowed cppa:party_id_list_ref_type optional
A reference to a list of allowed party identifiers.
businessTransactionActivity cppa:non-empty-string optional

When used for actions defined in an ebBP schema document, the value of this attribute MUST match ComplexBusinessTransactionActivity/@name or BusinessTransactionActivity/@name

collaborationActivity cppa:non-empty-string optional

When used for actions defined in an ebBP schema document, the value of this attribute MUST match a defined CollaborationActivity/@name.

denied cppa:party_id_list_ref_type optional
A reference to a list of denied party identifiers.
id xs:ID required

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.
propertySetId xs:IDREF optional
A reference to a PropertySet. If this attribute is present in an ActionBinding, there MUST NOT be any Property child elements.
replyTo xs:IDREF optional

This attribute MAY be used to express that an action is a response to some other action and to identify that action. When bound to ebMS2 or ebMS3, this attribute also expresses that on messages for this action a RefToMessageId element is REQUIRED.

If ActionBinding X references another ActionBinding Y using replyTo, then Y MUST NOT itself reference any other ActionBinding Z.

A referenced ActionBinding MUST be a sibling element, i.e. it MUST be contained in the same ServiceBinding. As a consequence, when used with ebMS2 or ebMS3, the value for the Service header field will be the same for both legs in a Two Way MEP. Also see https://issues.oasis-open.org/browse/EBXMLMSG-73.

When used for actions defined in an ebBP schema document, this attribute MUST be present on actions representing a RespondingBusinessActivity and MUST reference an ActionBinding/@id for the corresponding RequestingBusinessActivity.

requestOrResponseAction cppa:non-empty-string optional

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.
sendOrReceive cppa:send_or_receive_type required

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.
use cppa:usetype required optional

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.

[ top ]
Element cppa:ChannelId
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A ChannelId identifies a channel that MAY be used to exchange a message in the context of a CPPA3 document.

In a CPP, multiple occurrences of ChannelId MAY be specified in an ActionBinding. A sequence of two or more ChannelId elements expresses alternative channels which the party is willing to use for the message exchange. The semantics of the order corresponds to a preference. If ChannelId X preceeds ChannelId Y within the scope of an ActionBinding, then the Party prefers use of X over Y for the specified action.

In a CPA, exactly one ChannelId MUST be present in an ActionBinding. It identifies the channel that Party and CounterParty agree to bind the specified action to.

Diagram
Diagram
Type xs:IDREF
Properties
content simple
[ top ]
Element cppa:PayloadProfileId
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A PayloadProfileId identifies a payload profile that MAY be used in the exchange of message for an ActionBinding.

In a CPP, multiple occurrences of PayloadProfileId MAY be specified in an ActionBinding. A sequence of two or more PayloadProfileId elements expresses alternative payload profiles which the party is willing to use for the ActionBinding. The semantics of the order corresponds to a preference. If PayloadProfileId X preceeds PayloadProfileId Y within the scope of an ActionBinding, then the Party prefers use of X over Y for the specified action.

In a CPA, at most one PayloadProfileId MUST be present. It identifies the payload profile that Party and CounterParty agree to bind the specified action to.

Diagram
Diagram
Type xs:IDREF
Properties
content simple
[ top ]
Element cppa:Property
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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).

Diagram
Diagram cppa3.tmp#Property_name cppa3.tmp#Property_type cppa3.tmp#Property_value cppa3.tmp#Property_minOccurs cppa3.tmp#Property_maxOccurs cppa3.tmp#Description
Properties
content complex
Children cppa:Description
Attributes
QName Type Use Annotation
maxOccurs cppa:maxoccurstype optional
The maximum occurrence of the property. In ebMS3, the allowed value is 1.
minOccurs xs:nonNegativeInteger optional
The minimum occurrence of the property. In ebMS3, the allowed values are 0 or 1.
name cppa:non-empty-string required
The name of the property.
type xs:anyURI optional
value cppa:non-empty-string optional
The value of the property, if the property has a fixed value. Note that this functionality is not mentioned in D.3.3 of [EBMS3CORE].
[ top ]
Element cppa:ActionBindingExtension
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
An abstract ActionBinding Extension element
Diagram
Diagram cppa3.tmp#ActionBindingExtensionType
Type cppa:ActionBindingExtensionType
Properties
content complex
abstract true
[ top ]
Element cppa:ServiceBindingExtension
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
An abstract ServiceBinding Extension element
Diagram
Diagram cppa3.tmp#ServiceBindingExtensionType
Type cppa:ServiceBindingExtensionType
Properties
content complex
abstract true
[ top ]
Element cppa:ServiceSpecificationExtension
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
An abstract ServiceSpecification Extension element
Diagram
Diagram cppa3.tmp#ServiceSpecificationExtensionType
Type cppa:ServiceSpecificationExtensionType
Properties
content complex
abstract true
[ top ]
Element cppa:PropertySet
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The PropertySet element defines a set of Property elements. It supports definitions of property sets that are reusable.

Diagram
Diagram cppa3.tmp#PropertySetType_id cppa3.tmp#Description cppa3.tmp#Property cppa3.tmp#PropertySetType
Type cppa:PropertySetType
Properties
content complex
Children cppa:Description, cppa:Property
Attributes
QName Type Use Annotation
id xs:ID optional
An XML identifier, allowing property definitions to be referenced within the XML document.
[ top ]
Element cppa:Channel
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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:

  1. 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.
  2. 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.

Diagram
Diagram cppa3.tmp#ChannelType_id cppa3.tmp#ChannelType_transport cppa3.tmp#ChannelType_asResponse cppa3.tmp#ChannelType_package cppa3.tmp#Description cppa3.tmp#ChannelProfile cppa3.tmp#MaxSize cppa3.tmp#ChannelType cppa3.tmp#AMQPChannel cppa3.tmp#DelegationChannel cppa3.tmp#EDIINTChannel cppa3.tmp#NamedChannel cppa3.tmp#TransportChannel cppa3.tmp#WSChannel cppa3.tmp#ebMS2Channel cppa3.tmp#ebMS3Channel
Type cppa:ChannelType
Properties
content complex
abstract true
Substitution Group
Children cppa:ChannelProfile, cppa:Description, cppa:MaxSize
Attributes
QName Type Use Annotation
asResponse xs:boolean optional

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.

id xs:ID required
A unique identifier for the Channel for cross-referencing within the XML document.
package xs:IDREF optional

The package attribute references a Package for a Channel.

This attribute MUST NOT be used for channels used for protocol message types that have a fixed and predictable format, such as receipts and erors.

transport xs:IDREF optional

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.

[ top ]
Element cppa:ChannelProfile
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:anyURI
Properties
content simple
[ top ]
Element cppa:MaxSize
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

Define the maximum value for some size aspect of a message or message part.

Diagram
Diagram cppa3.tmp#posfloat cppa3.tmp#SizeType_unit cppa3.tmp#SizeType
Type cppa:SizeType
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
unit restriction of xs:token optional
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.
[ top ]
Element cppa:ChannelFeature
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#ChannelFeatureType_id cppa3.tmp#ChannelFeatureType cppa3.tmp#Addressing cppa3.tmp#Bundling cppa3.tmp#Compression cppa3.tmp#ErrorHandling cppa3.tmp#ReceiptHandling cppa3.tmp#ReliableMessagingBinding cppa3.tmp#SecurityPolicy cppa3.tmp#Splitting cppa3.tmp#WSSecurityBinding cppa3.tmp#ebMS2SecurityBinding
Type cppa:ChannelFeatureType
Properties
content complex
abstract true
Substitution Group
Attributes
QName Type Use Annotation
id xs:ID optional
Identifier of the channel feature. This allows the feature to be reused in multiple channels.
[ top ]
Element cppa:Transport
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

An abstract element to configure a transport.

Diagram
Diagram cppa3.tmp#TransportType_id cppa3.tmp#Description cppa3.tmp#TransportType cppa3.tmp#TCPTransport
Type cppa:TransportType
Properties
content complex
abstract true
Substitution Group
Children cppa:Description
Attributes
QName Type Use
id xs:ID required
[ top ]
Element cppa:PayloadProfile
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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:

  1. 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.

Diagram
Diagram cppa3.tmp#PayloadProfile_id cppa3.tmp#Description cppa3.tmp#PayloadPart
Properties
content complex
Children cppa:Description, cppa:PayloadPart
Attributes
QName Type Use
id xs:ID optional
[ top ]
Element cppa:PayloadPart
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The PayloadPart element provides a logical definition of a payload part. A PayloadPart MAY be referenced from a PayloadProfile and from a Packaging element.

A PayloadPart MAY be signed at payload-level. A Signature element MAY be provided to record any relevant constraints on payload signatures, such as constraints on certificates or algorithms to be used. Note that processing such signatures is not functionality of the Channel and does not have to be provided by the Message Service handling that channel, but by business applications or other components that produce or consume payloads.

Similarly, a PayloadPart MAY be encrypted at payload-level. If this is the case, an Encryption element MAY be provided to provide any relevant constraints. As with payload signing, this encryption is not functionality of the Channel and the responsible Message Service Handler.

Presence of the Signature and Encryption element defines constraints on, respectively, signing and encryption. Absence of these elements specifies that no constraints are set. Whether payload level signing and encryption is required can be expressed using the requireSignature requireEncryption attributes.

In CPPA3, the Signature and Encryption elements and the requireSignature and requireEncryption attributes provide functionality similar to the CPPA2 ApplicationCertificateRef and ApplicationCertificateDetails elements. A difference is that CPPA2 defined these at CollaborationRole level, whereas CPPA3 defines them at PayloadPart level.

Note that use of the Signature and Encryption elements and the requireSignature and requireEncryption attributes is not required when messaging is used in a payload-content agnostic way. In that situation, messaging products MAY ignore the values of these elements. However, in those situations CPPA3 may still be useful. For example, any distribution mechanisms for CPPA3 could be leveraged to distribute keys to applications.

In ebMS3, a PayloadPart corresponds to an item on a PMode[1].BusinessInfo.PayloadProfile[] list.

A PayloadPart MAY be associated with one or multiple Schema elements. If more than one Schema element is specified, the part MUST conform to all specified schemas. For example, an XML document may have to conform to both a generic XML document schema and to a set of transaction-specific business rules expressed in another schema language.

For ebMS3, these elements in this type map to the payload properties defined for PayloadProfile[] items, as defined in D.3.3. of ebMS3 CORE.

Diagram
Diagram cppa3.tmp#PayloadPart_minOccurs cppa3.tmp#PayloadPart_maxOccurs cppa3.tmp#PayloadPart_requireSignature cppa3.tmp#PayloadPart_requireEncryption cppa3.tmp#Description cppa3.tmp#PartName cppa3.tmp#MIMEContentType cppa3.tmp#Schema cppa3.tmp#MaxSize cppa3.tmp#Property cppa3.tmp#http___docs.oasis-open.org_ebcore_ns_cppa_v3.0_Signature cppa3.tmp#Encryption
Properties
content complex
Children cppa:Description, cppa:Encryption, cppa:MIMEContentType, cppa:MaxSize, cppa:PartName, cppa:Property, cppa:Schema, cppa:Signature
Attributes
QName Type Use Annotation
maxOccurs cppa:maxoccurstype optional
minOccurs xs:nonNegativeInteger optional
requireEncryption xs:boolean optional
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.
requireSignature xs:boolean optional
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.
[ top ]
Element cppa:PartName
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element specifies a name for the payload part. This element is used to map parts defined in a payload profile to package definitions.

Diagram
Diagram
Type xs:token
Properties
content simple
[ top ]
Element cppa:MIMEContentType
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

Specifies the MIME content type of the part.

Diagram
Diagram
Type xs:token
Properties
content simple
[ top ]
Element cppa:Schema
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#Schema_location cppa3.tmp#Schema_version cppa3.tmp#Schema_namespace cppa3.tmp#Schema_element cppa3.tmp#Description
Properties
content complex
Children cppa:Description
Attributes
QName Type Use Annotation
element cppa:non-empty-string optional

For XML parts, this attribute specifies the name of an XML element that MUST be used as the root of the part.

If this attribute is used, for schemas that use namespaces the namespace attribute MUST be set as well.

location xs:anyURI optional

The location of the schema as a URI.

namespace cppa:non-empty-string optional

For XML parts, this attribute specifies the namespace of the root element.

version cppa:non-empty-string optional

If not specified in a located schema, the schema version can be specified using this attribute.

[ top ]
Element cppa:Signature
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The Signature element configures message signing. The CPPA3 Signature element is modelled after the W3C XML Signature structure [XMLDSIG-CORE, XMLDSIG-CORE1] but is also used to configure EDIINT.

In ebMS3, this type corresponds to the PMode[1].Security.X509.* parameters.

In a CPP, SignatureAlgorithm, DigestAlgorithm and CanonicalizationMethod MAY occur more than once, expressing alternative options. In a CPA, they MUST occur at most once, expressing the agreed option.

For EDIINT protocols, the SignElements, SignAttachments, SignExternalPayloads and SAMLTokenRef elements MUST NOT be used.

If the SignatureAlgorithm and DigestAlgorithm elements are not present, they MUST be specified indirectly, via the definition of a ChannelProfile.

If one or more SigningCertificatePolicySetRef elements is present, Policy Certification Authority certificates and the issuing Certificate Authority certificate in the signing certificate chain MUST contain a certificatePolicies X.509 extension, the values of which MUST be within the set of referenced policies.

Diagram
Diagram cppa3.tmp#SignatureFormat cppa3.tmp#SignatureAlgorithm cppa3.tmp#DigestAlgorithm cppa3.tmp#http___docs.oasis-open.org_ebcore_ns_cppa_v3.0_CanonicalizationMethod cppa3.tmp#SignatureTransformation cppa3.tmp#SigningCertificateRef cppa3.tmp#SigningCertificateRequired cppa3.tmp#SigningTrustAnchorSetRef cppa3.tmp#SigningCertificatePolicySetRef cppa3.tmp#SigningCertificateRefType cppa3.tmp#SAMLTokenRef cppa3.tmp#SignElements cppa3.tmp#SignAttachments cppa3.tmp#SignExternalPayloads
Properties
content complex
Children cppa:CanonicalizationMethod, cppa:DigestAlgorithm, cppa:SAMLTokenRef, cppa:SignAttachments, cppa:SignElements, cppa:SignExternalPayloads, cppa:SignatureAlgorithm, cppa:SignatureFormat, cppa:SignatureTransformation, cppa:SigningCertificatePolicySetRef, cppa:SigningCertificateRef, cppa:SigningCertificateRefType, cppa:SigningCertificateRequired, cppa:SigningTrustAnchorSetRef
[ top ]
Element cppa:SignatureFormat
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element identifiers a format to be used for signatures. It MUST NOT be used in contexts where only a single signature format is used, or where it is not possible to select a specific format, or where it is not common to specify the format.

For EDIINT, a common value is pkcs7-signature.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#SignatureFormat_version
Type extension of cppa:non-empty-string
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
version cppa:non-empty-string optional

The version number of the signature format.

[ top ]
Element cppa:SignatureAlgorithm
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element defines the signature algorithm to be used for generating and validating the signature.

In ebMS3, this corresponds to the PMode[1].Security.X509.Signature.Algorithm parameter.

Diagram
Diagram cppa3.tmp#AlgorithmType_version cppa3.tmp#AlgorithmType
Type cppa:AlgorithmType
Properties
content complex
Attributes
QName Type Use Annotation
version optional
An optional version indicator of the algorithm
[ top ]
Element cppa:DigestAlgorithm
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#AlgorithmType_version cppa3.tmp#AlgorithmType
Type cppa:AlgorithmType
Properties
content complex
Attributes
QName Type Use Annotation
version optional
An optional version indicator of the algorithm
[ top ]
Element cppa:CanonicalizationMethod
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The Canonicalization method to be applied in the creation of the signature.

This element does not correspond to any ebMS3 PMode parameter.

Diagram
Diagram
Type xs:anyURI
Properties
content simple
[ top ]
Element cppa:SignatureTransformation
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The Signature Transformation method to be applied in the creation of the signature.

This element does not correspond to any ebMS3 PMode parameter.

Diagram
Diagram
Type xs:anyURI
Properties
content simple
[ top ]
Element cppa:SigningCertificateRequired
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:boolean
Properties
content simple
[ top ]
Element cppa:SigningCertificateRefType
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

Specifies how the signing certificate is referenced in the WS-Security header

Diagram
Diagram cppa3.tmp#WSSSecurityTokenReferenceType
Type cppa:WSSSecurityTokenReferenceType
Properties
content simple
Facets
enumeration SubjectKeyIdentifier
enumeration BinarySecurityToken
enumeration X509IssuerSerial
enumeration X509Digest
[ top ]
Element cppa:SAMLTokenRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

A reference to a SAML token.

Diagram
Diagram cppa3.tmp#SecurityTokenRefType cppa3.tmp#SAMLTokenRefType_tokenId cppa3.tmp#SAMLTokenRefType cppa3.tmp#SecurityTokenRef
Type cppa:SAMLTokenRefType
Type hierarchy
Properties
content complex
Substitution Group Affiliation
Attributes
QName Type Use Annotation
tokenId xs:IDREF required
A IDREF type reference to a SAML token
[ top ]
Element cppa:SignElements
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#Expression
Properties
content complex
Children cppa:Expression
[ top ]
Element cppa:Expression
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element expresses an XPath expression.

If namespaces are used, XPath expressions MUST use namespaces in Clark notation ({ns}name) to obviate the need for shared values and definitions of prefixes.

Diagram
Diagram cppa3.tmp#non-empty-string
Type cppa:non-empty-string
Properties
content simple
Facets
minLength 1
[ top ]
Element cppa:SignAttachments
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:boolean
Properties
content simple
[ top ]
Element cppa:SignExternalPayloads
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element specifies if external payloads are to be signed.

This element MUST NOT be present in message formats that do not support external payloads or signing of external payloads.

There is no corresponding ebMS3 PMode parameter for this element.

Diagram
Diagram
Type xs:boolean
Properties
content simple
[ top ]
Element cppa:Encryption
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#EncryptionFormat cppa3.tmp#KeyEncryption cppa3.tmp#EncryptionAlgorithm cppa3.tmp#EncryptElements cppa3.tmp#EncryptAttachments cppa3.tmp#EncryptExternalPayloads cppa3.tmp#EncryptionCertificateRef cppa3.tmp#EncryptionCertificateRequired cppa3.tmp#EncryptionTrustAnchorSetRef cppa3.tmp#EncryptionCertificatePolicySetRef cppa3.tmp#EncryptionCertificateRefType
Properties
content complex
Children cppa:EncryptAttachments, cppa:EncryptElements, cppa:EncryptExternalPayloads, cppa:EncryptionAlgorithm, cppa:EncryptionCertificatePolicySetRef, cppa:EncryptionCertificateRef, cppa:EncryptionCertificateRefType, cppa:EncryptionCertificateRequired, cppa:EncryptionFormat, cppa:EncryptionTrustAnchorSetRef, cppa:KeyEncryption
[ top ]
Element cppa:EncryptionFormat
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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#.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#EncryptionFormat_version
Type extension of cppa:non-empty-string
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
version cppa:non-empty-string optional

The version number of the encryption format.

[ top ]
Element cppa:KeyEncryption
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The KeyTransport element supports the configuration of encryption key transport. It is designed to configure use of XML Encryption Key Transport and similar protocols.

Diagram
Diagram cppa3.tmp#EncryptionAlgorithm cppa3.tmp#MaskGenerationFunction cppa3.tmp#DigestAlgorithm
Properties
content complex
Children cppa:DigestAlgorithm, cppa:EncryptionAlgorithm, cppa:MaskGenerationFunction
[ top ]
Element cppa:EncryptionAlgorithm
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element can be used to specify the key transport algorithm and the data encryption algorithm.

Key Transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys. When using XML Encryption the value of this element can be used as value in KeyEncryption to determine xenc:EncryptedKey / xenc:EncryptionMethod / @Algorithm. The value is an identifier of an encryption algorithm like http://www.w3.org/2009/xmlenc11#rsa-oaep.

In ebMS3, see https://issues.oasis-open.org/browse/EBXMLMSG-45.

When using XML Encryption, the EncryptionAlgorithm element can also be used in DataEncryption to set the value of the xenc:EncryptedData / xenc:EncryptionMethod / @Algorithm attribute. The value is an identifier like http://www.w3.org/2009/xmlenc11#aes128-gcm

In ebMS3, this corresponds to the PMode[1].Security.X509.Encryption.Algorithm parameter.

Diagram
Diagram cppa3.tmp#AlgorithmType_version cppa3.tmp#AlgorithmType
Type cppa:AlgorithmType
Properties
content complex
Attributes
QName Type Use Annotation
version optional
An optional version indicator of the algorithm
[ top ]
Element cppa:MaskGenerationFunction
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element specifies the use of a mask generation function.

The value is an identifier of a mask generation function like http://www.w3.org/2009/xmlenc11#mgf1sha256.

When using XML encryption, it specifies the value of xenc:EncryptedKey / xenc:EncryptionMethod / xenc11:MGF.

Diagram
Diagram cppa3.tmp#AlgorithmType_version cppa3.tmp#AlgorithmType
Type cppa:AlgorithmType
Properties
content complex
Attributes
QName Type Use Annotation
version optional
An optional version indicator of the algorithm
[ top ]
Element cppa:EncryptElements
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#Expression
Properties
content complex
Children cppa:Expression
[ top ]
Element cppa:EncryptAttachments
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:boolean
Properties
content simple
[ top ]
Element cppa:EncryptExternalPayloads
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:boolean
Properties
content simple
[ top ]
Element cppa:EncryptionCertificateRequired
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram
Type xs:boolean
Properties
content simple
[ top ]
Element cppa:EncryptionCertificateRefType
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element specifies how the encryption certificate is referenced in the WS-Security header

Diagram
Diagram cppa3.tmp#WSSSecurityTokenReferenceType
Type cppa:WSSSecurityTokenReferenceType
Properties
content simple
Facets
enumeration SubjectKeyIdentifier
enumeration BinarySecurityToken
enumeration X509IssuerSerial
enumeration X509Digest
[ top ]
Element cppa:Packaging
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#PackagingType_id cppa3.tmp#Description cppa3.tmp#PackagingType cppa3.tmp#MIMEEnvelope cppa3.tmp#MTOMEnvelope cppa3.tmp#SOAPWithAttachmentsEnvelope cppa3.tmp#SimpleSOAPEnvelope
Type cppa:PackagingType
Properties
content complex
abstract true
Substitution Group
Children cppa:Description
Attributes
QName Type Use Annotation
id xs:ID optional

Identifier of the Package in the CPP or CPA.

[ top ]
Element cppa:PartyIdList
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

This element defines a list of party identifiers or (recursively) references to lists of party identifiers. The list logically includes all PartyIds included as direct child elements of the PartyIdList element, as well as all PartyIds indirectly included as child elements of PartyIdLists referenced (possibly recursively) as PartyIdListRef child elements.

Party Id lists are used for white listing and black listing counterparties in CPPs, using the allowed and denied attributes.

Party Id list references MUST NOT be circular.

Diagram
Diagram cppa3.tmp#PartyIdList_id cppa3.tmp#PartyId cppa3.tmp#PartyIdListRef
Properties
content complex
Children cppa:PartyId, cppa:PartyIdListRef
Attributes
QName Type Use Annotation
id xs:ID optional
A unique identifier of the party identifier list.
[ top ]
Element cppa:PartyIdListRef
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Diagram
Diagram cppa3.tmp#PartyIdListRef_href
Type extension of xs:string
Properties
content complex
Attributes
QName Type Use Annotation
href xs:anyURI optional
A reference to a PartyIdList.
[ top ]
Element cppa:CPPAExtension
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations
An abstract top level CPP or CPA Extension element
Diagram
Diagram cppa3.tmp#CPPAExtensionType
Type cppa:CPPAExtensionType
Properties
content complex
abstract true
[ top ]
Element cppa:CPA
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

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.

Diagram
Diagram cppa3.tmp#AgreementInfo cppa3.tmp#PartyInfo cppa3.tmp#CounterPartyInfo cppa3.tmp#ServiceSpecification cppa3.tmp#PropertySet cppa3.tmp#Channel cppa3.tmp#ChannelFeature cppa3.tmp#Transport cppa3.tmp#PayloadProfile cppa3.tmp#Packaging cppa3.tmp#CPPAExtension
Properties
content complex
Children cppa:AgreementInfo, cppa:CPPAExtension, cppa:Channel, cppa:ChannelFeature, cppa:CounterPartyInfo, cppa:Packaging, cppa:PartyInfo, cppa:PayloadProfile, cppa:PropertySet, cppa:ServiceSpecification, cppa:Transport, ds:Signature
[ top ]
Element cppa:AgreementInfo
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The AgreementInfo element provides metadata about the CPA.

Diagram
Diagram cppa3.tmp#AgreementIdentifier cppa3.tmp#Description cppa3.tmp#ProfileIdentifier cppa3.tmp#ActivationDate cppa3.tmp#ExpirationDate
Properties
content complex
Children cppa:ActivationDate, cppa:AgreementIdentifier, cppa:Description, cppa:ExpirationDate, cppa:ProfileIdentifier
[ top ]
Element cppa:AgreementIdentifier
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The AgreementIdentifier element is used to provide an identifier for the agreement. The type value and element content of the element MUST be unique in the context of the pair of parties to which it relates.

Communities MAY adopt format conventions for the value of the AgreementIdentifier element. For example, the value MAY be derived from the values of two CPP ProfileIdentifiers (if the CPA is formed from CPP) or from the (Counter)PartyInfo/PartyId values in the CPA. CPA tooling MAY allow users to specify and apply specific conventions.

The element corresponds, for ebMS2, to the CPAId message header

For ebMS3, it naturally corresponds to the PMode.Agreement parameter and AgreementRef header. However, that parameter and header are sometimes used to specify adherence to multilateral, community agreements. In that case, they are then more like a CPPA3 ChannelProfile indicator.

Diagram
Diagram cppa3.tmp#non-empty-string cppa3.tmp#AgreementIdentifier_type
Type extension of cppa:non-empty-string
Type hierarchy
Properties
content complex
Attributes
QName Type Use Annotation
type xs:anyURI optional

The type attribute defines a namespace in which the value of AgreementIdentifier is to be interpreted.

[ top ]
Element cppa:CounterPartyInfo
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

The CounterPartyInfo element provides information about a CounterParty. This element is only used in CPA.

When used for ebMS3, this element encodes some information relating to the PMode.{Initiator/Responder}.Party parameters.

Diagram
Diagram cppa3.tmp#PartyInfoType_href cppa3.tmp#PartyName cppa3.tmp#PartyId cppa3.tmp#PartyContact cppa3.tmp#Certificate cppa3.tmp#TrustAnchorSet cppa3.tmp#CertificatePolicySet cppa3.tmp#CertificateDefaults cppa3.tmp#IDPRegistration cppa3.tmp#IDPRegistrationSet cppa3.tmp#SSHKey cppa3.tmp#PartyInfoExtension cppa3.tmp#PartyInfoType
Type cppa:PartyInfoType
Properties
content complex
Children cppa:Certificate, cppa:CertificateDefaults, cppa:CertificatePolicySet, cppa:IDPRegistration, cppa:IDPRegistrationSet, cppa:PartyContact, cppa:PartyId, cppa:PartyInfoExtension, cppa:PartyName, cppa:SSHKey, cppa:TrustAnchorSet
Attributes
QName Type Use Annotation
href xs:anyURI optional

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.

[ top ]
Element cppa:SecurityToken
Namespace http://docs.oasis-open.org/ebcore/ns/cppa/v3.0
Annotations

An abstract Security Token

Diagram
Diagram cppa3.tmp#SecurityTokenType_id cppa3.tmp#SecurityTokenType cppa3.tmp#Certificate cppa3.tmp#SAMLToken cppa3.tmp#SSHKey
Type cppa:SecurityTokenType
Properties
content complex
abstract true
Substitution Group
Attributes
QName Type Use Annotation
id xs:ID optional
A unique identifier for the security token.