[PIN] of the user) and a signature application. We assume
that the mobile phone provider (MPP), the signature appli-
cation provider (SAP), and the smart card provider (SCP)
want to execute an agreement to put such a mobile phone
signature solution on the market. In order to reduce legal
uncertainties, the parties wish to include in the agree-
ment specific provisions to define as precisely as possible
the share of liabilities between them for the main types
of failures of the system. Their intention is to use these
provisions to settle liability issues in an amicable way by
the application of well-defined rules. At this stage, it may
be the case that all the components (software and hard-
ware) are already available and the only remaining task is
their integration. It may also be the case that some or all
the components still have to be developed. In general, no
assumption can thus be made on the fact that software
components can be designed or modified in a specific way
to make the implementation of liabilities easier. The only
assumptions made at this stage are:
• On the technical side: the availability of the functional
architecture of the system (interfaces of the com-
ponents and informal definition of their expected
behavior)
2. 1. it system
At the start of the contractual phase, the IT system is usually
defined in an informal way by its architecture: its compo-
nents, their interfaces, expected behaviors, and interactions.
In our case study, we assume that the electronic signature
system is made of the following components:
• A Server (Serv)
All the components except Serv are embedded in the
mobile phone. In this paper, we focus on liabilities related
to the mobile phone system and do not consider liabilities related to Serv or the communication network. These
liabilities could be handled in the same way by adding the
ECC and the telecommunication operator as additional
parties. The only functionality of OpSys that we consider
here is its role of medium for all communications between
the mobile phone components (i.e., between SigApp, Card,
and IO).
The architecture of the system and its information
flows are pictured in Figure 1. The protocol starts with
the ECCECC requesting a signature for document D (
message 1). The document is forwarded by Serv and SigApp,
and presented to the owner of the mobile phone (OWN)
by IO (messages
2,
3, and
4). If OWN refuses to sign, ECC
is informed through IO, SigApp, and Serv (messages 5-n,
6-n, 7-n, and 8-n). If OWN agrees, the document and the
PIN code entered by OWN are forwarded to Card by SigApp
(messages 5-y, 6-y, and 7-y). Next, depending on whether
Card authenticates the PIN code or not, the document
and the signature produced by Card are sent to ECC via
SigApp and Serv (messages 8-y-r, 9-y-r, and 10-y-r), or
ECC is informed via SigApp and Serv of the authentication failure (messages 8-y-w, 9-y-w, and 10-y-w). Note
that this scenario is a simplified version of a real protocol
which is sufficient to illustrate our purpose: for example,
in a real system, the PIN code would not be sent in clear
for security reasons – it would be provided through a hash
encoding.
2. 2. actors
We assume that the contract is to be executed by the three
parties involved in the manufacture and distribution of the
signature solution:
• The Mobile Phone Provider (MPP)
The owner of the mobile phone (OWN) and the ECC are supposed to execute different contracts with MPP which also
plays the role of mobile phone operator. We are concerned
only with the B2B contract between MPP, SAP, and SCP here.
We come back in Section 2. 4 to the legal consequences of
including the owner of the mobile phone (OWN) among the
parties. In the sequel, we shall use the word “party” for MPP,
SAP, and SCP, and the word “user” for the end-users of the
system (ECC and OWN).
Each component in the system is provided by one of the
parties. In our case, we assume that:
• The SigApp component is provided by SAP.
2. 3. informal agreement
The parties wish to define as precisely as possible the share
of liabilities between themselves in case of a claim from the
owner of the mobile phone. In practice, claims will typically
be addressed to MPP because MPP is the only party in direct
contact (and contractual relationship) with the owner of the
mobile phone (both as a MPP and operator). MPP will have
to indemnify the owner of the mobile phone if his claim