Figure 1. signature protocol.
is valid and may in turn be indemnified by one (or several)
of the other parties depending on the type of the claim,
the available log files, and the liability share defined in the
agreement.
In the following, we assume that each document to be
signed is originally stamped by ECC and this stamp q is
(i) unique, (ii) always included in the messages of a given session, and (iii) never modified. This stamp q can be seen as
a transaction number which makes it easier to distinguish
messages pertaining to different signature sessions. Lifting
or relaxing this assumption is possible, but at the expense of
a more complex model.
As an illustration, we consider two kinds of claims
from the owner of the mobile phone, called DiffDoc and
NotSigned, concerning the signature of an alleged document
D stamped q:
1. DiffDoc: The plaintiff OWN claims that he has been
presented a document D¢ stamped q different from
the alleged document D (stamped q). In the case of
a purchase order, for example, D and D¢ may differ
with respect to the quantity or price of the ordered
items.
2. NotSigned: The plaintiff OWN claims that he has never
been presented any document stamped q.
We assume that the parties agree on the following informal
share of liabilities for these two types of claims:
1. If OWN claims that he has been presented a document
D¢ stamped q different from the alleged document D
(stamped q), then, if this claim is valid
a. SAP shall be liable if SigApp has forwarded to OWN
a document (stamped q) different from the docu-
ment received from ECC.
b. Otherwise MPP shall be liable.
2. If OWN claims that he has never been presented any
document stamped q, then, if this claim is valid
a. If the smart card has wrongly validated a PIN for
document D stamped q, then SCP shall be liable.
b. Otherwise MPP shall be liable.
We do not discuss the value or justifications for this informal agreement here and just take it as an example of a possible share of liabilities. It should be clear that this share of
liabilities is the result of a negotiation between the parties,
based on a combination of technical as well as business and
legal arguments, and it does not have to (and usually cannot)
be justified formally. For example, the above rules for the
liability by default may be found acceptable by MPP because
he takes a significant part of the revenues of the business at
the expense of bearing the risk in connection with the customer. The point is that the formal framework should not
impose any undue constraint on the share of liabilities but
should provide means for the parties to express their wishes
as precisely as possible.
2. 4. Legal context
Even though the intention of the parties is to settle liability
issues in an amicable way, according to well-defined rules, it
is obviously necessary to take into account the legal context
pursuant to computer systems. Any misconception or overlooking of the legal constraints might lead to contractual
clauses that could be invalidated in court, thus increasing
rather than reducing legal risks. The two main categories
of legal constraints to be considered here concern the two
main phases of the process: ( 1) the formal definition of the
share of liabilities among the parties and ( 2) the analysis
of the log files to establish these liabilities after the fact.
In the following, we examine these two categories of legal
constraints in turn.
Liability Limitations: The first criterion to be taken into
account to assess the validity of contractual liability limitations is the qualification of the parties. For example,
