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