- From: bhaugen <linkage@interaccess.com>
- Date: Sat, 08 Jun 2002 10:27:37 -0500
- To: www-ws-arch@w3.org
The quotes below from James Bryce Clark might help to put the non-repudiation issue in context. To paraphrase, he says that you can't promise non-repudiation, you can only provide evidence to help avoid false claims and document your case if false claims are made. In other words, the best you can do is to provide a well-designed set of evidence, which could be a delimited task. I think several people in this thread have said as much, but here's a fairly authoritative statement. JBC's title is Chair, US American Bar Association Business Law Subcommittee on Electronic Commerce. The quotes are from the ebXML E-Commerce Patterns report: http://www.ebxml.org/specs/bpPATT.pdf Some of the terms in the full quote refer to the ebXML Business Process Schema Specification, but the meaning should be clear. <pull quote> In the electronic commerce context, an evaluative judgment that a set of messages creates an enforceable or nonrepudiatable contract should be understood to mean that the quality and coherence of the evidentiary artifacts available to prove it are acceptably strong. We cannot prevent trading partners from lying. We can design signal structures that make it easier to prove later. </pull quote> <full quote> A sidebar: Nonrepudiation and Enforceability Users of this document should note that the defined signals isNonrepudiation-Required, isNonRepudiationOfReceiptRequired and isLegallyBinding are significantly distinct from the generalized goals of nonrepudiation and legal enforceability. Invoking the former should assist, but does not assure, the latter. The goal of a well-designed electronic commerce model is to reduce the risk of repudiation and unenforceability to a reasonable minimum. No system will completely eliminate either risk. See [ABA Model Trading Partner Agreement 1992] and [UN/ECE Interchange Agreements for EDI 1995]. Repudiation risk occurs whenever a trading partner has an opportunity to avoid the consequences of its commitments. For example, under the BPSS, if you impose an timeToAcknowledgeAcceptance parameter (time>0) on a trading partner's response to you, he may validly reply with an exception claiming that your requesting document does not conform to the relevant business rules. That claim may or may not be true: in fact, nothing in the standard computationally prevents him from making a false exception at runtime. That opportunity may be the functional equivalent for him of a chance to repudiate. Say your requesting document offers to buy 1000 units of X. Assume you and he have a pre-existing contract requiring him to sell you 1000 units of X whenever you offer to buy them. He may have received, parsed and understood your requesting document as a purchase order to buy X. But he is still in a position to inaccurately claim that your purchase order failed a business rule check. Perhaps he has a limited supply of X, and a buyer who will pay more than you. At run time, there likely is no way for you to tell. What business signal parameters offer, in that instance, is a set of process rules that require you or him to keep and store significant artifacts from the transactional messaging, that later may be impartially interpreted. Any "legally binding" obligation should, as a design matter, generate a set of those artifacts that would be useful in proving later in court that (for example) the claim of a failed business rule check was fraudulent. In the electronic commerce context, an evaluative judgment that a set of messages creates an enforceable or nonrepudiatable contract should be understood to mean that the quality and coherence of the evidentiary artifacts available to prove it are acceptably strong. We cannot prevent trading partners from lying. We can design signal structures that make it easier to prove later. </full quote> -Bob Haugen
Received on Saturday, 8 June 2002 11:28:41 UTC