Re: [ebxml-cppa] Updated schema + examples

[Arvola Chan <arvola@tibco.com>]

Peter:

 

Some comments:

1. Re: point 2 in your previous message (see attached): I can think of no simple way to require that OtherActionBinding be mandatory in the case of CPAs and not present in the case of CPPs. One round-about approach is to specialize PartyInfo into CPPPartyInfo and CPAPartyInfo, CollaborationRole into CPPCollaborationRole and CPACollaborationRole, ServiceBinding into CPPServiceBinding and CPACollaborationBinding, WillInitiate into CPPWillinitiate and CPAWillInitiate, WillRespond into CPPWillRespond and CPAWillRespond, etc. For CPPWillInitiate and CPPWillRespond, there will only be one sub-element: ThisPartyActionBinding; for CPAWillInitiate and CPAWillRespond, there will be two sub-elements: ThisPartyActionBinding and OtherPartyActionBinding. Thus, CPP will have CPPPartyInfo as sub-elements and CPA will have CPAPartyInfo as sub-elements.
2. Re: point 2 in your enclosed message: This change does not seem to have been included in draft-cpp-cpa-08a.xsd. I still see AckSecurityDetailsRef and AckCertificateRef in draft-cpp-cpa-08a.xsd.
3. Re: recommendation on the prefixing of ID fields with trading partner names. To be more realistic, the SimplePart and Packaging IDs in the two example CPPs and the example CPA should be prefixed with the trading partner names. In the CPA, the SimplePart and Packaging elements should essentially be the union of the SimplePart and Packaging elements from the two CPAs that are effectively being merged.
4. Will you be submitting all the necessary textual changes to Version 1.01 of the CPA spec to reflect the schema changes in draft-cpp-cpa-08a.xsd, for incorporation into Version 1.03?

Regards,

-Arvola

-----Original Message-----
From: Peter Ogden <pogden@cyclonecommerce.com>
To: ebXML-CPPA (E-mail) <ebxml-cppa@lists.oasis-open.org>
Date: Monday, January 07, 2002 2:34 PM
Subject: [ebxml-cppa] Updated schema + examples

Attached is an updated version of the CPPA schema and examples.

This version (08a) differs from the previous version as follows:

 

1. Fixed a validation problem caused by the empty <SecurityPolicy/>

elements in the examples.

2. Added OtherPartyActionBinding elements to the CPA example.

3. Removed the AckSecurityDetailsRef from SenderNonRepudiation

and AckCertificateRef from ReceiverNonRepudiation.

4. Added ActionContext elements to the request/response

ActionBindings in the examples.

 

Regards,

 

Peter

 

---

• From: "Peter Ogden" <pogden@cyclonecommerce.com>
• To: "Arvola Chan" <arvola@tibco.com>,"ebXML-CPPA (E-mail)" <ebxml-cppa@lists.oasis-open.org>
• Date: Mon, 7 Jan 2002 07:50:37 -0700

Hi Arvola:

 

Thanks for the comments. Regarding ...

 

Point 1: I will fix this. I'm puzzled as to why my XML editor didn't complain about it.

 

Point 2: I started to add the OtherPartyActionBinding elements in the CPA example, but got to wondering whether they were really necessary. In my simple case, where where both sides match up exactly, it's pretty obvious in the CPA what goes with what. But I see now that in more complex cases where WillInitiate elements on one side don't match up one-for-one with WillRespond elements on the other, the OPAB does make sense. I'll fix the CPA example accordingly. Is there any way to make the schema disallow the OtherParty on the CPP and require it in the CPA?

 

Point 3: Yep, you're right. Don't know why I made this more complicated than it is. I will make the appropriate changes. 

 

Point 4: We can certainly add an endpoint to the TransportSender, but even with all the discussion last week about the From email address needing to match the email address in a signing cert (for SMTP transported messages), I'm still not convinced it's necessary. I'm pretty sure that SSL client authentication does not involve any sort of client URL. Maybe a brief discussion in our upcoming CPPA call can resolve this?

 

Peter

 

 

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, January 04, 2002 3:28 PM
To: Peter Ogden; ebXML-CPPA (E-mail)
Subject: Re: [ebxml-cppa] Schema and examples illustrating SecurityDetails and Sender/Receiver clarification

Peter:

 

Here are some comments on the schema and examples illustrating SecurityDetails and Sender/Receiver clarification:

1. Either the ##any wildcard element in SecurityPolicy needs to have a minOccurs of "0" or the examples should be modified to omit the empty SecurityPolicy element. Currently, the examples fail schema validation.
2. The WillInitiate and WillRespond elements (under ServiceBinding) each has a REQUIRED ThisPartyActionBinding and an OPTIONAL OtherPartyActionBinding. The intent is that OtherPartyActionBinding is not used in a CPP but is required in a CPA. In the latter case, we want to show that the sender's half of the delivery channel is matched up correctly to the receiver's half of the delivery channel (e.g., both the sender and the receiver specify the same communication protocol, the sender's signing certificate is compatible with the receiver's security details, etc.) This simplifies the logic that a MSH has to use at run time to determine the complete characteristics (including certificate references and security details) just by examining its own CollaborationRole element in the CPA.
3. I think the AckSecurityDetailsRef under SenderNonRepudiation and the AckCertificateRef under ReceiverNonRepudiation may be unnecessary. The sending of ReceiptAcknowledgment as a business signal will have its own ActionBinding to indicate the delivery channel characteristics and CertificateRef/SecurityDetailsRef.
4. Currently, there is an Endpoint element under TransportReceiver but not TransportSender. I wonder if an Endpoint will be necessary when SSL Client/Server mutual authentication is performed. I believe the server's URL is embodied in the server's certificate. Do we need to capture the sender's URL in the client's certificate? When SMTP is used, will we need to capture the sender's email address?
5. I agree with your earlier comments that we should probably recommend that the IDs used within CPPs be prefixed with the party's name so that there are no ID clashes when two CPPs are merged to form a CPA.

Regards,

-Arvola

----- Original Message -----

From: Peter Ogden

To: ebXML-CPPA (E-mail)

Sent: Thursday, January 03, 2002 3:34 PM

Subject: [ebxml-cppa] Schema and examples illustrating SecurityDetails and Sender/Receiver clarification

Attached is an updated CPPA schema that incorporates SecurityDetails and illustrates one way we might be able to clarify whether certain Transport and DocExchange properties are sender-related or receiver-related. Here are the main things to look at:

 

1. There is a new global SecurityDetails element that contains 0 or more sets of TrustAnchors. A trust anchor is just an IDREF to a root certificate (or certificate chain) that resides in the PartyInfo/CertificateRef collection. The PartyInfo now contains 1 or more of these new SecurityDetails elements.

 

2. In the CPA a DeliveryChannel is sort of "directional" in that it currently defines the sending and receiving properties needed to establish a one-way connection between a sending party and a receiving party. But in the CPP, each party specifies one "end" of a DC. That is, you specify the sending properties for the DC over which you will send requests/responses to your partner, and the receiving properties for the DC over which you will receive requests/responses from your partner. ActionBindings for messages you send would point to one of your send-side DC elements, ActionBindings for messages you receive would point to one of your receiver-side DC elements.

    Thus, under the PartyInfo/Transport element there is a TransportReceiver element and aTransportSender element. The receiver differs from the sender in that it has an Endpoint. Both types have a TransportSecurity element. For the receiver, you would specify a server-side authentication certificate and an optional set of SecurityDetails (trust anchors) governing the certificates you are willing to accept from the client. For the sender, you would specify a client-side authentication certificate and an optional set of SecurityDetails governing the certificates you are willing to accept from the server.

    Dale and Arvola exchanged email before the holidays discussing how to go about requesting (requiring) client-authenticated SSL. I haven't done anything with that yet - I'm still thinking about whether we need anything explicit in TransportSecurity or whether just the presence/absence of that element is enough. Any thoughts?

 

3. Similar to Transport, the DocExchange element contains an ebXMLSenderBinding element and an ebXMLReceiverBinding element. On the sender side, the NonRepudiation element contains a SigningCertificateRef pointing to the cert the sender wants to use for NRO and an AckSecurityDetailsRef pointing to the policy and trust anchors that govern the certificate the sender is willing to let the receiver use for signing acknowledgments. The sender-side DigitalEnvelope element contains an EncryptionSecurityDetailsRef element which points to the policy and trust anchors that govern the certificate the sender needs to obtain from the receiver for digital envelope key exchange. The ebXMLReceiverBinding element contains complementary elements.

 

Arvola commented earlier that specialization of Transport and DocExchange into Sender and Receiver flavors is not really necessary. I agree, but I think that doing so gives us the opportunity to make things a bit more obvious and less confusing. It also allows the schema to enforce, for example, that a TransportSender element contains a ClientCertificateRef and not a ServerCertificateRef. If after review we decide against this approach, reverting to the nonspecialized approach should be easy.

 

Respectfully,

 

Peter Ogden

---