IDABC Recognition Esignatures

Preliminary Study on Mutual Recognition of
eSignatures for eGovernment applications
Report
November 2007
November 2007
This report / paper was prepared for the IDABC programme by:
Author’s name: Siemens - Time.lex

Company’s name: Siemens IT Solutions and Services - Time.lex
Company’s address (optional):
Company’s logo (optional)
Contract No. 1, Framework contract ENTR/05/58-SECURITY, Specific contract N°1
Disclaimer
The views expressed in this document are purely those of the writer and may not, in any
circumstances, be interpreted as stating an official position of the European Commission.
The European Commission does not guarantee the accuracy of the information included in
this study, nor does it accept any responsibility for any use thereof.
Reference herein to any specific products, specifications, process, or service by trade name,
trademark, manufacturer, or otherwise, does not necessarily constitute or imply its
endorsement, recommendation, or favouring by the European Commission.
All care has been taken by the author to ensure that s/he has obtained, where necessary,
permission to use any parts of manuscripts including illustrations, maps, and graphs, on which
intellectual property rights already exist from the titular holder(s) of such rights or from her/his
or their legal representative.
This paper can be downloaded from the IDABC website:

http://europa.eu.int/idabc/
http://ec.europa.eu/idabc/en/document/6485/
© European Communities, 2007

Reproduction is authorised, except for commercial purposes, provided the source is acknowledged.
2
November 2007
Executive summary
The objective of the project is to analyse the requirements in terms of interoperability of electronic
signatures for different eGovernment applications and services taking into account the relevant
provisions of Directive 1999/93/EC on a Community framework for electronic signatures and their
national implementation as well as the report on the Directive and the standardisation activities on the
interoperability of electronic signatures.
The goal of this document is three-fold:
- identify and analyse the similarities and differences in the use of electronic signatures in
eGovernment applications in each Member State both in the legal context, and on the technical
implementation aspects;
- assess the impact of the identified similarities and differences on the interoperability of eSignatures
and hence of the eGovernment applications;
- prepare conclusions and recommendations on addressing interoperability issues related to the
mutual recognition of electronic signatures for eGovernment applications/services.
3
November 2007
Table of Contents
EXECUTIVE SUMMARY 3
1 DOCUMENTS 7
1.1 APPLICABLE DOCUMENTS 7
1.2 REFERENCE DOCUMENTS 7
2 GLOSSARY 8
2.1 DEFINITIONS 8
2.2 ACRONYMS 10
3 INTRODUCTION 11
4 ANALYSIS 14
4.1 EGOVERNMENT AND ESIGNATURE REGULATIONS 14
4.1.1 THE EUROPEAN LEGAL FRAMEWORK 14
4.1.1.1 Basic principles 14
4.1.1.2 Public sector clause: article 3.7 14
4.1.1.3 eSignatures and authentication 16
4.1.2 NATIONAL REGULATORY APPROACH MODELS 18
4.1.2.1 General strategy 18
4.1.2.2 National competence and organisation 24
4.1.3 NATIONAL ESIGNATURE REQUIREMENTS 27
4.1.3.1 Dominant Signature types 28
4.1.3.2 Choice of Unique identifiers 37
4.1.3.3 Technological choices 41
4.1.3.4 Cross border acceptance 41
4.1.4 NATIONAL TRENDS AND EXPECTATIONS 42
4.1.4.1 State of eSignatures 42
4.1.4.2 Interoperability requirements 43
4.1.4.3 Long term validity and storage 44
4.2 EGOVERNMENT APPLICATIONS USING ELECTRONIC SIGNATURES 47
4.2.1 APPLICATION APPROACH MODELS 47
4.2.1.1 Group 1: shared service approach 48
4.2.1.2 Group 2: ad-hoc approach 54
4.2.2 CLASSIFICATION BY MODEL 62
4.2.2.1 Introduction 62
4.2.2.2 Model 1: One-stop shop model 64
4.2.2.3 Model 2: common eSignature framework model 64
4.2.2.4 Model 3: Generic CSPs model 68
4
November 2007
4.2.2.5 Model 4: Application Specific CSP model 72

4.2.3 CLASSIFICATION BY COUNTRY 74
4.2.4 CLASSIFICATION BY SECTOR 77
4.2.4.1 eProcurement applications 77
4.2.4.2 Income tax applications 80
4.2.4.3 VAT applications 86
5 IMPACT ASSESSMENT AND RECOMMENDATIONS 92

5.1 INTRODUCTION 92
5.2 DEFINITIONS 92
5.2.1 SUPERVISION VS. ACCREDITATION 92
5.2.2 INTEROPERABILITY 92
5.2.2.1 Examples 94
5.2.3 CROSS-BORDER 95
5.2.3.1 Examples 97
5.2.4 NON-NATIONAL RESIDENTS 101
5.3 IDENTIFIED INTEROPERABILITY ISSUES AND RECOMMENDATIONS 103
5.3.1 AT LEGAL LEVEL 103
5.3.1.1 National perspective 103
5.3.1.2 Security levels – legal qualification of signature types 105
5.3.1.3 European eSignature directive compliance 107
5.3.1.4 Ad-Hoc solutions 107
5.3.1.5 Multiple government levels 108
5.3.1.6 National rules on identifiers 109
5.3.1.7 Conclusions 109
5.3.2 AT ORGANISATIONAL LEVEL 110
5.3.2.1 Link to eID schemes 110
5.3.2.2 Mutual recognition 111
5.3.2.3 Atypical registration procedures 112
5.3.2.4 Multiple speeds 115
5.3.3 AT TECHNICAL LEVEL 117
5.3.3.1 Incompatible use of identifiers 117
5.3.3.2 Signature Type 121
5.3.3.3 Dedicated Interface requirements 123
5.3.3.4 Recommendations 124
5.3.3.6 Signature format 124
5.3.3.7 Signature validation 125
5.3.3.8 Validation protocol 142
5.4 LIST OF POTENTIAL INTEROPERABILITY ISSUES AT TECHNICAL LEVEL 144
5.4.1 KEY LENGTH 144
5
November 2007
5.4.1.1 Problem description 144

5.4.2 CLIENT SOFTWARE 144
5.4.3 HARDWARE 144
5.5 INTEROPERABILITY ISSUES IN KEY E-GOVERNMENT SECTORS 144
5.5.1 EPROCUREMENT 145
5.5.2 VAT DECLARATIONS 147
5.5.3 INCOME TAXES 148
6 LIST OF RECOMMENDATIONS 150
7 CONCLUSIONS 153
8 ANNEX A: PATTERNS CROSS-COMPARISON 156

8.1 T HE COMPREHENSIVE REGULATORY APPROACH 156
8.2 T HE CENTRALISED REGULATORY APPROACH 158
8.3 T HE EPROCUREMENT SECTOR 161
8.4 T HE ET AX AND EVAT SECTORS 162
9 ANNEX B: TECHNICAL TRENDS SUMMARIZED 164
6
November 2007
1 Documents
1.1 Applicable Documents
[AD1] Framework Contract ENTR/05/58-SECURITY
1.2 Reference Documents
[RD1] eGovernment in the Member States of the European Union – 5th Edition – May
2006
http://ec.europa.eu/idabc/servlets/Doc?id=24769
[RD2] European Electronic Signatures Study
http://www.law.kuleuven.ac.be/icri/itl/es_archive.php?where=itl
[RD3] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 13 December 1999 on a Community framework for electronic
signatures
http://europa.eu.int/information_society/eeurope/i2010/docs/esignatures/esignatur
es_en.pdf
[RD4] Decision 2003/511/EC of 14 July 2003 on the publication of reference numbers of
generally recognised standards for electronic signature products in accordance
with Directive 1999/93/EC of the European Parliament and of the Council, OJ L
175, 15.7.2003, p.45
http://europa.eu.int/eur-
lex/pri/en/oj/dat/2003/l_175/l_17520030715en00450046.pdf
COUNCIL of 31 March 2004 on the coordination of procedures for the award of
public works contracts, public supply contracts and public service contracts
http://eur-
lex.europa.eu/LexUriServ/site/en/oj/2004/l_134/l_13420040430en01140240.pdf
[RD6] IDABC Work Programme Third Revision
http://ec.europa.eu/idabc/servlets/Doc?id=25302
COUNCIL of 31 March 2004 coordinating the procurement procedures of entities
operating in the water, energy, transport and postal services sectors
http://europa.eu.int/eur-
lex/pri/en/oj/dat/2004/l_134/l_13420040430en00010113.pdf
[RD8]
[RD9]
7
November 2007
2 Glossary
2.1 Definitions
In the course of this report, a number of key notions are frequently referred to. To avoid any
ambiguity, the following definitions apply to these notions and should also be used by the
correspondents.
o eGovernment application: any interactive public service using electronic means which is
offered entirely or partially by or on the authority of a public administration, for the mutual
benefit of the end user (which may include citizens, legal persons and/or other
administrations) and the public administration. Any form of electronic service (including
stand-alone software, web applications, and proprietary interfaces offered locally (e.g. at a
local office counter using an electronic device)) can be considered an eGovernment
application, provided that a certain degree of interactivity is included. Interactivity requires
that a transaction between the parties must be involved; one-way communication by a public
administration (such as the publication of standardised forms on a website) does not suffice.
It should be noted that for the purposes of this questionnaire, only services which rely on
eSignatures are relevant, and that the focus is on eGovernment applications offered to
citizens and businesses (A2C and A2B, rather than A2A).
o eSignature: data in electronic form which are attached to or logically associated with other
electronic data and which serve as a method of authentication with regard to this data. Note
that this also includes non-PKI solutions. However, PKI solutions are the principal focus of
this questionnaire, and non-PKI solutions should only be included if no PKI solutions are in
common use. It should also be noted that the questionnaire only examines eGovernment
applications in which the eSignature is used to sign a specific transaction, and not where the
signature is merely used as a method of authentication of the eSignature holder as defined
below.
o Advanced electronic signature: an electronic signature which meets the following

requirements:
(a) it is uniquely linked to the signatory;
(b) it is capable of identifying the signatory;
(c) it is created using means that the signatory can maintain under his sole control; and
(d) it is linked to the data to which it relates in such a manner that any subsequent change of
the data is detectable;
Again, this definition may cover non-PKI solutions.
o Qualified electronic signature: advanced electronic signatures which are based on a qualified
certificate and which are created by a secure-signature-creation device, as defined in the
eSignatures Directive1.
1
See http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:HTML
8
November 2007
o Authentication: the corroboration of the claimed identity of an entity and a set of its observed
attributes (i.e. the notion is used as a synonym of “entity authentication”). It should be noted
that the questionnaire is focused on the use of eSignatures as a method of signing a
transaction, and not on their use as a method for authenticating the eSignature holder.
o Relying party: any individual or organisation that acts in reliance on a certificate (in a PKI
solution) or an eSignature.
o Validation: the corroboration of whether an eSignature was valid at the time of signing.
9
November 2007
2.2 Acronyms
A2A ..............................................Administration to Administration
A2B .............................................. Administration to Businesses
A2C .............................................. Administration to Citizens
CA................................................ Certification Authority
CRL.............................................. Certificate Revocation Lists
CSP.............................................. Certificate Service Provider
eID ...............................................Electronic Identity
OCSP ...........................................Online Certificate Status Protocol
OTP..............................................One-Time Password
PKCS ...........................................Public-Key Cryptography Standards
PKI ...............................................Public Key Infrastructure
SA ................................................ Supervision Authority
SOAP ........................................... Simple Object Access Protocol
SCVP ...........................................Server-based Certificate Validation Protocol
SSCD ...........................................Secure Signature Creation Device
USB.............................................. Universal Serial Bus
TTP ..............................................Trusted Third Party
TSA..............................................Time Stamp Authority
TST ..............................................Time Stamp Token
XAdES ......................................... XML Advanced Electronic Signature
XML ............................................. eXtensible Markup Language
XML-DSIG.................................... XML Digital Signature
10
November 2007
3 Introduction
The background of this report is the European Community Programme for the interoperable delivery
of pan-European e-government services to public administrations, businesses and citizens
(hereinafter IDABC).2 The objective of IDABC is to identify, support and promote the development
and establishment of pan-European e-government services and the underlying interoperable
communications networks supporting the Member States and the European Community in the
implementation, within their respective areas of competence, of Community policies and activities,
achieving substantial benefits for public administrations, businesses and citizens.
The report is part of a larger study, of which the objective is to analyse the requirements in terms of
interoperability of electronic signatures for different e-government applications and services taking
into account the relevant provisions of Directive 1999/93/EC of 13 December 1999 on a Community
framework for electronic signatures and their national implementation. .
The first phase of this study provided an extensive overview of currently existing or envisaged
relevant e-government applications in all Member States, which make use of electronic signatures
(e.g. for public procurement, tax and social security declarations, request and delivery of documents,
etc.).
Per Member State, relevant information has been collected and a profile has been drafted describing
for each application the type of electronic signature legally required, the technical implementation of
the interface between the application and the electronic signature, the applicable technical restrictions
notably regarding interoperability with non-national electronic signatures and the authorities or
institutions that have been contacted to obtain information. The information has been collected
through a network of national experts.
The aim of this study is to analyse the national country profiles, to detect similarities and differences
and, on the basis of this comparative study, to provide an assessment from the perspective of
interoperability for cross-border e-government services in Europe.
The study focuses on signature applications with regard to the interaction between governmental
authorities and the public (A2B and A2C services, i.e. services to citizens, professionals, companies).
Purely internal interactions (A2A services, i.e. the e-government back-office) as such are not within
the scope of the study. Applications merely serving entity authentication purposes (i.e. not involving
electronic signatures) are not the aim of this study. They will be the object of a further study in the
framework of IDABC, focusing on electronic identity management schemes for e-government
purposes.
The main objective of the programme of which this study is a part, is to make progress in the field of
interoperability of electronic signature applications between Member States. The results of the study
must allow the elaboration of a strategy on the required inputs and components to produce an
interoperability solution for secure electronic signatures. Recommendations for such a strategy will be
the object of the third phase of the study.
This report aims at:

- comparing existing solutions and requirements from the countries and identifying similarities
and differences on the legal as well as on the technical levels. A topology of eGovernment
applications/services will be built based on their legal and technical requirements.
- detecting potential interoperability issues, i.e. legal and technical obstacles for using
electronic signatures in cross-border e-government transactions.
2
More information on the IDABC programme can be found on http://ec.europa.eu/idabc.
11
November 2007
- prepare conclusions and recommendations on addressing interoperability issues related to

the mutual recognition of electronic signatures for eGovernment applications/services
The report focuses on legal as well as on technical aspects of electronic signatures in e-government
applications.
The legal framework pertaining to the use of e-signatures in e-government applications can be a
deciding factor in its uptake. Particularly, the framework needs to meet the requirements of all
involved parties:
- it needs to offer legal certainty with regard to the requirements to be met by the used e-
signature technique;
- it needs to offer legal certainty with regard to the result of using the application (i.e. the legal
effect of the signature and the signed document);
- it needs to offer sufficient guidelines to service providers in all stages of the process
(application owners and designers, CSPs, token manufacturers, etc);
- it needs to ensure the long term validity of the signature and the signed document for any
application to which this factor is relevant;
- a variety of additional legal requirements need to be met, including with regard to privacy
protection, liability, and security.
In this report, we will describe what legal standards have been presented to the Member States and
Candidate Countries (hereafter: the ‘surveyed countries’), and how they have taken these to heart in
creating their own legal framework with regard to e-signatures in eGovernment applications. Specific
attention will be devoted to the requirements for the most dominant signature techniques for the
surveyed countries, and the impact that this may have on cross-border interoperability.
The main purpose is to provide a short descriptive overview of European regulatory initiatives and the
issues they present, and a more thorough examination of national approaches, specifically with
regard to their e-government regulations. To the extent possible, categories of approaches will be
proposed for each examined legal aspect. An evaluation of this information will be included in the
chapter on the impact of e-signature interoperability.
We will first take a brief look at the European legal framework with regard to e-signatures as it applies
to e-government applications, since this is essentially the baseline that has been provided to the
surveyed countries as a general target.
Secondly, the national regulatory approaches in the surveyed countries will be described, focusing on
the structural choices that have been made in establishing such a framework, particularly keeping into
account at which level regulations have been created (national vs. local; general vs. application
specific, etc.).
The third part of the analysis will indicate what e-signature solutions are
endorsed/recommended/required in the surveyed countries, and which requirements have been
imposed (including qualification according to the tiers of the e-signature directive, and accessibility of
the application to non-nationals). Finally the report will also examine the extent to which the
regulatory framework in the surveyed countries has stabilised at this point, and which future trends
can be expected.
From a technical perspective we will look in detail at every e-government application of all surveyed
countries to find if their approach is in some way illustrative of a given trend. The main purpose is to
describe the technical and organisational solution models, which need to be taken into account for
further analysis and recommendations. The applications will be classified in a limited number of
models, in order to obtain some degree of transparency and to enable an assessment with regard to
interoperability for cross-border e-government transactions.
12
November 2007
Four application models have been detected based on similarities shared by the described
eGovernment applications. The objective is to characterise and classify the various electronic
signature applications in the surveyed countries against these four models.
Secondly, we will define the concept of “interoperability”. Our analysis of the profiles of the surveyed
countries has shown that interoperability may have several interpretations. This section presents the
definition we used to classify the various e-government applications.
Thirdly, we present an analysis based on the models. For each model, a list of applications belonging
to that model will be presented, and the major deviations of each application type will be observed,
and assessed.
Finally, a last sub-section will contain a list of all eGovernment applications that have been assessed,
sorted by country and by model.
The legal and technical analysis of the e-signature applications in the surveyed countries will lead us
to a list of interoperability issues. The issues will be presented and can be used as a basis for a
discussion on possible European strategies in this area.
13
November 2007
4 Analysis
4.1 eGovernment and eSignature regulations
4.1.1 The European legal framework
Before taking a closer look at the national regulatory e-signature frameworks, it is worth providing a
short overview of the main European provisions in this regard, as they essentially constitute the
baseline provided to the Member States as an aide or limit to their own regulatory initiatives.
In this section, we will take a succinct look at the e-signatures directive3 (hereafter referred to as ‘the
Directive’) as it pertains specifically to the public sector.
4.1.1.1 Basic principles
The stated goal of the Directive, as expressed in article 1, was to create a harmonised legal
framework for the use of electronic signatures and certain related certification services, in order to
improve their legal reliability and encourage ongoing dematerialisation efforts:
“Article 1. The purpose of this Directive is to facilitate the use of electronic signatures and to
contribute to their legal recognition. It establishes a legal framework for electronic signatures
and certain certification-services in order to ensure the proper functioning of the internal
market. […]”
The Directive’s provisions were in principle horizontal in scope, i.e. without any inherent limitation to a
specific sector. Thus, its tiered categorisation of signatures (basic, advanced and qualified), and more
importantly the related principles of non-discrimination and legal equivalence (article 5) would have
been applicable to solutions employed in the e-government sector as well.
However, article 3.7 contains an important derogation of this principle:
“7. Member States may make the use of electronic signatures in the public sector subject to
possible additional requirements. Such requirements shall be objective, transparent,
proportionate and non-discriminatory and shall relate only to the specific characteristics of the
application concerned. Such requirements may not constitute an obstacle to cross-border
services for citizens.”
4.1.1.2 Public sector clause: article 3.7
It is clear that the Directive thus allows Member States to impose additional requirements to
electronic signatures as used in public sector applications. The main purpose of the legal section of
the report will be to assess how the Member States have interpreted this clause, and what type of
signatures they commonly require for such applications.
3
Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a
Community framework for electronic signatures, OJ L 13, 19.01.2000, p.12.
14
November 2007
It is noteworthy that the Directive prohibits the creation of obstacles “to cross-border services for
citizens” (emphasis added) but we don’t think that this term has to be interpreted in a strict sense in
this context.
However, even if this would be so, the requirements must remain “objective, transparent,
proportionate and non-discriminatory and shall relate only to the specific characteristics of the
application concerned”. Thus, it is clear that the intended goal was for such requirements to be the
exception (as they should be application-specific), and clearly justified by the needs of the service
being provided and the common interest.
Furthermore, and specifically with regard to the cross-border exchangeability of e-signature, the
Directive also explicitly notes that:
“Article 3 – Market Access

1. Member States shall not make the provision of certification services subject to prior
authorisation.
2. Without prejudice to the provisions of paragraph 1, Member States may introduce or
maintain voluntary accreditation schemes aiming at enhanced levels of certification-service
provision. All conditions related to such schemes must be objective, transparent,
proportionate and non-discriminatory.
Member States may not limit the number of accredited certification service providers for
reasons which fall within the scope of this Directive.
3. […]”
The ELSIGN Study4 already noted that these principles of voluntary accreditation and public sector
restriction occasionally combined to a situation which was hardly in compliance with the Directive’s
intentions:
“Also, the Directive’s rules on voluntary accreditation seem to be misunderstood by national

governments. Many European countries wrongfully consider voluntary accreditation schemes
as a means of controlling whether or not a Certification Service Provider operates in
compliance with the provisions of the Directive. Another alarming observation is that the
voluntary accreditation schemes, in many European countries, are in practice, not really
voluntary. A typical example being that many national e-government programmes only accept
accredited CSPs to participate in the programme, and thus indirectly oblige a CSP to get an
accreditation. This evolution is certainly not in line with the Directive’s vision.
Concerning the so-called ‘public sector exception’ of Article 3.7, which allows Member States
to make the use of electronic signatures in the public sector subject to possible additional
requirements, we have seen divergences in both the interpretation and implementation of this
provision. It seems clear that in many countries the use of electronic signatures in the public
sector is subject to additional (security) requirements. Communicating electronically with
public authorities is in many countries possible only through the use of signatures based on a
Qualified Certificate issued by an accredited CSP. Member States need to be reminded that
applying additional conditions can only be justified by objective reasons and should only relate
to the specific characteristics of the application concerned. Also, Member States need to
ensure that basic competition rules are not being infringed by their initiatives.” (p.5)
4
Study on the legal and market aspects of electronic signatures, see
http://europa.eu.int/information_society/eeurope/2005/all_about/security/electronic_sig_report.pdf
15
November 2007
Finally, in its recommendations, the ELSIGN Study stated:
“[…] it is necessary to perform a more detailed study on the internal Market consequences of
the e-government programmes of the Member States. There is a clear danger that these
programmes will result in national barriers, fragmentation and [lacking] interoperability.” (p. 12)
One of the main purposes of this report is precisely to assess whether or not this risk has materialised
in practice.
4.1.1.3 eSignatures and authentication
A major and frequently recurring point of debate is the relationship between electronic signatures and
authentication. In practice, it frequently occurs that a person is requested to authenticate himself in an
e-government application, after which he may exchange certain documents freely and without any
further technical steps. This method of proceeding (which is common in many countries, but which is
particularly prevalent in e.g. the United Kingdom, Lithuania, the Netherlands and Malta) is often
signalled as an electronic signature, both by the national experts and by the public sector application
owners. However, there is some debate as to whether or not such a process can be considered an
electronic signature.
A significant number of experts are of the opinion that this is the case. The reasoning behind this is
typically twofold. First of all, it is clear that the underlying process from a technical perspective can be
quite similar, in the sense that a PKI system is often5 used to authenticate the user, and that to the
layman this process is barely distinguishable from an actual act of signing6. Secondly, the Directive
explicitly defines the electronic signature as ‘data in electronic form which are attached to or logically
associated with other electronic data and which serve as a method of authentication’ (article 2.1,
emphasis added). Thus, there is a legal basis for the link between authentication and e-signatures7.
None the less, in our opinion the distinction between two core functionalities must be made. Firstly, it
is indeed clear that any signature will serve to some extent as a mechanism for authentication,
understood as the corroboration of a claimed set of attributes or facts with a specified, or understood,
level of confidence8. However, for the purposes of electronic signatures, the ‘authentication’ referred
to in the Directive can in our view only refer to data authentication, understood as the corroboration
that the origin and integrity of data is as claimed9; and not to entity authentication10.
5
But not always; username/password systems are also in common use for lower security type
applications.
6
Especially in cases such as the Belgian eID card, where the same PIN code is used for signature
purposes and authentication purposes, so that only the more attentive and knowledgeable users will
be able to ascertain which of the two certificates is actually being used by the application.
7
This perspective is also taken in the paper ‘Regulating a European eID – A preliminary study on a
regulatory framework for entity authentication and a pan European electronic ID for the Porvoo e-ID
Group’ by Thomas Myhr. See
http://www.fineid.fi/vrk/fineid/files.nsf/files/7431D844D1C359F9C225711F004553CB/$file/Thomas_M
yhr_report.pdf
8
See inter alia the Modinis eIDM Glossary, https://www.cosic.esat.kuleuven.be/modinis-
idm/twiki/bin/view.cgi/Main/GlossaryDoc#4_5_Authentication
9
See inter alia the Modinis eIDM Glossary, https://www.cosic.esat.kuleuven.be/modinis-
idm/twiki/bin/view.cgi/Main/GlossaryDoc#4_5_1_Data_authentication
16
November 2007
We argue against the extension of the notion of a signature to include entity authentication processes,
both for practical and for philosophical reasons. In legal practice, a signature has traditionally been
only one of many ways in which a person can confirm his identity, express his consent, effect non-
repudiation, and a myriad of other functions which are traditionally ascribed to signatures. The
signature has been given a specific legal status in most jurisdictions, although other ways of obtaining
the same legal result are usually (but not always) allowed. It is therefore not surprising that e-
government applications would show the same degree of flexibility, and permit other solutions than
electronic signatures to serve the same function. This does not mean in our opinion that such other
solutions can be readily considered to be signatures.
Indeed, if entity authentication could be said to be a form of signature on the grounds that it can
obtain similar results, the traditional value attached to signatures in many legal frameworks would be
in serious peril. After all, if one can be said to have electronically ‘signed’ a document after suitably
secure electronic entity authentication, then it seems one must also accept that a paper document
should be considered ‘signed’ if a person has merely handed it in after authenticating himself in
another suitable fashion (e.g. after ID card verification, or simply after visual identification by
someone familiar with the provider of the paper document). Paper documents should by this logic be
considered ‘signed’, even if there is ostensibly no signature attached to the document. This is not the
case: both in the paper and in the electronic context (as witnessed by the definition of the electronic
signature in the Directive), a signature is always ‘attached to or logically associated with’ the signed
document.
This distinction is thus not a purely theoretical or academic exercise. To accept that entity
authentication can be equalled to an electronic signature for the reason that the same functions are
served is an exaggeration of the theory of functional equivalence, to the point where the notion of a
signature becomes redundant, and where it merely becomes synonymous with the expression of
consent, validation, non-repudiation, and any other functionality which can be ascribed to a signature.
The purpose of the Directive was not to abolish the notion of a signature, but to allow technical
equivalents to it.
It is therefore our opinion that any process ensuring only entity authentication cannot be given the
status of an electronic signature, no more than a ‘real life’ entity authentication process can turn an
unsigned document into a signature bearing one.
These considerations should of course not be interpreted to mean that we consider entity
authentication as an invalid operating method in e-government applications, or indeed that we would
consider it to be somehow inadequate or less suitable than an electronic signature. As in any other
legal field, a signature has its purposes and its uses in e-government, but it should never be
considered to be a requirement when a different solution offers the necessary guarantees. We merely
wish to emphasise that in such cases, we find that no signature is actually used, and that applications
using purely entity authentication are therefore strictly speaking out of scope for this study.
It is interesting to note that many countries relying on entity authentication methods are in a transitory
phase, where the authentication method is planned as a user friendly but lower security level solution,
but where actual signature solutions are being planned for higher security applications.
10
See also the ELSIGN Study (The Legal and Market Aspects of Electronic Signatures report) in this
regard. See
http://europa.eu.int/information_society/eeurope/2005/all_about/security/electronic_sig_report.pdf
17
November 2007
Example: the Maltese approach:
“This mechanism is being rolled out in three phases. The first phase consists in the provision of a
username and password to each citizen for him/her to be able to authenticate himself/herself when
requesting eGovernment services. The second level is the distribution of digital certificates, while the
third level consists of a qualified digital certificate based on a smart card which would replace the
current Government-issued Identity Card. Malta is currently at the first phase of the project and has
implemented eID Level 1.
However, some eGovernment services already run on normalized digital certificates. For these
restricted number of eGovernment services, meant for Government’s business Clients, the Maltese
government procures digital certificates from a commercial CA. This allows Government, as a relying
party and the Business as the client, to benefit from a range of advanced eGovernment services
and to gain experience with certificate-based eServices. Digital certificates act as identity tokens for
electronic authentication but none of the eGovernment services require the user to sign
electronically.”
Thus, the main driver behind entity authentication as a proxy for electronic signatures seems to be
user friendliness and flexibility, rather than any philosophical or political preference. It has been noted
by several experts that entity authentication is retained as a proxy for electronic signatures for the
simple reason that it is considered ‘good enough’ in terms of safety and reliability, and that additional
requirements would encumber the underlying processes excessively in a manner that would offer little
added value.
For these reasons, entity authentication shall only be dealt with below insofar as it is presented by a
Member State as its current main proxy for electronic signatures. It should be noted that, for reasons
of brevity, ‘entity authentication’ will simply be referred to as ‘authentication’ in the remainder of the
report.
4.1.2 National regulatory approach models
A first question that needs to be assessed is how the surveyed countries generally regulate their e-
signature applications. There are several components to this question.
First of all, the general regulatory strategy of the surveyed states needs to be described: is there
centralised regulation, do the rules vary from sector to sector or even from application to application,
etc. In short, a first question is to what extent a global vision is enacted in the country’s regulation.
Secondly, there is the legal-technical issue of competence: at what level is regulation enacted? While
national harmonisation is expected, it is none the less conceivable that certain regions or even
communes in any given country have taken a frontrunner role, possibly by relying on different
technological solutions.
4.1.2.1 General strategy
While all surveyed countries have put in place specific regulation with regard to e-signatures in
general (typically as a result of the transposition of the Directive, or at least updated to reflect its
provisions), there is still a significant difference in the general strategies followed by the surveyed
18
November 2007
countries. While all aim to encourage the use of e-signatures in public sector applications, the
regulatory approach can differ significantly. Broadly, the following archetypes can be distinguished
(with the usual caveat that virtually no country falls cleanly and uniformly in one category, but that
most choose to incorporate aspects of several approaches).
4.1.2.1.1 Centralised
A first conceivable strategy (followed by a large majority of European countries) is the creation of a
single centralised legal framework, consisting of a single e-signatures law, on which all e-signature
uses are to be based. While this central legislation may have limited specific references to the use of
e-signatures in an e-government context (usually in the form of a transposition of the aforementioned
article 1.7 of the Directive), the focus is on establishing a global e-signatures framework, without
emphasis on the manner in which it is used.
Such central laws are then typically completed by a series of governmental/ministerial decrees
determining the specific modalities of the use of e-signatures in an e-government context. Thus, this
approach can be summarised as creating an e-signature regulatory core, and drafting the necessary
additions and clarifications around this core as required.
Example: the Belgian approach:
“The legal basis for the introduction of electronic signatures in eGovernment applications can be
found in various legislative provisions, which allow changing the way in which data are collected for
e.g. social security and tax purposes, or which put electronic notifications on par with paper
notification in a social security context.
By way of example, the social security contributions’ collecting institution can lay down the form and
11
rules for the electronic obligatory notification of the start and end of employee relationships . Also,
the social security management committee can lay down conditions for access to and use of the
information systems of social security institutions and the information system of the federal
government, including standards for message exchange.”
The result can be diverse and occasionally lacks consistency, since only the core is common, and
actual application details can vary quite widely.
This approach is followed in a number of countries, including:
11
Royal decree of 5 November 2002 introducing the immediate notification of an employment
relationship.
19
November 2007
Country Normative source:

Belgium The act of 9 July 2001 laying down a legal framework for electronic
signatures and certification services
Croatia Electronic signature act, Narodne novine, no. 10/2002
Cyprus Legal Framework for Electronic Signatures and Associated Matters Law of
2004
Czech Republic Act on electronic signature 227/2000 Coll.
Denmark Act no. 417 of 1 October 2000 on Electronic Signatures
Estonia Digital Signature Act (hereinafter DSA) on March 8, 2000
Finland The Act on Electronic Signatures (14/2003); and the Act on Electronic
Services and Communication in the Public Sector (13/2003)
France Act of 13 March 2000 regarding several provisions related to electronic
documents and the electronic signature; and the Arrêté of 26 July 2004 with
regard to the qualification of certification service providers issuing digital
certificates and to the accreditation of the bodies in charge of the
evaluation of CSPs.
Greece Presidential Decree 150/2001 of 25 June 2001
Hungary Act XXXV of 29 May 2001 on electronic signatures
Latvia Electronic Documents Law effective as of 1 January 2003
Lithuania Law on Electronic Signature No VIII-1822 of 11 July 2000
Luxembourg Regulation of 1 June 2001 on electronic signatures, electronic payments
and the creation of an electronic commerce committee
The Netherlands Act of 8 May 2003 on electronic signatures
Poland Regulation of the Ministry Council from August, 7th, 2002 concerning
technical and organisational requirements for qualified certification
authorities, certification policies for qualified certificates issued by them,
and technical requirements for secure signature creation and verification
devices
Romania Law no. 455/2001 regarding the electronic signature
Slovakia Act of 15 March 2002 on electronic signature
Sweden Act on Qualified Electronic Signatures
4.1.2.1.2 Comprehensive
This second approach attempts to solve this problem by first establishing a holistic e-government
policy or vision (or even a broader e-society policy comprising such issues as e-government, e-
inclusion, e-health, etc.), which is then implemented in a homogeneous manner throughout all
affected sectors.
This typically results in a single broader legal act encompassing electronic signatures (or e-society
activities in general); or in a series of regulatory initiatives aiming to gradually implement a
centralised vision.
20
November 2007
Example: the Austrian approach:
The E-Government Act is an overall legal basis for the instruments used to provide eGovernment
and for closer cooperation between all authorities providing eGovernment services. Guiding
principles are freedom of choice for users of which means of communication to use when submitting
public administration requests, security and improved legal protection provided by appropriate
technical means such as the citizen card, and unhindered access for people with special needs to
public administration information and services by the end of 2007.
The E-Government Act defines the principal eGovernment elements. This includes the citizen card
concept together with the identity management system based on sector-specific personal identifiers,
provisions on the authority to act as a representative, or electronic delivery. Related to electronic
signatures, two provisions have been made: […]”
Example: the German approach:
th
“On 13 September 2006 the federal Government passed a new programme with the name “E-
Government 2.0”. The content and basic thinking is in line with the E-Government action plan as part
of the i2010 initiative. Programme implementation resides with all federal departments with
coordination being handled by the Federal Interior Ministry. To this end a dedicated eGovernment
competence centre will be set up within the BMI in 2007.”
The main benefit of this approach is that such initiatives tend to benefit from an increased internal
consistency, since the relevant provisions are drafted as a whole. Such approaches also favour
distinct solution models, often emphasising one single token or one specific technology over others.
The downside of this approach is that the system can become inflexible or immune to changes, since
any modification can upset the coordination between the provisions, negating the central vision.

Austria The E-Government Act of 1 March 2004
Germany E-Government 2.0 programme
Italy Extensive set of rules, including d.lgs. 82/05, the Digital Administration Code
(“Codice dell’amministrazione digitale”
Portugal Resolution of the Council of Ministers No. 108/2003 the Plan of Action for the E-
Government
Slovenia eGovernment Strategy of the Republic of Slovenia for the period 2006 to 2010
Spain Plan de Medidas 2006-2008 para la mejora de la Administración (Measures Plan
to improve the Administration
Turkey The Information Society Transformation Policy (high level action plan)
21
November 2007
4.1.2.1.3 Sector Based
A decentralised version of the earlier approaches, this model entails the creation of a suitable legal
framework on a sector by sector basis, i.e. specific regulations for the social security sector, the tax
sector, public procurement, civil administration, etc. Rather than depending on a global e-signatures
model, this approach favours the creation of a model taking into account the specific problems and
sensitivities of each concerned sector.
The genesis of such approaches is typically not the result of a specific vision or of a desire to ensure
that the regulatory framework is optimally adapted to the needs of the sector involved. Rather, such
approaches tend to evolve organically in situations where no central framework for e-signatures
existed, but where the need for technological advancements was still felt and acted upon in a specific
sector. Thus, it is conceivable that sector specific solutions are created before a national solution
model.
This is e.g. the case in Malta, where the current trend is to rely on authentication mechanisms
(userID/password based), rather than on e-signatures, except for two distinct sectors where specific e-
signature solutions have been introduced.
Example: the Maltese approach:
“The usage of electronic signatures is as yet not very diffused, since most of the services launched
have been based on eID Level 1 authentication mechanism (using a username and password). This
is not the case for only the following eGovernment services:
i. the Inland Revenue Department’s (IRD) eGovernment services for:

• on-line submission of social security forms (for employers who employ ten or more
employees)
• on-line submission of tax and social security forms and the related payments of tax
contributions (for Tax Practitioners for their corporate taxpayers)
ii. the Vehicle Licenses Online for:

• vehicle-owners who wish to pay their road license online
• vehicle-owners who wish to check the due date of the next Vehicle Roadworthiness Testing
• Insurance agents who wish to provide the road-license payment to their clients through an
authenticated login”
The advantage of sector specific regulation is of course that the solution has been built to the exact
needs of that sector, which should (in theory) result in a relatively well suited framework.
The obvious downside is that solution models can differ greatly from sector to sector, thus harming
consistency on a national scale, and creating interoperability problems even within a nation’s borders.
Such approaches are typically implemented by simply modernising existing legal texts to
accommodate a specific new technology, without introducing more all-encompassing changes.
Alternatively, as in the Maltese example above, it can be a result of an as of yet incomplete transition
to a generic signature framework.
22
November 2007

Malta Specific systems for internal revenue and transportation sectors apart from the
generic regulation ( Chapter 426 of the Laws of Malta, subsequently amended by
Legal Notice 251 of 2006)
Ireland Electronic Commerce Act 2000 is applicable to e-signatures in general, but sector
specific rules exist as well
4.1.2.1.4 Ad hoc legal frameworks
This final model is the logical extreme of the sector based approach described above. In this specific
case, regulation is created not with regard to an entire legal system or to a specific sector, but
specifically for a single application. While more limited in scope than the sector based approach, the
underlying logic is similar: a desire or need to advance one specific application, while a more global
vision has not yet been universally accepted.
This is a model that has been followed to a certain extent in Bulgaria, where efforts are now underway
to harmonising national e-signature practices.
Example: the Bulgarian approach:
“At the present moment the Bulgarian eGovernment is at a stage of development whereby the
available electronic services are mostly separate elements than parts of an organized structure. The
eGovernment projects are usually implemented separately within the structure of one administrative
body and under the control and the coordination of this body. Steps for overcoming the lack of
coordination between the administrative authorities in relation to the eGovernment development
have been undertaken through drafting a particular legislative framework of the Bulgarian
eGovernment, including the eGovernment Strategy, Action Plan for the implementation of the
Strategy, eGovernance Act etc.”
A similar situation presently exists in Slovenia:
Example: the Slovenian approach:
“Currently the applications in public administration that rely on e-signature use different modules for
creating digital signatures. Most of them use web components while others integrate desktop signing
modules. Such a situation is quite unsuitable because digital signatures created in all these
applications are not interoperable and some of them are not developed according to guidelines and
recommendations. Recently a decision to unify solutions for digital signatures in all public
administration applications has been taken. A tender for development of an independent module for
creating digital signatures will soon start and the selected solution will be available to all public
administration institutions.”
23
November 2007
However, the availability of specific ad hoc solutions is not restricted to legacy applications that have
not yet been sufficiently harmonised. In several instances, applications were reported that relied on
distinct signature mechanisms because it was felt that the generic framework did not provide
adequate safeguards to meet the requirements of the field at hand:
Example: the UK approach:
However, there are two notable applications that do not use the [eGovernment] portal (and they are
both described in more detail below).
The first is the e-Conveyancing application being developed for the Land Registry, which is a
government executive agency and trading fund responsible to the Lord Chancellor that keeps and
maintains the Land Register of England and Wales. Its main purpose is to register title to land and to
record dealings once the land is registered. Established in 1862, it is required by statute to be self-
financing and makes no call on public funds.
It was felt that the extreme sensitivity and liability implications relating to transactions for the buying
and selling of people’s homes meant that a bespoke solution needed to be developed that could be
introduced carefully in phases with tight controls on all aspects of the process, and should thus not
be added into the more generic solution provided by the Government Gateway.
The second such application is the DTI’s Oil & Gas Trust Scheme. Here it was felt that the
requirements of the industrial sector being served were more specific than those provided for by the
Government Gateway’s generic approach and that the financial model dictated by the value of the
transactions meant that a standalone solution was the most efficient way of achieving a workable
solution. Like the Government Gateway, tScheme is used as the basis for determining the suitability
of the CAs but unlike it, there are extra requirements placed on the CA over and above the basic
tScheme approval criteria.
It should be noted that the existence of ad hoc legal frameworks can in a sense be encouraged by
harmonisation initiatives. For example, following the e-procurement directives (Directive 2004/17/EC
and Directive 2004/18/EC), a given Member State may decide to prioritise the implementation of an
e-procurement platform incorporating e-signature functionality, before a global strategy for e-
government applications in general has been put into place.
Again, the main risk is the creation of a disjointed or maladjusted legal framework, when a more
global vision is drafted into law that does not mesh entirely with the legacy application created for a
specific problem field.

Bulgaria The Electronic Documents and Electronic Signatures Act is an attempt to
coordinate eSignature policy; but harmonization is not yet complete.
United Kingdom Existing legislation is being amended on a case by case basis.
4.1.2.2 National competence and organisation
Aside from the general regulatory approach, issues of national competence can also play a
noteworthy role in assessing interoperability risks. Particularly (but by no means exclusively) within
24
November 2007
federal countries, the division of competences between the federal and regional levels can be
complicated, since there may be a common e-signature infrastructure which is offered on a federal
level which is open to use by regional or local authorities; or such regional or local authorities may
create their own independent infrastructures. Depending on the national situations, these diverging
local solutions may not (yet) have been subjected to harmonisation initiatives.
While the focus of the study was on national e-signature policy, which inevitably slants results toward
national solutions rather than regional/local initiatives, the main conclusion is that even federal
countries are attempting (or have already attempted) to harmonise their e-signature infrastructures on
a federal level. Two examples of this are Belgium and Germany.
“eGovernment, in particular horizontal integration, is driven by the following services:
Federal eGovernment
Federal eGovernment initiatives are lead and coordinated by FedICT, the Federal Public Service for
Information and Communication Technology (www.fedict.be).
Regional eGovernment
Regional eGovernment initiatives are lead and coordinated by the respective regional services.
• CORVE, the coordination service for Flemish eGovernment (http://www.corve.be);
• EASI, the coordination service for Walloon eGovernment (http://easi.wallonie.be);
• BRIC, the Brussels Regional Informatics Centre, for the Brussels Capital Region
(http://www.bric.irisnet.be/site/en).
Local eGovernment
Local eGovernment initiatives are lead and coordinated by local authorities, mostly municipalities.
Several municipalities set up an online interactive desk for the provision of eGovernment services
(www.iloket.be), developed by the IT service provider for communes (www.cipal.be). Typically, these
systems rely on the authentication mechanisms offered on a federal level, usually the e-ID card,
certificate or token offered by FEDICT (see below for a description of each option). In practice, the
user visits the communal website to access a local portal, which verifies the user’s credentials
through an LDAP framework offered by FEDICT. Upon successful authentication by FEDICT on a
federal level, the end user can access the local service.
[…]
As most electronic signatures in eGovernment applications have been designed at a federal level,
internal Belgian interoperability difficulties are few.”
25
November 2007
Similarly, the German report notes:
Example: the German approach:
“In recent years Germany has experienced enormous changes in the public administration arena
both at federal and state level and at community level. As long ago as 1999, the federal Government
placed extensive emphasis on its reform programme "modern state - modern administration" for
modernising the Federal Republic of Germany’s public administration. 440 of the federal
Government’s administrative services were made available online as part of the “BundOnline 2005“12
initiative, which came to an end in December 2005. The lead role was taken by the Federal Interior
Ministry (Bundesministerium des Inneren - BMI)13. It is fair to say however that only a very small
proportion was designed for the use of electronic signatures.
However, because of Germany's federal structure - Germany is organised into 16 federal states14,
which exercise responsibility on their own account and some of which are able to look back on a
long tradition - the federal Government is unable to take any far-reaching decisions on behalf of the
federal states and municipalities. As most administrative services in Germany are provided not by
the federal Government but by the states and municipalities, their eGovernment activities assume
particular significance in the German context. It would clearly be beyond the scope of this study to
examine all of the eGovernment initiatives of the 16 federal states.”
However, despite both being federal states, the practical situation is noticeably different, with Belgium
having a significantly more centralised system, with less fragmentation and diversity between its
constituent regions and communities15.
12
http://www.bundonline2005.de/
13
http://www.bmi.bund.de/
14
http://www.magazine-deutschland.de/bl_overview.php
15
It can be argued that this is a consequence of the historical genesis of the federal states involved:
Belgium is a centrifugal federal state (i.e. a former unitary state that has at some point decentralised
part of its competences), which could naturally lead to a more unified approach than would be the
case for a centripetal federal state such as Germany (i.e. a federal country composed of states that
traditionally had a larger degree of autonomy which have centralized part of their competences).
Since this discussion is out of scope for this Study, it will not be examined further.
26
November 2007
Again, it should be noted that issues of fragmentation between regions also occur in unitary nations:
Example: the Polish approach
“As the result of the hierarchical administrative structure most of systems and services built for
eGovernment purposes are also very hierarchised. Moreover, in the case of eGovernment systems in
Poland there is a tendency to centralise information during collection, storage and processing. The
information is transferred from the communities and district level to the regional administration authorities
(the ‘voivodeship’ level); then the direct transfer from the voivodeship level to the central administration
authorities (ministries, departments) occurs. […] Practically there are no intersector public administration
systems, nor regional/local government ones. It means there is a lack of a vertical and horizontal
integration. Therefore the citizen (or an organisation) has no possibility to gather information from one
access point. He is forced to use many portals and access points.
[…]
In Poland the minister designated for IT implementation is responsible for the development of intersector
A2C and A2B IT solutions (horizontal integration), whereas the responsibility for sector-specific IT
solutions (vertical integration) is delegated to the minister of an appropriate government administration
department.
So there is no institution at the national level which would be responsible for the development of all IT
systems which use digital signatures.”
4.1.3 National eSignature requirements
In this section, we will take a closer look at the signature requirements most commonly imposed by
laws or regulations to the dominant e-signature applications in the surveyed countries. It should be
noted that the emphasis here is not on the legal requirements imposed by the core legislations (which
is typically a faithful transposition of the Directive and therefore broadly includes provisions for all
signature types), but rather on the national administrative practices.
First of all, this requires an examination of the legal qualification of the signature type most commonly
required in e-government e-signature applications (in terms of the Directive: a
basic/advanced/qualified signature or an ad hoc solution that does not map cleanly into these
groups).
Secondly, we will examine what kind of unique identifiers are included in the certificates of PKI-based
signature systems, and the legal issues (mostly with regard to privacy regulations) revolving around
these.
A brief overview will also be given to the (lack of) technological neutrality of the legal frameworks in
the surveyed countries, and the extent to which any specific technology is allowed / encouraged /
mandated.
It should be reiterated that this report is descriptive; the consequences of these qualifications for
interoperability purposes will be dealt with in section 5 of this report. Nonetheless, a summary
overview will be provided at the end of this section describing the measures which are commonly
taken to allow cross-border functionality.
27
November 2007
4.1.3.1 Dominant Signature types
It is interesting to note that, while most countries have faithfully copied the provisions of the Directive,
several countries have interpreted these in a slightly different manner, or have tailored their specific
e-government e-signature policies to their legal traditions. In this section of the Report, we will provide
a short overview of the national e-signature policies, and discuss a few specific interesting examples
in more detail.
4.1.3.1.1 Overview table of signature requirements
In this section, we will provide a short overview of the requirements imposed on the principal e-
signature solutions in the surveyed countries. For specific details (including alternative signature
types less commonly encountered in these countries), we refer to the full country reports.
For the purposes of this report, the qualifications are used in the following sense:
• Qualified signature: use of a qualified certificate in combination with an SSCD, as the notion
is defined in the glossary above. Note that in most cases, the SSCD is not formally accredited
as such, but its status is generally accepted.
• Qualified certificate: use of a qualified certificate in the sense of the e-Signatures Directive16
is required, but no requirement of an SSCD is presented.
• Advanced signature: use of a non-qualified certificate meeting the requirements of the
Directive as presented in the glossary above.
• Simple signature: use of a lower level signature solution, meeting the definition of an
electronic signature in the Directive, but not that of an advanced or qualified signature. In this
case, the specific solution type is commented further below.
• Authentication: use of an authentication mechanism, typically based on a username/password
system, which cannot formally be considered a signature as discussed above in section 6.2.3.
In this case, the specific solution type is commented further below.
It should be noted that the table below contains the qualifications reported by the national
correspondents, as reviewed by the Expert Group.
Country Signature Detail / Other info

requirements
Austria Qualified signature The so called ‘Citizen Card concept’ is a voluntary concept,
typically but not necessarily (e.g. mobile phones) rolled out
through smart cards. Uses sector specific variations on a
unique ID number (the so called ‘SourcePIN’). Foreign
solutions can be integrated by mapping. So called
‘administrative signatures’ are being phased out (deadline: end
2007), but are considered as equivalent to qualified signatures.
16
As communicated by the correspondent. It should be noted that some countries may impose
additional requirements on qualified certificates, such as the French requirement for CSPs to issue
certificates in compliance with the norm AFNOR AC Z74-400 (TS 101 456); which would imply that
qualified certificates in other countries might not be considered qualified under French law if they
have not received such certification.
28
November 2007

requirements
Belgium Qualified signature Through mandatory eID card containing national register
number. Qualified soft certificates from accredited CSPs are
becoming secondary to the eID card.
Bulgaria Qualified certificate The so called ‘Universal Electronic Signature’, a soft certificate
containing the Uniform Citizen Number.
Croatia Qualified certificate Software certificate from (one) accredited CSP
Cyprus Authentication Signature functionality is to some extent emulated through
authentication procedures, but no real e-signature applications
were identified.
Czech Republic Qualified certificate Soft certificate from accredited CSP, can be stored on smart
card if desired
Denmark Advanced So called ‘OCES’, a soft certificate containing a personal
signature identification number (but not the holder’s central personal
number, which is the unique identifier used in the public
sector).
Estonia Qualified signature Through mandatory eID card containing personal ID number.
Finland Authentication; The TUPAS bank identification system is a two-factor
password authentication method, which does not use
qualified certificate
signatures. In contrast, the FINEID system is an eID card with
certificates for authentication and signatures.
France Advanced Soft non-qualified certificate in compliance with PRIS V1 from
signature an accredited CSP, can be stored on smart card or USB stick
if desired
Germany Qualified Soft certificate from accredited CSPs, can be stored on smart
signatures card if desired
Greece Qualified certificate Electronic signatures are only used in specific projects by
public officials, not yet by the general public.
Hungary Advanced Soft certificates from accredited CSPs, often stored on smart
signature and cards.
qualified certificate
Ireland Simple and The main system is the Irish Public Services Broker, which
qualified electronic functions as a central portal using a username/password
signature / system for authentication purposes. However, the outcome is
Authentication described as a simple signature. For a limited number of user
groups, qualified signatures are also in use.
Italy Qualified signature Certificates from accredited CSPs using SSCDs, usually
delivered through the eID card (an authentication card issued
by municipalities) or a national services card (a combination
authentication/signature card issued by several public
administrations).
Latvia Qualified signature Development is still in early stages: the sole CSP issuing
qualified software certificates thus far is Latvijas Pasts, and
the sole application is tax declaration.
29
November 2007

requirements
Lithuania Qualified signature There are some services, based on electronic signature (not
/ Authentication only for authentication), Citizens can read legal acts published
in official magazine (http://www.valstybes-zinios.lt). For
authentication in government services portal
(http://www.epaslaugos.lt/govgate/index.do?language=lt) is
possible to use qualified certificates or banking systems.
Luxembourg Advanced An advanced electronic signature on a smart card is offered by
signature / LuxTrust; qualified certificates are planned but not yet rolled
authentication out. In practice, username/password authentication is
frequently used instead of electronic signatures.
Malta Authentication / The baseline solution is the eID (electronic identity) which can
advanced signature be issued to the holders of a Maltese eID card, and which
and qualified consists only of a username and password. Future
certificate implementations will rely on advanced and qualified
certificates for higher levels of security as required by the
application (not yet implemented).
The Authentication / Both PKI Overheid (a hierarchy of accredited CSPs, using soft
Netherlands certificates) and DigiD (actually an authentication system;
Qualified certificate
requires a Social Security Number) are in common use; an eID
card by the name of eNIK is planned. Commercial CA
certificates (from accredited CSPs) are allowed for some
applications and available to foreigners.
Poland Advanced Advanced and qualified certificates are issued by accredited
signature CSPs, either as soft certificates or on a smart card. A
requirement for qualified certificates is most common in e-
government applications, although many applications require
their own solutions.
Portugal Advanced/qualified Present status is still fragmented. Advanced and qualified
signatures / certificates are issued by commercial CSPs, either as soft
Authentication certificates or on a smart card; authentication functionality is
used as well. An e-Card with a qualified signature certificate is
planned and will likely become the dominant technology in the
future, but it has not yet been deployed.
Romania Qualified certificate Soft certificate from accredited CSPs.
Slovakia Advanced and Qualified certificate from accredited CSPs stored on SSCD or
qualified signatures soft certificates, often stored on smartcards. An eID card is
planned
Slovenia Qualified certificate No uniform policy yet, but most applications rely on qualified
software certificates from accredited CSPs. Smart cards will
be deployed to the public in 2007-2008 (public sector officials
already use smart cards).
Spain Qualified signature The mandatory eID card (DNI) contains qualified certificates
for authentication and e-signatures. While deployment has
begun only recently, it will likely become the dominant
technology in the future. Soft certificates from accredited
CSPs are also in common use; they can be stored on a smart
card.
30
November 2007

requirements
Sweden Qualified signature Swedish eIDs (either soft certificates or smart cards) can
(see comment) contain certificates for authentication and e-signature
purposes, and contain the Swedish personal identity number.
These eIDs are issued by several recognised private sector
institutions (typically banks). It is noteworthy that the issuing
banks do not declare their certificates to be qualified, but that
they are in practice accorded a trust level which seems
comparable.
Turkey Qualified certificate The general legal framework is currently considered to be
unclear, stressing only the use of qualified certificates as a
prerequisite for equivalence to handwritten signatures. No e-
government applications using e-signatures were identified.
United Kingdom Authentication / No rigid distinction between authentication and signature.
Access through the Government Gateway Portal (either
Simple certificate
userID/password or certificate based, depending on the
application) permits signature functionality. CAs must be
accredited, but advanced/qualified certificates are generally
not a formal criterion.
4.1.3.1.2 Typical and atypical examples
In this section, we will look at a few Member States in detail if their approach is in some way
remarkable or illustrative of a given trend (e.g. The Netherlands’ use of authentication; the Estonian
generic eID based approach; the influence of historical legal traditions in Germany and Denmark;
etc.). The main purpose of this section is to describe a few typical legal solution models, which need
to be taken into account for further analysis and recommendations.
4.1.3.1.2.1 The Danish and German examples – the influence of legal traditions
Both the Danish and the German profiles are interesting examples of the influence of legal traditions
and socio-cultural sensitivities on the choices made when implementing a regulatory e-signatures
framework.
31
November 2007
The first example is the Danish solution model:
Example: the Danish approach
“The definitions of advanced and “qualified” electronic signature under Danish law are very close to
the definitions of the European Directive. Advanced and “qualified” electronic signatures cannot be
issued to legal persons under Danish law.
[…]
The practical effect of the Danish eSignature Act has been disappointing as no “qualified” electronic
signatures are being offered by certification providers in Denmark. One of the main obstacles has
been the requirement for signature holders to meet up and identify themselves in person. Realising
that few people would do this the Government initiated the establishing of above mentioned OCES
signature.
The OCES signature is a “light version” of the qualified electronic signature with the important
difference that the holder of an OCES signature does not have to perform fact to face identification.
The OCES signature is widely supported by public authorities in their eGovernment solutions and is
explained in details below.
The OCES signature is not covered by the Danish eSignature Act as the OCES signature is not
based on a qualified certificate. Neither is the OCES signature covered by any other general
eSignature legislation (the eSignature Act focusing on “qualified” electronic signatures is the only
general eSignature legislation under Danish law).”
The Danish legal situation is to a large extent a result of its traditionally more flexible approach to
electronic documents in civil and commercial relations. The presence of a signature was for most
document types not a requirement for the admissibility of the document in legal proceedings under
Danish law. It is telling from that perspective that the Danish eSignature Act does not contain a
transposition of art. 5.2 of the Directive with regard to the non-discrimination of e-Signatures. Rather,
the Danish eSignature Act focused more on the validity requirement of qualified signatures of art. 5.2
of the Directive.
The fact that the Danish government was able to make the pragmatic choice for an advanced
signature that did not require in-person identification is to a large extent a consequence of this
tradition of legal flexibility. As a result, the main e-signature solution in Denmark is an advanced
software certificate, a significantly lower barrier than in other countries.
The German example is radically different, again partially due to its legal tradition, which is
substantially more formal in Germany than in Denmark. The German Civil Code makes a distinction
between several categories of formal documents, including the mandatory written form (sec. 126
BGB), the agreed written form (sec. 127 BGB), the notarisation (sec. 128 BGB) and finally the
certification by a notary public (sec. 129 BGB), none of which traditionally could be signed in an
electronic form. Following the eCommerce directive and the eSignature directive (directive
1999/93/EC), the German legislator introduced two new document categories, the so called Textform
(sec. 126b BGB) and the electronic form (126b BGB), the latter of which was capable of replacing a
substantial number of traditional paper document types, but also required a qualified signature. Thus,
the qualified signature was the de facto standard for valid e-signatures under German law.
It is thus not surprising that this also became the standard for e-signatures in e-government
applications:
32
November 2007
Example: the German approach
“As regards the topic of electronic signatures in eGovernment applications, it is worth noting that
when electronic signature procedures are used or offered, only qualified signatures are used. This
applies for the federal Government, states and municipalities and can be traced to the German legal
system (so-called written form requirement).”
While choosing drastically different approaches, both the Danish and the German situations are thus
good examples of the influence of legal traditions on the present e-government framework.
4.1.3.1.2.2 The Estonian example – generic e-signature functionality through a mandatory eID
card solution
The Estonian system is equally interesting, because it was designed based on the requirement that
the solution offered should allow Estonian citizens to use electronic signatures in an easily accessible
and harmonious way, without having to consider differences between systems. To do so, it relies on a
tandem consisting of the mandatory eID card (which includes two qualified certificates: one for
signature functionality, and one for authentication purposes) and of a common digital signature
system, revolving around the common set of libraries, tools and applications known as DigiDoc.
Example: the Estonian approach
“In order to bring digital signatures into everyday life, common understanding and signature handling
practices are required. In addition, software and technology must be available for anyone interested, in
order to create compatible applications. After all, the key to unleashing potential digital signature benefits
lies in communication between organizations, not within one organization. Therefore, it is vital that all
organizations in a given community interpret and understand digital signatures the same way. In case of
Estonia, the community is the whole country.
A number of digital signature implementations and applications are available on the market, all claiming to
be suitable for specific purposes. However, no known application or implementation of the latest
standards was found which would suit the needs of the Estonian project, and reliance on foreign software
providers guaranteeing the functioning of a country's everyday life relying on digital signatures can also be
seen as a strategic risk. Therefore, a whole new approach – and a whole new software architecture –
was needed.
In 2002, SK together with its partners created an all-around digital signature architecture called DigiDoc.
As the name suggests, DigiDoc aims to meet all the needs users might have about digital signature
creation, handling and verification.
[…]
The DigiDoc library provides easy-to-use interfaces to all of the above and there is no need for application
developers to know OCSP protocol specifics or DigiDoc (XAdES, XML-DSIG) format internals. It can be
embedded in any application and on top of it, a COM interface has been implemented, making it easy to
add DigiDoc support to any Windows application supporting COM technology. A Java implementation and
webservice is also provided. DigiDoc architecture is presented in the figure below.
33
November 2007
However, providing the libraries, web service and formats was not enough because these do not add
value to end users without real applications. Although DigiDoc support is present in most Estonian
document management systems, some web sites dealing with documents etc, a couple of “standard”
end-user applications are also provided. DigiDoc Client is a Windows application that lets users simply
sign, verify and encrypt documents, and DigiDoc portal is an application that lets users do the same online
without the need to install any stand-alone software. Naturally, both are based on the same DigiDoc
library and thus fully compatible – signatures given in Client can be verified in portal and vice versa.”
This approach is particularly interesting because of the consistent distinction being made between the
e-signature components itself (the eID card, DigiDoc and the surrounding infrastructure) and the
applications making use of the signed documents. As a result, interoperability requirements become
easier to map than with solutions where specific applications have a larger impact on how signatures
are generated and/or processed.
4.1.3.1.2.3 The Dutch example – authentication as an interim solution
As discussed extensively above, there are a number of Member States which presently rely mostly on
authentication mechanisms as a sufficient proxy for e-signature functionality in public sector
applications. The Netherlands, which currently relies largely on the DigiD system, is one example of
this approach.
34
November 2007
The Dutch example:
“DigiD stands for Digital Identity and is a system shared between cooperating governmental agencies,
allowing to digitally authenticate the identity of a person who applies for a transaction service via internet.
With increasing numbers of public authority offices implementing the DigiD system, it is easy to begin
using their range of electronic services after first choosing your own login code (user’s name and
password) at www.DigiD.nl. In short: DigiD provides users with a personalised login code for the full
spectrum of contact with various governmental bodies. Anyone with a Social Fiscal number (SOFI-
number) can apply for a DigiD.”
However, while the DigiD system is an authentication system relying only on a username/password,
this solution will be complemented in the future by an eID card know as eNIK. Similar to comparable
solutions such as the Belgian, Estonian, Finnish, Italian and Spanish ones, eNIK would contain
distinct certificates for authentication and e-signature functionality. While it is presently not yet known
which applications would require eNIK in the future and which would continue to support DigiD, it is
likely that at least some applications will require the use of actual signatures in the future.
4.1.3.1.2.4 The Finnish approach – public/private sector collaboration
The Finnish situation is interesting because it offers two very distinct solutions: either a FINEID
signature (based on a qualified certificate on a smart card), or the bank controlled Tupas
authentication system.
Example: the Finnish approach
“Three different types of electronic signatures are predominantly used in eGovernment applications:
1. Signature applications based on the FINEID electronic identity card, which contains a qualified
certificate;
2. Signature applications based on the FINEID certificate card for organisation use (”organisation CA
certificates”) which contains a qualified certificate; and
3. TUPAS bank identification system.
The FINEID certificates are qualified signature certificates as specified in the relevant European Directive
and in the Finnish Act that implements the directive. For eGovernment applications the proportion of
qualified vs. Advanced certificates that are used for signing is not measurable since only FINEID and
Tupas based signature methods are offered in the services.
The Tupas system does not provide for qualified nor advanced signatures since it is a two-factor
password authentication method. Advanced certificates are not used in eGovernment services, even
though some are available (e.g. commercial SoneraCA certificates). The reasons for this are multiple and
they are described in more detail in section 6 of the report.”
35
November 2007
It is interesting to note that, despite to the division in functionality (with FINEID offering both signature
and authentication functionality, and TUPAS only offering authentication), both solutions are
commonly supported, without any clear system of preference.
4.1.3.1.2.5 The Bulgarian approach – higher regulatory threshold
While the Bulgarian EDESA (Electronic Documents and Electronic Signatures Act) globally follows
the provisions of the Directive, it is interesting to note that the baseline signatures concept is in fact
the advanced electronic signature of the Directive:
“According to Art. 13, Para. 1 of EDESA electronic signature is a data attached to the electronic
17
message (data message) in a way agreed between the author (the signatory) and the addressee
and enough secure for the needs of the turnover which:
• reveals the identity of the author (the signatory);
• reveals the consent of the author (the signatory) with the signed electronic message; and
• protects the content of the electronic message against any further changes.
The meaning of electronic signature under the Bulgarian EDESA is similar to the meaning of
advanced electronic signature under the Directive.”
Similarly, the Bulgarian advanced signature is in fact what the Directive labelled as a qualified
signature:
“The advanced electronic signature under EDESA could be equalled to the “qualified” electronic
signature under the meaning of art.5, para.1 of the eSignatures Directive.”
Finally, the signature type endorsed most frequently by the Bulgarian government (the so called
universal electronic signature) is an advanced signature relying on a qualified certificate. Thus, the
bar in Bulgaria is set relatively high, falling just short of a qualified signature (due to the lack of a
SSCD requirement).
In fact, the Austrian legislator took a similar approach, by retaining the qualified signature as the
fundamental notion (under the name of “secure electronic signature”):
17
The author is the natural person who makes the electronic statement – on his own behalf or on
behalf of a legal entity or another person as a proxy.
36
November 2007
Austrian legislation did not explicitly introduce the concept of advanced electronic signatures.
“Qualified” electronic signatures are however literally taken from the Directive by taking and
combining the definitions of advanced electronic signatures and the provisions of article 5 of the
Directive into a single definition. Qualified electronic signatures are referred to as “secure electronic
signatures” under Austrian legislation.
4.1.3.2 Choice of Unique identifiers
Certificate based systems incorporate a unique identifier in the signature certificate, which is often
derived from national registers, such as the national registry numbers for Belgium or Bulgaria (Unique
Citizen Number), the personal identification number based on the central personal number in
Denmark, or the tax number for Slovenia.
This presents a dual difficulty. First of all, this implies that such certificates cannot be issued to non-
nationals if such non-nationals cannot be entered into the national registers without a permanent
establishment, essentially barring them from using this specific e-signature solution (which is e.g. the
case in Belgium, Bulgaria, Denmark, Finland and Slovakia).
Example: the Danish approach:
“At the moment only persons with a Danish [Central Personal Register]-number can have an OCES-
personal digital signature. The reason being that the registration and identification process is based
on a CPR-register. For the same reason only companies registered in the Danish central business
register can have an OCES employee- and/or company certificate.”
Furthermore, such unique identifiers may be under specific legal protection rules barring them from
being used or access without prior authorization (which is e.g. the case under Belgian and Danish
law). Thus, from a legal-technical perspective the use (including validation) of such signatures
requires the relying party (even if this is a public authority) to obtain prior clearance from a mandated
instance (e.g. a sector committee within the national Privacy Commission in the Belgian example).
37
November 2007
“The national registry number was originally intended to be used for public sector applications only.
As a result, only a limited number of institutions are allowed to use the national registry number in
their internal processes.
With regard to the use of electronic signatures in eGovernment applications, the national register
number is particularly relevant because it is used as the unique identifier in the certificate of the e -ID
card (but not in commercial ca certificates). Furthermore, the national register number is also
envisaged to become the identifier to be used in the future for all back-office information exchanges
in eGovernment applications regarding all persons who hold such a number.
Providers of e-ID applications are only allowed to use the national register number in certain cases
upon authorisation from a sector committee, which is a subdivision of the national privacy
commission. Only certain categories of authorities and instances qualify for this permission.”
A similar situation exists for the Danish OCES, where the signature certificate contains a non-
protected personal identification number (PID), which however can only be issued to a person having
a central personal register number (CPR). While CA services exist that can be used to map a PID to
the corresponding CPR, such services may only be used after mandate by law or after obtaining the
holder’s permission. Permission for private parties to process the personal identification number must
generally be granted by law.
“Note that the serial number field for personal certificates contains a person specific identification
number (PID), which uniquely refers to a person’s central personal identification number. Conversion
can be achieved through a CA service, which maps the PID and CPR numbers and which is
accessible only to authorities who by law are entitled to use the CPR or by explicit consent given by
the certificate holder.
[…]
For company certificates the serial number field contains the company’s business registration
number, which can be concatenated with different qualifiers, denominating different departments in
the company. These numbers can be used by applications to uniquely identify a given company or
department of a company.
[…]
The [Act on the Civil Registration System] states that all Danish citizens are provided with a personal
identification number. The personal identification number may be handed over to public authorities in
compliance with the Danish Act on processing of personal data. Private parties are in general not
entitled to request personal identification numbers from the CPR-register. Public authorities who are
in possession of personal identification numbers are not entitled to make the personal identification
numbers public available.”
38
November 2007
The combination of these two factors constitutes an additional legal barrier to cross-border use of e-
signature solutions, since foreign national bodies would not be allowed to access such unique
identifiers either without prior authorisation. It is of course prohibitively difficult for each foreign relying
party to obtain such clearances.
For this reason, alternative solutions exist in many countries. Referring back to the Belgian model, the
unique identifier is only included in the national eID card signature certificate, but not in the software
certificates provided by private sector CSPs (who do not have automatic clearance to include such
identifiers in their certificates). Thus, no clearance is required for the use of these certificates, and
they can be issued to non-nationals.
“It should be noted that the three recognised certification authorities can also offer their certificates
to foreign entities, and that no generic standards have been put in place to accept certificates issued
by other entities. From an interoperability perspective, this means that any user of an application
requiring commercial ca certificates is limited to these providers; no other certification service
providers qualify.”
Additionally, certain countries choose to issue separate eID cards (without protected unique
identifiers) to non-nationals, or are looking at encrypting/hashing the protected identifier into a
separate number, equally unique but unlinkable to the original. Both solutions thus present a technical
solution (or at least a workaround) to the legal problem of protected identifiers. To some extent this
approach is followed in Slovenia, where the tax number need not be directly included in the
certificate, but can merely be referred to through a separate CSP-specific unique identifier:
“Certification Authorities in Slovenia use different approaches in mapping single certificate with its
holder’s identification data (i.e. tax number) but all of them manage some connection between the
user and his certificate. Some Certification Authorities simply add the tax ID number in certificates,
while others add a unique certificate identification (serial number) to a certificate and keep all the
data in a stand-alone database. Personal data in this database can only be used under conditions
regulated in the Personal Data Protection Act.”
Similarly, the Finnish FINEID uses a so-called FINUID, which is available to non-nationals. However,
the FINUID is derived from the social security number, so that only non-nationals with a permanent
establishment in Finland would qualify:
Example: the Finnish approach
“FINEID eSignature applications are available for all Finnish nationals and foreign permanent residents.
39
November 2007
All permanent residents, regardless of citizenship are able to receive a FINEID card with citizen certificate
and to use all available eGovernment services making use of it. The only limitation of the permanent
resident FINEID is in the physical card, which in this case does not constitute an ICAO travel document.
All permanent residents are covered by National Social Security, which provides for the SSN, which in
turn is automatically transformed into a FINUID that will be activated when a FINEID is issued. Asylum
seekers, tourists or other non permanent foreign residents are not allowed to receive a FINEID card or
citizen certificate.
[…]
The FINUID is a serial number (unique identification number) and a check sign identifying Finnish citizens
and foreign citizens residing permanently in Finland in accordance with the Municipality of Residence Act
who have been entered in the Population Information System.
The FINUID is included in the FINEID citizen certificate in two areas: as part of the certificate holder’s
Distinguished Name (DN) and as Serial Number (SN). The legal framework for the use of the Finnish
unique identification number is laid down in The Personal Data File Act (523/1999).
The origin of the FINUID is tied to the privacy concerns related to the use of the Social Security Number
(SSN). The legislation sought the use of the SSN in publicly accessible directory services – a serious
privacy concern that should be avoided. The public FINUID contained in the FINEID is of no use outside
the FINEID framework, thus making void any privacy concerns.
The FINUID provides the citizen with a code that serves as reference to the population registry system
containing information on the user. The PRC owns, creates and controls the FINUID, but other
organisations may use it for user identification purposes.”
It should be noted though that such solutions have of course not (yet) been implemented globally,
including e.g. in Bulgaria.
A more advanced approach was taken in Austria, where each entity is identified through an identity
link, which refers to data in official registers, including a separate register for non-nationals:
“The SourcePIN Register Regulation defines the activities of the SourcePIN Register Authority that
are necessary to implement the citizen card concept and the cooperation with its service providers.
This includes the creation of an identity link which is a separate data structure on the citizen card to
establish a link between an electronic signature and the unique identity of the citizen derived from
central registers (for natural persons the Central Register of Residents and a Supplementary
Register for Natural Persons). An identity management system allowing for integrating alien eIDs
has been defined using so-called recurring identities.
[…]
For natural persons not registered in Austria (e.g., expatriates, cross-border commuters, foreigners),
a Supplementary Register for Natural Persons is defined in the Supplementary Register Regulation.
Unique identification is maintained when a person’s data is moved between the Central Register of
Residents and the Supplementary Register for Natural Persons (e.g., being enrolled in the
Supplementary Register and then taking residence in Austria).
[…]
Identification of legal persons is carried out via the Register of Company Names, the Central
Register of Associations, or the Supplementary Register of Other Concerned Parties. The identifier
of these registers is used as sourcePIN – the encryption step carried by the SourcePIN Register
40
November 2007
Authority for natural persons is not done for legal persons.”
Thus, a model was created that permits a resolution of the problem of unique identifiers while
permitting cross border functionality (provided of course that an entity is willing and able to enter its
information in an Austrian official register).
Yet, even in cases where an unprotected unique identifier originating from a private sector CSP are
used as an identification method, issues can arise:
“Qualified and unqualified certification authorities issue electronic identifiers to individual persons (they are
not the same as eIDs mentioned in 4.2.1, and issued by appropriate public administration organs). Usually
these identifiers are Integrated Circuit Cards with cryptocontroller and private cryptographic keys and
public key certificates installed inside (obligatory solution used by qualified CAs) or software based tokens
(cryptographic keys and certificates stored outside ICC’s cryptographic modules).
[…]
Let us notice that commercial electronic IDs do not allow unambiguous assignment of a unique identifier to
the person – every CA has its own policy for electronic ID configuration. It is the main reason why they
cannot be used as national electronic IDs.”
4.1.3.3 Technological choices
It is interesting to note that regulations focus exclusively on the qualities to be exhibited by the
signature technology, but not on the medium itself. For example, the Belgian solution primarily
focuses on the national eID cards and on private sector certificates, but makes no statement for the
latter on the medium to be used. Thus, it is possible to obtain software certificates (to be installed in a
browser or kept separately, e.g. on a memory stick) or to receive a smart card containing this
certificate.
For instance, the Danish OCES is available in software certificate form, or on a smart card; and the
aforementioned Austrian solution is characterised as a “concept”, since there is no restriction to the
medium being used as a token (if indeed any material token is used at all).
4.1.3.4 Cross border acceptance
While this issue will be more extensively dealt with in the section 5 of this report, a few summary
observations can already be made at this stage.
It is worth reiterating that the use of unique identifiers which are specific to one country (e.g. national
register numbers) and which may be subject to specific prior authorisations before use can have a
detrimental effect on cross-border interoperability of e-signatures, as explained above.
41
November 2007
One of the main conclusions of the initial analysis is that there is insufficient openness of
administrations towards non-national solutions which in combination make cross-border
interoperability extremely difficult.
Notably, there is a distinct tendency towards relying only on national solutions, either:
• by relying on the aforementioned national register numbers as unique identifiers for

certificates (which essentially precludes any non-national entity from using the e-signature
application unless they are willing to take the disproportional step of establishing themselves
in the service’s country of origin); or
• by using national register numbers as an initial identifier necessary in the application
procedure for a certificate “recognized” by the public administration (foreigners without such
national identifier are automatically excluded from the application procedure); or
• by allowing only a limited group of recognised (i.e. accepted from a purely practical
perspective) or accredited (i.e. having successfully completed a formal voluntary
accreditation process as defined in the eSignatures Directive article 2.13) CSPs to offer valid
certificates. It should be noted that no surveyed country requires a CSP to be established
within its borders before it can be deemed acceptable; thus, on the surface this would not
appear to be an encumbrance to cross-border interoperability. However, in practice not a
single country has identified a foreign CSP who has received the required accreditation or
recognition18. This is not so much a result of an unwillingness to accredit such CSPs, but
rather for an insufficient business case to CSPs to justify requesting the accreditation or
recognition.
The result however is that validation of non-national certificates is not functional in practice, meaning
that national PKI hierarchies remain largely isolated by country.
4.1.4 National trends and expectations
A summary of trends and expectations can be provided at this stage.
4.1.4.1 State of eSignatures
As a first observation, it is clear that national regulatory frameworks tend to maintain their
technological neutrality with regard to e-signature means. While the use of smart cards is clearly
gaining in prevalence (possibly due to the greater security potential and the resulting ease with which
a qualified signature could be generated), this evolution is not made explicit in national e-signature
regulations. In fact, as is most emphatically witnessed in the Austrian example, there is a clear and
increasing awareness of the importance of technological neutrality.
“The citizen card is a technology neutral concept that allows for a variety of implementations. A
number of token exists allowing the citizen the choice which token (or tokens) to activate as citizen
card. The major ones are the health insurance cards, each bank card, or each mobile phone.
18
Although the line can be difficult to draw when a CSP is a local branch of a foreign undertaking.
E.g., in the Netherlands, one of the accredited CSPs is ESG De Electronische Signatuur B.V.,
affiliated to the German ESG Elektronische Signatur GmbH.
42
November 2007
Integration of the various technologies is done via an open interface referred to as “Security Layer”.
Implementations as software for the citizen’s PC are available from two vendors for free. In case of
mobile phones as citizen card the interface provided on the Internet with no installation needed at
the PC, respectively.”
Rather, it would appear that the increasing attention to smart cards is primarily attributable to policy
changes with regard to national security. As the introduction of eID cards is contemplated, the
integration of e-signature capabilities is a logical extension of this strategy, which offers an added
value that can ease the acceptability of eID cards in countries where they are traditionally considered
controversial.
None the less, from a legal perspective, e-government regulations tend to specify high level
requirements without referring to the material carrier of the e-signature, which has the dual
consequence of increasing both technical flexibility (as specific technologies are not commonly
mandated) and interoperability complexities (as actual implementations may vary even within a given
country).
It is equally interesting to note that authentication mechanisms are used in many countries as a viable
alternative to actual e-signatures, since the required functionality can often be emulated in a sufficient
manner by such mechanisms. In certain countries, including the Netherlands, the UK and Malta,
authentication mechanisms are currently the dominant solution for signature issues, and in most other
countries authentication takes at least the role of a second tier solution.
4.1.4.2 Interoperability requirements
While exceptions exist, it is noteworthy that most of the reports indicate that their national solution
frameworks have not been designed with cross-border interoperability in mind, and that no real
changes in this attitude are planned in the short term. In fact, national reports indicate that the notion
of interoperability has received some attention in the surveyed countries, but mostly in the context of
national harmonisation. In many countries, multiple e-signature solutions have been developed in
parallel and without internal coordination. In order to simplify this situation, internal harmonisation
initiatives are still underway in most countries in some form or other, such as the Belgian migration
towards the eID card as a general solution, the German trend towards a national eID framework, and
various central portal solutions, including in the UK and in Bulgaria.
“The available eGovernment applications (the information systems employed in the government
bodies) are not interoperable and are usually developed without an idea for being able to exchange
information with other applications.”
Furthermore, the common perception is that the business case for cross-border interoperability has
not been established, which is likely the main reason why it was not one of the design criteria from the
onset. None the less, there is an increasing awareness of the importance of cross-border functionality.
43
November 2007
“The OCES signature does not provide cross border functionality in its current form. In general this
applies to the eGovernment applications as such. The reason for this is probably a limited request
for such functionality for the time being combined with the fact that many of the applications are
providing services only relevant to Danish citizens (tax, health care and the like). More and more
demands coming from the implementation of different cross border solutions will increase the need
to address this challenge in the future.”
Given the scepticism with regard to the business case, it seems likely that external initiatives (e.g. in
the form of European intervention) may be required if any progress is to be made in the shorter term.
4.1.4.3 Long term validity and storage
One recurring pattern in many national reports was the fact that long term validity of e-signatures and
the storage of signed documents / certificates has not received a great deal of governmental
attention, either from a regulatory or from a technical / organisational perspective. Regulatory
intervention is typically limited to the repetition of the provisions of the Directive insofar as they relate
to long term storage19, with a reference to the applicability of the CSPs Certification Practice
Statements for further details. Thus, direct legislative intervention is this regard is very limited,
although generic (not e-government specific) exceptions exist:
“Slovenia recently adopted new law on the electronic records with full legal effects, registration and
accreditation of equipment and service providers:
• Protection of Documents and Archives and Archival Institutions Act (Official Gazette of the
RS, No. 30/2006),
• Regulation on documentary and archival material custody (Official Gazette of the RS, No.
86/2006).
This regulation governs the activities and internal rules of persons keeping documents and/or
archives, storage of such materials in physical and digital form, general conditions, registration and
accreditation of digital storage equipment and services, selection and transfer of archives to public
archival institutions, processing and keeping registers of archives, protection of film and private
archives, use of archives in archival institutions and work of the Archival Commission.
With regards to the electronic signature it is obligatory to capture or generate all necessary meta-
data about the certificates related to the electronic signature or time stamp, additional data
confirming the same authenticity of captured materials in comparison with the original materials, date
of creation, data on capture procedure, data on hardware and software, in which a document unit
was created, etc. The regulation sates that in case authenticity and integrity of captured materials
19
E.g. in Annex II to the Directive, stating that all relevant information concerning a qualified
certificate must be stored “for an appropriate period of time, in particular for the purpose of providing
evidence of certification for the purposes of legal proceedings. Such recording may be done
electronically.”
44
November 2007
proved with contents, which are losing or have completely lost their value or have been annulated
with time (e.g. electronic signature, time stamp and similar), authenticity of captured materials in a
long-term digital preservation form shall be provided with strictly controlled addition of contents (e.g.
reliably added meta-data, re-signing of contents or a new time stamp), confirming authenticity of
captured materials. Such contents can be added on the level of individual units, group of units or
entire captured material.”
A few countries (e.g. Estonia) had more explicit provisions, although this was the exception rather
than the rule:
Example: the Estonian approach:
“SK runs secure logging system which logs all changes in certificate status (activation, suspension,
termination of suspension and revocation) and all validity confirmations given by OCSP responder. In
case logging procedure fails, then given transaction will not be completed. This princip le ensures
existence of log record in the system.
Log records are cryptographically linked to prevent insider attacks and forging log records (for
example backdating the log record). Once a month, cryptographic hash is printed in newspaper. Log
record database is backed up in timely basis with three copies stored in different locations.
This kind of secure log system provides for dual purposes:

• auditability – in case of disputes there are means to prove that some validity confirmation
was (not) issued, was issued before/after some other event, etc.
• long term validity preservation of digital signatures – even after complete breakdown of all
keys and RSA algorithm one can prove that document signed at past is valid – by matching
confirmation data with log data.
Secure log is completely invisible to end-users with one exception – every ID-card holder can check
their personal records (certificate history and issued validity confirmations).”
While the surveyed countries do not appear to consider long term validity and storage of signed
electronic documents to be a key priority at this time, it is none the less important to highlight a
number of important issues.
First of all, apart from the legal issues, it is clear that the readability of electronic documents (both by
implementing sufficient security and back-up policies and by opting for file formats that guarantee
45
November 2007
long term accessibility) in general should be a policy priority in all eGovernment decisions. Situations
such as vendor lock-in or obsolescence of ageing equipment or file formats are irreconcilable with the
requirements incumbent on governments as a part of their good administrative governance
obligations. However, as such, this issue is not related to electronic signatures, and therefore falls
outside the scope of this study.
Specifically with regard to electronic signatures, it is important to note that the eSignatures Directive
does not contain any specific requirements with regard to the obligation of CSPs to retain signature
related data for any specific amount of time. Indeed, the issue is only tangentially referred to in Annex
II of the Directive:
“ANNEX II – Requirements for certification-service-providers issuing qualified certificates
Certification-service-providers must:
[..]
(i) record all relevant information concerning a qualified certificate for an appropriate period of
time, in particular for the purpose of providing evidence of certification for the purposes
of legal proceedings. Such recording may be done electronically;
[..]”
Thus, the Directive only prescribes a general obligation on the issuers of qualified certificates to
record all relevant information ‘for an appropriate amount of time’. This presents a number of clear
difficulties.
• First of all, the Directive does not specify which information exactly is ‘relevant’ to ensure the
long term validity of electronic signatures, and leaves it up to the CSPs (or Member States, if
they desire) to regulate this issue further.
• Secondly, the Directive only requires this information to be stored ‘for an appropriate amount
of time’; a notion which is to be interpreted keeping into account the possible need to rely on
electronically signed documents in legal proceedings. This offers little tangible help to CSPs,
as the validity of a document and the period during which it may be relevant in legal
proceedings can span almost all possibilities, from several days to several decades (e.g. for
contracts of an unlimited duration).
From an eGovernment perspective this can be particularly problematic, as administrative
regulations can often be extremely complex in this regard, and ostensibly similar types of
documents may be subject to vastly different rules with regard to the duration of their validity
and the period in time during which they may be disputed or relied upon in administrative or
civil proceedings. In short, even for CSPs issuing qualified certificates it is virtually impossible
to foresee precisely how much time is reasonable to ensure long term validity of a signature.
• This problem is exacerbated in a cross border context. For instance, in a specific Member
State a limited validity of e.g. five years may be sufficient for a specific document type (e.g.
an attestation of compliance with direct tax obligations), However, it is possible that an entity
is called upon after this period (e.g. after 7 years) to present such a document before a
different administration which has instated a longer validity period (e.g. 10 years), and as a
result, it will no longer be possible to validate the signature on the original document. This
need not be a problem in the case of easily replaceable document (e.g. one might imagine in
the present example that a tax administration might still be able to attest to an entity’s
compliance with tax regulations 7 years ago through a new attestation). However, this will not
always be the case. Sometimes, the requested information may no longer be available, and
no new electronic document can be created anymore.
From a practical perspective, this scenario is unlikely, as is demonstrated by the lack of
concern seen in the country profiles. None the less, the increasing uptake of electronic
signatures ensures that this problem will manifest itself in the future. It is therefore important
46
November 2007
that both signatories and recipients should be able to verify easily for how long any given
signature will remain verifiable. A simple referral to whatever CPS has been adopted by the
chosen CSP may not prove to be a sufficient answer, particularly in a cross border context,
where the required information may simply be linguistically inaccessible.
• Furthermore, the guidelines provided in the eSignatures Directive are only applicable to
CSPs issuing qualified certificates. For non-qualified signature certificates or non-PKI
signature solutions, no guidelines with regard to long term validity exist, so that signatories
and relying parties are entirely dependent on the local applicable legal framework. The same
goes for solutions which rely entirely on an authentication mechanism rather than on a
signature solution covered by the directive: in this case, the legal framework with regard to
legal signatures does not apply, and it is unlikely that a specific legal framework has been
created that is specifically targeted towards the long term validity of electronic documents
submitted through a secured electronic communications channel after a suitable
authentication procedure. In such cases, the parties will likely be entirely dependent on
applicable doctrine and jurisprudence, which will offer little to no legal certainty.
However, it is also important not to overstate these issues. As noted above, the matter of long term
storage and validity receives relatively little attention in practice, which is indicative of the fact that for
most applications this is not a major issue. For instance, in eProcurement procedures the validity of
an offer is only relevant until the expiration of the period in which a granted contract can be disputed;
after this period, only the final contract itself is legally relevant. While such periods obviously vary
from country to country, it is doubtful that they extend over a period of several years, given the need
for public service continuity and legal certainty when performing public sector contracts. Similarly,
income tax declarations are only relevant until a final tax has been established based on the contents
of the declaration and the period of contestation has expired, which is again unlikely to span several
years. Finally, for official certificates (e.g. birth certificates) and attestations (e.g. attestation of
domicile) it is often possible (and even required) to present current documents only, so that long term
validity is much less of an issue.
In summary, the country reports show that, at least with regard to electronic documents being used in
eGovernment applications, the surveyed countries take a very pragmatic approach, looking at the
needs of the application rather than at any abstract principles. None the less, it is important to be
aware that long term storage and validity will become an issue before long, and that no readily
available solution for the issues mentioned above seems to exist.
4.2 eGovernment applications using electronic signatures
4.2.1 Application approach models
The analysis of various eGovernment applications (approximately 130) described in the Country
Profiles has allowed for establishing a grouping of those applications based on similarities shared by
them.
Two main groups of applications have been identified:
• on one side, applications that have a shared-service approach, meaning that they are making
use of a common framework or of a common infrastructure;
• on the other side, applications that have an ad-hoc approach, meaning that they are built up
from scratch implementing e.g. their own signature functions or even their own certification
authority.
Obviously, there are applications that are more difficult to class because they refer to several models.
The next sections will describe the models with full details.
47
November 2007
4.2.1.1 Group 1: shared service approach
The first group concerns countries that have set-up a shared approach in the design of their
applications either by providing a one-stop shop infrastructure (Model 1) or by providing a common
framework for the use of eSignatures (Model 2).
There are several commonalities observed that are applicable to both models of this group.
Technical aspects:
eSignature type: None of the two models impose a specific eSignature type. The
eSignatures used can be either of type Simple, Advanced or Qualified.
Credential or token type: Applications of this first group (shared approach) do not impose
any type of token or credential because they are by design opened to support the largest
possible range of token/credential. These can be smart-card (eID card …) – USB Token –
virtual smart-card (the signature creation data is held within a central location (e.g. central
hardware security modules)), software certificates, user/password, one-time passwords
(OTP). …
eSignature validation: one of the main advantages of this shared approach resides in the
validation of eSignatures being realised either by a central module of the portal (in case of
model 1) or by using common libraries provided by the framework (model 2). In both cases,
the goal is to hide the validation complexity to the application. Applications do not need to
know how much Certification Service Providers are involved, neither what type of validation
protocols (CRLs, OCSP …) is provided by the CSP
Organisational aspects:
CSPs: as said previously, while choosing a shared approach, one of the implicit results is that
many CSPs can be easily provided to the applications.
Interoperability aspects
As far as interoperability is concerned, applications designed around one of these two models
are obviously more easily adaptable to provide true eSignature interoperability at validation
level as this has only to be achieved in one central place (being the portal or within the
framework).
4.2.1.1.1 Model 1: One-stop shop model
The one-stop shop model is usually provided at country level but it happen that sometimes, this
approach is used at a sector level.
The one-stop shop model is designed to facilitate the efficient provision of on-line services in a cost-
effective manner. It enables government organisations to focus on the rapid delivery of on-line
services, rather than in building time and time again the common underlying components required for
on-line services
It enables citizens, businesses, intermediaries and even other government organisations to
communicate with the Government from a single point of entry.
48
November 2007
Browser Soap Appl
Portal ID Management
Citizen_________________Application
eSignature
Application Application Application CSP’s
Besides aspects described at group level, there are features that are specifically bound to this model.
Among them:
Technical aspects specific to this model:
Access methods: The main advantage of this model is to provide a unified access method
to the various eGovernment applications via web browser or web services (relying on
international de-facto standards such OASIS WS-Security20). Communications between the
portal and the final applications are XML-based.
National Interoperability Framework: one e-government Interoperability Framework defines
the technical policies and specifications governing information flows across government and
the public sector.
Authentication: One centralised authentication module at portal level providing several
authentication levels (e.g.: level 1: user/password, level 2: one-time passwords, level 3:
certificate based).
Example: the UK approach

By deciding upon the portal approach for access to eGovernment services, the UK has been able to
implement a wide, and growing, range of services to the public and to commercial organisations
without having to expend repeated effort in getting the identity management piece implemented.
By this means also, if (or when) the Government implements an eID card it will be relatively
straightforward to make use of it in providing access to all of the services that are available via the
Government Gateway.
Note: Countries having federated several eGovernment applications in one portal approach may also
have applications based on other model (due to specific security or functional requirements).
20
This is an OASIS (http://www.oasis-open.org/) Standard document produced by the Web Services
Security Technical Committee. It proposes a standard set of SOAP extensions that can be used when
building secure Web services to implement message content integrity and confidentiality.
49
November 2007
Technical trends
All applications belonging to this model have defined a common set of XML documents to be
exchanged. This set of documents is always a part of the specification of a common
framework.
All applications require that the electronic signature is applied to a XML document defined
into the framework.
No other technical trends can be deduced from the low number (3) of applications belonging
to this model.
4.2.1.1.2 Model 2: common eSignature framework model
Very often, eSignature frameworks have been introduced to allow for rapid deployment of
eGovernment applications by providing eSignature primitives such as certificate validation, card
access (CSP, PKCS#11) …
Such framework may results from national legal provisions or national initiatives to support a specific
eSociety policy (e.g. introduction of the eID card).
Besides the features described at the group level, there are features specific to this model:
Access method: Even if the major part of the applications related to this model has web-
based interfaces, there are usually no requirements imposed by the framework.
National Interoperability Framework: there is no national interoperability framework defined
or it has not yet been implemented.
Authentication: Although that authentication is application-specific, the framework provides
certificate-based authentication functions.
50
November 2007
Application Application Application
eSignature framework
CSP’s CSP’s CSP’s
Example: the Spanish approach

The launch of the electronic national identity card has been complemented by the creation of a
multiPKI Validation Platform supported by the MAP that provides freely eSignature and eCertificate
validation services to eGovernment services (currently there are about 180 available services using
the platform).
The multiPKI Validation Platform validates electronic certificates and eSignatures issued by the main
Certification Authorities of the country, among them, the eID Certification Authority, and also provides
time-stamping services and an eSignature program that allows citizens to eSign documents in various
eSignature standards locally before being submitted over the Internet. The service is offered to
eGovernment applications of all public administrations (state, regional and local). The platform has
been built up on open source and open standards.
Technical trends
The type of signature which detaches clearly of the general tendency is "qualified". This fact is not
astonishing because the applications which are classified in this model rely in general on a framework
which has been set up for a national electronic identity card which requires a signature type
"qualified". However the type of signature "advanced" is always quite present.
The figure below represents the signature type support by applications belonging to this model.
4 applications support Simple signature type – 8 applications support advanced signature type – 5
applications support qualified certificate - 16 applications support "qualified" signature type.
51
November 2007
Signature type
20
15
10
0
si mpl e adv anc ed Qual i f i ed cer t i f i cat e Qual i f i ed s i gnat ur e
Applications relying to this model have stated that they support multiple type of token but the most
supported one is the Smart card.
The figure below represents the token type support by applications belonging to this model.
Token type
30
25
20
15
10
5
us er / pas s s of t USB Smar t Car d V i r t ual Smar t

Car d
Applications sign or required that specific documents type are signed. Some of them support different
type of signed document but this not a general trend.
The figure below represents the trend for application belonging to this model (“files” means not PDF
and not XML file type).
52
November 2007
Signed document type
4,5
4
3,5
3
2,5
2
1,5
1
0,5
0
XML PDF Web-Form files ASCII
The figure below represents the usage of signing tool type used by applications belonging to this
model.
Signing tool
7
6
5
4
3
2
1
0
Adobe Acrobat Applet/ActiveX eMail client other tools
53
November 2007
Example of other signing tools:
Bulgaria “Online submission of annual income tax declarations” and “VAT on Internet”
applications:
Question: “What are the software requirements on the client side (e.g. OS/specific
driver/middleware) for the use of eSignature?”
Answer: “…For the purposes of signing in .p7s format of the files that are to be attached,
a particular software DSTOOL is used. This software is freely downloadable from the
website of NIA....”
Italy “Telemaco, Signed Electronic Filing for Business Entities –Balance Sheets”
application:
Answer: “A software to sign the electronic declaration according to the Italian laws.
“Dike” is the InfoCamere free software for the digital signature available for Windows,
Mac platforms and a Linux distribution….”
4.2.1.2 Group 2: ad-hoc approach
There are numerous applications described in the country profiles that do not make use of a central
architecture nor of a common framework, mainly for historical reasons. They have been classified
under this second ‘ad-hoc’ group. Within this group, one can however distinguish two different
models: stand-alone applications that can interact with various external CSPs or stand-alone
applications that have set-up their own CSP inside the application.
There are several commonalities observed that are applicable to both models of this group.
Technical aspects:
Access method: Even if the major part of the applications related to this group has web-
based interfaces, access methods are defined by the applications themselves.
National Interoperability Framework: Applications are not compliant to a National
Interoperability framework (when existing).
Authentication: Specific to the application: user/password, one-time password, certificate-
based authentication...
54
November 2007
4.2.1.2.1 Model 3: Generic CSPs model
Usually, this model is implemented for two main reasons:

• Either, for historical reasons: no national framework / model existed at application
development time;
• Or application specific security/ functional requirements (e.g. specific key size) could not be
met by national framework/model.
It must be noted that many of the applications developed following this model have planned to move
to a shared service approach in the future.
Application Application Application
CSP’s CSP’s

eSignature type: The eSignature type is imposed by the application: can be either of type
Simple, Advanced or Qualified.
eSignature validation: Every application validates eSignatures against CSPs they trust.
Credential or token type: The credential/token type can be smart-card (eID card …) – USB
Token – virtual smart-card (the signature creation data is held within a central location (e.g.
central hardware security modules)), software certificates, user/password, one-time
passwords (OTP). …
CSPs: Applications of this model may support one or several CSPs but addition of a new
CSP requires a modification of the application.
Applications of this model are not closed to interoperability but to achieving this
interoperability would require sound modifications of every application.
55
November 2007
Example: the Slovenian approach

To speed up the rate at which on-line public services are made available for citizen and companies
several steps have already been made. As stated in Slovenian eGovernment Strategy national
interoperability framework is needed to attain the planned development of eGovernment until 2010.
SEP-2010 defines interoperability framework as linking of all elements (standards and
recommendations, uniform architecture, open standards and solutions, guidelines) in a national
interoperability framework for eGovernment services and solutions, which will provide organisational,
semantic and technical interoperability (including e-signature) and at the same time creative co-
operation in the preparation of an interoperability framework for pan-European services.
With this in mind the development of national interoperability framework has just started along with the
broad program dedicated to the electronic connection and interchange of data between national
registers. The two programs will be developed in parallel since they are to share common results and
solutions.
Currently the applications in public administration that rely on e-signature use different modules for
administration applications has been taken.
Technical trends
1 application support Simple signature type – 17 applications support advanced signature type – 34
Signature type
40
35
30
25
20
15
10
5
0
si mpl e advanced Qual if i ed cer ti f icate Qual if i ed si gnatur e
56
November 2007
Applications relying to this model have stated that they support multiple type of token but the most
supported one is the Smart card.
Token type
50
40
30
20
10
0
user / pass sof t USB Smar t Car d Vir tual Smar t
Car d
type of signed document but this not a general trends.
14
12
10
8
6
4
2
0
model.
57
November 2007
Signing tool
25
20
15
10
0
Czech Republic “Publication system on public contracts – publication subsystem

(eNotification) » application:
Answer: “…On-line version works only on Internet Explorer 6.0 XML602 Filler woks only
on Windows....”
Hungary “Electronic Firm Registration/Electronic Company Register” application:
Answer: “…They use ‘e-Szignó’, a professional signature creation application capable of

creating ETSI TS 101 903 compliant XML signatures.....”
58
November 2007
4.2.1.2.2 Model 4: Application Specific CSP model
Like the previous model, this one is also implemented for two main reasons:
• Either, for historical reasons: no national framework / model existed at application
development time;
• Or application specific security/ functional requirements could not be met by national
framework/model.
The major difference between this model and the previous one is that applications of this category
have no intention to open themselves to external CSPs.
Application Application
CSP CSP

eSignature type: Only Simple or Advanced eSignature. Applications based on this model do
not provide for qualified eSignatures mainly because their own CSPs do not comply with the
requirements imposed by national regulations.
eSignature validation: Each application validates the certificate against its own CSP.
Credential or token type: as the applications of this model provide their own CSP, usually
they only support software-based credentials.
CSPs: Applications operate their own CSP which is not accredited by a National Authority.
Applications falling in this category provide no interoperability at all. It’s a strong design
decision.
59
November 2007

The situation is worse in the case of unqualified signatures usage. Usually they are used in closed
systems, implemented for particular purposes and encompassing limited users’ populations. The
tendency to establish more and more internal certification authorities for Public administration IT
systems purposes is another serious mistake. Therefore it is hard to obtain interoperability in public
administration systems themselves, but most of all it is the great problem for communication with
external systems. For that problem two solutions could be considered: to use certificates issued by
commercial CAs only, or to establish one or few CAs only for public administration purposes.
Technical trends
3 application support Simple signature type – 4 applications support advanced signature type.
Signature type
si mpl e adv anced Qual i f i ed c er t i f i c at e Qual i f i ed s i gnat ur e
60
November 2007
Token type
user / pas s sof t USB Smar t C ar d V i r t ual Smar t

Car d
2,5
1,5
0,5
0
XM L PDF Web-Form files ASCII
61
November 2007
model.
Signing tool
2,5
1,5
0,5
0
Italy “Project CRS-SISS (Carta Regionale dei Servizi – Sistema Informativo Socio
Sanitario) » application:
Answer: “…Signature application implemented by CRS-SISS project....”
4.2.2 Classification by model
4.2.2.1 Introduction
Among the 127 eGovernment applications described in detail in the annexes (Annex C) of the
Country Profile collected for the 29 countries concerned by the study (27 Member States Countries +
2 Candidate Countries (Turkey and Croatia)), we have found 90 applications that make use of
eSignatures.
The remaining 37 ones are mainly using electronic certificates for achieving strong authentication but
not for signing any documents in the sense of Article 2.1 of the EC Directive on a Community
framework for electronic signatures ([RD3]) that defines ‘electronic signature’ as data in electronic
form which are attached to or logically associated with other electronic data and which serve as a
method of authentication.
62
November 2007
The following figure illustrates how many applications, among the 90 concerned applications, are
belonging to one of the four models presented in the previous section (see section 4.2.1).
8% 3%
30%
Model 1
Model 2
Model 3
Model 4
59%
Without surprise, we noted that two thirds of these applications have followed an ad-hoc approach as
defined above (see section 4.2.1.2).
However, the trend is clearly to unify the way how applications are implementing electronic signatures
in order to allow for better interoperability in the country itself, e.g. by setting-up a National
Interoperability Framework.
Example: the Slovenian approach

“Currently the applications in public administration that rely on e-signature use different modules for
administration applications has been taken. A tender for development of an independent module for
creating digital signatures will soon start and the selected solution will be available to all public
administration institutions.”
63
November 2007
Example: the Bulgarian approach

“Since at the present moment there are no unified rules concerning the development of the
information systems of the state bodies enforced, the rules for acceptance, issuance, exchange and
storage of electronic documents within the state administration and the integration of new
eGovernment services is independent of any common strategy and thus it is not-coordinated. Every
administrative body applies its own particular rules for the eGovernment services it provides but these
rules are not in compliance with the rules, practices and requirements established by other bodies.
A positive step for the development of the Bulgarian eGovernment and for ensuring the interoperability
of the applications is the elaboration of draft of the new eGovernance Act and the adoption of the
Bulgarian National Interoperability Framework.”
4.2.2.2 Model 1: One-stop shop model
4.2.2.2.1 List of applications belonging to the model
Country Application / Service Name

Ireland Irish Public Services Broker - www.reachservices.ie
Slovakia Central Portal of Public Administration
United Kingdom Government Gateway
4.2.2.2.2 Major differences observed
4.2.2.2.2.1 Software requirements
The “Government Gateway” portal, officially, only supports access by a client with a Microsoft
Operating System and a Microsoft Internet Browser.
UK “Government Gateway” application:
Answer: “Windows 95 or NT 4 (SP3) or higher with Internet Explorer 5.01 or above”
4.2.2.3 Model 2: common eSignature framework model

Austria FINANZOnline ( http://finanzonline.bmf.gv.at )
Electronic delivery (www.zustellung.gv.at)
64
November 2007

Meldebestätigung (https://meldung.cio.gv.at/egovMB/)
Versicherungszeitenauszug – Link
Public Procurement (pilot project tested with std AT
certificate on smart card)
Belgium Tax-on-Web (http://www.taxonweb.be)
Bulgaria Online submission of annual income tax declarations
VAT on Internet
Germany eVergabe
DEHSt Virtual Post Office (VPS2)
Denmark ETHICS
TastSelv Borger
Virk.dk – a government portal for Danish businesses
Netborger.dk
Estonia Internet Voting
Spain Registro Telemático (Online Registry)
PROFIT Política Industrial (AVANZ@)
Finland Lomake.fi public sector online forms service
ElmaTYVI Pro at http://tyvi.elma.fi
Italy Uniwex.
Unimoney.
Telemaco, Signed Electronic Filing for Business Entities –
Balance Sheets
PCTT (Processo Civile Telematico)
Intercent-ER.
The Netherlands Elektronische aangifte
Slovakia EKR – Electronic communication interface
Sweden eINK, Personal income taxes declarations (Sw: Inlämning av
självdeklarationsuppgifter) http://www.skatteverket.se
65
November 2007
4.2.2.3.2.1 Use of unique Identifier
Applications use information coming from the signature certificate to uniquely identify the user. Most
of the time this information is a national or sectoral unique number.
applications:
Question: “What information is included in the certificate, and what is the role of this
information in the functioning of the application?”
Answer: “The main identification information concerning the user is included in the
certificate (including name, address, uniform citizen number (UCN) or uniform
identification code of BULSTAT, grounds for representation etc.). The application
extracts the identification data in order to identify the user from the certificate, but not
from the declared data. If the UCN or the BULSTAT codes are not available in the
certificate, the system will not accept the certificate.”
Denmark Republic “OCES signature”:
Question: “Is the system accessible to non-nationals, and if so, how? If not, can the
system be upgraded for cross-border interaction?”
Answer: “At the moment only persons with a Danish CPR-number can have an OCES-
personal digital signature. The reason being that the registration and identification
process is based on a CPR-register. For the same reason only companies registered in
the Danish central business register can have an OCES employee- and/or company
certificate. With regards to technology the OCES standard is based on international
standards and therefore could be upgraded for cross-border interaction. The challenge
lies in the unique identification of the certificate holder.”
Spain “Registro Telemático” application:
Answer: “User identity: NIF (identification number), name and family name”
66
November 2007
Spain “PROFIT Política Industrial (AVANZ@)” application:
Answer: “The certificate includes the name and the national registration number (DNI) in
order to authenticate the user.”
Italy “PCTT (Processo Civile Telematico)” application:
Answer: “Person ID number (“Codice Fiscale”), used to uniquely identify the subject”
4.2.2.3.2.2 Signature type
Within this model the “Elektronische aangifte” application is the only one using a simple signature
framework (i.e.: the national DigiD framework). Other applications are using simple signature specific
to the application, advanced signature or signature based on qualified certificate.
The Netherlands “Elektronische aangifte” application:
Question: “Does the system rely on a simple / advanced / qualified / other signature?”
Answer: “DigiD is simple, the name password combination companies use to log in is
also simple. For companies using their own administrative software (or their consultants)
it is possible to make use of qualified signatures”
67
November 2007
4.2.2.3.2.3 Use of virtual smart card
Austria:
- “Since March 2004, each mobile phone can be activated as citizen card. Using the
administrative signature approach, the signature creation data is held by the mobile
phone service provider A1 using hardware security modules to protect the signature
creation data. A combination of one-time authorisation codes transmitted as SMS and
personal passwords of the signatory are used as activation codes. “
4.2.2.4 Model 3: Generic CSPs model

Bulgaria Electronic market for small public procurements:
Social security declarations on Internet
eGovernment portal of the Bulgarian government
ePortal of the Employment Agency
Croatia e-VAT
e-Pension Insurance Registration (e-Mirovinsko)
Czech Republic Publication system on public contracts – publication subsystem
(eNotification).
Government Gateway - DIS system
Tax-on-Web (http://adis.mfcr.cz/adis/jepo)
Germany OptiMahnOffice
Spain Taxes at Virtual Office
DELT@ (Declaración Electrónica de Trabajadores Accidentados)
LexNet
RESEVI
Finland Epoline eOLF (Epoline Online Filing)
68
November 2007

France TeleTVA
TeleIR
Achatpublic.com
impots.gouv.fr
Tele-c@rtegrise
Hungary Electronic Firm Registration/Electronic Company Register
www.irmcegszolgalat.hu
Registration on the Client Gate
http://www.magyarorszag.hu/ugyfelkapu/regisztracio
Electronic tax and contribution declarations for citizens
https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek
for entrepreneurs
https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.htm
l
Declaration of persons entitled for health insurance:
DSend system Electronic messaging system transmitting time
stamped and encrypted messages certified with electronic
signature
Electronically authenticated private pension fund declarations
system
e-Önkormányzat – eLocal Government Portal of the Local
Government of Budapest 13th district
http://www.bp13.hu/wps/portal/e-onkormanyzat:
e-Local Government system of the Local Government of
Hódmez•vásárhely, City with County Rights
Italy Servizi telematici Entratel e Fisconline.
The Netherlands TenderNed
Poland e-GIODO (http://egiodo.giodo.gov.pl)
Portugal Online Incorporation of companies
Romania National Electronic System (http://www.e-guvernare.ro),
component e-government.
e-Procurement (http://www.e-licitatie.ro).
69
November 2007

Slovenia e-Taxes (http://edavki.durs.si)
e-SJU – Portal for electronic services of public administration
(http://e-uprava.gov.si/storitve/)
EPOS (e-business)
Intrastat (http://intrastat-surs.gov.si/)
One-Stop-Shop - State Portal for businesses (http://evem.gov.si)
Annual Reports
Financial Accounts Statistics
Salary Reporting
Multilateral Compensation
Development IS on waste management field.
On-line access to health insurance data
E-business in agriculture
Animal disease notification system – ADNS
Registration Authority Application
Slovakia eTax – Online electronic services ( http://www.drsr.sk )
Sweden eSKD (Electronic Tax Return, Sw: Inlämning av moms och
arbetsgivaruppgifter) http://www.skatteverket.se
Företagsregistrering (http://www.foretagsregistrering.se)
(Company Registration eService)
Turkey Inward Processing Regime
United Kingdom Oil & Gas Trust Scheme
4.2.2.4.2.1 Signature type
Simple signature is not used by applications belonging to this model.

4.2.2.4.2.2 Software requirements
While the majority of the applications belonging to this model sign document/web forms with standard
tool (ActiveX control, java applet, Adobe Acrobat plug-in, smart card middleware) the two following
applications require the installation of specific software.
To sign document with the “Publication system on public contracts – publication subsystem
(eNotification)” application in the Czech Republic the user has to download and install the XML602
software.
70
November 2007

(eNotification)” application:
Question: “External interface”
Answer: “Web interface – on-line forms, uploading of off-line forms filled in XML602 filler
or Adobe .PDF and XML interface”
To sign document with the “e-VAT (e-PDV)” application in Croatia the user has to download and
install specific software (57,9 MB in size).
Croatia “e-VAT (e-PDV)” application:
“…the customer has to register electronic signature by the tax web site (http://www.porezna-
uprava.hr/e-porezna/OvlastenjaFull.asp) where appropriate software has to be downloaded and
installed. “
4.2.2.4.2.3 Use of specific application identifier in the certificate
The following application is very typical: users can obtained their electronic certificate from any
Certification Service Provider, even those installed outside UK, but the certificate must contain a
specific value in one of the certificate field. This forbids the use of general-purpose electronic
certificate.
United Kingdom “Oil & Gas Trust Scheme” application:

When describing additional requirements for certificate fields:
“These additional requirements include:
…
• “Subject – Organisation Unit” should hold an additional indicator (OGTS) after the entry to
identify that the certificate has been issued in accordance with the Oil and Gas Trust
Scheme, e.g. DTI (OGTS);
…”
71
November 2007
4.2.2.5 Model 4: Application Specific CSP model

Croatia University administration programme ISVU
Ireland Revenue On-line Service ROS
Ireland Companies Registration Office E-Filing
Italy Project CRS-SISS (Carta Regionale dei Servizi – Sistema
Informativo Socio Sanitario).
Latvia Electronic Declaration System (EDS)
Slovakia Electronic Public Procurement (EVO) – eTendering module
United Kingdom e-Conveyancing
4.2.2.5.2.1 Use of additional client attribute
In this example the identifier is the IP address of client workstation.

The “University administration programme ISVU)” application uses the IP address, a username
and a password to sign documents.
Bulgaria “University administration programme ISVU)” application:
Answer: “System relies on electronic signature based on assigned username and

password and also the IP address for that person”
4.2.2.5.2.2 Non standard eSignature/Document format
The “Electronic Declaration System (EDS)” application uses a proprietary key solution to sign
documents. The signed documents are in a non standard format (DUF – DBF).
72
November 2007
Latvia “Electronic Declaration System (EDS)” application:
Answer: “The system relies on non-PKI eSignature authentication.”
Question: “Expected future developments”
Answer: “Currently the eSignature provided by the State Revenue Service is different
from the qualified electronic signature as provided according to the Electronic Documents
Law. Nevertheless, the State Revenue Service is ready to accept electronic documents
signed by the qualified electronic signature.”
Question: “Data structures processed by the application”
Answer: “Data are entered into eXtensible Mark-up Language (XML) format and
processed in DUF, DBF formats.”
Question: “How are the signature/certificate presented to the application?”
Answer: “When the user has filled in his declaration, he is prompted to click on the
button “sign and submit” which appears only if the person has the signatory rights. The
signature is created using the private key data automatically saved on the eSignature
creation directory in the computer of the user. The user is requested to indicate the
location of the private key data file.”
73
November 2007
4.2.3 Classification by country
This section provides a list of all the eGovernment applications grouped by country and then by
model.
It reflects that many countries are on the way of unifying their eGovernment approach from an ad-hoc
model to an integrated model sharing the same infrastructure or the same framework.
Country Model Application / Service Name

Austria model 2 FINANZOnline ( http://finanzonline.bmf.gv.at )
Public Procurement (pilot project tested with std AT certificate on
smart card)
Belgium model 2 Tax-on-Web (http://www.taxonweb.be)
Bulgaria model 2 Online submission of annual income tax declarations
VAT on Internet
model 3 Electronic market for small public procurements:
Social security declarations on Internet
eGovernment portal of the Bulgarian government
ePortal of the Employment Agency
model 4 University administration programme ISVU
Croatia model 3 e-VAT
e-Pension Insurance Registration (e-Mirovinsko)
Czech Republic model 3 Publication system on public contracts – publication subsystem
(eNotification).
Government Gateway - DIS system
Tax-on-Web (http://adis.mfcr.cz/adis/jepo)
Germany model 2 eVergabe
DEHSt Virtual Post Office (VPS2)
model 3 OptiMahnOffice
Denmark model 2 ETHICS
TastSelv Borger
Virk.dk – a government portal for Danish businesses
Netborger.dk
Estonia model 2 Internet Voting
Spain model 2 Registro Telemático (Online Registry)
74
November 2007

PROFIT Política Industrial (AVANZ@)
model 3 Taxes at Virtual Office
DELT@ (Declaración Electrónica de Trabajadores Accidentados)
LexNet
RESEVI
Finland model 2 Lomake.fi public sector online forms service
ElmaTYVI Pro at http://tyvi.elma.fi
model 3 Epoline eOLF (Epoline Online Filing)
France model 3 TeleTVA
TeleIR
Achatpublic.com
impots.gouv.fr
Tele-c@rtegrise
Hungary model 3 Electronic Firm Registration/Electronic Company Register
https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek
for entrepreneurs
https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.htm
l
Declaration of persons entitled for health insurance:
DSend system Electronic messaging system transmitting time
stamped and encrypted messages certified with electronic
signature
Electronically authenticated private pension fund declarations
system
e-Önkormányzat – eLocal Government Portal of the Local
Government of Budapest 13th district
http://www.bp13.hu/wps/portal/e-onkormanyzat:
e-Local Government system of the Local Government of
Hódmez•vásárhely, City with County Rights
Ireland model 1 Irish Public Services Broker - www.reachservices.ie
model 4 Revenue On-line Service ROS
Companies Registration Office E-Filing
Italy model 2 Uniwex.
Unimoney.
75
November 2007

Telemaco, Signed Electronic Filing for Business Entities –Balance
Sheets
PCTT (Processo Civile Telematico)
Intercent-ER.
model 3 Servizi telematici Entratel e Fisconline.
model 4 Project CRS-SISS (Carta Regionale dei Servizi – Sistema
Informativo Socio Sanitario).
Latvia Model 4 Electronic Declaration System (EDS)
The Netherlands model 2 Elektronische aangifte
model 3 TenderNed
Poland model 3 e-GIODO (http://egiodo.giodo.gov.pl)
Portugal model 3 Online Incorporation of companies
Romania model 3 National Electronic System (http://www.e-guvernare.ro),
component e-government.
e-Procurement (http://www.e-licitatie.ro).
Slovenia model 3 e-Taxes (http://edavki.durs.si)
e-SJU – Portal for electronic services of public administration
(http://e-uprava.gov.si/storitve/)
EPOS (e-business)
Intrastat (http://intrastat-surs.gov.si/)
Annual Reports
Financial Accounts Statistics
Salary Reporting
Multilateral Compensation
Development IS on waste management field.
On-line access to health insurance data
E-business in agriculture
Animal disease notification system – ADNS
Slovakia model 1 eServices of Trade Register
model 2 EKR – Electronic communication interface
model 3 eTax – Online electronic services ( http://www.drsr.sk )
model 4 Electronic Public Procurement (EVO) – eTendering module
Sweden model 2 eINK, Personal income taxes declarations (Sw: Inlämning av
76
November 2007

model 3 eSKD (Electronic Tax Return, Sw: Inlämning av moms och
arbetsgivaruppgifter) http://www.skatteverket.se
Turkey model 3 Inward Processing Regime
United Kingdom model 1 Government Gateway
model 3 Oil & Gas Trust Scheme
model 4 e-Conveyancing
4.2.4 Classification by sector
4.2.4.1 eProcurement applications
As reported by the national correspondents, the following signature types, according to definitions
introduced at section 4.1.3.1.1, are required for existing eProcurement applications:
Country Model Signature Detail / Other info

requirements
Austria model 2 Qualified http://www.auftrag.at; a pilot has been run, but use of the application is not
signature yet generalised.
Belgium model 2 Qualified http://www.jepp.be/; currently only the notification platform is available; but
signature the legal framework indicates that qualified signatures will be required,
likely through the national eID card.
Bulgaria model 3 Qualified http://www.aop.bg; currently only the notification platform is available; but
certificate the legal framework indicates that the so called ‘Universal Electronic
Signature’ will be used, a qualified soft certificate. Smaller procurements
can be done through http://smallsrv.minfin.bg/), also using the Universal
Electronic Signature.
Croatia model 3 Qualified http://www.nn.hr/; no specific application, but electronic tenders are
certificate allowed under general regulations.
Cyprus n.a. None yet No e-signature functionality yet.
Czech model 3 Advanced Opportunities are published through www.isvzus.cz; no specific application
Republic signature with
qualified
certificate
Denmark model 2 Advanced http://www.innovasion.dk/, through the ETHICS application, using the so
signature called ‘OCES’, an advanced soft certificate.
Estonia n.a. Signatures are Opportunities are published through https://riigihanked.riik.ee/ but this
not required portal has e-signature functionality for authentication purpose on the basis
of PIN1 code.
Finland n.a. Authentication; Applications include http://www.hankintailmoitukset.fi,
no signature http://palvelut.tieke.fi/tati/, www.hymonet.com, www.kilpanet.com,
http://www.hansel.fi/index.php?id=286&action=empty&lang=en&s=1. None
of these use e-signatures at this time.
77
November 2007

requirements
France model 3 Advanced www.achatpublic.com and www.marchespublics.net.
signature
Germany model 2 Qualified http://www.evergabe-online.de/, a web platform using qualified (through
signature and smart card) and advanced (through soft certificate) signatures.
advanced
signature
Greece n.a. None yet No e-signature functionality yet.
Hungary n.a. None yet http://kszfweb.econet.hu/portal/; no e-signature functionality yet (although
advanced electronic signatures should be valid, there is presently no
application supporting their use).
Ireland n.a. None yet www.etenders.ie is the main portal, but thus far it does not use e-signature
functionality.
Italy model 2 Qualified http://www.consip.it/ (or e.g. http://www.intercent.it/ for local
signature procurements). In principle, the portal uses qualified signatures on a smart
card, but for some more limited services simple signatures are also
accepted.
Latvia n.a. None yet An eProcurement application exists, but it relies on a username/password
system.
Lithuania n.a. None yet CPPW is the main portal, but thus far it does not use e-signature
functionality.
Luxembourg n.a. None yet www.marches.public.lu is the main portal, but thus far it does not use e-
signature functionality.
Malta n.a. None yet http://www.contracts.gov.mt is the main portal, but thus far it does not use
e-signature functionality.
The model 3 Qualified In 2006 a new site has been launched, www.tenderned.nl This site co-
Netherlands signature ordinates on a national level electronic Public Procurement
Poland model 3 Qualified Portals include www.ppp.pwpw.pl, www.e-przetarg.pl and www.etender.pl.
signature
Portugal n.a. None yet Applications are being deployed, but do not use e-signatures yet.
Romania model 3 Qualified http://www.e-licitatie.ro
certificate and
advanced
signature
Slovakia model 4 Advanced https://evo.gov.sk is the main portal. Electronic Public Procurement (EVO)
signature – eTendering module
Slovenia n.a. None yet http://www.gov.si/mf/slov/index.htm is the main portal, but thus far it does
not use e-signature functionality.
Spain n.a. None yet http://catalogopatrimonio.meh.es/pctw/lic_electr.aspx is the main portal,
but thus far it does not use e-signature functionality.
Sweden n.a. Not specified No national e-procurement portal exists, but specific administrations may
request offers and accept electronically signed submissions. There is no
common norm for the signature type required.
Turkey n.a. None yet No application has been identified yet.
United n.a. None yet http://www.gateway.gov.uk/. While e-signatures are technically allowed, all
Kingdom applications currently use a username/password authentication system
instead of a signature.
78
November 2007
The following figure depicts the classification by model of applications belonging to this sector.
The clear domination of model 3 follows the trend observed at the European level.
eProcurement
Model 4 Model 1
8% 0%
Model 2
33%
Model 3
59%
Technical trends
The figure below represents the signature type support by applications belonging to this sector.
0 application support Simple signature type – 6 applications support advanced signature type – 4
Signature type
6
5
4
3
2
1
si mpl e adv anc ed Qual i f i ed cer t i f i cat e Qual i f i ed s i gnat ur e
79
November 2007
The figure below represents the token type support by applications belonging to this sector.
Token type
4,5
4
3,5
3
2,5
2
1,5
1
0,5
0
user / pass sof t USB Smar t Car d Vi r tual Smar t
Car d
4.2.4.2 Income tax applications
As reported by the national correspondents, the following signature types are required for existing
income tax declarations applications:

requirements
Austria model 2 Simple/Qualifi FINANZOnline (http://finanzonline.bmf.gv.at). Portal application
ed providing services:
signature
• To citizens: tax returns of employed persons,
application for family allowance, personal income taxes of
entrepreneurs, VAT declarations of entrepreneurs,
inspection of tax accounts;
• To companies: VAT declarations, income tax declarations,
corporation tax declarations;
• To municipalities: declaration of taxable basis for municipal
tax
80
November 2007

requirements
Belgium model 2 Simple / Tax-on-Web (http://www.taxonweb.be). The system relies:
Qualified
signature • either on the qualified signature provided by the e-ID card;
• or on the advanced signature provided by the federal token.
Note that the federal token is particularly interesting for people who
are not yet in the possession of an e-ID but want to obtain access to
secured online services. However, the token also presents certain
limitations, specifically with regard to the user group (which only
covers natural persons who possess three numbers, thus excluding
legal entities and certain non-nationals, namely those who have no
national identity card and can thus not present an identity card
number). Thus, for users outside of this group (who have no e-ID
card or token), the service is presently not accessible.
Bulgaria model 2 Qualified The system https://inetdec.taxadmin.minfin.bg/ relies on Universal
certificate Electronic Signatures. Note that the application collects the
identification number (UCN) not from the electronic declaration but
from the certificate supporting the electronic signature of the user.
Croatia n.a. None yet All tax declarations other than VAT declaration are not possible to be
done in electronic form.
Cyprus n.a. None yet TAXISnet (http://taxisnet.mof.gov.cy) is a special network provided
free of charge by the Inland Revenue Department, through which
Taxpayers-Natural Persons may submit initial Tax Returns by use of
electronic communication methods.
Czech model 3 Advanced All kind of taxes can be declared on-line via the application tax-on-
Republic signature with web (http://adis.mfcr.cz/adis/jepo) provided by the Czech Tax
qualified Administration. Note that Qualified certificates used for eSignature
certificate (adjoin to tax submission) must contain the unique identification of a
taxpayer. Based on this identification the personal data of a
subscriber can be determined.
Denmark model 2 Advanced TastSelv Borger (http://tastselv.skat.dk/). The OCES signature can
signature be used also for authentication.
Estonia n.a. No
information
Finland model 2 Qualified A large amount of electronic forms and applications for multiple
signature purposes, notably tax declarations, can be obtained from a website
set up by the Ministry of Finance (www.lomake.fi).
France model 2 Advanced The central portal for tax declarations in France is
signature http://www.impots.gouv.fr. For individuals, online tax declaration is
possible and widely used. Users register with their unique fiscal
number and a password, and thereafter receive an on-line certificate.
After that, he/she fills in the form and uses the issued certificate to
sign. The signature application is included into the TéléIR
application.
Germany n.a. No
information
Greece n.a. None yet Income Tax Return Forms may be found electronically in at the
Ministry of Economy and Finance Department’s website at:
http://www.taxisnet.gr
Hungary model 3 Advanced Electronic tax and contribution declarations for citizens
signature (https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek)
81
November 2007

requirements
Ireland model 4 Qualified Revenue On-line Service (ROS) is a central government online tax
signature system for the following categories of taxpayers: - self-employed
individuals, business, practitioners and, most recently, employees.
The system is accessible at www.ros.ie.
Note that Revenue Commissioners acts as its own Certification
Authority.
Italy model 2 Qualified Fisconline (http://fisconline.agenziaentrate.it) is targeted to individual
signature tax payers and small enterprises.
Latvia model 4 Simple Electronic Declaration System (EDS) (http://www2.vid.gov.lv). Note
signature that the system makes use of electronic signatures provided and
managed by the State Revenue Service on the basis of a signed
agreement.
Lithuania n.a. None yet Electronic Tax Declaration System (EDS) (http://deklaravimas.vmi.lt)
was launched in March 2004. It enables individuals and legal entities
to submit tax reports in digital format (via Internet, e-mail, CD and
etc.). The system does not use advanced / qualified eSignatures at
the moment.
Luxembou n.a. None yet The Ministry of Finances provides a website
rg (http://www.impotsdirects.public.lu/formulaires/index.html) where
electronic forms (Adobe Acrobat) can be downloaded.
Malta n.a. None yet Inland Revenue
(https://secure.gov.mt/ird/irdnet/login.aspx?auth=eid) is providing
individual taxpayers with the facility to submit their Income Tax
Return over the Internet. The system is based on eID Level 1
authentication mechanism (using a username and password).
The model 2 Simple Citizens may fill-in their electronic income tax declaration via
Netherland signature http://www.belastingdienst.nl/particulier/aangifte.html. In such case,
s the use of DigiD is required in case of electronic income tax
declaration. DigiD is used as a normal electronic signature. Note that
a Social Fiscal number (SOFI-nummer) is needed to apply for a
DigiD.
Poland n.a. None yet Ministry of Finances has decided to establish e-podatki (e-tax)
system to enable companies and individuals to transmit tax returns
via electronic means. It is planned to start the system at the
beginning of 2008.
Portugal n.a. None yet E-Declarations is a web platform (www.dgci.gov.pt) that enables the
communication of citizens and companies with the Portuguese Tax
Department (Direcção-Geral dos Impostos). Through this platform
all electronic forms for tax purposes can be obtained.
The system relies on the identification of the user (the user provides
the TAX number) and a password (from 8 up to 16 characters)
Romania model 3 Qualified National Electronic System (http://www.e-guvernare.ro) is the easy
signature to use central access point to online public information and services.
Through this portal, private companies can electronically fill, transmit
to central administration their fiscal declarations. Currently, by
legislation, only 6 declarations may be filled and transmitted
electronically by a limited number of companies.
82
November 2007

requirements
Slovakia model 3 Simple/Qualifi eTax application (http://www.drsr.sk) is an integrated system of
ed signature online services, intended for electronic communication between tax
authorities and citizens and enterpriser.
The system is accessible also to non-nationals under condition, that
certificate has to be issued by Certification Authority accredited by
Slovakian National Security Authority.
Slovenia model 3 Qualified The Slovenia eTax system
signature (http://edavki.durs.si/OpenPortal/Pages/StartPage/StartPage.aspx)
is a complete business solution combining a web portal with back
office integration and the highest level of security based on qualified
certificates (authentication and digital signature are based on
qualified digital certificates).
Note that the service is presently accessible only for Slovene
qualified certificates.
Spain model 3 Advanced / Personal income taxes can be declared on-line via the application
Qualified provided by the Tax Agency Virtual Office (https://aeat.es).
signature
Note that the service is currently accessible for all users that have a
NIF (Spanish Identification Number) and a certificate issued by one
of the recognised Spanish CSP
(http://www.aeat.org/prestelem/certauto.htm).
Sweden model 3 Advanced Personal income taxes can be declared on-line via the website of the
signature Swedish National Tax Board (http://www.skatteverket.se).
The application relies on the eID framework. Note that non-nationals
who are registered in Sweden and therefore are eligible for tax have
a personal identity number, which allow them to acquire an eID.
Turkey n.a. No
information
United model 1 Simple Income Tax Declarations can be submitted on-line vie the
Kingdom signature Government Gateway (http://www.gateway.gov.uk/).
83
November 2007
The general trend of European applications is not followed by applications belonging to this model.
We have the same number of model 2 and model 3 applications.
eTAX
Model 4 Model 1
12% 6%
Model 2
41%
Model 3
41%
Technical trends
application supports qualified certificate - 9 applications support "qualified" signature type.
Signature type
10
0
si mpl e advanced Qual if i ed cer ti f icate Qual i f i ed si gnatur e
84
November 2007
The figure below represents the trend for application belonging to this sector (“files” means not PDF
0
XML PDF Web-Form f iles ASCII
85
November 2007
model.
Signing tool
10
6
Series1
4
0
4.2.4.3 VAT applications
As reported by the national correspondents, the following signature types are required for existing
VAT applications:

requirements
Austria model 2 Simple/Qualifi FINANZOnline (http://finanzonline.bmf.gv.at). Portal application
ed signature providing services:
• To citizens: tax returns of employed persons,
application for family allowance, personal income taxes of
entrepreneurs, VAT declarations of entrepreneurs,
inspection of tax accounts;
• To companies: VAT declarations, income tax declarations,
corporation tax declarations;
• To municipalities: declaration of taxable basis for municipal
tax
Belgium model 3 Qualified VAT can be declared online via the Intervat application
signature (www.minfin.fgov.be). Note that only the three accredited
commercial CSP certificates are legally accepted for electronic
declarations.
Bulgaria model 2 Qualified The system https://inetdec.taxadmin.minfin.bg/ relies on Universal
certificate Electronic Signatures. It is intended to Bulgarian VAT payers
(registered under the Value Added Tax Act persons). Note that the
application extracts the identification number of the user - legal entity
(its BULSTAT uniform identification code) from the very certificate
Croatia model 3 Qualified e-PDV (http://www.porezna-uprava.hr/e-porezna/ePDV.asp). Note
certificate that the application requires using dedicated software on the client’s
workstation (57,9Mb) that is only available for Windows.
86
November 2007

requirements
Cyprus n.a. None yet TAXISnet (http://taxisnet.mof.gov.cy) is a special network through
which VAT Tax Returns and payment of Tax can be submitted.
Czech model 3 Advanced All kind of taxes can be declared on-line via the application tax-on-
Republic signature web (http://adis.mfcr.cz/adis/jepo) provided by the Czech Tax
with qualified Administration. Note that Qualified certificates used for eSignature
certificate (adjoin to tax submission) must contain the unique identification of a
taxpayer. Based on this identification the personal data of a
subscriber can be determined.
Denmark model 2 Advanced TastSelv Erhverv (http://www.skat.dk/SKAT.aspx?oID=199611). The
signature application is accessible to non-nationals who have a SE-number
(are paying VAT to Denmark). Non-nationals can only get access by
pin-code as OCES signatures are not offered to non-nationals.
Estonia n.a. No
information
Finland model 2 Qualified ElmaTYVI Pro (http://tyvi.elma.fi) is an electronic client service
certificate through which companies and associations can use web forms and
send reports (e.g. tax returns) to the authorities and other
organisations that collect statutory data. TYVI is a joint service of
many authorities.
France model 3 Advanced TéléTVA (http://tva.dgi.minefi.gouv.fr/). Note that: Enterprises have
signature to obtain their digital certificate from a certification service provider
recognized on a list published by the Ministry of Finance (see:
http://www.telecom.gouv.fr/rubriques-menu/entreprises-economie-
numerique/certificats-references-pris-v1/categories-familles-
certificats-references-pris-v-1-506.html. The signature application is
included into the TéléTVA application.
Germany n.a. No
information
Greece n.a. None yet The TAXISnet service (http://www.taxisnet.gr) provides services to
individual and corporate taxpayers, including electronic submission
of income tax forms, personalised online notification of the results of
the tax return clearance process, electronic issuing of certificates by
fax, electronic submission of VAT forms, and payment via banking
system services.
Hungary model 3 Advanced Businesses, organisations and natural persons subject to taxation
signature can submit their tax declarations and fulfil their data supply
obligations using the electronic tax declaration system eBev
(https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.html
).
Ireland model 4 Advanced Revenue On-line Service (ROS) is a central government online tax
signature system for the following categories of taxpayers: - self-employed
individuals, business, practitioners and, most recently, employees.
The system is accessible at www.ros.ie.
Note that Revenue Commissioners acts as its own Certification
Authority.
Italy model 3 Qualified Entratel (https://entratel.agenziaentrate.it) is used by professional tax
signature middlemen (accountants, counsellors, centres of assistance on tax
declarations) and by large enterprises.
87
November 2007

requirements
Latvia model 4 Simple Electronic Declaration System (EDS) (http://www2.vid.gov.lv). Note
signature that the system makes use of electronic signatures provided and
managed by the State Revenue Service on the basis of a signed
agreement.
Lithuania n.a. None yet Electronic Tax Declaration System (EDS) (http://deklaravimas.vmi.lt)
was launched in March 2004. It enables individuals and legal entities
to submit tax reports in digital format (via Internet, e-mail, CD and
etc.). The system allows using qualified eSignatures certificates for
authentication at the moment.
Luxembou model 4 Simple The eTVA system (see https://saturn.etat.lu/etva/index.do) currently
rg signature relies on simple signature (username/password) which should be
seen as a validation of the operation.
Malta n.a. No
information
The model 2 Qualified As of January 2005 all companies are obliged to file electronic tax
Netherland certificate declarations electronically via
s http://www.belastingdienst.nl/zakelijk/aangifte.html.
Businesses use a personal name/password to log in. They have
obtained this information via their Social-Fiscal number and can also
use DigiD. If they do not use the internet forms but their own
administrative software they can either use qualified signatures (e.g.
Diginotar is specifically indicated as a CSP where to obtain a digital
signature), or a name/password can be asked for.
Poland model 3 Qualified e-poltax system (https://e-poltax.mf.gov.pl) has been set-up for some
signature businesses (if yearly netto incomes exceed 5 millions EUR) to
provide following services:
(a) an application for electronic documents exchange with
Inland Revenue Service,
(b) an off-line application enabling to sign and to send
electronic tax returns to Inland Revenue Service,
(c) an electronic documents schemes repository.
It is some kind of temporary solution final solution before set-up of e-
Deklaracje (e-declarations) project foreseen in 2008.
Portugal model 3 Simple E-Declarations is a web platform (www.dgci.gov.pt) that enables the
signature communication of citizens and companies with the Portuguese Tax
Department (Direcção-Geral dos Impostos). Through this platform all
electronic forms for tax purposes can be obtained.
The system relies on the identification of the user (the user provides
the TAX number) and a password (from 8 up to 16 characters)
Romania model 3 Qualified National Electronic System (http://www.e-guvernare.ro) is the easy to
certificate use central access point to online public information and services.
Through this portal, private companies can electronically fill, transmit
to central administration their fiscal declarations. Currently, by
legislation, only 6 declarations may be filled and transmitted
electronically by a limited number of companies.
88
November 2007

requirements
Slovakia model 3 Qualified eTax application (http://www.drsr.sk) is an integrated system of
certificate online services, intended for electronic communication between tax
authorities and citizens and enterpriser.
The system is accessible also to non-nationals under condition, that
certificate has to be issued by Certification Authority accredited by
Slovakian National Security Authority.
Slovenia model 3 Qualified The Slovenia eTax system
certificate (http://edavki.durs.si/OpenPortal/Pages/StartPage/StartPage.aspx) is
a complete business solution combining a web portal with back
office integration and the highest level of security based on qualified
certificates (authentication and digital signature are based on
qualified digital certificates).
Note that the service is presently accessible only for Slovene
qualified certificates.
Spain model 3 Advanced / VAT taxes can be declared on-line, via the application provided by
Qualified the Tax Agency Virtual Office (https://aeat.es).
signature
Note that the service is currently accessible for all users that have a
NIF (Spanish Identification Number) and a certificate issued by one
of the recognised Spanish CSP
(http://www.aeat.org/prestelem/certauto.htm).
Sweden model 3 Qualified VAT return may be submitted electronically via the Swedish National
signature Tax Board website (http://www.skatteverket.se), by using an eID and
provided previous notification to the National Tax Board.
Turkey n.a. No
information
United model 1 Simple Electronic VAT Returns can be submitted on-line vie the Government
Kingdom signature Gateway (http://www.gateway.gov.uk/).
The clear domination of model 3 follows the trend observed at the European level.
89
November 2007
eVAT
Model 4 Model 1
14% 5%
Model 2
23%
Model 3
58%
Technical trends
application supports qualified certificate - 6 applications support "qualified" signature type.
Signature type
10
0
s i mpl e advanc ed Qual i f i ed cer t i f i c at e Qual i f i ed s i gnat ur e
90
November 2007
Token type
14
12
10
8
6
4
2
0
Car d
91
November 2007
5 Impact Assessment and Recommendations
5.1 Introduction
From the models defined at previous stage, an impact assessment of the similarities and differences
for the eGovernment applications identified is reported below. The most important interoperability
problems are listed.
5.2 Definitions
At the light of the various country profiles analysed, we have detected a slight difference in the
interpretation of concepts (Interoperability, Supervision …).
The next sections intend to clarify the definitions.
5.2.1 Supervision vs. Accreditation
A majority of the surveyed countries have established a list of certification service providers,
recognized for issuing certificates to be used in e-government applications. Some of the countries
maintain one central list for all applications (France, for example) while others work with separate lists
per sector or even per application.
Various country profiles demonstrate that there is confusion between these lists (registered CSP for e-
government transactions) and the lists that are kept following article 3 of the European e-signature
Directive.
Article 3 of the Directive prohibits submitting the access to the market of certification services to any
form of prior authorization (explicitly or via a “de facto” system). On the other hand the Directive
requests the Member States to set up a system for “supervision”. Any CSP providing services to the
public and claiming that its certificates are “qualified” (fulfilling the requirements of the Annexes to the
Directive) should be supervised by a supervisory body. Most of the Member States have
implemented this requirement via a notification scheme: all CSPs issuing qualified certificates to the
public have to notify their activities to the supervisory body and automatically appear on a list of
“supervised” CSPs. Some of the surveyed countries apparently have decided that all of these
“supervised” CSPs are automatically recognized as suitable certification authorities for e-government
transactions.
Article 3 of the Directive mentions also the possibility to establish voluntary accreditation schemes.
The objective of these schemes is to provide service providers with a possibility to obtain a quality
label for their services. These voluntary accreditation schemes don’t exist in all Member States and
are sometimes organised by the private sector (for example in the UK).
Various country profiles show that governments also establish accreditation schemes in the e-
government context. These accreditation schemes are not voluntary because the accreditation is, in
most of the cases, obligatory in order to access the “market” for e-government applications. One the
discussions is whether these practices are compliant with Art. 3.7 of the Directive (the so-called
“public sector” clause).
5.2.2 Interoperability
At the European level, full interoperability means that an eGovernment application of a given Member
State should accept any electronic signatures sent by any natural or legal person from any Member
State even if the signature is created using credentials coming from non-national Certification Service
Providers (CSPs).
92
November 2007
As many applications rely only on CSPs accredited by their own national accreditation body21, full
interoperability would mean that either its own national accreditation body must be able to accredit
non-national CSPs or that multilateral agreements must be established between Accreditation Bodies
from various Member States (see also sections 4.1.1.2 and 4.1.3.4)
Among all surveyed applications, no application has been assessed as interoperable in the sense of
the above definition. However, some applications claim to be interoperable under some conditions
(see section 5.2.2.1).
Interoperability
CSP
eGov
User Application
Country X Country Y
21
The public or private body charged with the elaboration of, and supervision of compliance with,
rights and obligations specific to the provision of certification services (cfr [RD3], Art 2 §13),
93
November 2007
5.2.2.1 Examples
The following application is technically and organisationally ready to accept signature created by Non-
National certificate. A foreign CSP is accredited by National accreditation authority but regulations
amendments are still needed.
Slovakia “eTax – Online electronic services” application:
Question:” Is the system accessible to non-nationals, and if so, how? If not, can the
Answer: “Yes the system is accessible also to non-nationals under condition, that
certificate has to be issued by Certification Authority accredited by NSA. For the full
access to the system (for the full cross-border interaction) is the amendment or
supplementation of the legislative required.”
Question:” What measures, if any, have been taken to ensure interoperability with
signatures created and/or certificates issued in other countries?”
Answer: “For interoperability insurance are a few measures needed. E.g. currently is one
Czech CSP accredited in Slovakia and on the basis of this accreditation are the qualified
certificates from this CSP recognised.”
The next application is technically ready to accept signature created by Non-National certificate but
regulations amendments are still needed.
Austria “FINANZOnline” application:
Answer: “The technical integration of alien e-IDs has been completed (to date Belgian,
Estonian, Italian, and Finish eID), but is not yet in operational use (e.g., not yet activated
in MOA-ID identification and authentication services for operational services). The steps
to be taken technically are mainly the integration of the root certificates into the MOA
modules. Legally, the identification follows a concept referred to a “recurring identity”
which cannot be used for official delivery services. Amendments of the legal basis would
be needed.”
94
November 2007
Next application is also technically ready to accept signature created by Non-National certificate but
national procedures are in preparation.

Answer: “Ministry of informatics prepares best practice on procedures in cross-border

recognition of qualified certificates.”
5.2.3 Cross-border
As mentioned above, many applications rely only on CSPs accredited by their own national
Accreditation Authority. Said this, they claim anyway to be opened for cross-border use which means
that non-nationals must first apply for credentials to one of the accredited CSPs.
As soon as qualified certificates are concerned, this means that non-nationals must physically register
in the country where the application is deployed.
Among all surveyed applications, 20 applications have been assessed as opened for cross-border use
in the sense of the above definition but none of them accept a signature generated by a Non-National
certificate.
95
November 2007
Cross Border
CSP
eGov
User
Application
Country X Country Y
Country Application/Service name

FINANZOnline ( http://finanzonline.bmf.gv.at )
Austria
Bulgaria Electronic market for small public procurements:
Czech Republic Publication system on public contracts – publication subsystem (eNotification).
Finland Epoline eOLF (Epoline Online Filing)
Electronic Firm Registration/Electronic Company Register
Hungary
Latvia Electronic Declaration System (EDS)
The Netherlands TenderNed
Romania e-Procurement (http://www.e-licitatie.ro).
Slovakia Electronic Public Procurement (EVO) – eTendering module
Företagsregistrering (http://www.foretagsregistrering.se) (Company
Sweden
Registration eService)
United Kingdom Oil & Gas Trust Scheme
Italy Uniwex.
Intercent-ER.
96
November 2007

Servizi telematici Entratel e Fisconline.
France impots.gouv.fr
Germany eVergabe
Turkey Inward Processing Regime
Cross-border applications
5.2.3.1 Examples
This application from Latvia requires an agreement to be taken between Non-National citizen and the
administration to accept its electronic signature generated by a national certificate.
It is clearly a “cross-Border” application. But the necessary national/sectoral measures that have to be
taken to recognise signature created by foreign certificate, do not exist.
Answer: “The system is accessible to non-nationals if they have concluded the

Agreement.”
Question:” Is What measures, if any, have been taken to ensure interoperability with
Answer: “The State Revenue Service has not taken any measures to ensure
interoperability with signatures created and/or certificates issued in other countries.”
97
November 2007
The following applications can be used by Non-National citizens having a certificate issued by an
accredited National CSP. Applications owners are aware that they are not interoperable with foreign
signature and mention possible solutions to be created at the European level.
Hungary “Electronic Firm Registration/Electronic Company Register

www.irmcegszolgalat.hu” application:
Answer: “As the system is based on qualified signatures, it may accept qualified
certificate from other EU member states from the legal point of view. However, in order
to verify qualified signatures from other EU member states, there would be a need for an
authentic source of CA certificates of qualified CAs from each member states. Without
such an authentic source, it is not possible to verify certificates of foreign CAs from the
technical point of view.”
Romania “eProcurement (http://www.e-licitatie.ro).” application:
Answer: “Yes. Currently, all the necessary for an authority or private company is the
online or offline registration. After that, applicant receives by e-mail an electronic
certificate issued by IGCTI for system usage.”
Answer: “There is an interoperability project in development, named “Bridge CA”.”
98
November 2007
The following applications are designed to allow interoperability of electronic signature but certificate
used for the creation of the electronic signature are limited to national one. This limitation comes from
the fact that there is no foreign accredited CSP.
Italy “Uniwex” application:
Answer: ”System is available (when significant) through web to anyone who owns a
valid (Italian so far) certificate and plays one of the aforementioned roles in the
university...”
Limiting the usage of certificate to the national one accredited by the Italian
Government.
99
November 2007
The Netherlands “e-Procurement” application:
Answer: ” Yes, if a foreign tenderer has a qualified electronic signature, the system will
be made accessible for this tenderer.”
But at the following question
Question:” Which institutions, providers, etc. are involved in the signature

scheme, and how do they relate?”
The answer was:
Answer: “Diginotar, Gemnet CSP, ESG: providers of electronic signatures,

certified by OPTA.”
Limiting the usage of certificate to the national one accredited by the Netherlands
Government.
The application is ready for cross-border but not for interoperability at the European level because of
missing National procedure to recognise signature created by Non-national certificate.
100
November 2007

Answer: ”The applications from the information system on public contracts – publication
subsystem (hereinafter “ISPC-PS”) are accessible free through the web sites of the
provider (www.isvzus.cz). However non-nationals need qualified certificates to use these
kinds of applications (qualified certificate according to the e-signature directive) – if
qualified certificate is not issued in his country, user must get qualified certificate in other
country.”
Answer: “Ministry of informatics prepares best practice on procedures in cross-border

recognition of qualified certificates.”
5.2.4 Non-National residents
There is a last definition that has been derived from the Country Profiles: use of applications by non-
nationals residing in the country where the application is provided. In that case, non-national residents
are usually ‘comparable’ to national ones. Usually, they can apply for credentials exactly as a
national. There are cases where this is not possible, e.g. because non-nationals are not provided with
a required unique identification number (e.g. in Denmark, Finland or Spain).
101
November 2007
Non-national residents
CSP
eGov
User Application
from Country X
Country Y
Among surveyed applications, there are 24 applications that claim to be opened to non-national
residents.

Bulgaria University administration programme ISVU
Finland Lomake.fi public sector online forms service
https://www.magyarorszag.hu/allampolgar/szolgaltatasok/jarulek for
entrepreneurs
https://www.magyarorszag.hu/allampolgar/szolgaltatasok/ebev.html
Hungary Declaration of persons entitled for health insurance:
DSend system Electronic messaging system transmitting time stamped and
encrypted messages certified with electronic signature
Electronically authenticated private pension fund declarations system
e-Önkormányzat – eLocal Government Portal of the Local Government of
Budapest 13th district http://www.bp13.hu/wps/portal/e-onkormanyzat:
Irish Public Services Broker - www.reachservices.ie
Ireland Revenue On-line Service ROS
Companies Registration Office E-Filing
The Netherlands Elektronische aangifte
102
November 2007

Portugal Online Incorporation of companies
National Electronic System (http://www.e-guvernare.ro), component e-
Romania
government.
Slovenia
EKR – Electronic communication interface
Slovakia eServices of Trade Register
eTax – Online electronic services ( http://www.drsr.sk )
Spain RESEVI
eINK, Personal income taxes declarations (Sw: Inlämning av
Sweden
United Kingdom Government Gateway
France Achatpublic.com
Croatia e-Pension Insurance Registration (e-Mirovinsko)
5.3 Identified interoperability issues and recommendations

Our survey of usages of advanced electronic signatures in e-government applications in the Member
States has revealed the following interoperability issues. The objective of this list is to provide a first
basis for a discussion in the perspective of future European strategies in this area. The list has been
divided into three categories: legal issues, technical issues and organisational issues. It should be
noted that such classifications always imply a certain element of subjectivity, since many of these
issues (e.g. the frequent link between e-signature solutions and electronic identity management
systems) entail components from all three categories. None the less, an effort has been made to
group each issue into the category which was considered to be predominant.
5.3.1 At Legal level
5.3.1.1 National perspective
5.3.1.1.1 Problem description
Most of the surveyed countries, as far as they have adopted electronic signatures in their e-
government applications, have organised this feature without taking into account electronic signatures
created by companies and individuals in other countries. The regulatory, technical and organisational
framework is always organised from a strictly national perspective. In most of the cases this national
perspective is implicit. The application presumes that the user is a national living on the country’s
territory. All kinds of practical obstacles prevent other users to access and actually use the
application.
5.3.1.1.2 Assessment
The strictly national perspective of most of the e-signature applications in the e-government sphere
could be a temporary issue. Priority is first given to e-signature features for the large majority of the
users. Serving more marginal categories, such as the occasional users from other countries, is not
considered as a first priority.
103
November 2007
5.3.1.1.3 Recommendations
One of the key observations in relation to this issue is that the national perspective is partly the
consequence of the principle of subsidiarity, which to a large extent permits Member States to make
their own choices with regard to their e-Signature policies. Eliminating this principle is neither possible
nor desirable.
However, the study has identified that there appears to be a tendency among Member States to
overlook the fact that this principle is not without its limitations, and that it does not allow them to
restrict the free movement of services (in this case, offering signature solutions with cross border
legal validity) without solid grounds. As noted above, restricting the types of acceptable electronic
signature solutions is permissible under the e-Signatures Directive, provided that the chosen
‘requirements shall be objective, transparent, proportionate and non-discriminatory and shall relate
only to the specific characteristics of the application concerned. Such requirements may not
constitute an obstacle to cross-border services for citizens.’ In practice, Member States typically
accept only their pre-approved national solutions.
This situation is certainly understandable, given the fact that applications in practice are typically
developed based on specific needs, and administrations justifiably prefer to focus on solutions that
offer an optimal benefit to a large majority of the targeted user group, rather than emphasising equal
accessibility to all potential European users. This is certainly the case for applications developed on a
regional or communal level, where the resources needed to obtain significant interoperability may be
unavailable, and where the expenses incurred to achieve such a goal would often be disproportionate
to any realised benefit. Additionally, administrations could argue that a requirement to use a specific
signature solution is not an ‘additional requirement’ in the sense of article 3.7, but rather an additional
possibility being offered to the traditional paper based procedures. In that perception, an ‘additional
requirement’ would only exist if an application were to impose demands that went beyond the general
requirements in vogue in a specific Member States. However, the implication of this interpretation
would be a de facto complete exemption of public sector applications of the basic principles of non-
discrimination and equivalence embraced by the Directive.
Member States should therefore be reminded of the letter and spirit of the public sector clause
(RECO1), and especially the limitation that additional requirements may not constitute an obstacle to
cross border services for citizens. Infringement proceedings for non-compliance with the e-Signatures
Directive however do not seem in order, given the complexity of the issue and the lack of a common
technical solution which would allow Member States from a practical perspective to accept and
validate non-national e-Signatures.
Additionally, Member States should be reminded of their notification obligations under article 11,
which requires them to notify to the Commission and the other Member States of (inter alia)
information on national voluntary accreditation schemes, including any additional requirements
pursuant to Article 3(7) (the public sector clause):
“Article 11 – Notification
1. Member States shall notify to the Commission and the other Member States the following:
(a) information on national voluntary accreditation schemes, including any additional

requirements pursuant to Article 3(7);
[…]”
When Member States choose to restrict access to public sector applications based on the signature
type being used (including a limitation to certain CAs or to one’s own eID card), it can be argued that
article 11.1.(a) requires them to notify the Commission and other Member States of this restriction. If
this were to be done systematically, this would greatly facilitate any interoperability activities, as an
accurate overview of accepted signature solutions would be easily available.
104
November 2007
However, we would not argue that the notification obligation should go so far as to require all
eSignature application providers to notify the supported signature solutions to the Commission. Such
an extensive interpretation would not be productive in improving the interoperability between national
systems, as it would flood the Commission with largely unusable information and impose an undue
burden on application providers who are attempting to improve their services for their users. Rather,
the notification obligation should be read as only pertaining to national voluntary accreditation
schemes, where the Member States who provide such schemes are also required to provide any
additional requirements pursuant to the public sector clause. I.e., the notification obligation of the
Member States with regard to additional requirements is a component of their general notification
obligations with regard to voluntary accreditation schemes, and not an autonomous obligation.
Member States should be reminded of the letter and spirit of the public sector clause (art. 3.7),
including their obligation in principle not to introduce requirements which constitute an obstacle to
cross-border services for citizens; and of their notification obligations under article 11 of the Directive
which require them to notify the Commission of any additional requirements imposed in application of
article 3.7 insofar as these are a part of any voluntary accreditation scheme. Member States must be
aware of the fact that the principles of non-discrimination and equivalence to handwritten signatures
should also apply to eGovernment applications, unless the public sector clause allows them to decide
otherwise. They must provide the Commission with the necessary information to support further
initiatives should the efforts of the Member States prove insufficient.
5.3.1.1.4 Conclusions
RECO1 Member States should be reminded of the letter and spirit of the public
sector clause (art. 3.7), including their obligation in principle not to
introduce requirements which constitute an obstacle to cross-border
services for citizens; and of their notification obligations under article 11
of the Directive which require them to notify the Commission of any
additional requirements imposed in application of article 3.7 insofar as
these are a part of any voluntary accreditation scheme.
Target group: Member States
5.3.1.2 Security levels – legal qualification of signature types
For similar applications, Member States don’t necessarily require the same type of electronic
signature. It is perfectly possible that a similar application in one Member State is only based on user-
id/password protection while another Member State requires qualified electronic signatures for the
same type of transaction. One question is whether Member State should remain entirely free to
determine independently from each other the security level of signatures in their e-government
applications. Is it acceptable that public procurement transactions can be signed with user-
id/password based electronic signatures in one country while other countries require qualified
certificates and SSCDs in this context?
It is probably not possible – but perhaps also not necessary - to harmonise the security level of
electronic signatures for each type of application. Does this mean, however, that every company and
105
November 2007
individual in every Member State will eventually need to have a complete set of electronic signature
facilities (at least including a qualified electronic signature facility)?
Similar to the issue noted above, the principle of subsidiarity and the public sector clause jointly imply
that Member States have the right to determine in principle which security level they require for each
specific application type (again, keeping in mind the limitations to this freedom in the public sector
clause, and also keeping in mind other and more far reaching harmonisation initiatives for specific
application types (such as the signature requirements for electronic invoicing). This right of the
Member States to autonomously determine the importance and security risks for each application and
the resulting signature requirements does not need to present any specific problem.
However, a larger concern is the current impossibility of ‘mapping’ non-national signature solutions
into a given security category. I.e., when presented with a non-national signature solution, a Member
State will typically have no way of determining how the signature was issued in the state of origin, and
therefore what kind of security/ reliability it provides. The issue then becomes a matter of trust in non-
national registration authority (RA) policies.
Apart from the recommendation above (reminding Member States of their obligations to notify the
Commission of restrictions in their e-Signature applications, which would result in a substantial
overview of accepted CSPs abroad), it is therefore important to inform application owners of the
signature solutions offered in other countries, and to take note of their obligation in principle to ensure
compatibility with equivalent signature solutions (RECO2). The final and long term goal would be to
enable application owners to define the signature needs of their applications in terms of a
security/reliability level, such as the appropriate legal classification under the eSignatures Directive,
rather than by assessing individual CSPs on a case by case basis. In short, application owners should
be able to shift from the current situation of ad hoc decisions for each application to a system where
they require a certain security/reliability level, rather than a specific certificate or CSP. (RECO3)
RECO2 Application owners should take note of signature solutions being used in
other countries as identified by this study, and be made aware of their
obligation in principle not to exclude foreign signature solutions
whenever possible, unless specific considerations meeting the criteria
of the public sector clause would permit this.
Target group: eGovernment application owner
RECO3 Application owners should be advised to shift from the current situation
of ad hoc decisions for each application, to a system where they require
their users to employ a certain security/reliability level, such as the
appropriate legal classification under the eSignatures Directive, rather
than a specific certificate or CSP.
106
November 2007
5.3.1.3 European eSignature directive compliance
Many Member States require certificates issued by “recognized” certification service providers. It is
questionable whether this is compliant with Article 3.1 of the European Directive 1999/93/EC, since
this could be construed as a requirement which is “de facto” equivalent to a prior authorisation.
There seems to be a need (on a Community level) for an operational interpretation of the “public
sector clause” (Art. 3.7) of the European e-signature Directive.
Consideration (10) of the e-Signatures Directive explicitly defines prior authorisation as ‘any
permission whereby the certification-service-provider concerned has to obtain a decision by national
authorities before being allowed to provide its certification services, but also any other measures
having the same effect.’ When jointly read with the public sector clause, it appears that the systematic
restriction of access to public sector services to the potential clients of specific certification service
providers which are largely inaccessible to non-nationals is contrary to the goals of the Directive.
None the less, it should also be acknowledged that this situation within the Member States does not
appear to result from a desire to shield certain (national) CSPs from competition or to otherwise
restrict the free movement of services, but rather from the legitimate need to ensure that their
services are sufficiently secured against misuse. Furthermore, it is also true that no operational
solution for the cross border validation of electronic signatures originating from a virtually unlimited
number of CSPs has been put in place, and that Member States can hardly be faulted for not
developing such solutions.
Thus, it is our opinion that, while the present national situation is at odds with the goals of the
Signatures Directive, this cannot be considered a material violation of the Directive’s ban against
prior authorisation schemes.
No further steps are in our opinion recommended at this stage for this particular issue.
5.3.1.4 Ad-Hoc solutions
Not all Member States have adopted a general all-encompassing central strategy with regard to
electronic signatures in e-government applications. There are many ad-hoc solutions and regulations
in this domain. This fragmentation can possibly hinder future interoperability initiatives.
This might be a temporary issue. In most of the surveyed countries the sectoral “ad hoc” approach
seems to be a first phase in the development of transactional e-government services. Sectoral “ad
hoc” solutions are implemented because there is not yet a clear strategy on the national level.
107
November 2007
In our opinion, no corrective action in this regard is necessary. While it is true that national diversity
between e-government applications currently exists and will likely continue to exist for some time, it is
important to note that all Member States acknowledge that a lack of internal interoperability is a
serious handicap that needs to be eliminated. In short, while the existence of ad hoc solutions can be
a barrier to cross border interoperability, Member States are by and large acting to remedy this
situation, so that no further action seems necessary.
It should also be noted (as has been stressed in section 4.1.2.1.3 and 4.1.2.1.4 above) that ad hoc
solutions in some cases have been inspired and are maintained by a conscious decision to implement
a solution that most closely meets the needs of a (typically limited and specialised) user base. In such
cases, it has been deemed more important to cater to the needs of the actual user group, rather than
to implement a generic solution which is of little use to the vast majority of the users of this solution.
In our opinion, such restrictive practices are in compliance with the public sector clause, since the
requirements are ‘objective, transparent, proportionate and non-discriminatory and [...] relate only to
the specific characteristics of the application concerned’ (article 3.7 of the Directive).
5.3.1.5 Multiple government levels
Usage of electronic signatures in e-government applications is not only regulated and organised on a
national level but often on a regional or local level. This factor should be taken into account in future
interoperability initiatives in this area.
Priority might be given to the promotion of interoperability of e-signatures in e-government

applications at the national level. The current solutions at regional and local levels might also
progressively adapt to national strategies and solutions in a further stage of development.
As the decentralisation of certain competences is a legal reality in many Member States, specific
initiatives in this field are neither warranted nor necessary. For interoperability purposes, it is
sufficient to ensure that the Member States are aware that any obligations in the Directive and any
recommendations in this report which are directly incumbent on them also affect any decentralised
administrations in the same manner. In other words, Member States must ensure that their
decentralised administrations observe their duties equally. (RECO4)
108
November 2007
Member States should be made conscious of the fact that their possible
national decentralisation of competences does not absolve them of their
obligations of adhering to the eSignatures Directive’s provisions, which
RECO4 includes the obligation of ensuring that local governments adhere to this
framework.
Target group: Member States
5.3.1.6 National rules on identifiers
Electronic signatures are frequently linked to national unique identifiers. They are used to initiate the
process for the application of a certificate or inserted in the subject field of the certificate. The
processing of these unique identifiers is sometimes strictly regulated (e.g. reserved for designated
authorities or service providers). The current national rules in this domain don’t take into account
processing by public authorities or service providers of other Member States.
Solutions have to be developed in the framework of e-ID interoperability. These will most probably
include legislative amendments in some of the surveyed countries.
5.3.1.7 Conclusions
From a pragmatic perspective, the two most significant legal issues are the national perspective in
signature solutions, and the difficulty of ‘mapping’ signature security requirements.
The first issue is the most fundamental one: when making eSignature applications available, the rules
regarding its use (regardless of the form they take) typically specify that only one or several specific
signature solutions are acceptable, to the exclusion of any others, with the chosen solutions typically
only being practically available to users residing or established within that country’s borders. This
practice is tantamount to prior authorisation, as it excludes any other signature solutions (which
almost invariably includes all non-national solutions), regardless of their reliability and security
requirements. In other words: signatures are not accepted or rejected based on their actual merits, but
based on a policy decision. While this policy decision is usually based on valid pragmatic
considerations (particularly the existence of an interoperable validation and assessment mechanism
for non-national signatures), this practically makes signature interoperability impossible.
The second problem goes to the underlying reason for these restrictions: even if Member States want
to accept non-national signature solutions, they are presently required to assess their security on a
case-by-case basis. This is an impossible task from a practical perspective, as it would require
application owners to verify the procedures and guarantees for the issuance and management of
foreign electronic signatures and see if they meet the requirements of their specific applications.
Specifically for non-qualified signatures (where legal equivalence to handwritten signatures is not a
given) this is a nontrivial problem, since no clear criteria for the determination of security levels exist.
The other identified issues are of lesser importance for the realisation of eSignature interoperability,
as they can mostly be resolved by providing a solution to the two key issues above.
109
November 2007
5.3.2 At Organisational level
5.3.2.1 Link to eID schemes
Usage of advanced electronic signatures is often closely linked to national identity management
scheme(s). Signature certificates are mostly issued in combination with authentication certificates
and follow the same rules and procedures. Every Member State organises its identity management
scheme(s) in a completely independent way; only where it is strictly necessary the Member States
establish solutions for non-nationals. Often (but certainly not always) these solutions require
certificates issued by local certification service providers or even an establishment or a legal
representation on the territory of the Member State.
Interoperability issues might to a certain extent more or less “automatically” is solved with the
progression in the area of mutual recognition or harmonisation of e-ID schemes.
The issue of identifiers is strictly speaking an issue of identity management, which does not fall
directly within the scope of this study. None the less, it can be noted that the Member State take
vastly different approaches to unique identifiers, and that the legal regimes applicable to them vary
equally. This can have a significant impact on the use cases of electronic signature solutions (e.g. in
the case of sector specific identifiers, which are designed to be meaningless outside of their context).
Given that these choices are largely the consequence of conscious and legitimate policy decisions,
further harmonisation with regard to the choice of identifiers seems undesirable and outside of
European regulatory competence.
The issues of identity management and electronic signatures are tightly interwoven, given that the
functional use of electronic signature typically depends on the reliable identification of the signatory
(without which the signature is of little use or value). However, in practice signatures are often
incorrectly used by requiring identifiers which are only available to nationals, thus excluding any
possibility of interoperability with foreign signature solutions. This should be discouraged (RECO5)
unless warranted under the terms of the public sector clause or unless the potential user group of the
application is indeed limited to entities who can reasonably obtain a credential with the required
identifier. Application owners should be made conscious of the interoperability consequences of
requiring the use of identification attributes in signatures which are only available within their country.
As a general rule, applications should not require that electronic signatures provide access to specific
identity information which foreign signatures would not be able to provide, unless this specific identity
information is strictly necessary for the proper functioning of the application.
In a more general sense, when determining the requirements for e-signature applications, application
owners must ensure that the signature requirements are not abused to add functionality which is
unrelated to the signature functionality itself (RECO6), such as automatically filling out identity
information such as names and register numbers, unless an alternative can be offered to users whose
signatures may not include the required information. In other words, while there is of course no
objection against using electronic signatures to add functionality beyond the traditional functions of a
handwritten signature (such as consent, non-repudiation etc.), applications should not make such
added functionality mandatory when this has the unintended side effect of making the use of foreign
signature solutions impossible.
110
November 2007
Application owners should be made conscious of the interoperability

consequences of requiring the use of identification attributes in
RECO5 signatures which are only available within their country.
When determining the requirements for e-signature applications,

application owners must ensure that the signature requirements are not
abused to add functionality which is unrelated to the signature
functionality itself when this would impair interoperability. There is no
objection against using electronic signatures to add functionality (such
as automatically filling out identity information or automated error
RECO6 correction) beyond the traditional functions of a handwritten signature
(such as expression of consent, non-repudiation etc.); however,
applications should not make such added functionality mandatory when
this has the unintended side effect of making the use of foreign
signature solutions impossible, unless an alternative can be offered to
users whose signatures may not offer the added functionality.
5.3.2.2 Mutual recognition
As a general rule, in all cases where Member States require a certificate issued by an accredited
certification service provider, it should be irrelevant by which Member State the certification service
provider has been accredited. A certificate issued by a certification service provider and accepted for
e-government transactions in one Member State, should, as a general rule, automatically be accepted
for similar e-government transactions in other Member States.
Currently most of the countries keep their own list of “recognized” service providers and these lists
only contain service providers established on the national territory. Examples, such as the Czech
CSP on the Slovakian list of “supervised” CSPs are very exceptional.
Accreditation schemes use evaluation profiles with determined security levels and requirements. One
solution could be to agree on a set of “model” evaluation profiles and on essential qualifications for
accreditation bodies which have to apply these profiles in order to perform conformity assessments
for certification service providers.
See section 5.3.1.2 above for recommendations on this issue.
111
November 2007
5.3.2.3 Atypical registration procedures
One of the most difficult problems with regard to interoperability is how to combine the sometimes
radically divergent approaches adopted by Member States in terms of security requirements and
trust. For example: Denmark doesn’t require registration based on in persona appearance for the so-
called OCES-signature, which is commonly used in Danish e-government applications. Even if this
process would meet the eSignature Directive’s requirements imposed on qualified certificates22, other
Member States may be reluctant to accept the resulting signature as adequate. This is especially true
when, as in the Danish case, the resulting signature is emphatically not considered a qualified
signature, so that it is not covered by the Directive’s equivalence provisions. This makes the Member
States’ choice of whether or not to accept the resulting signature largely political, and will inevitably
imply that Member States also take into consideration whether or not their own proposed signature
solutions require registration based on in persona appearance. Other example: In Finland the FINEID
offering both signature and authentication functionality, and TUPAS only offering authentication, are
commonly supported, without any clear system of preference. Can this flexibility be exported to other
Member States?
This discussion is closely linked to the one on European interoperability of e-ID schemes. One
approach is “mutual trust” whereby Member States trust each other’s registration procedures (even if
they are not based on physical presence). The other approach is to define a limited set of “trust
levels”. The latter solution can however lead to a situation whereby large groups of users from certain
Member States are excluded from (a major part of) the e-government applications in other Member
States.
Multiple solutions could be envisioned for this problem. While there are several theoretical models to
solve the technical issues in relation to the validation of signatures (i.e. the technical difficulty of
validating a certificate), none of these solve the more complicated issue of determining the
security/reliability of a non-national signature (i.e. the difficulty of determining the trustworthiness of a
signature solution). To solve the latter problem, the use of trust lists is often suggested (see below for
a discussion on this).
Provisionally however, the creation of a cross border validation model which enables the validation of
non-national electronic signatures certificates without determining their security/reliability is a useful
first step in its own right. (RECO7) Once a suitable cross border validation model has been put into
place, Member States would at a minimum have the ability of assessing the reliability of selected
non-national CSPs and deeming them acceptable for the purposes of their application. While this
does not necessarily meet the trust requirements of each specific application, this creates a first
infrastructural building block for the exchange of electronic signatures.
Thus, it is recommended that a pan-European signature certificate validation platform model is
developed to resolve the issues of certificate validation and the issue of creating trust between
existing CSPs. Such a platform would allow non-national PKI certificates to be validated in any
country. The functionality of this platform could at an initial stage be limited to certificates that are
considered qualified in the Member States, as there is less margin for national policy in this field.
22
And specifically Annex II, point d), which states that the identity of the certificate holder must be
verified ‘by appropriate means in accordance with national law’, which need not necessarily exclude
registration processes concluded fully at a distance.
112
November 2007
Given the legal status of qualified signatures as equivalent to hand written signatures, and provided
that a functional validation platform could be established, the prerogative of Member States to reject
non-national signatures based on qualified signature certificates would be reduced (especially in the
case of qualified signatures, where the rejection could only be justified based on a strict interpretation
of the criteria of the public sector clause).
In a second phase, the issue of RA assessment could be dealt with more methodically, relying e.g. on
the information yielded by the notification procedure of article 11 of the Directive, which should
contain the CSPs accepted by the Member States for their applications which are not inherently open
to non-national solutions.
However, the creation of such a validation platform could meet with a number of legal objections. It
should be noted that article 4 of the e-Signatures Directive emphatically embraces the principle that
the internal market for certification services should be permitted to operate freely, and that Member
States should not intervene in the provision of such services within the internal market:
“Article 4 – Internal market principles

1. Each Member State shall apply the national provisions which it adopts pursuant to this
Directive to certification-service-providers established on its territory and to the services which
they provide. Member States may not restrict the provision of certification-services originating
in another Member State in the fields covered by this Directive.
2. Member States shall ensure that electronic-signature products which comply with this
Directive are permitted to circulate freely in the internal market.”
An intervention on a European level (with a Member State mandate) could be seen as being at odds
with this restriction, as it implies indirect Member State intervention in a nascent market where private
sector parties have indeed begun to examine the possibility of rolling out cross country validation
services. Private sector certification service providers are aware of the difficulties in relation to cross
border validation. They have taken a number of initiatives to explore this market inefficiency and are
considering the research of specific solutions23. If this trend continues, the development of a signature
validation platform which operates on a European scale with a Member State mandate could be
interpreted as a violation of the free internal market provisions of the Directive. In our opinion, the
creation of such a platform should at a minimum be preceded by a consultation of the Member States
on the main policy and legal issues arising as a result of the introduction of a pan-European validation
platform (RECO8), specifically:
• The question could be raised whether or not the establishment of a validation platform
violates the provisions of article 4.1 of the Directive, and specifically whether the acceptance
of a common pan-European validation platform should be considered to be a restriction
imposed by the Member States on the provision of certification services originating in another
Member State Strictly speaking, this could be found to be the case, as the acceptance of
such a platform would deny the market of cross border validation platforms for e-government
applications to any other CSP currently developing solutions in this field (and might cause
financial harm to any CSP who have already made investments in this direction). However,
one might also support a narrower interpretation of article 4.1, and argue that a pan-European
validation platform is not at odds with the free market principles, because the main goal of the
clause is to restrict Member States from imposing restrictions on certificate services which
would hinder foreign service providers in gaining access to their markets. In contrast, a pan-
European platform would be established through common consensus between the Member
23
E.g. Det Norske Veritas has initiated some work in this field; see Report No. 2005-0673, Revision
No. 01, www.dnv.com/ict/va/va.asp
113
November 2007
States, and would thus not be an attempt from one Member State to shield its market from
foreign competition. One could additionally argue that a validation platform is not a service
‘originating in another Member State’ as described by article 4.1, since it would operate under
a joint mandate from the Member States, and thus be common to all of them and foreign to
none. As such, one might argue that the hypothesis of a validation platform established
consensually by the Member States acting jointly is not covered by article 4.1., since it is not
an attempt to shield national markets from foreign competition, but rather an attempt to open
them.
• The question could be raised whether or not the establishment of a validation platform
violates the provisions of article 4.2 of the Directive, and specifically whether the acceptance
of a common pan-European validation platform should be considered to be a restriction
imposed by the Member States on the free circulation of certification services in the internal
market. Consideration (10) of the Directive clearly states that ‘The internal market enables
certification-service-providers to develop their cross-border activities with a view to increasing
their competitiveness, and thus to offer consumers and businesses new opportunities to
exchange information and trade electronically in a secure way, regardless of frontiers; in
order to stimulate the Community-wide provision of certification services over open networks,
certification-service-providers should be free to provide their services without prior
authorisation; prior authorisation means not only any permission whereby the certification-
service-provider concerned has to obtain a decision by national authorities before being
allowed to provide its certification services, but also any other measures having the same
effect.’ Again, from a strict perspective one might consider that the internal market for cross-
border signature validation in e-government application could be harmed through the
establishment of a common validation platform, i.e. that this would constitute a measure
‘having the same effect [as prior authorisation]’. However, again it would also be possible to
consider the definition of the internal market from a more narrow perspective, by considering
that the common validation platform would only target e-government applications, but leave
e.g. private sector applications which also require cross-border validation unaffected. CSPs
would therefore still be able to develop their services for the broader cross-border validation
market, and it is indeed not unthinkable that such services in time would come to replace the
pan-European validation platform if and when private sector initiatives are capable of meeting
public sector requirements. From that perspective, cross border validation services for public
sector applications only could be likened to a certification service affecting only a closed
network, which would render article 4.2 inapplicable in accordance with Consideration (10)
quoted above (‘to stimulate the Community-wide provision of certification services over open
networks’).
• Should Member States argue against the more flexible interpretation of article 4 that has
been summarily illustrated above, they should consider what encouraging actions could be
taken to stimulate the private sector to accelerate the development of services which would
offer the same service levels as such a pan-European validation platform.
• Finally, if any action is taken by the Member States to create a pan-European validation
platform, the liability implications should be taken into account. While the validation platform
would not issue qualified certificates as such, one of its key functions is to guarantee a
certificate’s validity and value to a relying party. As a result, article 6.1 of the Directive would
apply;
“Article 6 - Liability 1. As a minimum, Member States shall ensure that by issuing a
certificate as a qualified certificate to the public or by guaranteeing such a certificate
to the public a certification-service-provider is liable for damage caused to any entity
or legal or natural person who reasonably relies on that certificate:
(a) as regards the accuracy at the time of issuance of all information
contained in the qualified certificate and as regards the fact that the certificate
contains all the details prescribed for a qualified certificate;
114
November 2007
(b) for assurance that at the time of the issuance of the certificate, the
signatory identified in the qualified certificate held the signature-creation data
corresponding to the signature-verification data given or identified in the
certificate;
(c) for assurance that the signature-creation data and the signature-
verification data can be used in a complementary manner in cases where the
certification-service-provider generates them both;
unless the certification-service-provider proves that he has not acted negligently.”
Depending on the exact implementation and scope of the pan-European validation authority,
the application of these provisions will vary. If the services of the validation platform would
only span public sector application owners, relying parties would be limited to public sector
entities, which could simplify the negotiation of suitable liability agreements between the
Member States at the time of the platform’s creation.
It is clear for all of these issues that a positive interpretation that would welcome a pan-European
validation platform could potentially have a distorting impact on the further development of the
internal European market for certification services. Therefore the opinion of the Member States on
these issues should certainly be sought through a formal consultation (RECO8).
It is recommended that a pan-European signature certificate validation

platform model is developed to resolve the issues of certificate
RECO7 validation and the issue of creating trust between existing CSPs. Such a
platform would allow non-national PKI certificates to be validated in any
country.
Target group: Member States.
Because of the internal market provisions of the Directive, the creation

of pan-European validation platform should at a minimum be preceded
RECO8 by a consultation of the Member States on the main policy and legal
issues arising as a result of the introduction of such a platform.
Target group: European Commission and Member States
5.3.2.4 Multiple speeds
Electronic signatures in e-government applications are in permanent evolution but not all Member
States are progressing at the same rhythm. In a majority of the Member States individuals and
citizens don’t yet have the means to create and validate advanced electronic signatures.
115
November 2007
A European strategy for a better interoperability of e-signature solutions in the area of e-government
services should not necessarily follow the speed of the slowest. Pilot solutions can be proposed in
which – at least for a certain time – only the most advanced countries participate.
This specific issue does not require additional measures. It should be noted that Member States at
this time are in principle not required to offer e-Government services using a specific electronic
signature, and that there is thus no specific consequence if the users of a given Member State do not
possess the required means to use e-Government applications. While the development and
deployment of e-Government services is a policy priority in all Member States, the provisional lack
thereof does not present insurmountable difficulties. However, it is useful to reiterate that the Services
Directive will remove this freedom not to offer e-Government/e-Signature solutions to some extent,
since it requires Member States to provide single points of contact for service providers where they
can complete all procedures and formalities relating to access to a service activity and to the exercise
thereof at a distance and by electronic means (article 8). While the use of electronic signatures is not
strictly a requirement, it is difficult to imagine a Member State complying with its obligations under
this article without implementing at least some form of electronic signature.
Thus, this problem will receive significant attention in the coming years, as Member States will be
legally required to deploy functional electronic single points of contact.
Provisionally there seems to be neither a ground nor a need for further action in this field.
5.3.2.5 Conclusions
The first three issues are closely interrelated and form the crux of the organisational difficulties
surrounding the creation of eSignature interoperability, namely the question of how to create trust.
A first issue is the fact that eSignature functionality is largely dependent on being able to determine
who the signatory of any given signature is. If this cannot be determined unambiguously, the
signature is of little practical value, as it cannot fulfil the function of linking a text to its signatory.
From this perspective, the reliance on specific identifiers which are often meaningless in a foreign
context (e.g. national register numbers) offers limited value. Thus, one of the key issues in the use of
electronic signatures is that any relying party must be presented with enough information to identify
who has actually signed the underlying document. In the absence of an identity number which has
international value, recipients are usually forced to rely on a set of identity attributes which is
presented to them. However, there is no consensus on when such a set of identity attributes is
sufficient to consider someone identified. A signature from an unidentified origin has no value.
The issue of atypical registration procedures is closely linked to this. Even when a sufficiently
complete set of identification data can be presented to uniquely identify a signatory, the recipient
must still be able to rely on it, i.e. she must know with acceptable certainty that this information is
correct and factually originates from the entity claiming the attributes. This means that the relying
party must be able to confide in the registration procedures which preceded the allocation of an
electronic signature solution to a specific entity. This is a complicated matter in an international
116
November 2007
context, as there are no uniform practices or standards which can be used to judge the reliability of an
eSignature solution. In order to accept a foreign signature, an application provider would therefore
have to assess these procedures on a case-by-case basis, which is unmanageable from a practical
perspective.
The question of mutual recognition encompasses both of these aspects: application owners presently
have no way of determining which signature solution providers meet the security and reliability
requirements of their applications. At least for nonqualified signatures, this is a key problem that
transcends the technical issues of interoperability.
The other identified issues are of lesser importance for the realisation of eSignature interoperability,
as they can mostly be resolved by providing a solution to the three key issues above.
5.3.3 At Technical level
5.3.3.1 Incompatible use of identifiers
This issue concerns signatures based on certificates where the application requires the certificate to
contain a specific National/Sectoral/Regional unique number.
As already mentioned in the paragraph Choice of Unique identifiers this is a legal barrier for a full
interoperability at the European level but this is also a technical and organisational problem.
There is a clear need for application to identify the signatory of a document in order to start a
workflow processing of the document. In most of the cases that have been analysed (see section
4.2.2.3.2.1), eGovernment applications have chosen to impose their constraints on the certificates
used for signing. Indeed, for eGovernment applications, the easiest way to achieve signatory
identification is to insert a unique identifier in the certificate. This identifier is analysed by the
application during the signature validation process. If the expected identifier is not found, applications
simply stop their processing and reject the signature.
applications
“The main identification information concerning the user is included in the certificate (including name,
address, uniform citizen number (UCN) or uniform identification code of BULSTAT, grounds for
representation etc.). The application extracts the identification data in order to identify the user from
the certificate, but not from the declared data. If the UCN or the BULSTAT codes are not available in
the certificate, the system will not accept the certificate.”
Italy “PCTT (Processo Civile Telematico)” application:

“Person ID number (“Codice Fiscale”), used to uniquely identify the subject”
UK “OGTS (Oil & Gas Trust Scheme)” application:

“Subject – Organisation Unit” should hold an additional indicator (OGTS) after the entry to identify that
the certificate has been issued in accordance with the Oil and Gas Trust Scheme, e.g. DTI (OGTS)
117
November 2007
The “Oil & Gas Trust Scheme“ application is very typical: users can obtain their electronic certificate
from any Certification Service Provider, even those installed outside UK, but the certificate must
contain a specific value in one of the certificate field (“Subject – Organisation Unit” should hold an
additional indicator (OGTS) after the entry).
Such common practices have a great impact on the possible interoperability of the application. Prior
to be interoperable, i.e. opened to anyone able to respect legal signature requirements (e.g. use of
qualified signature), the application must modify its processing to allow use of certificates that do not
contain unique identification number.
From our analysis, 26 applications are concerned by this issue (see table below) but among the 26
only 5 applications declare to be opened for non-national person.
118
November 2007
Open to non-
national
Belgium Tax-on-Web (http://www.taxonweb.be) No
Online submission of annual income tax declarations No
VAT on Internet No
Bulgaria Social security declarations on Internet No
eGovernment portal of the Bulgarian government No
ePortal of the Employment Agency No
ETHICS No
TastSelv Borger No
Denmark
Virk.dk – a government portal for Danish businesses No
Provide the Application/Service Name: Netborger.dk No
Lomake.fi public sector online forms service Yes

Finland
ElmaTYVI Pro at http://tyvi.elma.fi No
Ireland Revenue On-line Service ROS Yes

The
Elektronische aangifte Yes
Netherlands
Poland e-GIODO (http://egiodo.giodo.gov.pl) No
e-Taxes (http://edavki.durs.si) No
Intrastat (http://intrastat-surs.gov.si/) No
Slovenia
One-Stop-Shop - State Portal for businesses
Yes
(http://evem.gov.si)
Development IS on waste management field. No
Spain Taxes at Virtual Office No
Registro Telemático (Online Registry) No
PROFIT Política Industrial (AVANZ@) No

Sweden Yes
Telemaco, Signed Electronic Filing for Business Entities –
No
Italy Balance Sheets
PCTT (Processo Civile Telematico) No
Czech Republic Tax-on-Web (http://adis.mfcr.cz/adis/jepo) No
119
November 2007
The use of unique identifier “legal – organisational – technical” problem addressed in paragraphs
Choice of Unique identifiers and Incompatible use of identifiers is an interoperability problem.
Nevertheless the analysis of the survey has found 90 applications that make use of eSignatures.
Among these 90 applications 26 require a unique identifier to be present in the certificate and among
these 26 only 5 applications have been assessed as opened to non-national person.
This issue concerns signatures based on certificates where the application requires that a specific
field of the certificate contains a specific National/Sectoral/Regional unique number because there is
a clear need for application to identify the signatory of a document.
The easiest and most often used way to achieve this is to insert a unique identifier in the certificate
but this has a great impact on the possible interoperability of the application.
In the paper-based world, identification data on official documents (e.g. tax declaration) are part of
the document itself (specific fields) and are certainly not deduced from the handwritten signature.
Why should this be different in the electronic world?
Even if, strictly speaking, the issue “use of incompatible identifiers” is an issue of identity
management, which does not fall directly within the scope of this study, and in order to avoid building
barriers to interoperability, we recommend avoiding the mandatory use of a specific identifier in the
certificates.
Indeed, we recommend that application owners allow their users to duplicate the paper-based world
approach: the unique number required by the application to identify the citizen/business should not be
a mandatory part of the signature/certificate. (RECO9).
It could, for example, be part of the document being signed, e.g. by filling it in either by the
citizen/business before the signing process or automatically filled in by the application after the
authentication process of the citizen/business.
Obviously, there is a drawback as soon as the signed document will have to be exchanged between
Member States. In such situation, there is an additional strong need that the format of document is
standardised. Although defining interoperable document formats does not fall directly in the scope of
this study, we suggest to take into account the common specifications developed by the eDoc Pilot24
within CIP (Competitiveness and Innovation framework Programme)25 which directly addresses
mutual recognition and interoperability of electronic documents.
RECO9 The unique number required by the application to identify the

citizen/business should not be a mandatory part of the signature/certificate.
24
eDoc Workshop, 18 April 2007, Brussels,
http://ec.europa.eu/information_society/activities/ict_psp/library/call_docs/docs/edoc_workshop_report
_v3_2.pdf
25
Available at: http://ec.europa.eu/information_society/activities/ict_psp/index_en.htm
120
November 2007
5.3.3.2 Signature Type
To achieve the full interoperability, applications of a given Member State shall accept signatures
generated by the credentials of any natural/legal person of the EU.
Concerning the signature type the survey shows that:
• There is no simple signature based on PKI solution.
• All advanced and qualified signatures are based on PKI solution.
The question to answer is: can a person, with a given type of signature provided by its own national
credential, use it to sign documents in another country. The following table illustrates this problem.
Destination application requirements in country B
Simple Advanced Qualified

Simple signature are specific to an
Person in Country A -
Simple application
Signature Type
or a National Framework
Advanced Possible
Qualified Possible Possible
Signature Type interoperability
A simple signature (non PKI based) can’t be used where PKI based (advanced or qualified signatures)
are requested due to the fact that validation processes are not the same. The opposite situation leads
also to a non-interoperability situation.
The simple signature interoperability requirement has not been observed. The simple signature is
application specific or supported by a National framework (not designed for interoperability).
Other type of signature (all PKI based) can be compatible with the application requirements.
The case where the signatory is provided with an Advanced Signature and where the eGovernment
application requires a Qualified Signature, leads to an issue. Indeed, in such cases, eGovernment
applications should reject the eSignature because it is not valid from a legal perspective. However, it
has limited technical means to verify that the eSignature has been created or not by a SSCD:
• Either by limiting the CSPs to a (reduced) list of CSP that issue certificates where the related
private key resides in a SSCD.
This is the way followed today by many eGovernment applications. It is however a barrier to a
full European interoperability;
• Or via the use of the Qualified Certificates Statements "qCStatements extension", defined in
121
November 2007
RFC 3739. Indeed, CSPs claiming to issue certificates where the private key related to the
certified public key resides in a Secure Signature Creation Device (SSCD) MAY use this
optional statement. In that case, this optional statement contains an Identifier of the
statement (represented by an OID), made by the CSP, stating that the private key associated
with the public key in the certificate is stored in a Secure Signature Creation Device
according to Annex III of the EU Directive 1999/93/EC, as implemented in the law of the
country where the CA is established.
Unfortunately, the Qualified Certificates Statements are optional. Furthermore, apparently

only Spain and Austria seem to make use of them.
As shown previously (see section 5.3.3.2), interoperability is very complicated to achieve between
simple signature solution which are not PKI-based and advanced or qualified signature which are all
PKI-based solutions.
Therefore, application owners should be recommended to make use of PKI-based signatures in
applications where interoperability in the short term is a key objective (RECO10). PKI-based
signatures might not be the only possible answer but, as of today, it is, without contest, the most
widely used solution that offers potential for interoperability.
However, using PKI-based signature does not solve the issue that an eGovernment application
requiring a qualified signature has technically no means to verify that the signature provided fulfils its
requirements. Nowadays, this issue is solved at the organisational level: eGovernment applications
requiring qualified signatures only accept signatures based on qualified certificates issued by CSPs
they trust. To solve the issue at a European level, we recommend relying on a Federated Validation
Authority model, as described at section 5.3.3.7.3.4.
We recommend also that qualified certificates issued by European CSPs comply with the “Qualified
Certificate profile”26 and, in particular, make effective use of the Qualified Certificates Statements
"qCStatements extension" as proposed by the ETSI Technical Specification. (RECO11).
26
ETSI: “Qualified Certificate profile”, ETSI TS 101 862, V1.3.3, January 2006
122
November 2007
RECO10 Application owners should be recommended to make use of PKI-based

signatures in applications where interoperability in the short term is a key
objective
RECO11 Compliance with ETSI Qualified Certificate profile is recommended.
5.3.3.3 Dedicated Interface requirements
A factor limiting interoperability at the technical level is applications requiring specific non-
standardised interfaces to be installed on the user’s workstation prior to sign a document.
Here we don’t talk about the middleware necessary to ‘drive’ the token containing the credentials
necessary for the signature (e.g. smartcard driver). Indeed, from an interoperability point of view,
every user is provided by his CSP with that middleware. This should be independent of the
eGovernment applications requirements.
Besides, there are 2 eGovernment applications that impose specific software to be installed on the
client’s workstation and which are therefore not opened for “Cross-border” access.

e-PDV (http://www.porezna-uprava.hr/e-porezna/ePDV.asp).
Croatia This application requires using dedicated software on the client’s workstation (57,9Mb)
that is only available for Microsoft Windows.
Publication system on public contracts – publication subsystem (eNotification)
Czech
Republic This application requires using dedicated software on the client’s workstation that is
only available for Microsoft Windows.
Applications using dedicated software
Among the 90 applications making the use of eSignature, 2 of them require specific software to be
installed on the client workstation. Moreover the software are only available for the Microsoft
Windows Operating System environment. Furthermore, to fulfil this requirement the user must have
the rights to install software which excludes the use of a workstation where the user has not the
credentials to do it (e.g. cyber café).
Imposing specific non-standardised interfaces to be installed is a clear barrier against interoperability
but limited to these 2 applications.
123
November 2007
5.3.3.4 Recommendations
In order to avoid imposing barrier against interoperability, eGovernment applications and CSPs
should use standardized interfaces or applications that are de-facto available on any platform.
Applications used for signing should be independent from the platform, such as Web Browsers.
Where standardized methods to sign a document exist - in fact no such standard for qualified
signatures with Web Browsers exists - the signature solution should use open interfaces based on
standard protocols and formats, (e.g. PKCS#11, HTTP, XML, etc) to not limit to specific platforms.
In any case, it is highly preferable that the client signature tool relies only on standardised interfaces
supported by every operating system to applications such as Internet Browsers. (RECO12)
It is also acceptable that eGovernment applications rely on de facto standard software (e.g. Adobe
Acrobat) to create their signatures. Such a solution is acceptable, even if it is less preferred when the
de facto standard software is vendor specific, which can potentially result in issues to manage
documents on the longer term, since readability is not guaranteed.
On the other hand, eGovernment applications that want to provide maximum interoperability within an
open environment should rely on CSPs that do not impose any specific non-standardised interfaces.
(RECO13)
5.3.3.5 Conclusions
The client signature tool should use standardized interfaces or

RECO12 applications that are de-facto available on any platform.
eGovernment applications that want to provide maximum

interoperability within an open environment should rely on CSPs that do
RECO13 not impose any specific non-standardised interfaces.
5.3.3.6 Signature format
Among the surveyed applications, many different types of signature formats have been found.
The majority of applications present XML documents/forms (23 over 58 eGovernment applications) to
the signatory and provides consequently a piece of program (Java applet or Active X) to sign it. In
those cases, the signature format used is most of the time based on XML-DSIG or XAdES (ETSI TS
101 903).
But, there are some applications (3) that make use of PKCS #7 (Cryptographic Message Syntax)
format. There is application that uses its own proprietary format.
Besides, there are also some applications (6) that are relying on Adobe Acrobat Reader to sign
documents.
124
November 2007
Having multiple signature formats in use across Europe does not constitute an interoperability barrier
as soon as the signed documents do not need to be exchanged from an application to another.
Anyway, even if this exchange of document has not yet been deemed necessary by application
providers, it seems obvious that it will be more and more requested in the future. At that time, making
use of common formats (e.g. XAdES as proposed by ETSI) will become a necessity.
To avoid issues linked to signature format recognition, we recommend to promote the use of
international standards. (RECO14)
Today, two main signature formats are emerging:
• CAdES (CMS Advanced Electronic Signature)27: defines a number of Electronic Signature
formats that build on CMS (RFC 3852) by adding signed and unsigned signature attributes ,
resulting in support for a number of variations in the signature contents and powerful
processing requirements.
• XAdES (XML Advanced Electronic Signature)28: set of extensions to XML-DSig29 making it
suitable for advanced electronic signature. While XML-DSig is general framework for digitally
signing XML documents, XAdES specifies precise profiles of XML-DSig for use with qualified
electronic signature in the meaning of European Union Directive 1999/93/EC. One important
benefit from XAdES is that electronically signed documents can remain valid for long periods,
even if underlying cryptographic algorithms are broken.
Promote the use of international standards (CAdES or XAdES) as

eSignature formats.
RECO14
Target group: European Commission, Member States, International
standardisation bodies
5.3.3.7 Signature validation
Most of the surveyed applications rely on the validation mechanisms provided by the CSP they trust
or on the validation mechanisms provided by their national framework. In any cases, they all are only
able to validate signature that have been generated by CSPs from their own country, i.e. the CSPs
that are accredited by their national accreditation authority.
27
ETSI: “Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures
(CAdES)”, ETSI TS 101 733, V1.7.3, January 2007
28
ETSI: “XML Advanced Electronic Signatures (XAdES)”, ETSI TS 101 903, v1.3.2, March 2006
29
W3C “XML-Signature Syntax and Processing”, W3C Recommendation, 12 February 2002
http://www.w3.org/TR/xmldsig-core/
125
November 2007
In general, eGovernment applications have been developed in that way because no trust relationships
exist with other CSPs but also because they want to limit the number of CSPs that they have to
interact with.
The limited number of CSPs currently supported by eGovernment applications is a major barrier to
interoperability. If every application would have to support all European established CSPs, the
situation will quickly become unmanageable. Indeed, at the European level, if we consider an
average of 3 CSPs per country, this would mean that every eGovernment application would have to
manage relationships with more than 80 CSPs!
5.3.3.7.2.1 Validation steps
In order to better understand the challenges that eGovernment application owners have to deal with
during signature validation, it has been found interesting to explain all the necessary steps of such
validation.
The signature validation process that must be implemented by every eGovernment applications is a
complex process composed of several steps:
1. Parsing and syntax checking of the signature;
2. Check the integrity of the signed data by:

a. Computing the signature using the same cryptographic algorithm parameters (hash
algorithm, signature algorithm, signature format and public key),
b. Comparing the newly computed signature to the attached signature. The validation
fails at this point if they are not the same
3. Check the validity of the certificate used to perform the electronic signature by:
a. Parsing and syntax checking of the certificate and its contents, including some
semantic checking like use of certificate compared to allowed use (key usage
extension) and presence of mandatory fields and critical extensions. Those checks
should be made in compliance with the common profile for X.509 based certificates
as defined by the ETSI technical specification TS 102 28030.
b. Determining CA trustworthiness:
i. Assessment that the CA is trustworthy, and that the quality of the certificate is
sufficient related to the intended use of the certificate;
ii. Validation of the CA’s signature on the certificate. This requires a trusted
copy of the CA’s own public key, either directly available, or obtained from
further certificates in a certificate chain.
c. Checking that the certificate is within its validity period, given by timestamps in the
certificate against the time of signing.
d. Checking that the certificate is not revoked, i.e. declared invalid by the CSP before
the end of the validity period. This is usually achieved thanks to the following
techniques: CRL or OCSP.
30
ETSI: “X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons”, ETSI TS 102 280
v1.1.1, March 2004
126
November 2007
In the case of certificate chains, the certificate validation process is even more complex
because the processing must be repeated for each certificate in the chain. Thus,
eGovernment applications are burdened with the overhead of constructing and validating the
certification paths.
Certificate chains occur when a CA is part of a trust structure where higher level or peer CAs
issue certificates for other CAs, and one or more such CA certificates must be processed
before reaching a CA that is directly trusted by the application.
4. If an advanced signature forms such as CAdES-T or XAdES-T has been used, then verify the
Time Stamp Token (TST) associated to the electronic signature,. This requires to:
a. Verify the integrity of the TST signature (see point 2 above);
b. Check the validity of the Time Stamping Authority (TSA) certificate used to sign the
TST (see point 3 above).
5.3.3.7.2.2 Issues
Syntactic parsing and checking of a certificate’s validity time are usually straightforward operations.
However, all other steps in the certificate validation processing more or less have problems related to
scaling, i.e. handling of certificates from a multitude of CSPs.
This is due to two main reasons:
• Trustworthiness of CA which is a complex process: assess assurance level, certificate
policies and certification practices statement; conduct annual audits; establish qualification
agreement (SLA, QoS …), etc.
• Lack of consistency in the semantic interpretation of certificate fields within various digital
certificate implementations. Not all European CSP give the same meaning to the same
certificate fields. Therefore, it is up to each application or national framework to develop:
– Ad-hoc parsing by “certificate type”,
– Specific OCSP/CRL connections,
– Ad-hoc syntax and semantic checks of certificates.
5.3.3.7.2.3 Good practice example
A very good example of efficient validation has been set-up in Spain. Indeed Spain also encountered,
at national level, the issues described at previous section, notably lack of certificate standardisation.
The MAP multiPKI Validation Platform (called Platform @firma v.5.0.) provides validation services of
the eCertificates and eSignature of the main recognised certification service providers to many
applications of eGovernment used by all Spanish public administrations (state, regional and local). In
nowadays this Platform holds 12 certification services providers31 and 69 types of eCertificates.
31
The list of authorities is available at
http://www.dnielectronico.es/seccion_aapp/rel_autoridades.html
127
November 2007
The way how Spain has solved the validation problematic would certainly be a good practice to take
into account at the European level.
Thanks to this multiPKI Validation Platform, the Spanish government has succeeded to achieve
eSignature interoperability at national level with a positive ROI. Furthermore, the multiPKI Validation
Platform is considered, in Spain, as key-enabler for eID
The current ROI, having in mind the technical investment and the number of transactions performed
by the service, shows the following balance:
- Investment during 2006 + 2007: 3,5 mill €
- Transactions already made: 3 million (end May 2007)
- Expected figures: 8,2 million transactions expected by the end of the first year.
- Cost per transaction at the moment: 0,43 €
This means a cost-effective service, much rational than a distributed structure with all public
administrations having to develop and implement SW modules to handle eSignature creation/
verification and certificates validations against all CSP in the country. A realistic assumption is to
estimate a total cost of 3 € per traditional administrative transaction, having to move physically to the
office (papercost, time spent by the civil servant, time spent by the citizen or business company…).
Taking into account the cost of investment for developing each eGov service, it appears quite a large
margin to assume that the ROI for the MPVP has already been met.
5.3.3.7.3.1 Introduction
Solving all issues bound to eSignature validation is a hard task to achieve and will require a lot of
time and effort to be solved. We strongly believe that the recommendation of setting-up a Federation
of Validation Authorities presented at section 5.3.3.7.3.4 is the solution that will help to solve many of
the eSignature validation issues presented in the problem description and assessment sections above
(see 5.3.3.7.1 and 5.3.3.7.2).
However, as we know that it will not be possible to set-up such Federation in the short-term, we
propose, as a step-wise approach, two alternative recommendations to solve the issue of verifying the
CSPs’ trustworthiness: publish a list of supervised CSPs (see section 5.3.3.7.3.2) and implement the
European Bridge/Gateway CA (see section 5.3.3.7.3.3).
Adopting one of these two recommendations will anyhow help eGovernment applications to reach the
interoperability they need and will be reusable as a building block by the Validation Authority
Federation.
All three recommendations are only valid is valid as long as PKI-based signatures are used (see also
section 5.3.3.2) (RECO15).
128
November 2007
5.3.3.7.3.2 List of supervised CSP
As depicted in the figure below, as a very first step for achieving CA trustworthiness, which is one of
the key elements of the signature validation process, we recommend publishing, on a central website,
a list of Certification Service Providers supervised32 by their respective national responsible body
(RECO16).
A similar principle has been adopted in the frame of the eEurope 2005 initiative
(http://ec.europa.eu/information_society/eeurope/2005/all_about/security/esignatures/index_en.htm).
With such list, eGovernment applications will, at least, be able to build trust relationships with the
CSPs present on the list. The drawback is that such list will only contain CSP providing Qualified
Certificates.
European Web site
Published List of supervised

CSPs by country
... ...
crl – ocsp crl – ocsp
Get certificate revocation status

eGov applications
eGov applications
Sign documents User

certificate Register users and
Register users and Provide credentials
Provide credentials
Sign documents User RA
RA User
certificate
certificate Sign documents
Country Y Country X
However, this basic solution does not provide all the functionality that an application would require.
E.g. there is no automatic mechanism to inform the application that a CSP has been excluded by its
national responsible body.
32
In the sense of Article 3.3 of the eSignature directive (cfr [RD3])
129
November 2007
5.3.3.7.3.3 European Bridge/Gateway CA
Another mean of achieving CA trustworthiness while solving issues raised by the list of supervised
CSP, is to implement the European IDA Bridge/Gateway CA33 (EBGCA) model (RECO17) that uses
the centralised administrative structure of a bridge, and distributes trust using both cross-certifications
and Certificate Trust Lists.
Indeed the EBGCA project has proven that the concept of a Bridge/Gateway CA is the most suited to
achieve CA trustworthiness at a European level.
As shown in the following figure, the EBGCA model will allow eGovernment applications to assess CA
trustworthiness using the so-called “Trust Service Provider Lists” (TSL). A Trust Service Provider List
is a way of securely transporting information about Trust Service Providers to the different
34
participants of the European IDA Bridge/Gateway CA. The framework of ETSI TS 102 231 is used
for the issuance and management of these Trust Service Provider Lists.
EBGCA
Root
TSLs CA
Root
Root
CA
CA
HTTP - HTTPS
Download TSL & Root CA
... ...
eGov applications
eGov applications Get certificate revocation status
Sign documents User

certificate Register users and
Register users and Provide credentials
Provide credentials
Sign documents User RA
RA User
certificate
certificate Sign documents
Country Y Country X
We remind that in order to be able to participate in the European IDA Bridge/Gateway CA, a
European Member State has first to sign the European IDA Bridge/Gateway CA Memorandum of
Understanding (MoU) as ruled by the “Certification Practices Statements for an operational EBGCA”.
This MoU contains a series of requirements that both the European IDA Bridge/Gateway CA and each
33
Europa - IDABC, Bridge/Gateway Certification Authority, September 2004,
http://europa.eu.int/idabc/en/document/2318
34
ETSI: “Electronic Signatures and Infrastructures (ESI); Provision of harmonized Trust-service
status information”, ETSI TS 102 231, V2.1.1, March 2006,
130
November 2007
European Member State Administration are required to meet to guarantee a sufficient level of
equivalence between the services provided by each Participating European Member State CA.
From a legal perspective, in order to apply the EBGCA model for generic eSignature applications, a
number of issues would need to be resolved, in addition to the aforementioned issues identified in
section 5.3.3.7.2.2 above.
First of all, the criteria for a Member State’s solutions to be included on a TSL should be elaborated.
As noted above, this has been done through a MoU. However, if multiple signature types (with
varying security levels) are to be integrated, it may be necessary to define multiple MoUs for each
signature level, with each Member States having to evaluate in which category their solution fits.
From this perspective, the likely result will also be different levels of Trust Service Providers, either
by including trust level information on a single TSL, or by simply creating multiple TSLs (one for each
trust level). Application owners could then choose to accept CAs registered on the appropriate TSL, n i
accordance with the requirements of the application. From a pragmatic perspective it may be useful
to initially restrict the scope of such an initiative to a single TSL containing only qualified signature
certificate CSPs.
A second issue would be determining the responsibility for the EBGCA, considering the potential for
liability. An EBGCA model may have only a limited appeal to Member State administrations if it
cannot offer any guarantees with regard to the reliability of the CA’s on its list(s). Similar to the
discussion in section 5.3.3.8. above, one of the key functions of an EBGCA model is to guarantee a
certificate’s validity and value to a relying party. At least with regard to trust lists containing qualified
certificates (which would certainly be a high priority), article 6.1 of the Directive would again apply;
“Article 6 - Liability 1. As a minimum, Member States shall ensure that by issuing a certificate
as a qualified certificate to the public or by guaranteeing such a certificate to the public a
certification-service-provider is liable for damage caused to any entity or legal or natural
person who reasonably relies on that certificate:
(a) as regards the accuracy at the time of issuance of all information contained in the
qualified certificate and as regards the fact that the certificate contains all the details
prescribed for a qualified certificate;
(b) for assurance that at the time of the issuance of the certificate, the signatory
identified in the qualified certificate held the signature-creation data corresponding to
the signature-verification data given or identified in the certificate;
(c) for assurance that the signature-creation data and the signature-verification data
can be used in a complementary manner in cases where the certification-service-
provider generates them both;
unless the certification-service-provider proves that he has not acted negligently.”
Again, suitable liability agreements would need to be drafted to determine the responsibility of a
EBGCA towards the Member States, the application owners (or other relying parties) and the
participating CSPs.
In addition, the same objections related to the possible disruption of the internal market could be
raised against an EBGCA model as against a validation platform, on the same grounds as described
in section 5.3.3.8. above, with the same potential justifications applying. Again, the opinion of the
Member States on these issues should be sought through a formal consultation (RECO18).
Finally, it is also clear that the choice of applicable law may prove to be politically sensitive, and may
also be important to determine the legal validity of any disclaiming clauses.
5.3.3.7.3.4 Validation Authority Federation
In our understanding, a technical solution that would answer many of the technical challenges that
eGovernment applications are facing is to set-up a ‘Validation Authority Federation’ (RECO19). In
131
November 2007
order to explain our model, we have decided to first present the services such solution should provide
to eGovernment applications. Some examples of similar implementations are presented in a second
section. Then a section will present the technical components that have to be set-up to provide the
described services. Finally, we will describe the interfaces that our solution will have to set-up towards
the various stakeholders.
5.3.3.7.3.4.1 Services
Prior to define what would be the Validation Authority Federation architecture, it has been deemed
necessary to present the various services that such solution would have to propose as a minimum.
5.3.3.7.3.4.1.1 CA trustworthiness
One of the key issues in the validation process described above (see section 5.3.3.7.2.1) is the
assessment of the CA trustworthiness.
When thinking at a European level, CA trustworthiness can be achieved by several known
techniques:
• Hierarchy: this would mean that a common root CA would be set-up at the European level
and would issue certificate to all subordinate CAs (i.e. every Member State CAs). Such
situation has already been rejected by Member States since it would give too much power to
the root CA that would be established at European level because it can force existing
members to trust certificates of a new member simply by certifying the new Member State’s
CAs, hence removing national control over trust35.
• Cross-certification (full mesh): the effort needed, particularly at the legal side, is very huge. At
the European level, considering 3 CAs per country, this would impose more than 3500
relationships to be set-up!
• Bridge-CA: is a more promising approach. At the European level, the European IDA
Bridge/Gateway CA36 has proposed a model that uses the centralised administrative structure
of a bridge, and distributes trust using both cross-certifications and Certificate Trust Lists.
In our Validation Authority Federation model, the CA trustworthiness is a service provided by the
Federation (in combination with the Bridge/Gateway CA model) to the eGovernment applications for
all European CSPs.
5.3.3.7.3.4.1.2 Certificate Validation
Apart CA trustworthiness, we strongly believe that a Validation Authority Federation would also need
to provide centralised certificate revocation status services to the eGovernment applications avoiding
each application to establish relationships with every CSPs throughout Europe.
This is one of the main services that our Validation Authority Federation model will provide to
eGovernment applications allowing them to off-load this complex and power consuming task.
Indeed, in order to validate a certificate, a chain of multiple certificates, called a certification path,
may be needed to be validated, comprising the certificate of signer, signed by one CA, and zero or
more additional certificates of CAs signed by other CAs.
For eGovernment applications, delegating certificate path validation to a trusted validation authority
can offer significant advantages. As stated in the RFC 337937: “the time required to send the target
35
See « A bridge CA for Europe’s Public Administrations - Feasibility study », IDA, Final Report, July
2002, http://ec.europa.eu/idabc/servlets/Doc?id=17267
36
Europa - IDABC, Bridge/Gateway Certification Authority, September 2004,
http://europa.eu.int/idabc/en/document/2318
132
November 2007
certificate to the validation server, receive the response, and authenticate the response, can be
considerably less than the time required for the application to perform itself certification path discovery
and validation. Even if a certification path were readily available to the client, the processing time
associated with signature verification for each certificate in the path might (especially when validating
very long paths or using a limited processor) be greater than the delay associated with use of a
validation server”.
5.3.3.7.3.4.1.3 Signature Validation
As a matter of fact, it could also be envisaged that a Validation Authority Federation provides
signature validation services, such as:
• Verification of the integrity of the signed data;
• Technical signature compliance, i.e. verification of the signature compliance to technical

standards (e.g. CAdES or XAdES);
• Compliance of the eSignature with regards to the eGovernment application policy. E.g.
cryptographic algorithm parameters (hash algorithm, signature algorithm, …).
5.3.3.7.3.4.1.4 Value-added services
In addition to the previous traditional services that would be expected from a Validation Authority,
there are various value-added services that could be provided, e.g.:
• Certificate qualification, i.e. indication of the certificate quality derived certificate extensions
(e.g. Qualified Certificate Statement) or from the certificate policy;
• Certificate holder information extraction and semantic processing. I.e. providing in a
standardised XML form, name, surname, … of the certificate holder;
• Signature format transformation for long-term archiving, i.e. providing a service to transform
a signature into a long-term secure data format including validation data (e.g. XAdES-A or
CAdES-A);
• Time Stamp Token (TST) validation , i.e. verifying the integrity of the TST signature,
checking the validity of the Time Stamping Authority (TSA) certificate used to sign the TST.
Those services should be subject to Service Level Agreements defined and agreed by all interested
parties, i.e. the Validation Authority and the Certification Service Providers, ensuring any
eGovernment application’s user that a reliable, interoperable, scalable, and widespread service for
signature validation is available to them.
5.3.3.7.3.4.2 Examples
To illustrate the Validation Authority Federation model proposed, this section will present three
examples of similar models:
1. The Spanish solution38, which takes care of all eSignature and electronic certificates
validation, provides a lot of advantages:
37
RFC 3379 - Delegated Path Validation and Delegated Path Discovery Protocol Requirements,
September 2002 - http://tools.ietf.org/html/rfc3379
38
MultiPKI Validation Platform. More detailed information at: http://www.epractice.eu/cases/1984
133
November 2007
• Hiding of the eSignature/certificate validation work to the eGovernment application by off-

loading it to a trusted server. This off-loading mechanism is called Delegated Path
39
Validation/ Delegated Path Discovery ;
• Transitivity of agreements with all the CA established in the country reduce the need to
establish N*M agreements CSP-Public Administration and the technical connection to
each CSP;
• Provision of the whole certificate validation steps as described above (see section
5.3.3.7.2.1), i.e. certificate syntax checking, CA trustworthiness, validation of certificate
expiration and validation of certificate status;
• Translation of the fields of the certificate X.509 to a normalized XML schema (holder’s
name, surname and national ID; certificate’s issuer information: name of CA, legal
address, …; certificate’s usage, type of certificate, ...), saving the effort to eGovernment
Portals;
• Service is non intrusive with administrative procedures (based on Web Service
technology).
This centralised building up approach to create a common service providing eID and
eSignature features to eGovernment applications has been proved to be a rational and cost
effective approach and a key enabler for the eID in Spain. It has unburden eGovernment
applications of the hard tasks of developing SW modules to deal with the creation/
verification of the eSignature, the handling of crypto libraries, CRL and OCSP protocols for
the verification of digital certificates or the need of physical network connection to all
Certification Service Providers of the country.
2. The Council of the Notariats of the European Union (CNUE40) started to develop an electronic
signature verification platform that is designed to allow all European civil law notaries to
identify notarial electronic deeds from other countries as such, and to properly take note of
their content.
The prototype of the verification platform already allows the verification of signatures from
civil law notaries coming from France, Germany, Italy and Spain. This can indeed already be
considered a truly pan-European achievement.
3. DNV Validation Authority41 has been set-up for private organizations in 2006. It offers a new
independent third party trust service to manage the process of verifying digital signatures and
validating the accompanying digital identity (eID) certificates. DNV’s Validation Authority
services will enable effective use of digital signatures by reducing cost and complexity and
providing true interoperability between different eID certificates.
39
RFC 3379, “Delegated Path Validation and Delegated Path Discovery Protocol Requirements”,
September 2002, http://tools.ietf.org/html/rfc3379
40
www.cnue.be
41
DET NORSKE VERITAS – Validation Authority, REPORT NO. 2005-0673, REVISION NO. 01,
www.dnv.com/ict/va/va.asp
134
November 2007
The model has been presented at some big PKI events (5th Annual PKI R&D Workshop
(NIST), Porvoo 8 meeting …).
5.3.3.7.3.4.3 Components
The Validation Authority Federation model is composed of several components.

In each Member States, there should be a National Validation Authority in place. At the European
level, there should be a European Validation Authority Gateway allowing all National Validation
Authorities to communicate with each other.
As we know that not all Member States will set-up a National Validation Authority or perhaps not all at
the same time, we propose also to set-up a Generic Validation Authority at the European level
allowing eGovernment applications of Member States which do not have a National Validation
Authority to anyway participate to the Federation. This Generic Validation Authority should be seen as
an extension of the European Bridge/Gateway CA.
5.3.3.7.3.4.3.1 National Validation Authority
Currently eGovernment applications need to query the certificate validation services from the CSP
having issued the certificate issued to the signing party. As explained earlier, this is a complex task.
To solve this issue, we recommend Member States to set-up a National Validation Authority (NVA)
which will allow eGovernment applications to outsource the signature validation tasks to this NVA,
exactly in the same way as the Multi-PKI Validation Platform in Spain (see section 5.3.3.7.3.4.2).
The following figure represents a National Validation Authority and shows how it may integrate with
application approach models described at section 4.2.1.
National Validation Authority

...
crl – ocsp
National Validation Authority

Web Services Web Services Web Services
Model 3 & 4
Request certificate Receive certificate

validation Request certificate Receive certificate Request certificate Receive certificate
Validation status
Model 1
validation Validation status validation Validation status

Model 2
and qualification
and qualification and qualification
Server
Server
Web Portal
eGov Applications
Server
Se rver
Register users and Server

Server
Provide credentials eGov Applications eGov Applications
User
RA
RA
RA
RA certificate
Sign documents
135
November 2007
The National Validation Authority proposed in our model will act as the central point of validation for
all eGovernment applications deployed in the Member State.
As is, the National Validation Authority should be able to validate any eSignatures as soon as the
signature has been created using an electronic certificate issued by a CSP located in the same
country. The services provided by the National Validation Authority should be equivalent to those
described at section 5.3.3.7.3.4.1.
One can also imagine that some Member States will not only create one National Validation Authority
but, for example, a federation of regional or sectoral Validation Authorities.
Of course, for eGovernment applications this does not solve the issue of validating eSignatures
created using an electronic certificate issued by a foreign CSP. To solve this issue, the National
Validation Authority should be able to communicate with the National Validation Authority of the
foreign country (provided that it exists). That’s the reason for the introduction of the European
Validation Authority Gateway presented in the next section.
5.3.3.7.3.4.3.2 European Validation Authority Gateway
In order to allow National Validation Authorities to communicate with each other and thus creating the
concept of Validation Authority Federation, an important component needs to be set-up at the
European level. We called it the European Validation Authority Gateway (EUVAG).
The first role of this central component is to establish the trust relationships between all National
Validation Authorities. Secondly, the EUVAG provides the link between all NVAs from a
communication point of view. Indeed, when receiving a validation request, the EUVAG will redirect
the request to the competent National Validation Authority based on the eSignature certificate
content, thus hiding the complexity of National Validation Authorities network.
The following picture represents the technical concept.
136
November 2007
Validation Authority Federation

EBGCA Root
Web Services
Root
Root Root
TSLs CA
CA
CA
CAs
EU Validation Authority Gateway
Generic Validation Authority
Web Services
crl – ocsp
Request signature
Request signature
validation
... ... ...
validation
crl – ocsp National Validation National Validation

Authority Authority
User
certificate
Web Services Web Services
Request certificate Request signature Request signature
status validation validation
eGov eGov eGov

apps apps apps
Sign Sign
Sign Sign User
User
certificate
certificate
Country Z Country X Country Y
The concept is based on a unique European Validation Authority Gateway that would only act as a
gateway between National Validation Authorities of the Member States. In our model, to validate an
eSignature, an eGovernment application deployed in country X would have to contact its own
National Validation Authority. If the certificate used to electronically sign originated from a
Certification Authority of country Y, then the Validation Authority from country X would have to
contact the European Validation Authority Gateway, which will in its turn redirect the validation
request to the National Validation Authority of country Y. The whole validation process will be done in
country Y in compliance with the national rules governing the certification authority and with the
knowledge of the semantics behind the certificate fields.
If the signature originating country (country Z in the previous drawing) does not have a National
Validation Authority in place, then the validation process will be left to the Generic Validation
Authority as explained in the next section.
5.3.3.7.3.4.3.3 Generic Validation Authority
As we know that not all Member States will set-up a National Validation Authority or perhaps not all at
the same time, we also propose to set-up a Generic Validation Authority at the European level
137
November 2007
allowing eGovernment applications of Member States which do not have a National Validation
Authority to participate to the Federation anyway.
We propose to build this European Generic Validation Authority on the basis of the European
Bridge/Gateway CA. In addition to the services provided by the EBGCA, i.e. distribution of Trusted
Status Lists, we suggest to implement certificate validation services for all CSP belonging to Member
States which have not set-up their own National Validation Authority.
At this stage, we do not believe that the proposed European Generic Validation Authority could
additionally provide all signature validation services or value-added services as described at section
5.3.3.7.3.4.1.3 and 5.3.3.7.3.4.1.4. However, even if providing semantic analysis of the certificate
might become a nightmare for the Generic Validation Authority as it doesn’t control the data, and its
interpretation, stored in the certificate; it would anyway be more efficient to achieve this semantic
analysis centrally than to leave it up to every eGovernment applications.
5.3.3.7.3.4.3.4 Interactions
The following diagram intends to explain the relationships and interactions between the different
components of the Validation Authority Federation presented above. Especially, it intends also to
explain how the model can work when not all the components are present.
138
November 2007
Country X EU Country Y
eGov Appl NVA-X EU VA G NVA-Y Issuing CA
WS request WS request Redirect CRL/OCSP request

a b c d
1 WS response WS response CRL/OCSP response
g f e
WS request WS request Generic VA

a b Redirect CRL/OCSP request
2 c d
WS response WS response CRL/OCSP response
g f e
WS request Redirect CRL/OCSP request

a b c
3 WS response CRL/OCSP response
e d
WS request
a Redirect CRL/OCSP request
4 WS response
b c
CRL/OCSP response
e d
139
November 2007
Case 1: the “normal” case.

In the ideal situation, where the Validation Authority Federation is fully deployed, i.e. every Member
States has set-up its own National Validation Authority, there will be no need to have a Generic
Validation Authority at the European level.
In this situation, an eGovernment application of Country X will request, via web services (a), the
validation of an eSignature to its National Validation Authority. If the signature has been created using
a certificate issued by a CSP which is not from the same country, NVA-X will request, via web
services (b), the signature validation to the European Validation Authority Gateway. This latter will
redirect the request to NVA-Y (c), i.e. the National Validation Authority of the foreign country where
the CSP is located. NVA-Y will perform all signature validation tasks. Notably, it will request the
certificate revocation status from the issuing CSP (d). NVA-Y will then send the response to the
validation request directly to NVA-X (f), which will, in its turn, forward it to the eGovernment
application (g).
Case 2: the “no NVA-Y” case.

In the second case, we suppose that no National Validation Authority has been set-up in the Member
State where the signing certificate has been issued. This second case will show how the Generic
Validation Authority is involved in the whole validation process.
validation of an eSignature to its National Validation Authority. If the signature has been created using
a certificate issued by a CSP which is not from the same country, NVA-X will request, via web
services (b), the signature validation to the European Validation Authority Gateway. As the NVA-Y
doesn’t exist, the gateway will redirect the request to the Generic Validation Authority (c) will perform
certificate validation tasks, i.e. it will request the certificate revocation status from the issuing CSP
(d). The Generic Validation Authority will then send the response to the validation request directly to
NVA-X (f), which will, in its turn, forward it to the eGovernment application (g).
Case 3: the “no NVA-X” case.

In the third case, we suppose that no National Validation Authority has been set-up in the Member
State of the eGovernment application, i.e. the eGovernment application has no National Validation
Authority to help in the validation of the eSignature. This case shows how the European Validation
Authority Gateway will replace the missing NVA-X.
validation of an eSignature to the European Validation Authority Gateway. This latter will redirect the
request to NVA-Y (b), i.e. the National Validation Authority of foreign country where the CSP is
located. NVA-Y will perform all signature validation tasks. Notably, it will request the certificate
revocation status from the issuing CSP (c). NVA-Y will then send the response to the validation
request directly to the eGovernment application (e).
Case 4: the “no NVA-X nor NVA-Y” case.

In the fourth case, we suppose that there is no National Validation Authority at all. This case will show
how the European Validation Authority Gateway and the Generic Validation Authority will help the
eGovernment application to validate the eSignature.
validation of an eSignature to the European Validation Authority Gateway. As the NVA-Y doesn’t
exist, the gateway will redirect the request to the Generic Validation Authority (b), which will perform
certificate validation tasks, i.e. it will request the certificate revocation status from the issuing CSP
(c). The Generic Validation Authority will then send the response to the validation request directly to
the eGovernment application (e).
140
November 2007
5.3.3.7.3.4.4 Interfaces
Basically a Validation Authority would have to propose two interfaces: one towards eGovernment
applications and one towards the CSPs.
5.3.3.7.3.4.4.1 Interfaces towards eGovernment applications
In our opinion, to support the services described above (see section 5.3.3.7.3.4.1), the interface
between the VA (being the National Validation Authority or the European Validation Authority
Gateway) and the eGovernment application should be based on web services, i.e. exchange of a
defined XML message via a secured standardised protocol (e.g. HTTPS42). Nowadays, web services
are supported by almost all web application environments providing an easy way of integration for
eGovernment applications.
5.3.3.7.3.4.4.2 Interfaces towards CSPs
The Validation Authority (being the National Validation Authority or the Generic Validation Authority)
should not impose new interfaces to be provided by CSPs. Therefore, it should rely on the existing
ones:
CRL
For CSP that only support a CRL interface, the VA will have to download on a regular basis the
Certificate Revocation List of the CSPs and to store it in one database. This is obviously not the
preferred interface as it could impose huge databases to be kept at the VA level.
OCSP
Online Certificate Status Protocol (OCSP) as defined in RFC2560 is a very simple request/reply
protocol that allows clients to ask an “OCSP responder” about the revocation status of one or more
certificates. The OCSP responder returns digitally signed responses regarding the status of the
certificates identified in the request. OCSP is designed to return real-time responses to client queries,
and can provide an efficient method for returning certificate status on demand.
From the VA point of view, OCSP is highly preferred to CRL.
RECO15 New eGovernment applications should be encouraged to make use of

PKI-based signatures if cross border interoperability is considered of
importance
RECO16 Publish, on a central website, a list of Certification Service Providers
supervised43 by their respective national responsible body
Target group: European Commission
42
HTTP over SSL
43
141
November 2007
RECO17 Implement the European IDA Bridge/Gateway CA (EBGCA) model that

uses the centralised administrative structure of a bridge, and distributes
trust using both cross-certifications and Certificate Trust Lists.
Target group: European Commission
RECO18 The same legal concerns as voiced by RECO8 apply, and the same
consultation of the Member States should be sought.
Target group: European Commission; Member States
RECO19 Set-up a pan-European ‘Validation Authority Federation’
Target group: European Commission; Member States
5.3.3.8 Validation protocol
Validating an electronic certificate is a complex process. First, it must be checked if the certificate
belongs to a trusted CSP (the whole certification chain has to be analysed), then the validity is
verified (does the certificate expired?) and finally the status must be verified (is the certificate
rejected?).
To achieve the certificate status check, the application can make use of different protocols: CRL (a
red list of rejected/suspended certificates downloaded from the CSP’s site), OCSP (a request
certificate status is sent to the CSP which sends back a response of "current", "expired," or
"unknown.").
SCVP (Server-based Certificate Validation Protocol) has been designed to make it easier to deploy
PKI-enabled applications by delegating path discovery and/or validation processing to a server, and
to allow central administration of validation policies within an organization.
Among surveyed applications, 72 applications have answered the question « What types of validation
protocols are used for the electronic certificate validation? (OCSP, CRLs, SCVP…) »:
• 43 are only supporting CRL as validation protocol,
• 26 support both CRLs and OCSP,
• 3 support only OCSP protocol.
None of the surveyed application support SCVP.
The responses are not surprising, as they fit perfectly with the validation protocols usually provided by
CSPs.
There is potentially an issue for the three applications that only support OCSP as validation protocol.
Indeed, not all CSPs presented in the various country profiles have set-up an OCSP responder. Many
of the CSPs only provide a certificate validation mechanism based on CRLs (e.g. in Austria: A1
mobile phone signature or in Finland: FINEID citizen’s card).
Of course, the issue is more related to specific applications that have not been designed for
interoperability and that only support validation protocols provided by the CSPs they trust. To achieve
interoperability, eGovernment applications should support as many validation protocols as possible.
142
November 2007
The complexity for applications of supporting the validation protocol provided by the CSP they trust,
will automatically disappear as soon as the recommendation ‘Validation Authority Federation’ (see
section 5.3.3.7.3.4) is made available to eGovernment applications.
Indeed, by using such a model, the whole validation process will be off-loaded to the Validation
Authority preventing eGovernment applications to support multiple protocols.
5.3.3.9 Conclusions
From a technical point of view, among the eight issues presented above, two of them are considered
as having a major impact on potential interoperability:
• Signature validation: eGovernment applications are relying on the validation mechanisms
provided by the CSPs they trust. At the National level this can be a problem due to the high
number of accredited CSPs but at the European level, if every application would have to trust
all European potential CSPs, the situation would quickly become unmanageable at the
application level.
• Incompatible use of identifiers: This issue concerns signatures based on certificates where
the application requires that the certificate to contan a specific National/Sectoral/Regional
unique number to identify the signatory of a document.
143
November 2007
5.4 List of potential interoperability issues at technical level

Besides issues that have been clearly identified, there are still some possible issues that may arise in
the future. Those potential interoperability issues are listed here below.
5.4.1 Key length
5.4.1.1 Problem description
eGovernment applications may impose, for security reasons, a certain key length (e.g. 2048 bits) that
is not provided by the user’s certificate. If such security requirement is met by an application, it could
prevent non-nationals users to make use of the application.
Note that the situation is nowadays controlled at the national level, where applications only supports
the signature key length provided by their national CSPs.
5.4.2 Client software
eGovernment applications may provide client-side software (JAVA applet/Active X or even FAT
client) that may not be supported in the user environment. Among surveyed applications, a large
number of them are only supported on Microsoft Windows operating system.
Moreover, applications may also require to exchange signed emails which would not be possible with
certain email applications (e.g. Outlook Express cannot send mail signed with Belgian eID because
the Belgian eID certificate do not contain the email address of the signatory).
5.4.3 Hardware
From an interoperability point of view, hardware requirements on the client side are not imposed by
the applications but by the type of token that is used.
However, for applications that claim to be opened for cross-border use, this may constitute a barrier
as each supported token may require its own driver which may interfere with other installed drivers
(for national use).
5.5 Interoperability issues in key e-government sectors

The list above outlines the interoperability issues that have been generally identified in existing e-
government applications. However, the distribution of these issues between e-government sectors is
fairly uneven, in the sense that certain issues are significantly more prevalent or have a much
stronger impact in some services than in others. This is an important consideration for interoperability
purposes, since applications in some sectors show more potential (i.e. a better business case) for
interoperability than others. For this reason, the three sectors discussed above (e-procurement,
income tax declarations and VAT declarations) will be examined in more detail below, with a
discussion of the main interoperability issues.
144
November 2007
5.5.1 eProcurement
E-Procurement is one of the sectors which are generally considered to have one of the strongest
business cases for interoperability, in the sense that efficient e-signature interoperability could affect a
large number of stakeholders (both public sector parties and private sector tenderers) who could
realise a potentially substantial cost savings through electronic procurement. Despite this fact, no
substantial interoperability has been realised yet. In part, this is due to the relative newness of the
European legal framework44 (specifically the e-Procurement Directives 2004/17 and 2004/18) and the
fact that most Member States are still in the early stages of implementation of their applications, as
described above (see the table under 4.2.4.1: 14 countries out of 29 indicated that no application was
available yet). However, a number of the aforementioned issues also play a strong role.
Specifically, the descriptions of the e-Procurement applications above clearly show that Member
States have assumed a strongly national perspective, in which it is assumed that any tenderer should
apply for the appropriate signature solution in the country involved, regardless of the form that this
may take, and even if this means that a representative of the foreign entity would need to register or
appear personally in the country where the tender was published. Cross border functionality of the
electronic platform is not yet considered to be a key priority in this regard.
Apart from this national perspective, other issues discussed above also certainly play a role in this.
For one, the required signature type (advanced – advanced using a qualified certificate – qualified
signature) complicates matters, since it would appear to be politically and legally infeasible to expect
countries to accept signature types which are not deemed adequate under their own frameworks.
Finally, the descriptions above also indicate that some countries do not even consider signatures to
be essential to the tendering process, which is e.g. witnessed in Estonia (no signature is required) and
Finland (electronic authentication is sufficient). It is clear that the Member States apply widely varying
demands to the security needs of e-procurement procedures, and that there is no consensus on the
role of (or the need for) an electronic signature. Under such circumstances, interoperability between
all Member States’ systems can only be a longer term goal.
The existence of these issues and their magnitude may seem somewhat surprising, given that the
role of electronic signatures is specifically regulated in the aforementioned directives. However, the
approach taken by both Procurement Directives is quite comparable to the basic rules of the
eSignatures Directive as outlined above:
As a basic principle, the eProcurement Directives state that ‘the tools to be used for communicating
by electronic means, as well as their technical characteristics, must be non-discriminatory, generally
available and interoperable with the information and communication technology products in general
use.’ (article 42.4 of Directive 2004/18/EC and article 48.4 of Directive 2004/17/EC). This is
comparable to the equivalence and non-discrimination rules of article 5 of the eSignatures Directive,
which in principle bars the recipient of an electronic signature from denying its validity or admissibility
on the grounds that it is in electronic form. Thus, the basic rule is that Member States are required to
provide an interoperable platform which does not preclude non-national solutions from being used.
However, in public sector applications this general rule is somewhat negated by the public sector
clause (article 3.7) of the eSignatures Directive, as discussed in detail above, allowing Member
States to make the use of electronic signatures in public sector applications ‘subject to possible
additional requirements. Such requirements shall be objective, transparent, proportionate and non-
discriminatory and shall relate only to the specific characteristics of the application concerned. Such
requirements may not constitute an obstacle to cross-border services for citizens.’
It is thus not surprising that the eProcurement Directives (which by definition are public sector
applications subject to the public sector clause of the eSignatures Directive) contain similar
provisions. According to the Directives, ‘Member States may, in compliance with Article 5 of Directive
1999/93/EC, require that electronic tenders be accompanied by an advanced electronic signature in
conformity with paragraph 1 thereof’ (article 42.5 (b) of Directive 2004/18/EC and article 48.5 (b) of
Directive 2004/17/EC). In short, even in procurement procedures, Member States may elect to
44
See http://ec.europa.eu/internal_market/publicprocurement/e-procurement_en.htm
145
November 2007
require the use of qualified signatures. As shown above, this is a common requirement in the Member
States (see section 4.2.4.1. – 5 countries out of 29 indicated that a qualified electronic signature was
required, with a further 5 indicating that at least a qualified certificate would be needed).
In itself, this could already prove to be problematic in Member States where national governments
have elected not to make qualified signatures a common part of their eGovernment strategy (as is
e.g. the case in Denmark), since it would make the acquisition of qualified signature solutions
noticeably more complex in such countries. However, even when Member States do offer qualified
signature solutions, it is far from certain that entities in that Member State would be able to participate
in tendering procedures in other countries. As the table in section 4.2.4.1 has shown, eProcurement
applications relying on qualified signatures typically accept only signatures generated through
certificates issued by CSPs which have been accepted by the application owner in that country. If an
aspiring tenderer cannot reasonable receive a qualified certificate from such a CSP (either because
this requires a physical identification before a registration authority in that country, or because it even
requires an actual establishment or domicile in that country, both of which are common
requirements), then access to an eProcurement application is practically impossible.
It goes without saying that this situation is manifestly contrary to the goals of the eProcurement
Directives (and against the basic principles of the eSignatures Directive in general). The resolution of
this specific situation is therefore no different than that of any other eSignature application in the
public sector: the absence of suitable (and affordable) interoperability solutions, and specifically of a
functional and reliable validation and trust mechanism, is the key impediment to the realisation of the
goals of the eSignatures and eProcurement Directives, more than any political consideration.
However, even apart from these issues, it is clear that e-Procurement also presents a number of
unique difficulties which are not encountered (or at least not to the same extent) in other sectors.
These will be further discussed below.
• Firstly, it should be realised that, unlike other typical eGovernment applications,
eProcurement does not typically rely on a single document being signed by a single entity.
Public procurements commonly require the participating entity to submit a number of
supporting evidentiary documents in addition to the main offer, including such documents as
social security certificates, extracts from articles of associations, declarations of non-
bankruptcy, and attestations of conformity with direct and indirect tax requirements. This is a
significantly more complex situation, as it would be an insufficient solution to merely roll
electronic versions (e.g. scans) of such documents into one digital envelope which is then
digitally signed by the tenderer.
After all, in this case, the legal value of the certificates is debatable, since their authenticity is
only backed by the tenderer, but not by the actual issuing authorities. Such a situation is
acceptable in procurements where the purchasing body has only requested copies of
evidentiary documents, but not in cases (which is the typical situation) where original
documents have been requested. If original documents have been demanded, then the
originals also need to be equipped with a suitable authenticity verification mechanism, the
most obvious solution being a signature from the issuing authority. Such solutions are not
commonly offered at this time, as many Member States are still issuing paper documents
exclusively.
Thus, a first issue to be aware of is the need of multiple signatures from multiple
stakeholders. The recipient of an electronic offer must be able to validate all of these.
• Secondly, not only do public procurements commonly involve signatures from the authorities
responsible for issuing supporting documents, it is also common for offers to be prepared and
submitted jointly, in the form of a consortium, temporary association (with or without legal
personality) or simply in the form of a prime contractor backed by one or more
subcontractors. It goes without saying that this increases the problem noted above
exponentially, as each of the participating entities may need to provide its own set of
supporting documents (potentially from many different countries and/or administrations
within these countries); and the main offer itself may need to be jointly signed by all of the
participants. This can be a problem when e.g. extending a consortium to a country that does
not commonly work with qualified signatures, when the consortium is planning to introduce a
146
November 2007
bid in a country requiring such signatures. Under extreme circumstances (and particularly in
case of last minute offers being filed), this may even lead to a discrimination against
otherwise perfectly suitable consortia partners, on the sole grounds that they cannot
electronically sign the final document.
• Thirdly, a key issue that is somewhat more prevalent in eProcurement applications than in
most other types of eSignature applications is the issue of determining the authorisation to
represent a specific entity. Obviously, from the perspective of the tenderer, this is not a
particularly exclusive issue, since e.g. VAT declarations on behalf of legal entities also
present the difficulty that the natural person signing a specific document actually has to have
a legal mandate to represent this entity. However, as noted above, the larger problem is
represented by the inclusion of signed supporting evidentiary documents.
In each of the included electronic documents, the recipient (i.e. the purchasing body) must be
able to determine not who signed the document (the exact natural person is in fact irrelevant
in this case), but in what capacity the document was signed, and whether or not the signature
suffices to consider the document an official expression of the issuing body’s authority. This
requires suitable technical and organisational solutions to be put into place to be able to
retrieve the identity and status of the issuing body from whom the supporting document
originated, and above all a suitable trust mechanism to be able to determine whether this
document is in fact lawful and meets the requirements of the procurement regulations.
It should be noted that this problem has in fact never been resolved with complete certainty in
an offline context. Reliability and authenticity of non-national documents is often assessed
based on its overall appearance (the presence of a suitable letterhead, signatures and
stamps), rather than on any conclusive validation procedure. None the less, as with the
electronic signature in general, it can be expected that eProcurement will be held to a higher
standard in this regard.
• Finally, an additional eSignature specific difficulty which has largely escaped specific scrutiny
is the issue of liability limitations. Unlike handwritten signatures, electronic signatures are
typically restricted through the issuing CSP’s Certification Practice Statement, which limits the
liability of the CSP and often restricts the validity of the signature to commitments up to a
certain threshold. Again, the combination of multiple signatures in the case of consortia, along
with the complex and various rules regarding liability in public procurements (often explicitly
requiring that each of the partners of a consortium must accept full liability for the whole of
the offer, rather than solely for its own part) makes for an unreliable situation. After all, if an
offer with a value of 10 million EUR is filed by a consortium of three partners, while one
signature has a value restriction of 5 million EUR, then a provision of joint full liability may in
fact invalidate the signature, and could thus threaten the validity of the offer as a whole. No
real solution to this problem has yet been found, to our knowledge.
Again, it should be emphasised that this problem also exists in an offline context to a certain
degree, as the articles of association of some entities may specify that the entity cannot be
represented by a single signature in contracts exceeding a certain value. In those cases too,
the validity of an offer with an unsuitable signature is debatable. However, the transition to
electronic tendering obviously exacerbates this problem, since it adds the CPS as an
additional restriction to the articles of association.
Thus, it is clear that public procurement is not only an interesting test case for electronic signatures in
eGovernment applications in general, but it is also one of the most complicated types of applications.
For this reason too, it should be considered a key priority. Resolution of the interoperability problems
faced by public procurements implies a resolution of the majority of eSignature related difficulties.
5.5.2 VAT Declarations
Many of the issues described above in the e-procurement section also apply to VAT declarations, in
particular the tendency to assume a purely national perspective by permitting only locally established
solutions (which is a uniform element in e-government e-signature applications); and the wide variety
147
November 2007
of solutions being offered (ranging from no signature/authentication to simple signatures, advanced

signature, advanced with qualified certificates, and qualified signatures; see section 4.2.4.3, which
specifically shows a fairly equal spread between simple and advanced signatures (accepted in 13
applications out of 29) and qualified signatures (accepted in 12 out of 29)).
None the less, there are also a number of issues identified above which are more typical for VAT
declarations. First of all, VAT administrations tend to have a tradition of operating as a distinct
administrative unit within each country, relying on their own registers (or at least on common tax
registers). For this reason, it is perhaps not surprising to find that there is a strong link between e-
signatures in VAT applications and eID schemes for tax payers. This can be witnessed by the fact that
several of the application descriptions indicate that a specific unique identifier must be included in the
signature certificate or must be presented in another manner (e.g. in Bulgaria, Czech Republic,
Portugal and Spain). Obviously, this implies that interoperability cannot be realised if the applications
functionally require such identifiers (e.g. in order to process the declarations) or if administrations are
unwilling to accept declarations which lack such identifiers (e.g. because it presents a
disproportionate administrative burden).
As with eProcurement above, one of the key problems is the matter of mandates and representations,
since VAT declarations are typically filed on behalf of a legal entity. However, unlike tenders, such
declarations are typically not filed by the direct legal representative of the legal entity (general
managers, CEOs, directors…), but rather by one or more members of the administrative staff of the
legal entity, or even by an external service provider. Thus, the issue of being able to determine the
legal capacity of the signatory and whether or not the signatory can in fact represent a specific legal
entity is of paramount importance in VAT declarations.
Equally interesting is the fact that, due to the nature of VAT declarations and the inherent necessity of
accommodating foreign users, most countries have implemented VAT solutions which are explicitly
available to foreign users. However, these always require prior registration in the country of
declaration. In effect, this is also how the mandate issue above is usually resolved, as such
registration procedures require an explicit mandate to be given by the legal entity to a specific natural
person.
It is also interesting to note that certain countries (e.g. Denmark) have implemented ad hoc solutions
for foreign users which effectively result in two separate systems (with different security levels or a
different legal status) for one application.
Thus, the issue of cross border interoperability in VAT declarations has not yet been resolved, largely
due to a lack of a common eSignature interoperability solution, coupled with the need for a simple
mandate management system that allows the recipient to easily assess if a given natural person is
indeed qualified to represent a legal entity.
5.5.3 Income taxes
Income tax declarations are one of the more popular eSignature applications, being off ered in 22 of
26 responses (see section 4.2.4.2.; 3 surveyed countries did not indicate whether or not a solution
was available). The reason for this is likely twofold: first of all, the manual processing of income tax
declarations is very labour intensive, requiring that manually provided information is transferred to an
electronic form, thereafter to be processed automatically. Thus, paper based declarations represent a
large and unnecessary administrative expense, both in time and money. Additionally, such
declarations are one of the easier to implement:
• they do not usually require multiple signatures or multiple documents since declarations are
usually filed individually; with the noticeable exception of tax systems which require a joint
declaration between marital partners;
• the legal capacity of the signatory does not need to undergo extensive screening, as one
typically files ones taxes in a personal capacity. It should be noted though that some
applications include the possibility of giving a mandate to a service provider (accountant or
tax consultant);
148
November 2007
• the incentive for abuse is limited, since there is no benefit to filing false declarations under
the pretence of being a third party, apart from a possible fleeting sense of malicious
satisfaction;
• long term validity is not much of an issue, since a final tax is established in a relatively short
term; and
• the user group is extensive and largely homogeneous, consisting mostly of the national
population.
Thus, roll-out is relatively easy and cheap, and can yield high cost savings. It should therefore come
as no surprise that so many surveyed countries have chosen to deploy an income tax declaration
application; nor that the legal threshold for electronic signatures is set somewhat lower than usual: of
the 22 reported applications, only 6 require a qualified signature, 8 require a simple or advanced
signature, and in 8 cases an authentication scheme of some sort (including two factor authentication)
was sufficient. This is in line with what one might expect given the lower incentive for abuse.
With regard to specific issues, income taxes are similar to VAT declarations in the sense that they are
often closely linked to tax registers (see e.g. the French policy of allowing electronic declarations
based on a unique tax identifier), and that they therefore typically require prior registration in the
country of declaration. Again, these systems have been designed and implemented from a purely
national perspective: if the system is usable by foreigners at all, then this is only the case by using an
e-signature solution offered in the country of declaration. Finally, income tax applications again show
the full scale of possible solutions, covering most varieties of electronic signatures and several forms
of electronic authentication.
However, income tax declarations tend have a smaller focus on non-nationals than either VAT
declarations or e-Procurement, since the vast majority of income tax declarations originate either
from citizens of a country, or at least from persons who have already been registered in local
database to meet their obligations under administrative, fiscal or social security law. For this reason,
the link between eID schemes and e-signatures tends to be stronger with income tax applications.
For the exact same reason, the business case for interoperability seems weaker for income taxes
than for VAT declarations and e-procurement, which explains to a certain extent why accessibility to
foreigners is considered a lower priority goal.
In that sense, income tax applications are a convenient first indication of a country’s main e-signature
policies: the user group is large and fairly homogeneous, allowing a single e-signature solution to
cover the needs of most users in a way that provides a large benefit for these users and for tax
administrations. From a negative point of view, the interest in interoperability is much smaller for
income declarations than for the other two applications discussed above.
149
November 2007
6 List of recommendations
ID Description Target group

RECO1 Member States should be reminded of the letter and spirit of Member States
the public sector clause (art. 3.7), including their obligation in
principle not to introduce requirements which constitute an
obstacle to cross-border services for citizens; and of their
notification obligations under article 11 of the Directive which
require them to notify the Commission of any additional
requirements imposed in application of article 3.7 insofar as
these are a part of any voluntary accreditation scheme.
RECO2 Application owners should take note of signature solutions eGovernment
being used in other countries as identified by this study, and application owner
be made aware of their obligation in principle not to exclude
foreign signature solutions whenever possible, unless specific
considerations meeting the criteria of the public sector clause
would permit this.
RECO3 Application owners should be advised to shift from the current eGovernment
situation of ad hoc decisions for each application, to a system application owner
where they require their users to employ a certain
security/reliability level, such as the appropriate legal
classification under the eSignatures Directive, rather than a
specific certificate or CSP.
RECO4 Member States should be made conscious of the fact that their Member States
possible national decentralisation of competences does not
absolve them of their obligations of adhering to the
eSignatures Directive’s provisions, which includes the
obligation of ensuring that local governments adhere to this
framework.
RECO5 Application owners should be made conscious of the eGovernment
interoperability consequences of requiring the use of application owner
identification attributes in signatures which are only available
within their country.
RECO6 When determining the requirements for e-signature eGovernment
applications, application owners must ensure that the signature application owner
requirements are not abused to add functionality which is
unrelated to the signature functionality itself when this would
impair interoperability. There is no objection against using
electronic signatures to add functionality (such as
automatically filling out identity information or automated error
correction) beyond the traditional functions of a handwritten
signature (such as expression of consent, non-repudiation
etc.), applications should not make such added functionality
mandatory when this has the unintended side effect of making
the use of foreign signature solutions impossible, unless an
alternative can be offered to users whose signatures may not
offer the added functionality.
150
November 2007

RECO7 It is recommended that a pan-European signature certificate Member States
validation platform model is developed to resolve the issues of
certificate validation and the issue of creating trust between
existing CSPs. Such a platform would allow non-national PKI
certificates to be validated in any country.
RECO8 Because of the internal market provisions of the Directive, the European
creation of pan-European validation platform should at a Commission and
minimum be preceded by a consultation of the Member States Member States
on the main policy and legal issues arising as a result of the
introduction of such a platform.
RECO9 The unique number required by the application to identify the eGovernment
citizen/business should not be a mandatory part of the application owner
signature/certificate.
RECO10 Application owners should be recommended to make use of eGovernment
PKI-based signatures in applications where interoperability in application owner
the short term is a key objective
RECO11 Compliance with ETSI Qualified Certificate profile is eGovernment
recommended. application owner
RECO12 The client signature tool should use standardized interfaces or eGovernment
applications that are de-facto available on any platform. application owner
RECO13 eGovernment applications that want to provide maximum eGovernment
interoperability within an open environment should rely on application owner
CSPs that do not impose any specific non-standardised
interfaces.
RECO14 Promote the use of international standards (CAdES or XAdES) European
as eSignature formats. Commission,
Member States,
International
standardisation
bodies
RECO15 New eGovernment applications should be encouraged to eGovernment
make use of PKI-based signatures if cross border application owner
interoperability is considered of importance
RECO16 Publish, on a central website, a list of Certification Service European
Providers supervised45 by their respective national responsible Commission
body
RECO17 Implement the European IDA Bridge/Gateway CA (EBGCA) European
model that uses the centralised administrative structure of a Commission
bridge, and distributes trust using both cross-certifications and
Certificate Trust Lists.
RECO18 The same legal concerns as voiced by RECO8 apply, and the European
same consultation of the Member States should be sought. Commission,
Member States
45
151
November 2007

RECO19 Set-up a pan-European ‘Validation Authority Federation’. European
Commission,
Member States
152
November 2007
7 Conclusions
While all surveyed countries have integrated some form of e-signature functionality into their e-
government applications, the level of national harmonisation varies significantly. Although a smaller
number of countries have implemented a uniform e-signature policy and infrastructure (e.g. in
Denmark or Estonia), most others are still recovering from a legacy of ad hoc solutions in need of
harmonisation. Thus, insofar as interoperability has been a concern from a regulatory perspective, the
focus has mostly been on creating national rather than cross border interoperability.
Secondly, there seems to be a definite trend towards the creation of a single centralised e-signature
infrastructure, which allows specific applications to simply ‘plug in’, thus ensuring a better (more
homogeneous) user experience and minimising redundancy. This is equally true in countries which
are attempting to align sector specific solutions (e.g. Bulgaria) as for countries that have had diverse
developments due to administrative/constitutional reasons (e.g. Germany). If continued, this trend will
obviously facilitate the realisation of cross border interoperability.
From a regulatory perspective, the most significant provisional conclusion seems to be that the
surveyed countries have made a rather extensive (and possibly excessive) use of the possibility
allowed by the Directive to impose additional requirements to the use of e-signatures in public sector
applications. Specifically, and regardless of the precise method followed, all surveyed countries
exclusively allow certificates from formally accredited or recognised service providers, where foreign
CSPs are rarely if ever accredited or recognised. The practical result of this is that every aspiring user
of an e-signature in an e-government application first needs to address himself to the appropriate
CSP (typically outside of his own borders), thus creating a significant barrier to uptake by non-
nationals.
This situation seems rather contrary to the goal expressed in article 3.7 of the Directive, which stated
that any additional requirements imposed on the use of e-signatures within public sector applications
should be “objective, transparent, proportionate and non-discriminatory and shall relate only to the
specific characteristics of the application concerned.” Given the fact that most surveyed countries
have chosen or are evolving to one blanket model for all e-government applications requiring an
electronic signature, the practical consequence is that any imposed requirement covers a large
number of applications, regardless of its exact functionality, and that it practically stops non-nationals
from using foreign e-signature applications. It seems doubtful that national practices in this regard can
be reconciled with the Directive’s objectives of creating an Internal Market for e-signatures, an
ambition which included the public sector.
From a technical point of view standard and market trends are in general followed by applications.
This is a normal behaviour for any application in order to reduce development costs and deployment
delay (why re-invent the wheel when it already exists).
The availability and the usage of a national/sectoral/regional framework to authenticate users and to
provide e-signature services also reduce the deployment delay.
The natural evolution in the design of applications has to follow:
1. The national regulatory framework
2. The standards and the market trends
The observed trend concerning the application design is a tendency to migrate from the model 4 to
the model 3 in all cases where a legal and procedural framework exists at the national level.
Where technical frameworks are available at the national/sectoral/regional level a migration from the
model 3 to the model 1/2 can be observed.
The present situation concerning the European full interoperability is that we have a gap of guidance
between the regulation (enforce interoperability) and the way to achieve it at the organisational and
technical level. This situation leads to a situation where the Member States have to rely on
153
November 2007
themselves to establish interoperability, e.g. via bilateral or multilateral agreements. There appears to
be an urgent need for Community initiative in this domain.
The evolution of applications to a European e-signature full interoperability service for citizens or
businesses should follows the same rules (availability of a framework at the European level).
To answer one of the major issues that eGovernment applications are facing, i.e. signature validation,
the most significant recommendation is to set-up a Federation of Validation Authorities.
The concept is based on a unique European Validation Authority Gateway that would only act as a
gateway between National Validation Authorities of the Member States. In our model, to validate an
eSignature, an eGovernment application deployed in country X would have to contact its own
National Validation Authority. If the certificate used to electronically sign originated from a
Certification Authority of country Y, then the Validation Authority from country X would have to
contact the European Validation Authority Gateway, which will in its turn redirect the validation
request to the National Validation Authority of country Y. The whole validation process will be done in
country Y in compliance with the national rules governing the certification authority and with the
knowledge of the semantics behind the certificate fields.
As we know that not all Member States will set-up a National Validation Authority (like country Z in the
figure) or perhaps not all at the same time, we also propose to set-up a Generic Validation Authority
at the European level allowing eGovernment applications of Member States which do not have a
National Validation Authority to participate to the Federation anyway.
We propose to build this European Generic Validation Authority on the basis of the European
Bridge/Gateway CA. In addition to the services provided by the EBGCA, i.e. distribution of Trusted
Status Lists, we suggest to implement certificate validation services for all CSPs belonging to
Member States which have not set-up their own National Validation Authority.
Validation Authority Federation

EBGCA Root
Web Services
Root
Root Root
TSLs CA
CA
CA
CAs
EU Validation Authority Gateway
Generic Validation Authority
Web Services
crl – ocsp
Request signature
Request signature
validation
... ... ...

validation
crl – ocsp National Validation National Validation

Authority Authority
User
certificate
Web Services Web Services
Request certificate Request signature Request signature
status validation validation
eGov eGov eGov

apps apps apps
Sign Sign
Sign Sign User
User
certificate
certificate
Country Z Country X Country Y
154
November 2007
The main advantage of the whole concept is to provide a step-wise approach allowing Member States
to set-up a National Validation Authority at their best convenience, not necessarily at the same time in
every Member State.
155
November 2007
8 Annex A: Patterns Cross-comparison
8.1 The Comprehensive regulatory approach

The eGovernment applications are filtered on the “comprehensive” regulatory approach.
Country Regulatory Sectors Model Application/Service Signature

approach Name type
Austria Comprehensive eTax, eVAT model 2 FINANZOnline ( simple –
http://finanzonline.bmf.gv. qualified
at ) signature
Austria Comprehensive Horizontal model 2 Electronic delivery simple –
(www.zustellung.gv.at) qualified
signature
Austria Comprehensive Residence model 2 Meldebestätigung simple –
(https://meldung.cio.gv.at/ qualified
egovMB/) signature
Austria Comprehensive Social Security model 2 Versicherungszeitenausz simple –
ug – Link qualified
signature
Austria Comprehensive eProcurement model 2 Public Procurement (pilot Qualified
project tested with std AT signature
certificate on smart card)
Slovenia Comprehensive eTax model 3 e-Taxes Qualified
(http://edavki.durs.si) certificate
Slovenia Comprehensive Horizontal model 3 e-SJU – Portal for Qualified
electronic services of certificate
public administration
(http://e-
uprava.gov.si/storitve/)
Slovenia Comprehensive Custom model 3 EPOS (e-business) Qualified
certificate
Slovenia Comprehensive Statistics model 3 Intrastat (http://intrastat- Qualified
surs.gov.si/) certificate
Slovenia Comprehensive Horizontal model 3 One-Stop-Shop - State Qualified
Portal for businesses certificate
(http://evem.gov.si)
Slovenia Comprehensive eBusiness model 3 Annual Reports Qualified
certificate
Slovenia Comprehensive eBusiness model 3 Financial Accounts Qualified
Statistics certificate
Slovenia Comprehensive Salary Report model 3 Salary Reporting Qualified

certificate
Slovenia Comprehensive eTax model 3 Multilateral Compensation Qualified
certificate
Slovenia Comprehensive Environment model 3 Development IS on waste Qualified

management field. certificate
Slovenia Comprehensive eHealth model 3 On-line access to health Advanced /
insurance data Qualified
certificate
156
November 2007

approach Name type
Slovenia Comprehensive Agriculture model 3 E-business in agriculture Qualified
certificate
Slovenia Comprehensive Animal model 3 Animal disease Qualified

notification system – certificate
ADNS
Slovenia Comprehensive model 3 Registration Authority Qualified
Application certificate
Spain Comprehensive eTax, eVAT model 3 Taxes at Virtual Office Advanced /

Qualified
signature
Spain Comprehensive education model 2 Registro Telemático Advanced
(Online Registry) signature
Spain Comprehensive Social Security model 3 DELT@ (Declaración Advanced
Electrónica de signature
Trabajadores
Accidentados)
Spain Comprehensive Information model 2 PROFIT Política Advanced /
society Industrial (AVANZ@) Qualified
signature
Spain Comprehensive eJustice model 3 LexNet Qualified
signature
Spain Comprehensive Insurance model 3 RESEVI Advanced
signature
Italy Comprehensive education model 2 Uniwex. Qualified
signature
Italy Comprehensive eTax model 2 Unimoney. Qualified
signature
Italy Comprehensive eTax model 2 Telemaco, Signed Qualifiied
Electronic Filing for signature
Business Entities –
Balance Sheets
Italy Comprehensive eJustice model 2 PCTT (Processo Civile Qualified
Telematico) signature
Italy Comprehensive eProcurement model 2 Intercent-ER. Qualified
signature
Italy Comprehensive eTax model 3 Servizi telematici Entratel Qualified
e Fisconline. signature
Italy Comprehensive eHealth model 4 Project CRS-SISS (Carta Advanced
Regionale dei Servizi – signature
Sistema Informativo
Socio Sanitario).
Germany Comprehensive eProcurement model 2 eVergabe Advanced /
Qualified
signature
Germany Comprehensive Environment model 2 DEHSt Virtual Post Office Qualified
(VPS2) signature
Germany Comprehensive eJustice model 3 OptiMahnOffice Qualified
signature
Turkey Comprehensive eBusiness model 3 Inward Processing Qualified
Regime certificate
157
November 2007
8.2 The Centralised regulatory approach

The eGovernment applications are filtered on the “centralised” regulatory approach.
approach Name type
Belgium Centralised eTax model 2 Tax-on-Web simple -

qualified
signature
Czech Centralised eProcurement model 3 Publication system Qualified
Republic on public contracts – certificate
publication
subsystem
(eNotification).
Czech Centralised Horizontal model 3 Government Qualified
Republic Gateway - DIS certificate
system
Denmark Centralised eProcurement model 2 ETHICS advanced
signature
Denmark Centralised eTax model 2 TastSelv Borger advanced
signature
Denmark Centralised Horizontal model 2 Virk.dk – a advanced
government portal signature
for Danish
businesses
Denmark Centralised Horizontal model 2 Provide the advanced
Application/Service signature
Name: Netborger.dk
Estonia Centralised voting model 2 Internet Voting Qualified
signature
Finland Centralised Horizontal model 2 Lomake.fi public Qualified
sector online forms certificate
service
Finland Centralised eTax model 2 ElmaTYVI Pro Qualified
certificate
Finland Centralised patent model 3 Epoline eOLF Qualified
(Epoline Online certificate
Filing)
Hungary Centralised eBusiness model 3 Electronic Firm Advanced
Registration/Electron signature
ic Company Register and
Qualified
certificate(f
or some
functions)
Hungary Centralised Horizontal model 3 Registration on the Qualified
Client Gate certificate
158
November 2007

approach Name type
Hungary Centralised eTax model 3 Electronic tax and Advanced

contribution signature
declarations for
citizens & for
entrepreneurs
Hungary Centralised eHealth model 3 Declaration of Advanced
persons entitled for signature
health insurance:
Hungary Centralised eHealth model 3 DSend system Advanced
Electronic signature
messaging system
transmitting time
stamped and
encrypted messages
certified with
electronic signature
Hungary Centralised ePension model 3 Electronically Qualified
authenticated private certificate
pension fund and
declarations system Advanced
signature
Hungary Centralised Horizontal model 3 e-Önkormányzat – Advanced
eLocal Government signature /
Portal of the Local Qualified
Government of certificate
Budapest 13th
district
Hungary Centralised Horizontal model 3 e-Local Government Advanced
system of the Local signature /
Government of Qualified
Hódmez•vásárhely, certificate
City with County
Rights
Latvia Centralised eTax model 4 Electronic Simple
Declaration System signature
(EDS)
The Centralised eProcurement model 3 TenderNed Qualified
Netherlands certificate
The Centralised eTax, eVAT model 2 Elektronische Qualified
Netherlands aangifte certificate
Poland Centralised Personal Data model 3 e-GIODO Qualified
Protection certificate
Portugal Centralised eProcurement model 3 Online Incorporation Qualified
of companies signature /
Advanced
signature
159
November 2007

approach Name type
Romania Centralised eTax model 3 National Electronic Qualified

System, component certificate
e-government.
Romania Centralised eProcurement model 3 e-Procurement (e- Qualified
licitatie) certificate
Slovakia Centralised Custom model 2 EKR – Electronic Advanced
communication signature
interface
Slovakia Centralised Trade model 1 eServices of Trade Qualified
Register signature
Slovakia Centralised eTax model 3 eTax – Online Qualified
electronic services ( signature
http://www.drsr.sk )
Slovakia Centralised eProcurement model 4 Electronic Public Advanced
Procurement (EVO) signature
– eTendering
module
Sweden Centralised eTax model 2 eINK, Personal Qualified
income taxes signature
declarations
Sweden Centralised eTax, eVAT model 3 eSKD (Electronic Qualified
Tax Return) signature
Sweden Centralised eBusiness model 3 Företagsregistrering Qualified
(Company signature
Registration
eService)
France Centralised eVAT model 3 TeleTVA Advanced
signature
France Centralised eTax model 3 TeleIR Advanced
signature
France Centralised eProcurement model 3 Achatpublic.com Advanced
signature
France Centralised eTax model 3 impots.gouv.fr Advanced
signature
France Centralised eTax model 3 Tele-c@rtegrise Advanced
signature
Croatia Centralised eVAT model 3 e-VAT Qualified
certificate
Croatia Centralised ePension model 3 e-Pension Insurance Qualified
Registration (e- certificate
Mirovinsko)
Czech Centralised eTax model 3 Tax-on-Web Qualified
Republic certificate
160
November 2007
8.3 The eProcurement sector

The eGovernment applications are filtered on the eProcurement sector.

approach Name type
Austria Comprehensiv eProcurement model 2 Public Procurement Qualified
e (pilot project tested signature
with std AT certificate
on smart card)
Bulgaria AdHoc Fw eProcurement model 3 Electronic market for Qualified
small public certificate
procurements:
Czech Centralised eProcurement model 3 Publication system on Advanced
Republic public contracts – signature
publication subsystem
(eNotification).
Denmark Centralised eProcurement model 2 ETHICS advanced
signature
The Centralised eProcurement model 3 TenderNed Qualified
Netherlands signature
Romania Centralised eProcurement model 3 e-Procurement Qualified
(http://www.e- certficate /
licitatie.ro). Advanced
signature
Slovakia Centralised eProcurement model 4 Electronic Public Advanced
Procurement (EVO) – signature
eTendering module
Italy Comprehensiv eProcurement model 2 Intercent-ER. Qualified
e signature
France Centralised eProcurement model 3 Achatpublic.com Advanced
signature
Germany Comprehensiv eProcurement model 2 eVergabe Advanced
e signature /
Qualified
signature
161
November 2007
8.4 The eTax and eVAT sectors

The eGovernment applications are filtered on the eTax and eVAT sectors.
Country Regulatory Sectors Model Application/Servic Signature

approach e Name type
Austria Comprehensive eTax, model 2 FINANZOnline simple –
eVAT qualified
signature
Belgium Centralised eTax model 2 Tax-on-Web simple –
qualified
signature
Bulgaria AdHoc Fw eTax model 2 Online submission Qualified
of annual income certificate
tax declarations
Bulgaria AdHoc Fw eVAT model 2 VAT on Internet Qualified

certificate
Denmark Centralised eTax model 2 TastSelv Borger advanced
signature
Finland Centralised eTax model 2 Lomake Qualified
certficate
Finland Centralised eVAT model 2 ElmaTYVI Pro Qualified
certficate
Hungary Centralised eTax model 3 Electronic tax and Advanced
contribution signature
declarations for
citizens & for
entrepreneurs
Ireland Sector based eTax model 4 Revenue On-line Qualified
Service ROS signature
Latvia Centralised eTax model 4 Electronic Simple
Declaration System signature
(EDS)
The Centralised eTax, model 2 Elektronische qualified
Netherland eVAT aangifte certficate
s
Romania Centralised eTax model 3 National Electronic Qualified
System, component signature
e-government.
Slovenia Comprehensive eTax model 3 e-Taxes Qualified
certificate
Slovenia Comprehensive eTax model 3 Multilateral Qualified
Compensation certificate
Slovakia Centralised eTax model 3 eTax – Online Qualified
electronic services signature
162
November 2007
Country Regulatory Sectors Model Application/Servic Signature

approach e Name type
Spain Comprehensive eTax, model 3 Taxes at Virtual Advanced /
eVAT Office Qualified
signature
Sweden Centralised eTax model 2 eINK, Personal Advanced
income taxes signature
declarations
Sweden Centralised eTax, model 3 eSKD (Electronic Advanced
eVAT Tax Return) signature
France Centralised eVAT model 3 TeleTVA Advanced
signature
France Centralised eTax model 3 TeleIR Advanced
signature
signature
signature
Italy Comprehensive eTax model 2 Unimoney. Qualified
signature
Italy Comprehensive eTax model 2 Telemaco, Signed Qualified
Electronic Filing for signature
Business Entities –
Balance Sheets
Italy Comprehensive eTax model 3 Servizi telematici Qualified
Entratel e signature
Fisconline.
signature
signature
Croatia Centralised eVAT model 3 e-VAT Qualified
certificate
Czech Centralised eTax model 3 Tax-on-Web Qualified
Republic certficate
163
November 2007
9 Annex B: Technical trends summarized

In section “4.2.1 Application approach models” technical trends by model are presented. This annex
summarized the values.
Note: In this summary, two phenomenon can appear:
• The sum is greater than the number of surveyed applications (90). This is the case when e.g.
one application supports several token types;
• The sum is lower than the number of surveyed applications (90). This can happen because
not all applications have answered all questions of the survey questionnaire.
Qualified Qualified
Signature type simple advanced
certificate signature
10 37 39 25
Virtual
Smart
Token type user/pass soft USB smart
Card
card
6 43 23 71 4
Signed
document type
18 12 14 10 4
Adobe Applet/Active other

Signing tool eMail client
Acrobat X tools
5 26 1 20
The type of signature which detaches clearly of the general tendency is "qualified/based on qualified
certificate". However the type of signature "advanced" is always quite present.
The figure below represents the signature type support by applications.
164
November 2007
Signature type
45
40
35
30
25
20
15
10
5
0
si mpl e advanced Qual i f i ed cer ti f i cate Qual i f i ed si gnatur e
Applications have stated that they support multiple type of token but the most supported one is the
Smart card.
The figure below represents the token type support by applications.
Token type
80
70
60
50
40
30
20
10
0
Car d
type of signed document but this not a general trend.
The figure below represents the trend for application (“files” means not PDF and not XML file type).
165
November 2007
20
18
16
14
12
10 Series1
8
6
4
2
0
XM L PDF Web-Form files ASCII
The figure below represents the usage of signing tool type.
Signing tool
30
25
20
15 Series1
10
0
Adobe Acrobat Applet / Act iveX eM ail client other t ools
Example of other signing tools (extracted from the country profiles):
Italy “Project CRS-SISS (Carta Regionale dei Servizi – Sistema Informativo Socio
Sanitario) » application:
Answer: “…Signature application implemented by CRS-SISS project....”
166
November 2007

(eNotification) » application:
Answer: “…On-line version works only on Internet Explorer 6.0 XML602 Filler woks only
on Windows....”
Hungary “Electronic Firm Registration/Electronic Company Register” application:
Answer: “…They use ‘e-Szignó’, a professional signature creation application capable of

creating ETSI TS 101 903 compliant XML signatures.....”
Bulgaria “Online submission of annual income tax declarations” and “VAT on

Internet”applications:
Answer: “…For the purposes of signing in .p7s format of the files that are to be attached,
a particular software DSTOOL is used. This software is freely downloadable from the
website of NIA....”
167
November 2007
Italy “Telemaco, Signed Electronic Filing for Business Entities –Balance Sheets”
application:
Answer: “A software to sign the electronic declaration according to the Italian laws.
“Dike” is the InfoCamere free software for the digital signature available for Windows,
Mac platforms and a Linux distribution….”
168

IDABC Recognition Esignatures

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IDABC Recognition Esignatures

Uploaded by

Copyright:

Available Formats

Preliminary Study on Mutual Recognition of

eSignatures for eGovernment applications

Author’s name: Siemens - Time.lex

Contract No. 1, Framework contract ENTR/05/58-SECURITY, Specific contract N°1

This paper can be downloaded from the IDABC website:

© European Communities, 2007

4.2.2.5 Model 4: Application Specific CSP model 72

5 IMPACT ASSESSMENT AND RECOMMENDATIONS 92

5.4.1.1 Problem description 144

6 LIST OF RECOMMENDATIONS 150

8 ANNEX A: PATTERNS CROSS-COMPARISON 156

9 ANNEX B: TECHNICAL TRENDS SUMMARIZED 164

1.1 Applicable Documents

[AD1] Framework Contract ENTR/05/58-SECURITY

1.2 Reference Documents

o Advanced electronic signature: an electronic signature which meets the following

A2A ..............................................Administration to Administration

A2B .............................................. Administration to Businesses

A2C .............................................. Administration to Citizens

CA................................................ Certification Authority

CRL.............................................. Certificate Revocation Lists

CSP.............................................. Certificate Service Provider

eID ...............................................Electronic Identity

OCSP ...........................................Online Certificate Status Protocol

PKCS ...........................................Public-Key Cryptography Standards

PKI ...............................................Public Key Infrastructure

SA ................................................ Supervision Authority

SOAP ........................................... Simple Object Access Protocol

SCVP ...........................................Server-based Certificate Validation Protocol

SSCD ...........................................Secure Signature Creation Device

USB.............................................. Universal Serial Bus

TTP ..............................................Trusted Third Party

TSA..............................................Time Stamp Authority

TST ..............................................Time Stamp Token

XAdES ......................................... XML Advanced Electronic Signature

XML ............................................. eXtensible Markup Language

XML-DSIG.................................... XML Digital Signature

This report aims at:

- prepare conclusions and recommendations on addressing interoperability issues related to

4.1 eGovernment and eSignature regulations

4.1.1 The European legal framework

4.1.1.1 Basic principles

4.1.1.2 Public sector clause: article 3.7

“Article 3 – Market Access

“Also, the Directive’s rules on voluntary accreditation seem to be misunderstood by national

Finally, in its recommendations, the ELSIGN Study stated:

4.1.1.3 eSignatures and authentication

Example: the Maltese approach:

4.1.2 National regulatory approach models

4.1.2.1 General strategy

Example: the Belgian approach:

Country Normative source:

Example: the Austrian approach:

Example: the German approach:

Country Normative source:

4.1.2.1.3 Sector Based

Example: the Maltese approach:

i. the Inland Revenue Department’s (IRD) eGovernment services for:

ii. the Vehicle Licenses Online for:

Country Normative source:

4.1.2.1.4 Ad hoc legal frameworks

Example: the Bulgarian approach:

A similar situation presently exists in Slovenia: