[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