Re: D-AR006.6 proposal

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