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
Peter:
Here are some comments on the schema and examples
illustrating SecurityDetails and Sender/Receiver clarification:
- 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.
- 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.
- 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.
- 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?
- 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 -----
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
|