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 AlignmentService

• 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