1. 1 April 18 th, 2002 Electronic Commerce Promotion Council of Japan (ECOM) 5 th ebXML Asia Committee Taipei meeting Current Status of OASIS ebXML CPPA TC

2. 2 General Report of the latest OASIS ebXML CPPA F2F Meeting (January 28-30 2002, San Francisco in USA) (1/2) 1. Participants (13 people) ・ Dale MobergCyclone Commerce, Leader of CPPA TC ・ Marty SachsIBM, Leader of previous ebXML Initiative TP team ・ Arvola ChanTIBCO, Member of RosettaNet, ebXML MSG TC ・ Brian HayesCommerce One, Leader of ebTWG BPSS group ・ Himagiri MukkamuraSYBASE ・ Peter OgdenCyclone Commerce ・ Kevin LiuSAP ・ Selim AissiIntel ・ Pallavi MaluIntel, Member of ebTWG BPSS group ・ Jean ZhengVitria ・ Yukinori SaitoECOM (Remote) ・ David FisherDrumond Gr. Key member of ebXML MSG TC ・ Jamie 2. General Proceedings (1/2) (1) Main discussion points are examination and confirmation about next version of CPPA specification. There are about 230 issue items (Issue List), and all the items were reviewed. (2) CPPA spec. is closely related to MSG (Messaging service) and BPSS (Business process specification schema). Descriptions of relationship with these specifications are described in CPPA spec. (3) The next official version number of CPPA will be V2.0. Reason: -Version no. of MSG and Registry is V2.0. -There are many changes in next version of CPPA.

3. 3 (4) Negotiation specification ・ Draft of Requirement specification was made already. ・ Planning of making specification and confirmed who will be charged. -Specification of the negotiation process (Definition of the negotiation verbs, Message envelope structure, Message Schema) -Sample NCPANCPA: CPA for negotiation -Sample NDDNDD (Negotiation Data Descriptor): CPP for negotiation -Tutorial for implementers -Best-Practice document if appropriate (5) Future Development items (supposed to be V3.0) ・ Study specifications about security and involve them in CPPA -SAML (OASIS), XML encryption (W3C), XACML (OASIS), XKMS (W3C) ・ Context and BP level agreement ・ WSDL convergence ・ Intermediaries and Multiparty ・ Supporting Specifications e.g. Tutorial and Implementation guide ・ SME simplification e.g. Dynamic negotiation, Template of CPA ・ BSI (Business Service Interface) efforts. This will be proposed to W3C. General Report of the latest OASIS ebXML CPPA F2F Meeting (January 28-30 2002, San Francisco in USA) (2/2) 2. General Proceedings (2/2)

4. 4 The Latest Status of OASIS ebXML CPPA TC (CPPA TC Teleconference, April 5, 2002) 1. Coordination with WSDL Karl Best (OASIS) asked CPPA TC to consider what coordination between our activities and W3C activities might be beneficial. Dale noted that we have explicit dependencies on XMLDsig, Xlink (and its dependencies, such as XPath), and of course on XML and XML Schema specifications. No special need for coordination was identified for these dependencies. CPPA TC agreed that it might be beneficial if CPPA and WSDL were in some way coordinated or put together. It was noted that there is a sub team pursuing research on how that integration can occur, and several CPPA members (Kevin, Pallavi, and Dale) participate in the WSDL WG. Arvola also noted that the Architecture WG within the Web Services activity is also relevant to CPPA, and there was agreement that we should monitor developments in that group also. 3. Next F2F meeting ・ Possibly June 3-5 2. Schedule of CPPA Spec. ・ Reviewing current draft (V1.11) within CPPA TC members until April 19, 2002 ・ Public review (Supposed to be May, 2002) ・ Submit to OASIS for approval (Supposed to be early June) ・ 90 days Official Review in OASIS organization (Supposed to be July, August, and September)

5. 5 Information of CPPA TC Activities 1. Specification 2. XML Schema and Examples ・ The latest Version is V1.11. ・ Everyone can see the current draft in CPPA Web site. http://www.oasis-open.org/committees/ebxml-cppa/ ・ The latest schema and example files are available to see in the following page. http://www.oasis-open.org/committees/ebxml-cppa/schema/ -XML Schema of ebXML BPSS -XML Schema of ebXML CPPA -Example of Process-Specification Document, CPP (Company A and B), and CPA 4. E-mail lists ・ In keeping with OASIS' policy of open discussions, the archives of all TC lists may be viewed by the public; go to http://lists.oasis-open.org/archives/ 3. Meeting Minutes http://www.oasis-open.org/committees/ebxml-cppa/minutes/index.shtml

6. 6 General Explanation of CPPA Specification and related Specifications ・ CPPA (Collaboration-Protocol Profile and Agreement Specification) V1.11 (draft-bpss-example-017) (draft-cpp-example-companyA-017.xml) (draft-cpp-example-companyB-017.xml) (draft-cpa-example-017.xml) ・ MSG (Message Service Specification) V2.0 ・ BPSS (Business Process Specification Schema) V1.02 April 10, 2002 Based on: (1)Relationship between BPSS, CPPA, and MSG (2)Examples of BPSS, CPP/CPA, and MSG Header

7. 7 Business Process and Information Model ebXML Process-Specification Document ebXML CPP/CPA ebXML Business Service Interface Configuration Process-Specification Document and Business Service Interface Configuration Using Business Process Modeling, a user may create a complete Business Process and Information Model. Based on this Business Process and Information Model and using the ebXML Business Process Specification Schema the user will then extract and format the nominal set of elements necessary to configure an ebXML runtime system in order to execute a set of ebXML business transactions. The result is an ebXML Process-Specification Document. Alternatively the ebXML Process-Specification Document may be created directly, without prior explicit business process modeling. An ebXML Process-Specification Document contains the specification of Business Transactions and the choreography of Business Transactions into Business Collaborations. This ebXML Process-Specification Document is then the input to the formation of ebXML Collaboration-Protocol Profiles and Collaboration-Protocol Agreements. These ebXML Collaboration-Protocol Profiles and Collaboration-Protocol Agreements in turn serve as configuration files (e.g. Messaging Header) for ebXML Business Service Interface software.

8. 8 An user create Process-Specification Document supposed to be used some Buyers and Sellers. Usually, Process-Specification Document is created by Service unit. (e.g. each RosettaNet PIP) Process-Specification Document describes choreography of Business Transactions and role of Parties. Creation of Process-Specification Document Creation of CPP(Company A) and CPP(Company B) A buyer creates CPP (Company A) based on ebXML CPPA Specification, In case of Business process scenarios, CPP points Process-Specification Document by URI. (Head of Process- Specification Document and position of Role element) And the buyer describe many CPP information. (ServiceBinding, DeliveryChannel, Transport, DocExchange, Packaging) Also, a Seller create CPP (Company B) like the same way. Creation of CPA between Company A and B In usual case, The buyer creates CPA together with CPP (A) and CPP (B). The relationship between CPA and Process-Specification Document is same as CPP. That is, some URI under ProcessSpecification element and Role element point to suitable position of Process-Specification Document General Procedure to create Process-Specification Document, CPP, and CPA

9. 9 Relationship between Process-Specification Document, CPP, and CPA <ProcessSpecification uuid= <BusinessDocument name= <BusinessTransaction name= <RequestingBusinessActivity <RespondingBusinessActivity <BinaryCollaboration name=“Request Purchase Order” <InitiationgRole name=“Buyer” <RespondingRole name=“Seller” Process-Specification Document (RosettaNet PIP3A4) <PartyInfo partyname=“CompanyA” <ProcessSpecification name=“PIP3A4 xlink:href=“http://www.rosettanet.org/-- <Role name=“Buyer” xlink:href=://www-- <ServiceBinding <DeliveryChannel <PartyInfo partyname=“CompanyB” <ProcessSpecification name=“PIP3A4 xlink:href=“http://www.rosettanet.org/-- <Role name=“Seller” xlink:href=://www-- <ServiceBinding <DeliveryChannel <PartyInfo partyname=“CompanyA” <ProcessSpecification name=“PIP3A4 xlink:href=“http://www.rosettanet.org/-- <Role name=“Buyer” xlink:href=://www-- <ServiceBinding <DeliveryChannel <PartyInfo partyname=“CompanyB” <ProcessSpecification name=“PIP3A4 xlink:href=“http://www.rosettanet.org/-- <Role name=“Seller” xlink:href=://www-- <ServiceBinding <DeliveryChannel CPP(CompanyA ) CPP(CompanyB) CPA(CompanyA,B)

10. 10 Modifying Parameters of PSD (Process-Specification Document) based on information in the CPA A Process-Specification Document and CPP/CPA has same kinds of parameters. An example is Security attributes that are counterparts of the attributes of the CPA BusinessProcessSpecification element. When a CPA created, the Parties may decide to accept different value of these parameters. In this case, these parameters shall override the original values expressed in the Process-Specification Document. In this case, overridden Process-Specification Document should be a copy of the original Process- Specification Document. Because the original Process-Specification Document may be used some different parties. original Process-Specification Document Customized Process-Specification Document Public PSD for every party For special parties (e.g. company A,B) Customize CPA (A,B) Copy

11. 11 Examples of Process-Specification Document, CPP, and CPA These examples are supposed to be followings. ・ Binary collaboration between 2 companies. (‘CompanyA’, and ‘CompanyB’) ・ These companies do collaboration using the RosettaNet PIP3A4 as Business Process Scenarios. -PIP3A4 is recognized as ‘Service’ in the view point of BPSS. -PIP3A4 has two business actions. These are recognized as ‘Action’ in the view point of BPSS. ‘Purchase Order Request Action’ and ‘Purchase Order Confirmation Action’.

12. 12 Business Transaction Dialog of RosettaNet PIP3A4: Request Purchase Order (V02.00)

13. 13 #Name Time toAcknowledgeReceipt SignalTime toAcknowledgeAcceptance SignalTime to Respond toActionIncluded in Time toPerformIs AuthorizationRequired?Is Non-RepudiationRequired?Is Secure TransportRequired? 1.Purchase Order Request Action 2 hrsN/A24 hrs YYYY 1.1.Receipt Acknowledgment N/A YYYY 1.2.Purchase Order Confirmation Action 2 hrsN/A YYYY 1.2.1.Receipt Acknowledgment N/A NYYY Message Exchange Controls of RosettaNet PIP3A4

14. 14 <BusinessDocument name="Puchase Order Request “ nameID="Pip3A4PurchaseOrderRequest “ specificationLocation="PurchaseOrderRequest.xsd"> <BusinessDocument name="Puchase Order Confirmation" nameID="Pip3A4PurchaseOrderConfirmation “ specificationLocation="PurchaseOrderConfirmation.xsd"> <RequestingBusinessActivity name="Purchase Order Request Action" nameID="PurchaseOrderRequestAction “ isAuthorizationRequired="true" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S"> <DocumentEnvelope businessDocument="Puchase OrderRequest “ businessDocumentIDRef="Pip3A4PurchaseOrderRequest" /> <RespondingBusinessActivity name="Purchase Order Confirmation Action “ nameID="PurchaseOrderConfirmationAction" isAuthorizationRequired="true" isNonRepudiationRequired="true “ timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S"> <DocumentEnvelope businessDocument="Purchase Order Confirmation “ businessDocumentIDRef="Pip3A4PurchaseOrderConfirmation" /> <BusinessTransactionActivity name="Request Purchase Order" nameID="RequestPurchaseOrder_BTA “ businessTransaction="Request Purchase Order"businessTransactionIDRef="RequestPurchaseOrder_BT “ fromAuthorizedRole="Buyer" fromAuthorizedRoleIDRef="BuyerId" toAuthorizedRole="Seller" toAuthorizedRoleIDRef="SellerId" timeToPerform="P0Y0M0DT24H0M0S"/> Example of Process-Specification Document （ RosettaNet PIP3A4 ） ←Definition of Business Document (P.O.R. ） ←Definition of Business Document (P.O.C. ）

15. 15 This Process-Specification Document has 3 parts contents. (1)Business Document ・ Two Business Documents are defined named ’Purchase Order Request’ and ‘Purchase Order Confirmation’. (2)Business Transaction ・ One Business Transaction is defined named ‘Request Purchase Order’ in this Process-Specification Document. ・ This Business Transaction has two actions named ’Purchase Order Request Action’ and ‘Purchase Order Confirmation Action’ under RequestingBusinessActivity element and RespondingBusinessActivity element. ・ These BusinessActivity elements define associated Business Documents under DocumentEnvelope element. ・ Some security parameters are defined under these BusinessActivity elements. e.g. isAuthorizationRequired, isNonRepudiationRequired, timeToAcknowledgeReceipt (3)Binary Collaboration ・ One Binary Collaboration is defined named ‘Request Purchase Order’ in this Process- Specification Document. ・ BinaryCollaboration element defines associated Business Transaction. -Under this element, Roles (‘Buyer’ and ‘Seller’) are defined. Some parameters related collaboration are defined. e.g. timeToPerform, isConcurrent Explanation of Example of Process-Specification Document

16. 16 123456789 <tp:ProcessSpecification tp:version="2.0" tp:name="PIP3A4RequestPurchaseOrder"xlink:type="simple “ xlink:href="http://www.rosettanet.org/processes/3A4.xml" /> bpid:icann:rosettanet.org:3A4$2.0 <tp:ThisPartyActionBinding tp:id="companyA_ABID1" tp:action="Purchase Order Request Action “ tp:packageId="CompanyA_RequestPackage"> asyncChannelA1 <tp:BusinessTransactionCharacteristics tp:isNonRepudiationRequired="true “ tp:isSecureTransportRequired="true “ tp:isAuthorizationRequired="true" tp:timeToAcknowledgeReceipt="PT2H" tp:timeToPerform="P1D" /> Example of CPP Document (Company A) (1/2) ↓Definition of Company A ’ s ＩＤ ←Link to Company A ’ s details Info. ←Definition of Collaboration Spec. ↑Definition of Service Binding ・ Link to Packaging and Delivery Channel ・ Definition of Business Transaction Characteristics ←Definition of Delivery Channel ・ Link to TransportID and docExchange ・ Definition of Messaging Characteristics

17. 17 HTTP SSL 3 PT2H Guaranteed http://www.w3.org/2000/09/xmldsig# http://www.w3.org/2000/09/xmldsig#sha1 http://www.w3.org/2000/09/xmldsig#dsa-sha1 S/MIME DES-CBC ←Definition of Transportation Spec. ←Definition of Reliable Messaging Spec. ←Definition of Non Repudiation Spec. ←Definition of Digital Envelope Spec. Example of CPP Document (Company A) (2/2)

18. 18 Explanation of Example of CPP (CompanyA) ・ ’CompanyA’ is supposed to be a buyer, and ‘CompanyB’ is supposed to be a seller. ・ These companies adopted DUNS number as a party identification. [ProcessSpecification element] ・ ProcessSpecification element specifies URI of associated Process-Specification Document. [Role element] ・ Role element specifies role of party. ・ The role of CompanyA is defined as buyer by Role element (‘name’ and ‘xlink:href’ attributes)

19. 19 [ServiceBinding element] ・ ServiceBinding element defines Delivery Channels and Packaging by each Action. And also Delivery Channels and Packaging are specified by sending action or receiving action. e.g. CanSend element (for sending action), CanReceive element (for receiving action) ・ In this example, CPP(A) has one ServiceBinding element. And this ServiceBinding element has several CanSend elements and CanReceive elements. ・ The value of Service element ‘bpid:ican:rosettanet.org:3A4$2.0’ will be used as the value of the Service element in the ebXML Message Header. [Certificate element] ・ In case of certification under CPPA specification, All Business documents are digitally signed based on XML Digital Signature specification [XMLDSIG]. ・ Certification information is defined by Certificate element. These certificate information are referred elsewhere in the CPP. Certificate information is able to be defined independently by using certID or securityId attributes. ・ TrustAnchors element represents a root certificate trusted by this party.

20. 20 Action (CompanyA) →(A→B) ←(A ← B) Delivery ChannelPackaging Purchase Order Request Action →asyncChannelA1CompanyA_RequestPackage Receive Acknowledgement ←asyncChannelA1CompanyA_ReceiptAcknowledge mentPackage Purchase Order Confirmation Action ←asyncChannelA1CompanyA_ResponsePackage Receive Acknowledgement →asyncChannelA1CompanyA_ReceiptAcknowledge mentPackage Definition of Delivery Cannel and Packaging by using ActionBinding element [DeliveryChannel element] ・ Delivery Channel and Packaging are able to be defined by separately and independently using ActionBinding element and DeliveryChannel element. ・ DeliveryChannel element has a function to determine Messaging characteristics. BusinessTransactionCharacteristicsMessageingCharacteristics (asyncChannelA1) (asyncChannelA1) -isNonRepudiationRequired: true-syncReplyMode: none -isNonRepudiationReceiptRequired: true-ackRequested: always -isSecureTransportRequired: true-ackSignatureRequested: always -isConfidential: transient-dupulicateElimination: always -isAuthenticated: persistent -isAuthorizationRequired: true

21. 21 Delivery ChannelTransportDocExchange asyncChannelA1transportA2docExchangeA1 [DeliveryChannel element] ・ Delivery Channel also defines Transport and docExchange. [Transport element] ・ Transport element defines the party’s network communication capabilities. ・ Communication capabilities are able to be defined by every sending and receiving action. transportA2TransportSenderTransportProtocol:HTTP V1.1 TransportSecurityProtocol:SSL V3.0 TransportReceiverTransportProtocol:HTTP V1.1 Endpoint:https://www.CompanyA.com/servlets/ebxmlhandler/sync TransportServerSecu rity TransportSecurityProtocol:SSL V3.0

22. 22 [docExchange element] ・ docExchange element defines characteristics regarding exchange of business documents. ・ These characteristics are able to be defined by sending and receiving action. SenderBindingReceiverBinding ReliableMessagingRetries RetryInterval MessageOrderSemantics 3 PT2H Guaranteed 3 PT2H Guaranteed PursistDurationP1D NonRepudiationNonRepudiationProtocol HashFunction SignatureAlgorism SigningCertificate xmldsig# Xmldsig#sha1 Xmldsig#dsa-sha1 CompanyA_SigningCert xmldsig# Xmldsig#sha1 Xmldsig#dsa-sha1 CompanyA_MessageSecurity DigitalEnvelopDigitalEnvelopProtocol EncriptionAlgorism EncriptionSecurity S/MIME V2.0 DES-CBC CompanyA_MessageSecu rity S/MIME V2.0 DES-CBC CompanyA_EncriptionCert [Packaging element] ・ Packaging element provides specific information about how the Message Header and payload constituent(s) are packaged for transmittal over the transport. ・ The Packaging element provides information about MIME content types, XML namespaces, security parameters, and MIME structure. ・ These information are capable to be defined by each sending and receiving action. docExchangeA1

23. 23 - - - 2001-05-20T07:21:00Z 2002-05-20T07:21:00Z - - Example of CPA Document (Company A and B)

24. 24 Explanation of Example of CPA This CPA has two PartyInfo elements. One is information for CompanyA (DUNS ’123456789’), the other one is information for CompanyB (DUNS ’987654321’). The role of CompanyA is buyer; this is specified by Role element under PartInfo element. The role of CompanyB is seller. [Status element] The value ‘proposed’ means that the status of this CPA is under negotiation between two companies. The other value ‘agreed’ and ‘signed’ are capable. [Start element] ‘2001-05-20T07:21:00Z’ means that this CPA will be valid from the time of 7:21 am UTC (Coordinated Universal Time) on May 5, 2001. [End element] ‘2002-05-20T07:21:00Z’ means that this CPA will be invalid from the time of 7:21 am UTC (Coordinated Universal Time) on May 5, 2002. [ConversationConstraints element] ‘100’ of invocationLimit attribute means that if the number of conversations is reached to 100 times, this CPA is terminated and must be renegotiated. ‘10’ of concurrentConversations attribute means that 10 conversations can be in process at the same time. The meaning of number as the content of this element is number of business transaction (e.g. Purchase order), is not a performance parameter.

25. 25 Relationship between CPA and Messaging Header CPA (A,B) Business Document Message Header Header Envelope Payload Envelope Payload ・ When the Business Document is composed by middleware above the Message Service Interface (MSI), Some parameters are referred and implemented in the Message Header in the Business Document. Message Header Element/Attribute Corresponding CPA Element/Attribute PartyId element Role element CPAId elementCpaid attribute in CollaborationProtocolAgreement element ConversationId elementNo equivalent; should be generated above the MSI Service element Action elementAction attribute in ActionBinding element TimeToLiveComputed as the sum of Timestamp (in message header)+PersistDuration (under DocExchange element) MesageIdNo equivalent; generated by the MSH (Message Service Handler) per message

26. 26 Example of Message Header of ‘Purchase Order Request’ Document 123456789 987654321 http://rosettanet.org/processes/3A4.xml#seller uri:companyA-and-companyB-cpa 987654321 bpid:icann:rosettanet.org:3A4$2.0 Purchase Order Request Action UUID-2 2000-07-25T12:19:05 UUID-1 ---- ←Definition of ebXML Message Header ←Description of IDs of From and To ↓Description of corresponding Service ←Description of corresponding Action