[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
David, I've embedded a couple comments below, prefixed with my initials. Cheers, Tony ----- Original Message ----- From: David Fischer To: CPPA Sent: Sunday, October 21, 2001 6:32 PM Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 Sorry I missed the meeting, it didn't make it onto my calendar. Comments: If end-to-end, signed Acknowledgment is requested, it provides NRR -- in the same way DeliveryReceipt does. NRR cannot be provided at the BPSS/Application level since MSH does not pass the entire message and thus the Application cannot generate the required Digest(s). TW: That seems like a strong statement. Signing the entire message is sufficient, but is it always necessary? I understand that messaging elements may convey information relevant for non-repudiation, e.g., a timestamp. Such information may also appear in a particular type of business payload. Since the MSH does not do any application parsing, any Business Level receipts cannot be done at the MSH level. While the Application cannot do NRR, it can/must provide anything along the lines of "Message verified/being processed" (i.e. Delivery Receipt). The Application would pass this signal to the MSH with a flag which says "sign this". While it would not be illegal for the Application to send a signed/encrypted payload to the MSH (would this be S/MIME?), it is not within our model to do so. TW: I expect that some security-sensitive applications will call for transmitting encrypted content between authorized persons or applications, not just between their respective MSHs. The latter is more likely to compromise security, for example by exposing confidential information to unauthorized persons within an enterprise. An Acknowledgment can be requested separately from Reliable Messaging although the only difference is duplicateElimination. I thing/agree that MSH signals should be returned synchronously for HTTP. This should be the default. Maybe we don't need a flag, just make this a requirement (Why would this ever be done asynchronously for HTTP?) I think I agree with Dale. This should match the transport method (sync for HTTP, async for SMTP) and should not change per message. Regards, David Fischer Drummond Group. -----Original Message----- From: Tony Weida [mailto:rweida@hotmail.com] Sent: Saturday, October 20, 2001 5:05 PM To: CPPA Subject: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001 Draft minutes of the October 18 teleconference are attached. Please send me any additions or corrections. Cheers, Tony Weida Independent CPPA Fan :-)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC