CPPA3 Overview

CPPA3 Version 3 of ebXML Collaboration Protocol Profiles (CPP) and Agreements (CPA) Successor to version 2, which is in use since around 2004. In draft: Specification XML schema Schema documentation

Overview of the CPPA3 Schema

CPP Profile of a Party Cross-references for layering and reuse Profile Metadata (specific, version, validity intervals) Party Information Service Information Channels, Channel Features and Transports Payload Profiles and Packaging Access Control Information Cross-references for layering and reuse Profile can be signed Optional Extension Elements

CPA Agreement between a Party and a CounterParty Profile Metadata (identifier, validity intervals) Party Information Counter Party Information Messaging configuration as in CPP Signatures Optional Extension elements

Profile Metadata <cppa:ProfileInfo> <cppa:ProfileIdentifier>Acpp</cppa:ProfileIdentifier> <cppa:ActivationDate>2014-01-01T00:00:00</cppa:ActivationDate> <cppa:ExpirationDate>2021-01-01T00:00:00</cppa:ExpirationDate> <cppa:PhaseIn>P10D</cppa:PhaseIn> </cppa:ProfileInfo>

Agreement Metadata <c<cppa:AgreementInfo> <cppa:AgreementIdentifier>Acpp_Bcpp</cppa:AgreementIdentifier> <cppa:Description xml:lang="en">Agreement formed from Acpp and Bcpp at 2017-08-17T17:26:39.983969</cppa:Description> <cppa:ProfileIdentifier href="http://a.example.com/acpp.xml">Acpp</cppa:ProfileIdentifier> <cppa:ProfileIdentifier href="http://b.example.com/bccp.xml">Bcpp</cppa:ProfileIdentifier> <cppa:ActivationDate>2017-08-27T17:26:39.984004</cppa:ActivationDate> <cppa:ExpirationDate>2021-01-01T00:00:00</cppa:ExpirationDate> </cppa:AgreementInfo>

Service Specification Services for a Business Process Area Party Role and Counter Party Role Service Bindings covers sending and receiving actions Actions bound to channels and payload profiles

Service Specifications Service Specifications can link to versioned business process choreography descriptions For example, OASIS ebBP or OMG BPMN Sample Norway e-Health / Social Security profile in CPPA3 format converted from production CPPA2 sample indicates support for multiple versions of some processes:

Sample v2.5 of IndividuellRefusjon process and service, two sending and two receiving actions, bindings to an ebMS2 over SMTP channel

Sample ENTSOG Service Specification for ZSH/ZSO role pair, services A09 and A06

Channels Abstract schema element Channel supporting extensibility using substitutions for specific messaging protocols For example ebMS3Channel for ebMS3/AS4 Channels have attributes : id attribute, so actions can be bound bind to channels transport attribute binds a channel to a transport (e.g. HTTPChannel) Optional cross-references to reused channel feature descriptions Channels can be: Bound to transports and packaging Related to each other (one channel supporting a feature of another channel)

Channel definition samples (1 and 2) Base case, channel is fully defined by referencing a predefined agreed channel profile, referencing a transport and a package Variant channel, based on same channel but overrides the compression feature definition (preferring brotli compression but still accepting gzip)

Channel Definition Sample (3) <cppa:ebMS3Channel id="_BXCX" transport="_65FN" package="_BQR5"> <cppa:Description xml:lang="en">Channel formed from a_ch_send (Channel for outgoing ENTSOG AS4 User Messages) in ENTSOG AS4 Profile for TSO 1 and b_b_ch_receive (Channel for incoming ENTSOG AS4 User Messages) in ENTSOG AS4 Profile for TSO 2</cppa:Description> <cppa:ChannelProfile>http://www.entsog.eu/publications/as4#AS4-USAGE-PROFILE/v2.0/UserMessageChannel</cppa:ChannelProfile> <cppa:SOAPVersion>1.2</cppa:SOAPVersion> <cppa:WSSecurityBinding> <cppa:WSSVersion>1.1</cppa:WSSVersion> <cppa:Signature> <cppa:SignatureAlgorithm>https://www.w3.org/2001/04/xmldsig-more#rsa-sha256</cppa:SignatureAlgorithm> <cppa:DigestAlgorithm>http://www.w3.org/2001/04/xmlenc#sha256</cppa:DigestAlgorithm> <cppa:SigningCertificateRef certId="_OYHRBO"/> </cppa:Signature> <cppa:Encryption> <cppa:KeyEncryption> <cppa:EncryptionAlgorithm> http://www.w3.org/2009/xmlenc11#rsa-oaep</cppa:EncryptionAlgorithm> <cppa:MaskGenerationFunction>http://www.w3.org/2009/xmlenc11#mgf1sha256</cppa:MaskGenerationFunction> <cppa:DigestAlgorithm>http://www.w3.org/2001/04/xmlenc#sha256</cppa:DigestAlgorithm> </cppa:KeyEncryption> <cppa:EncryptionAlgorithm>http://www.w3.org/2009/xmlenc11#aes128-gcm</cppa:EncryptionAlgorithm> <cppa:EncryptionCertificateRef certId="_4UP74O"/> </cppa:Encryption> </cppa:WSSecurityBinding> <cppa:AS4ReceptionAwareness> <cppa:DuplicateHandling> <cppa:DuplicateElimination>true</cppa:DuplicateElimination> <cppa:PersistDuration>P10D</cppa:PersistDuration> </cppa:DuplicateHandling> <cppa:RetryHandling> <cppa:Retries>5</cppa:Retries> <cppa:RetryInterval>PT30S</cppa:RetryInterval> </cppa:RetryHandling> </cppa:AS4ReceptionAwareness> <cppa:ErrorHandling> <cppa:DeliveryFailuresNotifyProducer>true</cppa:DeliveryFailuresNotifyProducer> <cppa:ReceiverErrorsReportChannelId>_ODHW</cppa:ReceiverErrorsReportChannelId> </cppa:ErrorHandling> <cppa:ReceiptHandling> <cppa:ReceiptChannelId>_ODHW</cppa:ReceiptChannelId> </cppa:ReceiptHandling> <cppa:Compression> <cppa:CompressionAlgorithm>application/gzip</cppa:CompressionAlgorithm> </cppa:Compression> </cppa:ebMS3Channel> Channel Definition Sample (3) Expands the definition by adding the implied default feature settings (can be automated)

Channel Definition Samples (4) Channel defined using reusable channel feature definitions for security, reliable messaging, error handling, receipt handling and compression Only the SOAP version needs stating

Binding Actions to Channels Sequence of ChannelId elements expresses alternatives, ordered by decreasing preference Could be used for migrations (e.g. AS2 to AS4)

Channel Features Configure a feature of a channel, for example use of security Can be linked to a channel by ID reference or as nested subelement

Delegation Allows a party to express that an action is delegated to use a channel provided by a third party Delegation is a channel like any other channel Use delegation as one of multiple alternative channels Use alternative delegation channels to associate with more than one service provider Service provider models: Three corner: A delegates sending to C, B delegates receiving to C Four corner: A delegates sending to C, B delegates receiving to D, C and D are known to be interconnected

Transports Configure the use of a transport (like HTTP) for a channel Configure networking (protocols, security)

Payload Profiles Configure payload parts used Optionally specify schema

Packaging Specify how payload parts are enveloped Only useful when packaging is not (fully) defined by the message protocol

Certificates and Trust Anchors Parties can specify certificates they use and where/for which purpose they use them PKI optional Parties can specify trust anchors, lists of CA root certificates, that counterparty certificates must chain to Different services, or different protocols, can have different trust anchor lists

Access Control Profile elements can be annotated with “allowed” and “denied” attributed Global settings on CPP root element At other levels for more fine-grained control (e.g. limit a particular service to a subset) Values are identifiers of lists of identifiers of allowed or denied parties Can be used to created “views” for particular audience Can be used to restrict agreements

CPPA3 Predefined algorithms

Algorithms Pre-defined in CPPA3 specification Implemented in open source cppa3 toolkit, https://pypi.org/project/cppa3/ Formation Create a CPA from a presented pair of CPPs Matching Checks if a presented CPA is consistent with a presented CPP

Main Functionality Validity interval Service Specification with mirroring role pairs Service binding with mirroring send/receive action pairs Compatibility checks on channels, channel features, transport, payload profiles, packaging Intersecting where profile specifies alternatives Check certificates against trust anchors Check authorization (allowed/denied parties) Check delegation Etc.

DISCOVERY and registration

e-business discovery vision of ebXML (AD 2001)

Discovery and Registration BDX Location DNS-based discovery of metadata service for a known party Returns HTTPS URL for a CPPA3 CPP Metadata Service Retrieve of CPP using (anonymous or authenticated) HTTPS Custom “views” based on client identity and allow/deny authorization annotations CPA creation can be automated using “formation” algorithm Agreement Registration Propose registration of a CPA that matches (extends) retrieved CPP Can be automated using “match” algorithm

Sample Flow

Implementations and Applications

CPPA3 library Python open source cppa3 toolkit https://pypi.org/project/cppa3/ Modules: Formation of a CPA from two CPPs Match a CPA against a CPP Create a “view” on a CPP Macro expansion for “ChannelProfile”, allowing for overrides Upconvert a v2 CPP or CPA to CPPA3 Generate “Pmodes” for ebMS3/AS4 in a JSON format Convert a CPP subset to OASIS BDX SMP 1.0 Used in the following implementations

ENTSOG Proof of Concept Generate CPP, CPA and P-Mode from basic set of party parameters Assumes a fixed AS4 profile (ENTSOG) Supports Domibus and Flame FMS P-Mode XML Available from https://bitbucket.org/ebcore/as4_mgmt_poc

E-SENS Proof-of-Concept Unfinished self-service portal for AS4 configuration (developed by IT.NRW) Exported parameters used to generate: CPPs CPAs Domibus P-Mode XML (valid, not tested) On IT.NRW GIT (not public)

EASEE-Connect Service under development for the EASEE-gas members Portal for information sharing of AS4 parameters CPPA3 export option

Links to SPECIficationS

Specification Links Specification CPPA3 XML Schema Samples https://www.oasis-open.org/committees/document.php?document_id=64485&wg_abbrev=ebcore CPPA3 XML Schema https://www.oasis-open.org/committees/document.php?document_id=64482&wg_abbrev=ebcore Samples https://www.oasis-open.org/committees/document.php?document_id=64486&wg_abbrev=ebcore Exception schema https://www.oasis-open.org/committees/document.php?document_id=64483&wg_abbrev=ebcore