Prominent Changes To the CPP A Specification January 28

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 Messaging. Characteristics attributes • sync. Reply. Mode • ack. Requested • ack. Signature. Requested • duplicate. Elimination • Actor Reliable. Messaging element provides RM runtime parameters

Business Process Spec Alignment Service • Use uuid attibute of Process. Specification element in BPSS instance Action • Add Action. Context to provide hierarchical path information leading from top-level Binary. Collaboration to Requesting. Business. Activity or Responding. Business. Activity • Mapping from Action. Context to simple name • Extensions to map to alternate flow language

Alignment Of Attribute Names And Values is. Confidential • persistent, transient, persistent-and- transient is. Authenticated is. Authorization. Required is. Non. Repudiation. Receipt. Required is. Secure. Transport. Required

Action Binding Each party identifies actions it is going to initiate or respond to (may be subset of actions from business process) Explicit Action. Bindings for BPSS Signals and exceptions Provide mapping to Delivery. Channel and Packaging CPA matches Delivery. Channels used by sender and receiver for each action See Will. Initiate and Will. Respond elements in schema

Synchronous Reply Modes Only applicable to synchronous transports (e. g. , HTTP) msh. Signals. Only => only MSH level signal (e. g. RM Acknowledgment) returned synchronously signals. Only => MSH signal + response returned asynchronously signals. And. Response => no NRR for response. Only => no NRR for response

Security. Details • Based on eb. XML Technical Architecture Risk Assessment recommendations • Allows a party to specify trust model(s) and policy related to its use of partners’ certificates • Defined under Party. Info, referenced elsewhere in CPP/CPA via Security. Details. Ref • In general one party identifies cert to use while counter party identifies Trust. Anchors for validating cert

Security. Details • Trust. Anchors is a collection of Certificate. Refs 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 Security. Details for different purposes • e. g. , SSL authentication vs. digital enveloping

Delivery Channel Specialization • Sending and receiving parameters now separate and independent • Transport • Doc. Exchange • Allows schema to enforce presence / absence of certain properties • In particular, Certificate. Ref and Security. Details. Ref

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

Transport. Sender • Properties of sending end of a delivery channel • Transport. Client. Security • Transport connections always established by sender, so sender specifies client security • Client. Certificate. Ref – used to authenticate to server • Server. Security. Details. Ref – applied to server certs

Transport. Receiver • Properties of receiving end of a delivery channel • Endpoints – URIs for services provided to clients • Transport. Server. Security • Transport connections always accepted by receiver, so receiver specifies server security • Server. Certificate. Ref – used to authenticate to client • Client. Security. Details. Ref – 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

Doc. Exchange • Initiator’s eb. XMLSender. Binding and Responder’s eb. XMLReceiver. Binding must mesh

Sender. Non. Repudiation • Sender’s non-repudiation properties • Signing. Certificate. Ref – the party will use this cert for signing messages

Receiver. Non. Repudiation • Receiver’s non-repudiation properties • Signing. Security. Details. Ref – trust anchors and policy applied to sender’s signing certificate

Sender. Digital. Envelope • Sender’s encryption properties • Encryption. Security. Details. Ref – trust anchors and policy applied to receiver’s encryption certificate

Receiver. Digital. Envelope • Receiver’s encryption properties • Encryption. Certificate. Ref – 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 W 3 C 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