Prominent Changes To the CPP/A Specification January 28, 2002

Change Areas Alignment with Messaging Specification on Reliable Messaging and Per Message Semantics Alignment with Business Process Specification on Service and Action Explicit Identification of Actions Each Party Will Initiate or Respond to Clarification of Synchronous Reply Modes Security Details and Clarification of Certificate Refs

Change Areas (cont.) Specializing Delivery Channels for Sending and Receiving Improved BPSS/CPP/CPA Examples Improved Schema Definition Mapping Between Messaging And CPP/A Parameters

Messaging Spec Alignment MessagingCharacteristics attributes syncReplyMode ackRequested ackSignatureRequested duplicateElimination Actor ReliableMessaging element provides RM runtime parameters

Business Process Spec Alignment Service Use uuid attibute of ProcessSpecification element in BPSS instance Action Add ActionContext to provide hierarchical path information leading from top-level BinaryCollaboration to RequestingBusinessActivity or RespondingBusinessActivity Mapping from ActionContext to simple name Extensions to map to alternate flow language

Alignment Of Attribute Names And Values isConfidential persistent, transient, persistent-and- transient isAuthenticated isAuthorizationRequired isNonRepudiationRequired isNonRepudiationReceiptRequired isSecureTransportRequired

Action Binding Each party identifies actions it is going to initiate or respond to (may be subset of actions from business process) Explicit ActionBindings for BPSS Signals and exceptions Provide mapping to DeliveryChannel and Packaging CPA matches DeliveryChannels used by sender and receiver for each action See WillInitiate and WillRespond elements in schema

Synchronous Reply Modes Only applicable to synchronous transports (e.g., HTTP) mshSignalsOnly => only MSH level signal (e.g. RM Acknowledgment) returned synchronously signalsOnly => MSH signal + response returned asynchronously signalsAndResponse => no NRR for response responseOnly => no NRR for response

SecurityDetails Based on ebXML Technical Architecture Risk Assessment recommendations Allows a party to specify trust model(s) and policy related to its use of partners’ certificates Defined under PartyInfo, referenced elsewhere in CPP/CPA via SecurityDetailsRef In general one party identifies cert to use while counter party identifies TrustAnchors for validating cert

SecurityDetails TrustAnchors is a collection of CertificateRefs to trust anchor certificates A trust anchor is a root certificate issued by a Certification Authority trusted by the party Security policy is just a placeholder, for now Policy definitions from OASIS XACML TC not quite ready for use Can specify different SecurityDetails for different purposes e.g., SSL authentication vs. digital enveloping

Delivery Channel Specialization Sending and receiving parameters now separate and independent Transport DocExchange Allows schema to enforce presence / absence of certain properties In particular, CertificateRef and SecurityDetailsRef

Transport Transport can be a sender, receiver, or both Synchronous messaging requires both TransportSender and TransportReceiver within the same Transport may use different protocols Sender specifies client security, receiver specifies server security Initiator’s TransportSender and Responder’s TransportReceiver must mesh

TransportSender Properties of sending end of a delivery channel TransportClientSecurity Transport connections always established by sender, so sender specifies client security ClientCertificateRef – used to authenticate to server ServerSecurityDetailsRef – applied to server certs

TransportReceiver Properties of receiving end of a delivery channel Endpoints – URIs for services provided to clients TransportServerSecurity Transport connections always accepted by receiver, so receiver specifies server security ServerCertificateRef – used to authenticate to client ClientSecurityDetailsRef – applied to client certs

Transport patterns Client establishes connection to server All clients are senders All servers are receivers Some servers are senders e.g., synchronous responder Some clients are receivers e.g., synchronous requestor

DocExchange Initiator’s ebXMLSenderBinding and Responder’s ebXMLReceiverBinding must mesh

SenderNonRepudiation Sender’s non-repudiation properties SigningCertificateRef – the party will use this cert for signing messages

ReceiverNonRepudiation Receiver’s non-repudiation properties SigningSecurityDetailsRef – trust anchors and policy applied to sender’s signing certificate

SenderDigitalEnvelope Sender’s encryption properties EncryptionSecurityDetailsRef – trust anchors and policy applied to receiver’s encryption certificate

ReceiverDigitalEnvelope Receiver’s encryption properties EncryptionCertificateRef – certificate to be used in digital envelope key exchange

Improved Examples One BPSS instance Two complementary CPP instances One merged CPA instance Matching of Action Bindings between initiator and responder Synchronous and asynchronous Service Bindings Illustration of Service and Action values obtained from business process IDREFs validated by XML aware editor

Improved Schema Definition Based on W3C Recommended version of XML Schema, DTD no longer provided Improved data type specification Cardinality constraints Wildcard elements for extensibility Annotations for documentation Validated by conforming schema editor

Messaging And CPA Mapping New normative appendix on how to use Messaging and CPP/A specs together Correspondence between message header and CPA elements/attributes Correspondence between implicit messaging parameters and CPA elements/attributes