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