ebxml-msg — archive

[System]

David, I'm not an expert on security matters but I am sensing from the discussions that there is a substantial body of opinion on the side of considering nonrepudiation as an application-level function even if the entity that actually applies it is the MSH acting on behalf of the application and that on the receiving end, it is the application that is interested in nonrepudiation and has the responsibility to save the nonrepudiation information in tamperproof storage, etc. In any case, the main point that I tried to make was that there was no serious thought behind putting the CPA nonrepudiation element in the delivery channel. In fact, I believe it is there because it was there in the IBM tpaML submission and none of us on the TP team gave any thought to whether it is in the right place. The first step is to come to a consensus as to which architectural layer is the right place for nonrepudiation. Then, if it is not in an appropriate place in the CPA, it should be moved. Regards, ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* David Fischer <david@drummondgroup.com> on 09/04/2001 12:42:45 PM To: Martin W Sachs/Watson/IBM@IBMUS, Dale Moberg <dmoberg@cyclonecommerce.com> cc: ebxml-msg@lists.oasis-open.org Subject: RE: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and the layering mishmash (was jumbled into: reliable messaging - hop by hop) Marty, you said you are now understanding that NRR is not MSH functionality. Why? What has made you come to that conclusion? David Fischer Drummond Group.