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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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