OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment



NRR and RM are not orthogonal.  We need to send a Receipt to the sender stating
that the Message has arrived -- RM.  NRR is something we add to a Receipt to
ensure authenticity.    Security is never orthogonal to anything.  Security is
always an add-on.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Thursday, August 30, 2001 12:28 PM
To: ebxml-msg@lists.oasis-open.org
Cc: ebxml-cppa@lists.oasis-open.org
Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment


The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the
ReceiptAcknowledgement signal. NRR and reliable messaging are orthogonal. A
business process may specify the non repudiation of receipt for the
requesting business activity business message and/or the repudiation of
receipt for the responding business activity business message, without
requiring that reliable messaging be used. I think the Messaging Service
should not tie NRR to the DeliveryReceipt element if the latter is used
exclusively in reliable messaging.

The MSH is not responsible for validating the syntax of payloads. NRR at the
MSH level does not really implement NRR as called for by the business
process specification. NRR at the BPSS level includes syntax validation on
the payloads. Receipt Acknowledgement business signals have to be persisted
in order to satisfy legal requirements implied by NRR. I just don't see the
utility of persisting the DeliveryReceipt generated at the MSH level in
addition to the ReceiptAcknowledgement signal. This may just be unnecessary
overhead.

Currently, NRR parameters are tied to the DeliveryChannel element in the
CPP/A. According to Marty, these parameters may have to be relocated / added
to the ProcessSpecification and/or the Role element in order to properly
model the non repudiation requirements associated with the business process.

I strongly feel that non repudation is one area that the MSG, CPP/A, and BP
groups must closely coordinate among themselves in their 1.1 specifications.

-Arvola




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC