eu-publi.com

Transcript

eu-publi.com

EU-PUBLI.COM:
Facilitating Co-operation amongst European Public Administration
employees through a Unitary European Network Architecture and the
use of Interoperable Middleware Components
SUMMARY
KEYWORDS
e-Government, Interworkflows, Web services,
Public Administration
Architecture, Common
European Administration
Space, Cooperative
information systems
The EU-Publi.com project introduces information technology in order to
facilitate inter- European collaboration amongst Public Administration employees.
Mature and leading edge information technology solutions in the form of
middleware components and Web services are employed in order to achieve
interoperability. These components are structured in a technical architecture
referred to as the UEN (Unitary European Network). Amongst the important items
to be addressed is the conceptual compatibility and homogenization amongst the
European PA’s in the areas of interest of the user partners of the project. This is
attained through a Public Administration architecture that models data and
processes in order to make explicit their commonality or correspondence.
PROBLEM
Web Site
www.eu-publi.com
Fig1: A macro-process
Business
PROJECTSHOWCASES
Business
Web
Services
Web
Services
ITALIAN
USERPARTNER •Info Provision
GREEK
USERPARTNER
•FormFilling
Governments around the world are introducing electronic government.
Practically all governments are making available critical information online,
streamlining their processes through the use of information and communication
technology and interacting electronically with their customers (e.g. citizens,
businesses). Defined broadly, e-government is the use of information and
communication technology to promote more efficient and effective government,
facilitate more accessible government services, allow greater public access to
information and make government more accountable to citizens. However, in
order to obtain successful results from e-government, changes are required in
many aspects of how Public Administration works.
The EU-Publi.com project attempts to introduce such changes in the particular
area of facilitating cooperation amongst Public Administration employees. The
cooperation that is sought in the project is defined broadly involving employees of
Public Administrations in different European countries. However the results can be
applied to facilitate co-operation among Public Administration organizations within
the same European country as well as employees of a single Public Administration
organization across different departments.
The high-level objective of the EU-Publi.com project is to make advances in the
general area of a common European Public Administration space. In such a space
a European Citizen will be able to request a service that will trigger processes that
cut across more than one national European administration, the execution of
which will be appropriately coordinated.
Currently, typical processes executed by Public Administration employees are
fragments of a larger whole that is identifiable through the service it provides to
the end customer (e.g. citizen). Relating these processes in terms of causal
relationships macro-processes can be established that typically extend over
several Public Administration organizations. A typical macro-process starts in one
public administration organization, the workflow then moves to another public
administration organization, and onto a third and so on. As an example, the
Figure above shows a very fragmented macro-process for providing aid to
disabled persons, which could require up to 20 interactions with various Public
Administration organizations including the Department of Internal Affairs and its
peripheral units (i.e. Prefectures), the Department of Treasury, the local health
authority, and the City Council.
•Two-way interaction
•Transaction
National
Web
Services
Web
Services
Web
Services
National
Web
Services
MockWS
Web
Services
Fig 2: EU-Publi.com Showcase
AIM
The EU-Publi.com project attempts to achieve interoperability amongst Public
Administration organizations by defining a Unitary European Network Architecture
into which the collection of distributed, autonomous systems of each Public
Administration can be brought together into a common cooperative environment.
In turn, this will act as a framework for the development of new and the
reengineering of existing European Public Administration processes in order to be
made suitable for facilitated cooperation.
Contract No: IST-2001-35217
Date:
1 May 2002
Duration:
36 months
EC funding: 1.280.000 Euro
TECHNICAL APPROACH
The software (middleware) components that are developed as part of the EUPubli.com project employ state-of-the-art in middleware technology based on the
Web services paradigm that exhibits simplicity and scalability. In order to apply
such component-based approaches, current Public Administration processes need
to be suitably re-packaged.
Developing software (middleware) components that will implement the
interoperability features in a generic enough fashion to render them reusable in
multiple Public Administration domains as well as in the current integration issues
that the user partners face, is an important challenge for the EU-Publi.com
project.
Since the e-services that will be prototyped as part of the EU-Publi.com project,
are new the scenarios of Public Administration cooperation must be envisioned
rather than modeled after an existing service. Scenarios are sought that provide
macro-processes that are both “interesting” as well as representative of the types
of interactions that can occur in Public Administration.
The EU-Publi.com architecture is layered thus enforcing the important
separation of concerns between the design of added-value and business-aware
services, and their actual deployment. As shown in the Figure aside, the EUPubli.com architecture consists of three functional layers for Transport,
Interoperability and Cooperative Service. The transport service layer consists of
standard TCP/IP. The basic service layer includes information resources such as
e-mail, file transfer, and Web access. The middleware in the cooperative service
layer facilitates the development and deployment of applications among
administrations. The Cooperative Service layer includes the middleware services
that enable the development and deployment of new inter-administrations
cooperative applications.
In order to guarantee quality of service (QoS) to clients of the EU-Publi.com
system, fault tolerance and high availability are considered as key issues. EUPubli.com specifications will build on the notion that services offered in the Public
Administration domain must be highly available. In particular their overall
availability must be such that will allow employees and administrations to trust
the system but also developers to implement cooperative applications trusting the
availability of the systems involved. This requirement can be satisfied only by
enforcing fault tolerance and high availability policies at the different levels of the
EU-Publi.com architecture, exploiting different techniques such as Transport
Service Layer Availability, Domain Services Availability, Server Availability etc.
EXPECTED RESULTS
EU-Publi.com allows the Public Administration employee to cooperate more
easily with other Public Administration employees at the intra-organization, interorganization as well as at the European level. By enabling interoperability
amongst currently heterogeneous Public Administrations, EU-Publi.com will bring
about new e-services for Public Administration. For example,
• the European citizen will be provided with seamless Public Administration
services at the organization, national and European level,
• European Public Administrations will be able to gradually offer the
European citizen certain common European Public Administration
services.
In particular, the common European Public Administration architecture and the
interoperability components that are developed as part of the EU-Publi.com
project can serve as a standardized and reusable infrastructure on the basis of
which other common European Public Administration services can be composed in
a modular fashion from existing national services. Following this common
cooperative architecture, Public Administration organizations can expose an
increasing part of their external services in successive iterations.
Customers
EU-Publi.com Public Administration Processes
(services offered to citizens, organizations, etc.)
human-centered and application-centered-automation
human-centered
automation
Nationwide CIS
CIS of
Area 1
CIS of
Area 2
CIS of
Area N
Cooperative service layer
Basic service layer
(e-mail, file transfer, www access, etc.)
Transport service layer
(standard TCP/IP Internet protocols)
Fig 3: Cooperative Architecture
PARTNERS
Centre for Research &
Technology Hellas /
Informatics & Telematics
Institute, EL
University of Rome “LA
SAPIENZA” / Department
of Computer and Systems
Science (DIS), IT
Ibermática S.A., SP
Altec Information and
Communication Systems
S.A., EL
Prefecture of
Thessaloniki, EL
Italian Institute for
Foreign Trade, IT
United Nations
Thessaloniki Centre for
Public Service
Professionalism, EL
COORDINATOR
Prof. K. Tarabanis
CERTH / ITI
6th km Charilaou-Thermi rd,
57001, Thermi-Thessaloniki
Tel: (+30) 310 891 578
Fax: (+30) 310 891 649
E-mail: [email protected]
INFORMATION SOCIETY TECHNOLOGIES
(IST)
PROGRAMME
EU-PUBLI.COM
Facilitating Co-operation amongst European Public Administration employees
through a Unitary European Network Architecture and the use of Interoperable
Middleware Components
D1.1
Project Presentation and State of the Art
Prepared for the European Commission
under Contract No. IST-2001-35217 as a deliverable from
WP 1 – Overall Model Design and Specification
Date of issue: 06/08/2002
Project Coordinator:
CERTH/ITI
Centre for Research and Technology Hellas/ Informatics and Telematics Institute
Greece
Partners:
UNIROMA
University of Rome “La Sapienza”/ Dipartimento di Informatica e Sistemistica
Italy
IBERMATICA
Ibermática S.A.
Spain
ALTEC
Altec Information and Communication Systems S.A.
Greece
ICE
Italian Institute for Foreign Trade
Italy
NATH
Prefecture of Thessaloniki
Greece
UNTC
United Nations Thessaloniki Centre for Public Sector Professionalism
Greece
PUBLIC
Dissemination Level
Distribution List
Written by:
Prof. Roberto Baldoni
Massimo Mecella
Mariangela Contenti
Alessandro Termini
UNIROMA
Prof. Konstantinos Tarabanis
Vasso Parousi
CERTH/ITI
(Chapter 1)
Elina Syritzidou
Fotini Vogiatzi
NATH
(Section 3.2)
Document Change Log
Version #
Draft D1.1
D1.1
Issue Date
20/07/2002
06/08/2002
Sections Affected
All
All
D1.1: Project Presentation and State of the Art
Relevant Information
Page 2
Table of Contents
1
PROJECT PRESENTATION ...................................................................................................7
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
2
INTRODUCTION ......................................................................................................................8
OBJECTIVES ...........................................................................................................................8
BENEFITS .............................................................................................................................10
KEY MILESTONES ................................................................................................................10
INNOVATION ........................................................................................................................11
TARGET MARKETS ...............................................................................................................12
PROJECT CONSORTIUM ........................................................................................................14
REFERENCES ........................................................................................................................15
TECHNICAL ASPECTS .........................................................................................................16
2.1
BASIC PROTOCOLS ...............................................................................................................16
2.1.1
TCP/IP (Transmission Control Protocol / Internet Protocol)....................................16
2.1.1.1 How TCP Works.....................................................................................................16
2.1.1.2 TCP Features...........................................................................................................17
2.1.1.3 Connection Types ...................................................................................................17
2.1.1.4 TCP and IP Service Users.......................................................................................17
2.1.2
Telnet...........................................................................................................................18
2.1.2.1 Telnet Server...........................................................................................................18
2.1.2.2 Telnet Client............................................................................................................19
2.1.3
FTP (File Transfer Protocol)......................................................................................19
2.1.4
HTTP (Hyper Text Transfer Protocol) .......................................................................20
2.1.5
e-mail Protocols..........................................................................................................22
2.1.5.1 MIME and SMTP ...................................................................................................22
Other Encoding Standards ..................................................................................................22
Advantages and Disadvantages of SMTP...........................................................................22
2.1.5.2 Client Mail Retrieval with POP and IMAP ............................................................22
POP3 (The Post Office Protocol version 3)........................................................................22
IMAP (The Internet Mail Access Protocol)........................................................................23
POP3 Versus IMAP4 ..........................................................................................................23
2.2
COOPERATIVE TECHNOLOGIES.............................................................................................23
2.2.1
Object Oriented Middleware ......................................................................................24
2.2.1.1 OMG CORBA (OMG Common Object Request Broker Architecture).................24
Overview.............................................................................................................................24
Technical Details ................................................................................................................25
CORBA Services ............................................................................................................26
CORBA Facilities ...........................................................................................................26
Application Objects ........................................................................................................26
Object Implementation....................................................................................................27
ORB Core........................................................................................................................27
ORB Interface .................................................................................................................28
IDL Stubs ........................................................................................................................28
Dynamic Invocation Interface (DII) ...............................................................................28
Object Adaptor................................................................................................................28
Skeleton...........................................................................................................................28
Page 3
Dynamic Skeleton Interface (DSI)..................................................................................28
CORBA Compliance ......................................................................................................28
2.2.1.2 COM – DCOM (Distributed Component Object Model) .......................................29
Technical Details ............................................................................................................30
Discussions .....................................................................................................................32
Costs and Limitations .....................................................................................................33
2.2.1.3 CTM Framework (Component Transaction Monitors Framework) .......................33
MTS (Microsoft Transaction Monitor)...............................................................................34
Sun CTM.............................................................................................................................34
CORBA CTM .....................................................................................................................35
Benefits of a Standard Server-Side Component Model......................................................35
2.2.1.4 Microsoft .NET .......................................................................................................36
The .NET Framework .........................................................................................................37
2.2.1.5 Sun EJB (Sun Enterprise Java Beans) ....................................................................39
Enterprise JavaBeans goals.................................................................................................39
How an EJB client/server system works.............................................................................40
The Enterprise JavaBeans Component ...........................................................................40
The Enterprise JavaBeans Ccontainer ............................................................................40
The EJB Object and the Remote Interface......................................................................40
Types of Enterprise JavaBeans .......................................................................................41
Creating Server-Side Beans: the Home Interface ...............................................................42
Using Server-Side Beans: the Remote Interface.................................................................43
2.2.1.6 CCM (CORBA Component Model) .......................................................................44
2.2.2
Message Oriented Middleware ...................................................................................49
2.2.2.1 IBM Websphere MQ (MQ Series)..........................................................................49
Introduction.........................................................................................................................49
Queue Managers .................................................................................................................49
Queue Opening ...................................................................................................................50
Putting and Getting Messages.............................................................................................50
Messaging and Queue Managers ........................................................................................50
2.2.2.2 Sun JMS (Java Messaging Service)........................................................................51
Introduction.........................................................................................................................51
The JMS Environment ........................................................................................................51
JMS Essentials ....................................................................................................................52
Publish/Subscribe Messaging .........................................................................................52
Point-to-Point Messaging................................................................................................52
Quality of Service ...........................................................................................................53
Message Selectors...........................................................................................................53
2.2.2.3 TIB/Rendezvous .....................................................................................................54
Architecture.........................................................................................................................54
Communication...................................................................................................................55
Primitives ............................................................................................................................55
2.2.3
Web Oriented Middleware..........................................................................................56
2.2.3.1 XML (eXensible Markup Language)......................................................................56
2.2.3.2 SOAP (Simple Object Application Protocol) .........................................................58
2.2.3.3 Language for Web-Services....................................................................................59
WSDL and WSCL (Web Services Description and Conversation Language) ...................59
ebXML CPP and CPA (Collaboration Protocol and Agreement) ......................................60
2.2.3.4 Repositories for Web-Services ...............................................................................61
Page 4
UDDI (Universal Description, Discovery and Integration)................................................61
ebXML Registry .................................................................................................................62
2.2.3.5 Coordination of Web-Services................................................................................64
WSFL (Web Service Flow Language)................................................................................64
ebXML BPSS (ebXML Business Process Specification Schema) .....................................65
2.3
SECURITY.............................................................................................................................66
2.3.1
Introduction.................................................................................................................66
2.3.1.1 Network Security Model.........................................................................................67
2.3.1.2 Cryptography ..........................................................................................................69
Symmetric encryption.........................................................................................................69
Asymmetric encryption.......................................................................................................70
2.3.1.3 Digital Signature .....................................................................................................70
Certificate............................................................................................................................71
2.3.2
Security Protocols.......................................................................................................72
2.3.2.1 IPSec (Internet Protocol Security) ..........................................................................72
2.3.2.2 SSL/TSL (Secure Socket Layer / Transport Layer Security) .................................74
SHTTP (Secure HTTP).......................................................................................................75
2.3.2.3 PGP (Pretty Good Privacy) and S/MIME (Secure MIME) ....................................77
2.3.2.4 WS-Security (Web Services-Security) ...................................................................78
Credential Exchange ...........................................................................................................78
Message Integrity................................................................................................................79
Message Confidentiality .....................................................................................................79
2.3.2.5 SAML (Security Assertion Markup Languange)....................................................80
2.3.3
Access Control ............................................................................................................81
2.3.3.1 Firewall ...................................................................................................................81
2.3.3.2 VPN (Virtual Private Network) ..............................................................................83
Remote access client connections.......................................................................................83
LAN-to-LAN internetworking............................................................................................84
Controlled access within an intranet ...................................................................................84
VPN Protocols ....................................................................................................................84
PPTP (Point-to-Point Tunneling Protocol) .....................................................................84
L2TP (Layer Two Tunneling Protocol) ..........................................................................85
IPSec (Internet Protocol Security) ..................................................................................85
SOCKS Network Security Protocol................................................................................85
VPN Hardware and Software..........................................................................................85
2.3.4
Authentication and Indentification .............................................................................85
2.3.4.1 Password .................................................................................................................85
2.3.4.2 Smartcard ................................................................................................................86
2.3.4.3 Biomedical Data......................................................................................................86
2.3.4.4 Certificate X509 v3.................................................................................................86
2.3.4.5 Kerberos..................................................................................................................88
2.4
HIGH AVAILABILITY AND FAULT TOLERANCE .....................................................................91
2.4.1
Replication Logic ........................................................................................................91
2.4.2
Non-CORBA Fault Tolerant Systems..........................................................................92
2.4.2.1 Arjuna .....................................................................................................................92
2.4.2.2 FRIENDS................................................................................................................93
2.4.2.3 COMERA (COM Exensible Remoting Architecture) ............................................95
2.4.3
CORBA Fault Tolerant Systems..................................................................................96
2.4.3.1 Interoperability limitations......................................................................................98
Page 5
FT Corba Overview ............................................................................................................98
2.4.3.2 IRL (Interoperable Replication Logic) .................................................................100
2.4.3.3 FTS (Fault Tolerance Service)..............................................................................100
A Design Overview of FTS ..............................................................................................101
2.4.3.4 Discussion .............................................................................................................102
2.5
REFERENCES ......................................................................................................................103
2.5.1
Basic Protocols .........................................................................................................103
2.5.2
Middleware and Web-Services .................................................................................103
2.5.3
Security .....................................................................................................................105
2.5.4
High Availability and Fault Tolerance .....................................................................106
3
LEGAL ISSUE ........................................................................................................................108
3.1
3.2
3.3
4
ITALIAN LAW .....................................................................................................................108
GREEK LAW .......................................................................................................................112
EU-PUBLI.COM LEGAL REQUIREMENTS ........................................................................117
CASE STUDY .........................................................................................................................118
4.1
INTRODUCTION TO E-GOVERNMENT ..................................................................................118
4.2
THE ITALIAN UNITARY NETWORK (RUPA) .......................................................................121
4.2.1
Introduction...............................................................................................................121
4.2.2
Cooperative Processes..............................................................................................122
4.2.3
The Cooperative Architecture...................................................................................125
4.2.3.1 Domains and Cooperative Gateways ....................................................................126
4.2.3.2 Types of Cooperative Systems..............................................................................126
4.2.3.3 Approaches to Cooperation...................................................................................127
4.2.4
Cooperative Projects ................................................................................................129
4.2.5
Discussion .................................................................................................................130
4.3
UK ON LINE PROJECT .......................................................................................................133
4.3.1
The Architectural Framework...................................................................................133
4.3.2
Standards and protocols ...........................................................................................135
4.3.3
Security and trust ......................................................................................................135
4.3.4
e-Government Interoperability Framework..............................................................136
4.4
FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK (FEAF) ...........................................137
4.4.1
The Framework.........................................................................................................139
4.4.1.1 Level I ...................................................................................................................139
4.4.1.2 Level II..................................................................................................................140
4.4.1.3 Level III ................................................................................................................142
4.4.1.4 Level IV ................................................................................................................144
4.5
OTHER COUNTRIES .............................................................................................................148
4.6
REFERENCES ......................................................................................................................151
5
APPENDIX..............................................................................................................................152
5.1
5.2
LIST OF FIGURES ................................................................................................................152
LIST OF TABLES .................................................................................................................153
Page 6
1 Project Presentation
Project acronym:
EU-PUBLI.COM
Project full title:
EU-PUBLI.COM: Facilitating Co-operation amongst European Public
Administration employees through a Unitary European Network Architecture
and the use of Interoperable Middleware Components
Project Logo:
Contract no:
IST-2001-35217
Duration:
36 months (May 2002 - April 2005)
Abstract:
The EU-Publi.com project introduces information technology in order to
facilitate inter- European collaboration amongst Public Administration
employees. Mature and leading edge information technology solutions in the
form of middleware components and Web services are employed in order to
achieve interoperability. These components are structured in a technical
architecture referred to as the UEN (Unitary European Network). Amongst
the important items to be addressed is the conceptual compatibility and
homogenization amongst the European PA’s in the areas of interest of the
user partners of the project. This is attained through a Public Administration
architecture that models data and processes in order to make explicit their
commonality or correspondence.
List of Key words:
e-Government, Inter-workflows, Web services, Public Administration
Architecture, Common European Administration Space, Cooperative
information systems
This project is being partially funded by the European Commission DG INFSO under the IST programme.
The content of this publication is the sole responsibility of the project partners listed herein and in no way
represent the view of the European Commission or its services.
Page 7
1.1 Introduction
Governments around the world are introducing electronic government. Practically all governments
are making available critical information online, streamlining their processes through the use of
information and communication technology and interacting electronically with their customers (e.g.
citizens, businesses). Defined broadly (Peristeras, Tsekos and Tarabanis, 2002), e-government is the
use of information and communication technology to promote more efficient and effective
government, facilitate more accessible government services, allow greater public access to
information and make government more accountable to citizens. However, in order to obtain
successful results from e-government, changes are required in many aspects of how Public
Administration works.
The EU-Publi.com project attempts to introduce such changes in the particular area of facilitating
cooperation amongst Public Administration employees. The cooperation that is sought in the project
is defined broadly involving employees of Public Administrations in different European countries.
However the results can be applied to facilitate co-operation among Public Administration
organizations, within the same European country as well as employees of a single Public
Administration organization across different departments.
1.2 Objectives
The high-level objective of the EU-Publi.com project is to make advances in the general area of a
common European Public Administration space. In such a space a European Citizen will be able to
request a service that will trigger processes that cut across more than one national European
administration, the execution of which will be appropriately coordinated.
Figure 1.1: A Common European Administration Space
Currently, typical processes executed by Public Administration employees are fragments of a larger
whole that is identifiable through the service it provides to the end customer (e.g. citizen). Relating
these processes in terms of causal relationships macro-processes can be established that typically
extend over several Public Administration organizations. A typical macro-process starts in one
public administration organization, the workflow then moves to another public administration
organization, and onto a third and so on. As an example, the Figure below shows a very fragmented
macro-process for providing aid to disabled persons, which could require up to 20 interactions with
various Public Administration organizations including the Department of Internal Affairs and its
peripheral units (i.e. Prefectures), the Department of Treasury, the local health authority, and the
City Council (Batini and Mecella, 2001).
Page 8
Figure 1.2: A macro-process
Fragmentation of responsibilities, frequent interruptions of processes inside a Public Administration
organization are currently commonplace. For example, Public Administration employees cannot
access all the information needed to complete their steps in the process, and a delay occurs while the
missing information is sought from another source. Often, the citizen serves as a messenger,
providing the information needed to establish communications between public administration
organizations. It has been estimated by studies that in the case of the Italian PA as an example, 38%
of the processes break during their execution because an administration needs information from
others, and currently these needs are satisfied through paper document and ordinary mail. When
addressing this case at a European level, the problems appear much more pronounced.
The difficulty of cooperation among different administrations not only results in inefficient
execution of such macro-processes and in the end, inefficient provision of services, but also in a
frustration amongst Public Administration employees. In order to enable Public Administration
employees to provide such e-government services, the EU-Publi.com project aims at achieving
interoperability amongst Public Administration organizations that will allow these organizations to
cooperate and collaborate more readily and effectively.
The EU-Publi.com project attempts to achieve this interoperability amongst Public Administration
organizations by defining a Unitary European Network Architecture into which the collection of
distributed, autonomous systems of each Public Administration can be brought together into a
common cooperative environment. In turn, this will act as a framework for the development of new
and the reengineering of existing European Public Administration processes in order to be made
suitable for facilitated cooperation.
Page 9
1.3 Benefits
EU-Publi.com allows the Public Administration employee to cooperate more easily with other
Public Administration employees at the intra-organization, inter-organization as well as at the
European level. By enabling interoperability amongst currently heterogeneous Public
Administrations, EU-Publi.com will bring about new e-services for Public Administration. For
example,
•
•
the European citizen will be provided with seamless Public Administration services at the
organization, national and European level,
European Public Administrations will be able to gradually offer the European citizen certain
common European Public Administration services.
In particular, the common European Public Administration architecture and the interoperability
components that are developed as part of the EU-Publi.com project can serve as a standardized and
reusable infrastructure on the basis of which other common European Public Administration
services can be composed in a modular fashion from existing national services. Following this
common cooperative architecture, Public Administration organizations can expose an increasing
part of their external services in successive iterations.
1.4 Key Milestones
In the EU-Publi.com project, interoperability amongst European Public Administrations is achieved
• by building a common European Public Administration architecture that addresses
conceptual interoperability of Public Administration services at the European level
(Tarabanis and Peristeras, 2002), and,
• by developing suitable software (middleware) components that will implement the
interoperability features for the Public Administration domain.
The domain in which the above will be developed in the EU-Publi.com project pertains to business
lifecycle management (i.e. establishing a business, dissolving a business, providing assistance to a
business etc.) since this subject area is of common interest to the project’s user partners.
Therefore, key milestones of the project include:
•
The prototyping of a European Public Administration architecture in the domain of interest,
and,
•
The demonstration of new e-services provided by European Public Administrations in the
domain of interest
Page 10
PROJECT SHOWCASES
Business
Web
Services
ITALIAN
USER PARTNER
Business
Web
Services
•Info Provision
GREEK
USER PARTNER
•Form Filling
•Two-way interaction
•Transaction
National
Web
Services
Web
Services
Web
Services
National
Web
Services
Mock WS
Web
Services
Figure 1.3: EU-PUCLI.COM Showcase
1.5 Innovation
The software (middleware) components that are developed as part of the EU-Publi.com project
employ state-of-the-art in middleware technology based on the Web services paradigm that exhibits
simplicity and scalability. In order to apply such component-based approaches, current Public
Administration processes need to be suitably re-packaged.
Developing software (middleware) components that will implement the interoperability features in a
generic enough fashion to render them reusable in multiple Public Administration domains as well
as in the current integration issues that the user partners face, is an important challenge for the EUPubli.com project.
Since the e-services that will be prototyped as part of the EU-Publi.com project, are new the
scenarios of Public Administration cooperation must be envisioned rather than modeled after an
existing service. Scenarios are sought that provide macro-processes that are both “interesting” as
well as representative of the types of interactions that can occur in Public Administration.
The EU-Publi.com architecture is layered thus enforcing the important separation of concerns
between the design of added-value and business-aware services, and their actual deployment. As
shown in the Figure below, the EU-Publi.com architecture consists of three functional layers for
Transport, Interoperability and Cooperative Service (Mecella and Battini, 2000). The transport
service layer consists of standard TCP/IP Internet protocols. The basic service layer includes
information resources such as e-mail, file transfer, and Web access. The middleware in the
cooperative service layer facilitates the development and deployment of applications among
administrations. The Cooperative Service layer includes the middleware services that enable the
development and deployment of new inter-administrations cooperative applications.
Page 11
Customers
EU-Publi.com Public Administration Processes
human-centered
automation
Nationwide CIS
CIS of
Area 1
CIS of
Area 2
CIS of
Area N
Basic service layer
Figure 1.4: Cooperative Architecture
In order to guarantee quality of service (QoS) to clients of the EU-Publi.com system, fault tolerance
and high availability are considered as key issues. EU-Publi.com specifications will build on the
notion that services offered in the Public Administration domain must be highly available (e.g. a
service can survive a fault if it is provided by a set of server replicas hosted by distinct servers). In
particular their overall availability must be such that will allow employees and administrations to
trust the system but also developers to implement cooperative applications trusting the availability
of the systems involved. This requirement can be satisfied only by enforcing fault tolerance and high
availability policies at the different levels of the EU-Publi.com architecture, exploiting different
techniques such as Transport Service Layer Availability, Domain Services Availability, Server
Availability etc.
1.6 Target Markets
The EU-Publi.com project developments will affect the areas of
Software development for Public Administrations
In particular, the markets of inter-workflow software and ERP systems are prime target markets.
While, these markets have been considerably active in the private sector, the public sector appears to
be lagging. In the cases where such software exists the proposed systems are country-specific since
the differences amongst Public Administration even within the European Union are considerably
large.
In this respect, the architecture for Public Administration developed as part of the EU-Publi.com
project can serve as a seed for a unifying framework which software vendors can exploit in
Page 12
attempting to build public sector ERP’s and public sector inter-workflow software with a wider (e.g.
European) market. In addition, the software (middleware) components to be developed as part of the
EU-Publi.com project can act as resounding demonstrators of these new e-services that European
Public Administrations can offer to their citizens.
Domain models for Public Administration
While models and architectures in the private sector are harder to embrace given the often diverging
views of particular enterprises, such models for the public sector appear to have a more promising
take-up potential since the public sector is highly centralized and monopolistic by its nature.
Therefore the architecture for Public Administration developed as part of the EU-Publi.com project
aspires to influence standards development in the area of Public Administration that has recently
become an area of active research. At the European level, the role of the European Commission is
instrumental for coalescing the individual efforts for building architectures of Public Administration
for countries of the European Union.
In the interest of promoting reusability and increasing the likelihood of take-up potential of the
elements of the EU-Publi.com architecture for Public Administration, both existing specifications,
models and architectures for Public Administration will be taken into account (Tarabanis and
Peristeras, 2000) and the new specifications that will be developed will be based on established
specification methodologies and languages (e.g. XML, eb-XML, UML).
Page 13
1.7 Project Consortium
Partner’s Name
Acronym
Role
Country
Centre for Research & Technology Hellas /
Informatics & Telematics Institute
CERTH / ITI
Scientific
Partner
Greece
University of Rome “LA SAPIENZA” /
Department of Computer and Systems
Science (DIS)
UNIROMA
Scientific
Partner
Italy
Ibermática S.A.
IBERMATICA
Industrial
Partner
Spain
Altec Information and Communication
Systems S.A.
ALTEC
Industrial
Partner
Greece
Prefecture of Thessaloniki
NATH
User Partner
Greece
Italian Institute for Foreign Trade
ICE
User Partner
Italy
United Nations Thessaloniki Centre for
Public Service Professionalism
UNTC
Dissemination
Partner
Greece
Coordinator contact details: Professor Konstantinos Tarabanis
Centre for Research & Technology Hellas /
Informatics & Telematics Institute
Address:
Tel:
Fax:
E-mail:
Web:
6th km Charilaou - Thermi road, 57001
Thermi-Thessaloniki
(+30) 310 891 578
(+30) 310 891 649
[email protected]
www.eu-publi.com
Page 14
1.8 References
Batini, C. and M. Mecella (2001). "Enabling Italian E-Government through a Cooperative
Architecture." IEEE Computer.Vol. 34(2).
Mecella, M. and C. Battini (2000). Cooperation of Heterogeneous Legacy Information Systems: a
Methodological Framework. 4th International Enterprise Distributed Object Computing Conference
(EDOC 2000), Makuhari, Japan.
Peristeras, V., T. Tsekos and K. Tarabanis (2002). Analyzing e-Government as a Paradigm Shift.
Annual Conference of the International Association of Schools and Institutes of Administration
(IASIA), Istanbul, Turkey, 17-20 June 2002.
Tarabanis, K. and V. Peristeras (2000). "Towards an Enterprise Architecture for Public
Administration : A Top Down Approach." European Journal of Information Systems.Vol. 9(Dec.
2000): 252-260.
Tarabanis, K. and V. Peristeras (2002). Towards Interoperability amongst European Public
Administrations. 13th Database and Expert Systems Applications Conference (DEXA), Aix-enProvince, France, 2-6 September.
Page 15
2 Technical Aspects
This chapter is focused on the technical aspects involved in the design of the Unitary European
Network architecture. It collects a wide overview of the specifications, protocols and algorithms
defined in literature. It is structured in five sections as follow:
• Section 2.1 deals with the standard basic protocols commonly used to support interactions in
a distributed environment.
• Section 2.2 deals with advanced technologies to be used to provide interoperability among
different platforms. It is based on the concept of middleware distinguishing among three
classes: Object Oriented Middleware (subsection 2.2.1), Message Oriented Middleware
(subsection 2.2.2) and Web Oriented Middleware (subsection 2.2.3). The technologies
introduced in each subsection represent basic building blocks that can be combined together
to realize the Cooperative service layer.
• Section 2.3 introduces security problems involved in a distributed interaction and presents
several security mechanisms and protocols widely accepted in the Internet community.
• Section 2.4 deals with fault tolerance and high availability issues that may be taken into
account in the development of the Unitary European Network to prevent possible
unavailability of the services provided.
• Section 2.5 encloses, organized in sections, the reference to the arguments dealt with in the
chapter.
2.1 Basic Protocols
2.1.1 TCP/IP (Transmission Control Protocol / Internet Protocol)
TCP is a connection-oriented, end-to-end protocol that provides (i) the packet sequencing, (ii) error
control, and (iii) other services required to provide reliable end-to-end communications. IP (Internet
Protocol) takes the packet from TCP and passes it along whatever gateways are needed, for delivery
to the remote TCP layer through the remote IP layer.
TCP does not require reliability of the communication protocols below itself. Therefore, TCP works
with lower-level protocols that are simple, potentially unreliable datagram services. TCP uses IP for
a lower-level protocol.
2.1.1.1 How TCP Works
TCP is connection-oriented. Therefore, before transferring data, there must be established a logical
transport layer connection with a peer user. To establish this connection, TCP uses a "three-way
handshake," in which the initiating TCP sends a Protocol Data Unit (PDU) with a synchronize
(SYN) bit set to 1 in its header. The responding TCP then sends back a PDU with both the SYN bit
and the Acknowledged (ACK ) bit set, and possibly, some user data. Time and, if necessary,
retransmission are used to recover PDUs lost in this process, allowing each side to indicate its
starting sequence number. Because of the possibility of lost or delayed PDUs, this three-way
exchange ensures that connections are established correctly.
To release a connection, one TCP sends a PDU with the FIN flag set and a sequence number one
greater than that assigned to the last octet of the transmitted data. Upon receipt of this PDU, the
responding TCP sends back a PDU carrying an ACK for the FIN's sequence number and a FIN of its
own (this ACK or FIN may appear in the same PDU or in different PDUs). The TCP that sent the
Page 16
first FIN must respond with an ACK for this new FIN. This rather complex procedure allows a
graceful close, ensuring that no data is lost during release of the connection.
2.1.1.2 TCP Features
Since IP does not always guarantee reliable transfer of data, TCP implements several reliability
features to ensure that data arrives at its destination uncorrupted and in the order sent:
• sequence numbers: TCP assigns a sequence number to each data segment it transmits. The
receiving host uses the sequence numbers to make sure that all the data arrives in order;
• out-of-order caching: as TCP receives data segments, it puts them in sequential order and
forwards them to the receiving TCP client. If TCP fails to receive one or more segments and
cannot complete the sequential ordering, it stores the remaining segments in cache memory
for as long as the TCP connection exists. When TCP receives the missing segments, it takes
the stored segments from cache memory, puts them into sequential order with the newly
received segments, and then forwards them to the receiving TCP client;
• checksums: to ensure the integrity of the data, the sending host adds a checksum to each
segment it transmits. The receiving host recalculates the checksum, and if there is damage,
discards the segment;
• flow control: flow control allows the receiving host to regulate how much data is sent to it.
To activate flow control, the receiving host advertises a window that indicates how much
data it can accept. When the transmit window is full, the sending host must stop sending data
until the receiving host can open the window again. Specifying the maximum window size
allowed for each connection, it si possible to control the rate of data transfer on your TCP
connections;
• acknowledgment with retransmission: TCP requires the receiving host to acknowledge
that it has received the data. If the sending host does not receive an acknowledgment within a
set timeout interval, the sending station retransmits the data. TCP determines the timeout
interval by estimating the average time it takes to send a segment and receive an
acknowledgment for it.
2.1.1.3 Connection Types
TCP is a connection-oriented protocol that requires application programs at both end-points of a
connection to agree to it before TCP traffic can pass across an internet. To do so, the application
program at one end-point performs a passive open while the application program at the other endpoint performs an active open. For passive opens, a TCP client (the process or application program
that uses TCP) waits to accept incoming connection requests. Clients using passive opens can listen
for specific connection requests or for a range of inbound requests. In an active open, the client
initiates the connection. Once a connection has been created, application programs can begin to pass
data; that is, the programs at each end-point exchange messages that guarantee reliable delivery.
2.1.1.4 TCP and IP Service Users
TCP is the layer between IP and protocols running at higher layers in the network hierarchy. Figure
2.1 shows a simple network architecture with four users of TCP/IP services: Telnet, FTP, HTTP and
email protocols.
Page 17
Telnet
FTP
HTTP
e-mail
TCP
IP
Figure 2.1: TCP between IP and Clients
The interface between TCP and programs that use TCP consists of a set of messages exchanged
between the clients and TCP, and a set of functions and macros that user programs call to exchange
TCP messages. These programs use the functions and macros to:
• open, close, abort, and get the status of connections;
• control the flow of data;
• encapsulate data for TCP to transmit;
• process received TCP data.
When a program passes data to TCP, the TCP layer formats the data and calls on the IP layer to
transmit the data to its destination.
2.1.2 Telnet
Telnet is a virtual terminal protocol that is part of the TCP/IP protocol suite. It allows you to access
any system on your network running the Telnet server software. Accessing Telnet establishes a
virtual connection between a terminal and the specified host. Once the client is connected to a host
through Telnet, its terminal appears to be connected directly to that host.
Telnet offers three basic services:
• it defines a network virtual terminal that provides a standard interface to remote systems.
Clients do not have to understand the details of all possible remote systems; they are built to
use the standard interface;
• it allows client and server to negotiate options, and it provides a set of standard options;
• it treats both ends of the connection symmetrically. So, instead of forcing the client side to
connect to a user's terminal, Telnet allows an arbitrary program to become a client.
Furthermore, either end of the connection can negotiate options.
2.1.2.1 Telnet Server
When a Telnet server is created, the router accepts inbound requests from a Telnet client and
establishes a Telnet session to the Technician Interface.
A PC with a network configuration can run a Telnet terminal emulation program to establish a
remote session on a router (Figure 2.2). In this case, the PC is defined as a Telnet client and the
router as a Telnet server.
Page 18
$
Telnet Server
Inbound
Telnet Session
TCP
connection
Figure 2.2: Telnet Server
2.1.2.2 Telnet Client
When a Telnet client is created, the router sends outbound requests to a remote host to establish a
Telnet session on a remote node. After the router establishes the Telnet session, you can access all
Technician Interface commands.
If the client is connected to a router via console cable, it can use the Telnet command to establish a
remote session on a remote router (Figure 2.3). In this case, the local router is defined as the Telnet
client and the remote router as the Telnet server.
$
Telnet Client
Telnet Server
Outbound
Telnet Session
Console
cable
TCP
connection
Figure 2.3: Telnet Client
2.1.3 FTP (File Transfer Protocol)
The File Transfer Protocol allows files to be transferred from a server to an FTP client or from an
FTP client to the server. FTP ensures the integrity of data transferred from one system to another.
Using FTP, you can log in to a remote host, identify yourself, list remote directories, copy files to or
from the remote host, and execute a few simple commands remotely.
When you enable FTP on the router, you can:
• download files from a host system to a remote router and retrieve files from the router;
• examine the directory listing of files on the remote router;
• delete files on the remote router.
Page 19
The FTP client initiates an FTP session with the FTP server on the router. The session establishes
two separate connections between host and router as follows:
• control connection: the communication path between the FTP client and the FTP control
server for the exchange of commands and replies used for sending a command request or
response;
• data connection: a full-duplex connection over which data is transferred in a specified mode
and type between FTP client and FTP server.
The FTP client residing on the host and the FTP server residing on the router rely on the underlying
support of TCP and IP for the reliable, sequenced transfer of data and control messages (Figure 2.4).
Host
Router
FT P
client
FT P
server
T CP
T CP
Key
Control connection
Data connection
IP
IP
LAN/WAN
Figure 2.4: FTP Client and Server
2.1.4 HTTP (Hyper Text Transfer Protocol)
The Hypertext Transfer Protocol (HTTP) is the foundation protocol of the World Wide Web
(WWW). HTTP is a protocol for transmitting information with the efficiency necessary for making
hypertext jumps. The data transferred by the protocol can be plain text, hypertext, audio, images, or
any type of Internet-accessible information.
HTTP is a transaction-oriented client/server protocol. The most typical use of HTTP is between a
web browser and a web server. To provide reliability, HTTP makes use of TCP. Nevertheless,
HTTP is a "stateless" protocol; each transaction is treated independently. A typical implementation
creates a new TCP connection between client and server for each transaction and then terminates the
connection as soon as the transaction completes, although the specification doesn't dictate this oneto-one relationship between transaction and connection lifetimes.
The stateless nature of HTTP is well suited to its typical application. A normal session of a user with
a web browser involves retrieving a sequence of web pages and documents. Ideally, the sequence is
performed rapidly, and the locations of the various pages and documents may include a number of
widely distributed servers.
Another important feature of HTTP is flexibility in the formats that it can handle. When a client
issues a request to a server, it may include a prioritized list of formats that it can handle, and the
server replies with the appropriate format. For example, a lynx browser can't handle images, so a
Page 20
web server need not transmit any images on web pages to this browser. This arrangement prevents
the transmission of unnecessary information and provides the basis for extending the set of formats
with new standardized and proprietary specifications.
Figure 2.5 illustrates three examples of HTTP operation.
Request chain
TCP Connection
Response chain
Origin Server
User Agent
Request chain
A
B
C
Response chain
Origin Server
User Agent
Request chain
A
B
C
Response chain
Origin Server
User Agent
Figure 2.5: Examples of HTTP operation
The simplest case is one in which a user agent establishes a direct connection with an origin server.
The user agent is the client that initiates the request, such as a web browser being run on behalf of an
end user. The origin server is the server on which a resource of interest resides; an example is a web
server at which a desired home page resides. For this case, the client opens a TCP connection that's
end-to-end between the client and the server. The client then issues an HTTP request: the request
consists of a specific command (referred to as a method), a URL, and a message containing request
parameters, information about the client, and perhaps some additional content information. When
the server receives the request, it attempts to perform the requested action and then returns an HTTP
response. The response includes status information, a success/error code, and a message containing
information about the server, information about the response itself, and possibly body content. The
TCP connection is then closed.
The middle part of Figure 2.5 shows a case in which there is no end-to-end TCP connection between
the user agent and the origin server. Instead, there are one or more intermediate systems with TCP
connections between logically adjacent systems. Each intermediate system acts as a relay, so that a
request initiated by the client is relayed through the intermediate systems to the server, and the
response from the server is relayed back to the client.
Referring to Figure 2.5, the lowest portion of the figure shows an example of a cache. A cache is a
facility that may store previous requests and responses for handling new requests. If a new request
arrives that's the same as a stored request, the cache can supply the stored response rather than
accessing the resource indicated in the URL. The cache can operate on a client or server or on an
intermediate system other than a tunnel. In Figure 2.5, intermediary B has cached a request/response
transaction, so that a corresponding new request from the client need not travel the entire chain to
the origin server, but instead is handled by B.
Page 21
Not all transactions can be cached, and a client or server can dictate that a certain transaction may be
cached only for a given time limit.
2.1.5 e-mail Protocols
The Internet standard for e-mail is the Simple Mail Transport Protocol (SMTP). SMTP is the
application-level protocol that handles message services over TCP/IP networks.
SMTP is the most prevalent of the e-mail protocols. A primary weakness of standard SMTP is the
lack of support for non-text messages.
Besides SMTP, there are two other protocols for delivering mail to workstations. These are POP3
and IMAP4.
2.1.5.1 MIME and SMTP
MIME (Multipurpose Internet Mail Extensions) supplements SMTP and allows the encapsulation of
multimedia (non-text) messages inside of a standard SMTP message. MIME uses Base64 encoding
to convert complex files into ASCII.
Other Encoding Standards
Several other standards exist for encoding non-ASCII messages. The more popular of these are
BinHex and uuencode.
BinHex stands for Binary Hexadecimal and is considered by some to be a Macintosh version of
MIME. Uuencode stands for UNIX-to-UNIX Encoding because of its UNIX origin, although it is
now supported by many non-UNIX platforms. Although MIME, uuencode, and BinHex do have
several fundamental differences, they accomplish the same primary goal allowing non-text files to
be sent in text messages. The method you use will depend upon your mail User Agent (UA) and the
UAs used by the target recipients.
Advantages and Disadvantages of SMTP
SMTP has several primary advantages and disadvantages.
The advantages are as follows:
• SMTP is very popular;
• it is supported on many platforms by many vendors;
• SMTP has low implementation and administration costs:
• SMTP has a simple addressing scheme.
The disadvantages are as follows:
• SMTP lacks certain types of functions;
• SMTP lacks the security specified in X.400;
• Its simplicity limits its usefulness.
2.1.5.2 Client Mail Retrieval with POP and IMAP
POP3 (The Post Office Protocol version 3)
Page 22
POP allows local mail UAs to connect to the MTA and pull mail down to your local computer,
where you can read and respond to the messages. POP was first defined in 1984, then updated by
POP2 in 1988. The current standard is POP3.
POP3 UAs connect via TCP/IP to the server (typically port 110). The UA enters a username and
password (either stored internally for convenience or entered each time by the user for stronger
security). After authorized, the UA can issue POP3 commands to retrieve and delete mail.
POP3 is a receive-only protocol. POP3 UAs use SMTP to send mail to the server.
IMAP (The Internet Mail Access Protocol)
POP3 is a very good and simple protocol for retrieving messages to your UA. However, its
simplicity results in a lack of several desired features. For instance, POP3 only works in offline
mode, meaning that the messages are downloaded to the UA and deleted from the server.
The Internet Mail Access Protocol (IMAP) picks up where POP3 leaves off. IMAP was first
conceived in 1986 at Stanford University. IMAP2 was first implemented in 1987. IMAP4, the
current specification, was accepted as an Internet standard in 1994. IMAP4 is found at TCP port
143.
POP3 Versus IMAP4
There are many fundamental differences between POP3 and IMAP4. The advantages of POP3 are
• it is very simple;
• it is widely supported.
Due to its simplicity, POP3 is often limited. For example, it can only support one mailbox, and the
messages must be deleted from the server (although many implementations support a "pseudoonline" mode allowing messages to be left on the server).
IMAP4 has several distinct advantages:
• stronger authentication;
• support for multiple mailboxes;
• greater support for online, offline, or disconnected modes of operation.
IMAP4's online mode support allows UAs to download only a subset of the messages from the
server, search for and download only messages matching a certain criteria, and so on. IMAP4 also
allows a user or UA to move messages between server folders and delete certain messages. IMAP4
is much better suited for the mobile user who needs to work at several different computers, or the
user who needs to access and maintain several different mailboxes. The major drawback to IMAP4
today is that it is not widely deployed by ISPs, notwithstanding the fact that many IMAP4 clients
and servers exist today.
2.2 Cooperative Technologies
The role of middleware is to ease the task of designing, programming and managing distributed
applications by providing a simple, consistent and integrated distributed programming environment.
Essentially, middleware is a distributed software layer, or ‘platform’ which abstracts over the
complexity and heterogeneity of the underlying distributed environment with its multitude of
network technologies, machine architectures, operating systems and programming languages.
Page 23
Different middleware platforms support different programming models. Perhaps the most popular
model is Object Oriented Middleware (OOM), in which applications are structured into (potentially
distributed) objects that interact via location transparent method invocation. Prime examples of this
type of middleware are the OMG's CORBA and Microsoft's Distributed COM. Both of these
platforms offer (i) an interface definition language (IDL) which is used to abstract over the fact that
objects can be implemented in any suitable programming language, (ii) an object request broker
which is responsible for transparently directing method invocations to the appropriate target object,
and (iii) a set of services (e.g. naming, time, transactions, replication etc.) which further enhance the
distributed programming environment.
Not all middleware is object based, however. Two other popular paradigms are Event Based
Middleware and Message Oriented Middleware (MOM) both of which mainly employ ‘single shot’
communications rather than the request-reply style communication found in object based
middleware. Event based middleware is particularly suited to the construction of non-centralized
distributed applications that must monitor and react to changes in their environment. Examples are
process control, Internet news channels and stock tracking. It is claimed that event based
middleware has potentially better scaling properties for such applications than object based
middleware. Message oriented middleware, on the other hand, is biased toward applications in
which messages need to be persistently stored and queued. Workflow and messaging applications
are good examples.
After the diffusion of object-centric middleware like OOM, in the last years new service-centric
architectures and platforms are emerging in the scene; these platforms raise the level of abstraction
in software module considering as basic building blocks entire services rather than the single
objects. This approach is well suited for open and dynamically changing environment as the web is;
for this reason the so called Web Oriented Middleware (WOM) are gaining more and more attention
from designers and developers.
2.2.1 Object Oriented Middleware
Like RPC (Remote Procedure Call), OOM offers synchronous, typed communication between
components of a distributed program. Developed out of a need to extend the Object-Oriented
programming paradigm to distributed systems, the middleware typically consists of a mechanism to
allow methods to be invoked on remote objects, plus services to support the naming and location of
objects in a system-wide manner.
In practice, the synchronous paradigm has been found to be inadequate for the needs of applications.
The traditional method of programming around blocking calls is to use multi-threading at the caller,
but there are still some interaction needs that are not met by request-response synchronous
invocation and managing multiple threads requires additional overheads. As a result, more recent
OOM systems have started to include asynchronous services such as event services and CORBA's
"one-way calls" that do not require a response.
2.2.1.1 OMG CORBA (OMG Common Object Request Broker Architecture)
Overview
The Common Object Request Broker Architecture (CORBA) is a specification of a standard
architecture for object request brokers (ORBs). A standard architecture allows vendors to develop
Page 24
ORB products that support application portability and interoperability across different programming
languages, hardware platforms, operating systems, and ORB implementations:
Using a CORBA-compliant ORB, a client can transparently invoke a method on a server object,
which can be on the same machine or across a network. The ORB intercepts the call, and is
responsible for finding an object that can implement the request, passing it the parameters, invoking
its method, and returning the results of the invocation. The client does not have to be aware of where
the object is located, its programming language, its operating system or any other aspects that are
not part of an object's interface". The "vision" behind CORBA is that distributed systems are
conceived and implemented as distributed objects. The interfaces to these objects are described in a
high-level, architecture-neutral specification language that also supports object-oriented design
abstraction. When combined with the Object Management Architecture. CORBA can result in
distributed systems that can be rapidly developed, and can reap the benefits that result from using
high-level building blocks provided by CORBA, such as maintainability and adaptability.
The CORBA specification was developed by the Object Management Group (OMG), an industry
group with over six hundred member companies representing computer manufacturers, independent
software vendors, and a variety of government and academic organizations. Thus, CORBA specifies
an industry/consortium standard, not a "formal" standard in the IEEE/ANSI/ISO sense of the term.
The OMG was established in 1988, and the initial CORBA specification emerged in 1992. Since
then, the CORBA specification has undergone significant revision, with the latest major revision
(CORBA v2.0) released in July 1996.
Technical Details
CORBA ORBs are middleware mechanisms, as are all ORBs. CORBA can be thought of as a
generalization of remote procedure call (RPC) that includes a number of refinements of RPC,
including:
• a more abstract and powerful interface definition language
• direct support for a variety of object-oriented concepts
• a variety of other improvements and generalizations of the more primitive RPC.
It is impossible to understand CORBA without appreciating its role in the Object Management
Architecture (OMA), shown in Figure 2.6. The OMA is itself a specification (actually, a collection
of related specifications) that defines a broad range of services for building distributed applications.
The OMA goes far beyond RPC in scope and complexity. The distinction between CORBA and the
OMA is an important one because many services one might expect to find in a middleware product
such as CORBA (e.g., naming, transaction, and asynchronous event management services) are
actually specified as services in the OMA.
OMA services are partitioned into three categories: CORBAServices, CORBAFacilities, and
ApplicationObjects. The CORBA ORB is a communication infrastructure through which
applications access these services, and through which objects interact with each other.
CORBAServices, CORBAFacilities, and ApplicationObjects define different categories of objects in
the OMA; these objects (more accurately object types) define a range of functionality needed to
support the development of distributed software systems.
Page 25
Application Objects
ORB
CORBA Services
CORBA Facilities
Figure 2.6: Object Management Architecture
CORBA Services
CORBAServices are considered fundamental to building non-trivial distributed applications. These
services currently include asynchronous event management, transactions, persistence,
externalization, concurrency, naming, relationships, and lifecycle.
Naming Service
Provides the ability to bind a name to an object. Similar to other forms of directory service.
Event Service
Supports asynchronous message-based communication among objects. Supports chaining of
event channels, and a variety of producer/consumer roles.
Lifecycle Service
Defines conventions for creating, deleting, copying and moving objects.
Persistence Service
Provides a means for retaining and managing the persistent state of objects.
Transaction Service
Supports multiple transaction models, including mandatory "flat" and optional "nested"
transactions.
Concurrency Service
Supports concurrent, coordinated access to objects from multiple clients.
Relationship Service
Supports the specification, creation and maintenance of relationships among objects.
Externalization Service
Defines protocols and conventions for externalizing and internalizing objects across processes
and across ORBs.
CORBA Facilities
CORBAFacilities may be useful for distributed applications in some settings, but are not considered
as universally applicable as CORBAServices. These "facilities" include: user interface, information
management, system management, task management, and a variety of "vertical market" facilities in
domains such as manufacturing, distributed simulation, and accounting.
Application Objects
Page 26
Application Objects provide services that are particular to an application or class of applications.
These are not (currently) a topic for standardization within the OMA, but are usually included in the
OMA reference model for completeness, i.e., objects are either application-specific, support
common facilities, or are basic services.
Figure 2.7 depicts most of the basic components and interfaces defined by CORBA. This figure is an
expansion of the ORB component of the OMA depicted in Figure 2.6.
Object
Implementation
Client
skeleton
DII
IDL
stub
ORB
interface
DSI
Object Adapter
Core Broker
ObjectORB
Request
Figure 2.7: The CORBA Architecture
Object Implementation
One element that is crucial to the understanding of CORBA is the interface definition language
(IDL) processor. All objects are defined in CORBA (actually, in the OMA) using IDL. IDL is an
object-oriented interface definition formalism that has some syntactic similarities with C++. There is
a different IDL compiler for each language supported by CORBA.An important point to note is that
CORBA specifies that clients and object implementations can be written in different programming
languages and execute on different computer hardware architectures and different operating systems,
and that clients and object implementations can not detect any of these details about each other. Put
another way, the IDL interface completely defines the interface between clients and objects; all
other details about objects (such as their implementation language and location) can be made
"transparent" (Figure 2.8).
IDL File
IDL to Java Compiler
application
(JAVA)
IDL to C++ Compiler
stub
(JAVA)
stub
(C++)
Java
ORB
skeleton
(C++)
implementation
(C++)
C++O
RB
Figure 2.8: The CORBA IDL compiler
ORB Core
Page 27
The CORBA runtime infrastructure. The interface to the ORB Core is not defined by CORBA, and
will be vendor proprietary.
ORB Interface
A standard interface (defined in IDL) to functions provided by all CORBA- compliant ORBs.
IDL Stubs
Generated by the IDL processor for each interface defined in IDL. Stubs hide the low-level
networking details of object communication from the client, while presenting a high-level, object
type-specific application programming interface (API).
Dynamic Invocation Interface (DII)
An alternative to stubs for clients to access objects. While stubs provide an object type-specific API,
DII provides a generic mechanism for constructing requests at run time (hence "dynamic
invocation"). An interface repository (another CORBA component) allows some measure of type
checking to ensure that a target object can support the request made by the client.
Object Adaptor
Provides extensibility of CORBA- compliant ORBs to integrate alternative object technologies into
the OMA. For example, adaptors may be developed to allow remote access to objects that are stored
in an object-oriented database. Each CORBA-compliant ORB must support a specific object adaptor
called the Basic Object Adaptor (BOA) (not illustrated in Figure 2). The BOA defines a standard
API implemented by all ORBs.
Skeleton
The server-side (or object implementation-side) analogue of IDL stubs. IDL skeletons receive
requests for services from the object adaptor, and call the appropriate operations in the object
implementation.
Dynamic Skeleton Interface (DSI)
The server-side (or object implementation-side) analogue of the DII. While IDL skeletons invoke
specific operations in the object implementation, DSI defers this processing to the object
implementation. This is useful for developing bridges and other mechanisms to support inter-ORB
interoperation.
CORBA Compliance
As noted, CORBA is a specification, not an implementation. Therefore, the question of compliance
is how a consumer knows if a product is CORBA-compliant and what this mean. CORBA
compliance is defined by the OMG: the minimum required for a CORBA-compliant system is
adherence to the specifications in CORBA Core and one mapping, where mapping refers to a
mapping from IDL to a supported programming language. The CORBA Core is defined for
compliance as including the following:
• the interfaces to all of the elements depicted in Figure 2.9;
• interfaces to the interface repository;
• a definition of IDL syntax and semantics;
Page 28
• the definition of the object model that underlies CORBA (e.g., what is an object, how is it
defined, where do they come from).
Significantly, the CORBA Core does not include CORBA interoperability, nor does it include
interworking. A separate but related point is that CORBA ORBs need not provide implementations
of any OMA services.
There are as yet no defined test suites for assessing CORBA compliance. Users must evaluate
vendor claims on face value, and assess the likelihood of vendor compliance based upon a variety of
imponderables, such as the role played by the vendor in the OMG; vendor market share; and press
releases and testimonials. Hands-on evaluation of ORB products is an absolute necessity. However,
given the lack of a predefined compliance test suite, the complexity of the CORBA specification
(see next topic), and the variability of vendor implementation choices, even this will be inadequate
to fully assess "compliance."
While CORBA defines a standard, there is great latitude in many of the implementation detailsORBs developed by different vendors may have significantly different features and capabilities.
Thus, users must learn a specification, the way vendors implement the specification, and their valueadded features (which are often necessary to make a CORBA product usable). While CORBA
makes the development of distributed applications easier than with previous technologies, this ease
of use may be deceptive: The difficult issues involved in designing robust distributed systems still
remain (e.g., performance prediction and analysis, failure mode analysis, consistency and caching,
and security).
Facility with CORBA may require deep expertise in related technologies, such as distributed
systems design, distributed and multi-threaded programming and debugging; inter-networking;
object-oriented design, analysis, and programming. In particular, expertise in object-oriented
technology may require a substantial change in engineering practice, with all the technology
transition issues that implies (see The Technology Adoption Challenge).
The OMA is also evolving, and different aspects are at different maturity levels. For instance,
CORBAFacilities defines more of a framework for desired services than a specification suitable for
implementation. The more fundamental CORBAServices, while better defined, are not rigorously
defined; a potential consequence is that different vendor implementations of these services may
differ widely both in performance and in semantics. The consequence is particularly troubling in
light of the new interoperability features; prior to inter-ORB interoperability the lack of uniformity
among CORBAServices implementations would not have been an issue.
2.2.1.2 COM – DCOM (Distributed Component Object Model)
COM refers to both a specification and implementation developed by Microsoft Corporation which
provides a framework for integrating components. This framework supports interoperability and
reusability of distributed objects by allowing developers to build systems by assembling reusable
components from different vendors which communicate via COM. By applying COM to build
systems of preexisting components, developers hope to reap benefits of maintainability and
adaptability.
COM defines an application programming interface (API) to allow for the creation of components
for use in integrating custom applications or to allow diverse components to interact. However, in
Page 29
order to interact, components must adhere to a binary structure specified by Microsoft. As long as
components adhere to this binary structure, components written in different languages can
interoperate.
Distributed COM is an extension to COM that allows network-based component interaction. While
COM processes can run on the same machine but in different address spaces, the DCOM extension
allows processes to be spread across a network. With DCOM, components operating on a variety of
platforms can interact, as long as DCOM is available within the environment.
It is best to consider COM and DCOM as a single technology that provides a range of services for
component interaction, from services promoting component integration on a single platform, to
component interaction across heterogeneous networks. In fact, COM and its DCOM extensions are
merged into a single runtime. This single runtime provides both local and remote access.
COM and DCOM represent "low-level" technology that allows components to interact; COM+
integrates MTS services and message queuing into COM, and makes COM programming easier
through a closer integration with Microsoft languages as Visual Basic, Visual C++, and J++. COM+
will not only add MTS-like quality of service into every COM+ object, but it will hide some of the
complexities in COM coding.
The distinctions among various Microsoft technologies and products are sometimes blurred. Thus,
one might read about "OLE technologies" which encompass COM, or "Active Platform" as a full
web solution. In this technology description, we focus on the underlying technology represented by
COM, DCOM, and COM+.
Client
Application
Interface
Ponter
Object
Figure 2.9: Client using COM Object through an interface pointer
Technical Details
COM is a binary compatibility specification and associated implementation that allows clients to
invoke services provided by COM-compliant components (COM objects). As shown in Figure 2.9,
services implemented by COM objects are exposed through a set of interfaces that represent the only
point of contact between clients and the object. COM defines a binary structure for the interface
between the client and the object. This binary structure provides the basis for interoperability
between software components written in arbitrary languages. As long as a compiler can reduce
language structures down to this binary representation, the implementation language for clients and
COM objects does not matter - the point of contact is the run-time binary representation. Thus,
COM objects and clients can be coded in any language that supports Microsoft's COM binary
structure.
A COM object can support any number of interfaces. An interface provides a grouped collection of
related methods. For example, Figure 2.10 depicts a COM object that emulates a clock. IClock,
IAlarm and ITimer are the interfaces of the clock object. The IClock interface can provide the
appropriate methods (not shown) to allow setting and reading the current time. The IAlarm and
ITimer interfaces can supply alarm and stopwatch methods.
Page 30
IClock
ITimer
IAlarm
Clock
Object
Figure 2.10: Clock COM Object
COM objects and interfaces are specified using Microsoft Interface Definition Language (IDL), an
extension of the DCE Interface Definition Language. To avoid name collisions, each object and
interface must have a unique identifier. Interfaces are considered logically immutable. Once an
interface is defined, it should not be changed-new methods should not be added and existing
methods should not be modified. This restriction on the interfaces is not enforced, but it is a rule that
component developers should follow. Adhering to this restriction removes the potential for version
incompatibility-if an interface never changes, then clients depending on the interface can rely on a
consistent set of services. If new functionality has to be added to a component, it can be exposed
through a different interface.
Figure 2.11: Three methods for Accessing COM Objects
Every COM object runs inside of a server. A single server can support multiple COM objects. As
shown in Figure 2.11, there are three ways in which a client can access COM objects provided by a
server:
1. In-process server: The client can link directly to a library containing the server. The client
and server execute in the same process. Communication is accomplished through function
calls.
2. Local Object Proxy: The client can access a server running in a different process but on the
same machine through an inter-process communication mechanism. This mechanism is
actually a lightweight Remote Procedure Call (RPC).
3. Remote Object Proxy: The client can access a remote server running on another machine.
The network communication between client and server is accomplished through DCE RPC.
The mechanism supporting access to remote servers is called DCOM.
All COM objects are registered with a component database. As shown in Figure 2.12, when a client
wishes to create and use a COM object:
Page 31
1.
2.
3.
4.
It invokes the COM API to instantiate a new COM object;
COM locates the object implementation and initiates a server process for the object;
The server process creates the object, and returns an interface pointer at the object;
The client can then interact with the newly instantiated COM object through the interface
pointer.
An important aspect in COM is that objects have no identity, i.e. a client can ask for a COM object
of some type, but not for a particular object. Every time that COM is asked for a COM object, a new
instance is returned. The main advantage of this policy is that COM implementations can pool COM
objects and return these pooled objects to requesting clients. Whenever a client has finished using an
object the instance is returned to the pool. However, there are mechanisms to simulate identity in
COM such as monikers.
Figure 2.12: Creating a COM object pointer
Discussions
Platform support. COM and DCOM are best supported on Windows 95 and NT platforms. However,
Microsoft has released a version of COM/DCOM for MacOS that supports OLE-style compound
documents and the creation of ActiveX controls. Software AG, a Microsoft partner, has released
DCOM for some UNIX operating systems, concretely OS/390, HP-UX 11.0, SUN Solaris, AIX 4.2,
4.3, Tru64 Unix 4.0 and Linux. However, DCOM over non-Windows platforms has few supporters.
Until DCOM for alternate platforms has solidified, the technology is best applied in environments
that are primarily Windows-based.
Platform specificity of COM/DCOM components. Because COM and DCOM are based on a native binary
format, components written to these specifications are not platform independent. Thus, either they
must be recompiled for a specific platform, or an interpreter for the binary format must become
available. Depending on your perspective, the use of a binary format may be either an advantage
(faster execution, better use of native platform capabilities) or a disadvantage (ActiveX controls,
unlike Java applets, are NOT machine independent).
Security. Because COM/DCOM components have access to a version of the Microsoft Windows API,
"bad actors" can potentially damage the user's computing environment. In order to address this
problem, Microsoft employs "Authenticode" uses public key encryption to digitally sign
components. Independent certification authorities such as VeriSign issue digital certificates to verify
the identity of the source of the component. However, even certified code can contain instructions
that accidentally, or even maliciously, compromise the user's environment.
Page 32
Support for distributed objects. COM/DCOM provides basic support for distributed objects. There is
currently no support for situations requiring real time processing, high reliability, or other such
specialized component interaction.
Costs and Limitations
Low cost development tools from Microsoft (such as Visual C++ or Visual Basic), as well as tools
from other vendors provide the ability to build and access COM components for Windows
platforms. Construction of clients and servers is straightforward on these platforms. In addition, the
initial purchase price for COM and DCOM is low on Windows platforms. For other platforms the
prices are considerably more expensive. DCOM for mainframes, for example, costs around two
hundred thousand dollars by December 1999.
Beyond basic costs to procure the technology, any serious software development using
COM/DCOM/COM+ requires substantial programmer expertise-the complexities of building
distributed applications are not eliminated. It would be a serious mistake to assume that the advent
of distributed object technologies like COM/DCOM/COM+ reduces the need for expertise in areas
like distributed systems design, multi-threaded applications, and networking.
However, Microsoft has a strong support organization to assist individuals developing COM/DCOM
clients and objects: many sample components, books and guides on the subject of COM/DCOM
development are available.
2.2.1.3 CTM Framework (Component Transaction Monitors Framework)
A new breed of software called application servers has recently evolved to manage the complexities
associated with developing business systems in today's Internet world. An application server is often
made up of some combination of several different technologies, including web servers, ORBs,
MOM, databases, and so forth. An application server can also focus on one technology, such as
distributed objects.
The simplest facilitate connectivity between the client applications and the distributed objects are
called object request brokers (ORBs). ORBs allow client applications to locate and use distributed
objects easily. ORBs, however, have frequently proven to be inadequate in high-volume
transactional environments. ORBs provide a communication backbone for distributed objects, but
they fail to provide the kind of robust infrastructure that is needed to handle larger user populations
and mission-critical work. In addition, ORBs provide a fairly crude server-side component model
that places the burden of handling transactions, concurrency, persistence, and other system-level
considerations on the shoulders of the application developer. These services are not automatically
supported in an ORB. Application developers must explicitly access these services (if they are
available) or, in some cases, develop them from scratch.
Early in 1999, Anne Thomas of the Patricia Seybold Group coined the term component transaction
monitor (CTM) to describe the most sophisticated distributed object application servers. CTMs
evolved as a hybrid of traditional TP monitors and ORB technologies. They implement robust
server-side component models that make it easier for developers to create, use, and deploy business
systems. CTMs provide an infrastructure that can automatically manage transactions, object
distribution, concurrency, security, persistence, and resource management. They are capable of
handling huge user populations and mission-critical work, but also provide value to smaller systems
because they are easy to use. CTMs are the ultimate application server. Other terms for this kind of
Page 33
technology include Object Transaction Monitor (OTM), component transaction server, distributed
component server, COMware, and so forth.
MTS (Microsoft Transaction Monitor)
Microsoft was one of the first vendors to ship a CTM, the Microsoft Transaction Server (MTS).
MTS uses a server-side component model and a distributed component service based on DCOM.
When MTS was introduced in 1996, it was exciting because it provided a very comprehensive
environment for business objects. With MTS, application developers can write COM (Common
Object Model) components without worrying about system-level concerns. Once a business object is
designed to conform to the COM model, MTS will take care of everything else, including
transaction management, concurrency, resource management--everything! MTS makes it simple for
application developers. If they want to influence how a business object interacts with system-level
services, they use property sheets. It's like setting properties of a GUI widget in Visual Basic: just
bring up the property sheet and choose the transactional context, the security attributes, the name
binding, and other properties from a list box or from some other GUI widget. Once the business
objects are deployed in MTS, their remote interfaces can be assembled like building blocks into
business solutions.
Although the features provided by MTS are great and its application developer API is very simple,
as an open standard, MTS falls short. MTS is Microsoft's proprietary CTM, which means that using
it binds you to the Microsoft platform. This may not be so bad, because MTS and DCOM work well,
and the Microsoft platform is pervasive. However, if the deployment is made on a non-Microsoft
platform or to non-Microsoft clients, MTS is not a viable solution. Morover, MTS only supports
stateless components; it doesn't support persistent objects.
Sun CTM
In 1997, Sun Microsystems was developing the most promising standard for server-side components
called Enterprise JavaBeans. Sun offered some key advantages. First, Sun was respected and was
known for working with vendors to define the best solutions possible. Sun had a habit of adopting
the best ideas in the industry and then making the Java implementation an open standard--usually
successfully. The Java database connectivity API, called JDBC, was a perfect example. Based
largely on Microsoft's own ODBC, JDBC offered vendors a more flexible model for plugging in
their own database access drivers. In addition, developers found the JDBC API much easier to work
with. Sun was doing the same thing in its newer technologies like the JavaMail™ API and the Java
Naming and Directory Interface (JNDI).
The great advantage of the EJB approach is that it doesn't matter how you implement the low-level
services; all that matters is all the facilities be applied to the components according to the
specification. In addition, the Java language offered some pretty enticing advantages, not all of them
purely technical. First, Java was a hot and sexy technology and simply making your product Javacompatible seemed to boost your exposure in the market. Java also offered some very attractive
technical benefits. Java was more or less platform independent. A component model defined in the
Java language would have definite marketing and technical benefits.
As it turned out, Sun had not been idle after it announced Enterprise JavaBeans. Sun's engineers had
been working with several leading vendors to define a flexible and open standard to which vendors
could easily adapt their existing products. This was a tall order because vendors had different kinds
of servers including web servers, database servers, relational database servers, application servers,
and early CTMs. It's likely that no one wanted to sacrifice their architecture for the common good,
Page 34
but eventually the vendors agreed on a model that was flexible enough to accommodate different
implementations yet solid enough to support real mission-critical development. In December of
1997, Sun Microsystems released the first draft specification of Enterprise JavaBeans and vendors
have been flocking to the server-side component model ever since.
CORBA CTM
All the non-MTS designs uses CORBA as a distributed object service. CORBA is both language and
platform independent, so CORBA CTM vendors could provide their customers with more
implementation options. The problem with CORBA CTM designs was that they all had different
server-side component models. In other words, if you developed a component for one vendor's
CTM, you couldn't turn around and use that same component in another vendor's CTM. The
component models were too different.
Besides the CORBA protocol, the most obvious standard needed was a component model, which
would allow clients and third-party vendors to develop their business objects to one specification
that would work in any CORBA CTM. Microsoft was, of course, pushing their component model as
a standard--which was attractive because MTS was an actual working product--but Microsoft didn't
support CORBA. The OMG (Object Management Group), the same people who developed the
CORBA standard, were defining a server-side component model. This held promise because it was
sure to be tailored to CORBA, but the OMG was slow in developing a standard--at least too slow for
the evolving CTM market.
Benefits of a Standard Server-Side Component Model
CTMs require that business objects adhere to the server-side component model implemented by the
vendor. A good component model is critical to the success of a development project because it
defines how easily an application developer can write business objects for the CTM. The component
model is a contract that defines the responsibilities of the CTM and the business objects. With a
good component model, a developer knows what to expect from the CTM and the CTM understands
how to manage the business object. Server-side component models are great at describing the
responsibilities of the application developer and CTM vendor.
A CTM's relationship with its component model is also similar to the relationship the railway system
has with trains. The railway system manages the train's environment, providing alternate routes for
load balancing, multiple tracks for concurrency, and a traffic control system for managing resources.
The railway provides the infrastructure that trains run on. Similarly, a CTM provides server-side
components with the entire infrastructure needed to support concurrency, transactions, load
balancing, etc.
Trains on the railway are like server-side components: they all perform different tasks but they do so
using the same basic design. The train, like a server-side component, focuses on performing a task,
such as moving cars, not managing the environment. For the engineer, the person driving the train,
the interface for controlling the train is fairly simple: a brake and throttle. For the application
developer, the interface to the server-side component is similarly limited.
Different CTMs may implement different component models, just as different railways have
different kinds of trains. The differences between the component models vary, like railway systems
having different track widths and different controls, but the fundamental operations of CTMs are the
same. They all ensure that business objects are managed so that they can support large populations
of users in mission-critical situations. This means that resources, concurrency, transactions, security,
Page 35
persistence, load balancing, and distribution of objects can be handled automatically, limiting the
application developer to a simple interface. This allows the application developer to focus on the
business logic instead of the enterprise infrastructure.
So what does it mean to be a standard server-side component model? Quite simply, it means that
you can develop business objects using the Enterprise JavaBeans (EJB) component model and
expect them to work in any CTM that supports the complete EJB specification. This is a pretty
powerful statement because it largely eliminates the biggest problem faced by potential customers of
CORBA-based CTM products: fear of vendor "lock-in." With a standard server-side component
model, customers can commit to using an EJB-compliant CTM with the knowledge that they can
migrate to a better CTM if one becomes available. Obviously, care must be taken when using
proprietary extensions developed by vendors, but this is nothing new. Even in relational database
industry--which has been using the SQL standard for a couple of decades--optional proprietary
extensions abound.
Having a standard server-side component model has benefits beyond implementation independence.
A standard component model provides a vehicle for growth in the third-party products. If numerous
vendors support EJB, then creating add-on products and component libraries is more attractive to
software vendors. The IT industry has seen this type of cottage industry grow up around other
standards like SQL, where hundreds of add-on products can be purchased to enhance business
systems whose data is stored in SQL-compliant relational databases. Report generating tools and
data warehouse products are typical examples. The GUI component industry has seen the growth of
its own third-party products. A healthy market for component libraries already exists for GUI
component models like Microsoft's ActiveX and Sun's original JavaBeans component models.
Similarly, Enterprise JavaBeans will benefit from third-party products. It is likely that ERP systems
and business object frameworks based on EJB will thrive. As an example, IBM's San Francisco
business object framework is migrating to the EJB component model. We will also see cottage
industries grow up around EJB. Add-on products that provide services to EJB-compliant systems
like credit card processing, legacy database access, and other business services will be introduced.
These types of products will make development of EJB systems simpler and faster than the
alternatives, making the EJB component model attractive to corporate IS and server vendors alike. It
is also likely that a small market for prepackaged EJB components will also develop.
2.2.1.4 Microsoft .NET
.NET is a "software platform". It's a language-neutral environment for writing programs that can
easily and securely interoperate. Rather than targetting a particular hardware/OS combination,
programs will instead target ".NET", and will run wherever .NET is implemented.
.NET is also the collective name given to various bits of software built upon the .NET platform.
These will be both products (Visual Studio.NET and Windows.NET Server, for instance) and
services (like Passport, HailStorm, and so on).
Microsoft have been pushing a language and platform independent interoperability mechanism for
some years now. It's called Component Object Model (COM). There is a degree of overlap between
the COM and .NET: .NET hides many of the messy details that COM makes programmers (or at
least C/C++ programmers; VB programmers will see far fewer differences in this regard) deal with.
COM is all native code, and requires programmers to be conscious of many low-level details which
Page 36
make development using the full power of the technology more burdensome. .NET makes these
issues disappear.
On the other hand, COM still has some things in its favour. COM/DCOM has a huge installed base
(it can be used on pretty much any Win32 machine), and is used quite extensively (particularly in
newer versions of Windows). Lots of bits of Windows rely on COM components (for instance,
Explorer/Internet Explorer), and lots of applications similarly rely on them. For the time being, at
any rate, pure .NET can't replace COM. It does become, however, a legacy technology.
However, it is possible to use use COM components from .NET, and you can expose .NET objects
as COM components: all the programmers need to do is to add some attributes to their code and
their .NET classes can be used just like COM components. Thus the gap between .NET and COM is
bridged.
The .NET Framework
The .NET Framework has two main parts:
1. The Common Language Runtime (CLR).
2. A hierarchical set of class libraries
The CLR is described as the "execution engine" of .NET. It provides the environment within which
programs run. The most important features are:
• Conversion from a low-level assembler-style language, called Intermediate Language (IL),
into code native to the platform being executed on.
• Memory management, notably including garbage collection.
• Checking and enforcing security restrictions on the running code.
• Loading and executing programs, with version control and other such features.
Before talking in more detail about these, a few bits of terminology need to be clarified.
Managed Code
"Managed Code" is code that targets .NET, and which contains certain extra information —
"metadata" — to describe itself. Whilst both managed and unmanaged code can run in the
runtime, only managed code contains the information that allows the runtime to guarantee, for
instance, safe execution and interoperability.
Managed Data
With Managed Code comes Managed Data. CLR provides memory allocation and deallocation
facilities, and garbage collection. Some .NET languages use Managed Data by default - C#,
Visual Basic.NET, JScript.NET - whereas others - C++ - do not. Targetting CLR can, depending
on the language you're using, impose certain constraints on the features available; for instance,
C++ loses multiple inheritance. As with managed and unmanaged code, one can have both
managed and unmanaged data in .NET applications - data that doesn't get garbage collected but
instead is looked after by unmanaged code.
Common Type System
The CLR uses something called the Common Type System (CTS) to strictly enforce type-safety.
This ensures that all classes are compatible with each other, by describing types in a common
way. CTS defines how types work within the runtime (their declaration and usage), which
enables types in one language to interoperate with types in another language, including crossD1.1: Project Presentation and State of the Art
Page 37
language exception handling. As well as ensuring that types are only used in appropriate ways,
the runtime also ensures that code doesn't attempt to access memory that hasn't been allocated to
it (that is to say, the code is type-safe).
Assemblies
.NET programs are constructed from "Assemblies". An Assembly is a compiled and versioned
collection of code and metadata that forms an atomic functional unit. All Assemblies contain a
Manifest, which contains (i) the Assembly name, version, and locale, (ii) a list of files that form
the Assembly, (iii) what dependencies the Assembly has, and (iv) what features are exported by
the Assembly.
The CLR ensures is that programs don't attempt to do anything dangerous. The language most
changed by this is C++. Regular C++ permits all sorts of tricks and mistakes. One can allocate a
block of memory and then write too much data to that block, overwriting whatever happened to be
lying beyond the allocated block of memory. Or one can pretend that one type is another type
(deliberately or accidentally). And one can (attempt to) access any location in memory and modify
its contents.
The CLR also enforces restrictions similar to those restrictions already used in Windows for
ActiveX controls. These allow, for instance, an object embedded into a web page to perhaps write to
your screen, but not access your hard disk. It provides sand-boxing of programs running within the
CLR. Administrators can override the default settings — to, for instance, allow downloaded
components with a certain digital signature to have more access than they normally would.
This security is enforced by means of a "stack walk". This relies on examination of the "call stack".
The call stack represents currently active functions that have been called by the function "above"
them in the stack, but not yet finished. The call stack lives somewhere in memory (there will be one
for each thread), and as each function gets called, the current location on the stack moves down in
memory. Moving up the stack means going towards the function that called the current one
(eventually, one will reach the beginning of the stack, which is where the first function to be called
has its data). Functions can demand certain permissions. When they do, the runtime will examine the
call stack to ensure that the permission has been granted.
An important feature of managed code is the metadata: metadata is data describing data. As
mentioned, there's information identifying a particular assembly, and the assemblies that assembly
relies upon. The security privileges required by the assembly are also listed.
The final kind of metadata is attributes: they provide a flexible and extensible way of modifying the
compile-time and run-time environment. If there isn't an attribute to modify the way the runtime
works in the way you want, you can define your own. It would be possible at runtime to interrogate
these attributes, and find out who wrote each class and when.
The ability to use any language that can target IL is a fundamental feature of .NET. This is achieved
through the Common Type System (CTS). The CTS defines how classes (or "types", in .NETese)
are defined. It describes a number of different features a class can have; member functions
(methods), member variables ("fields"), events, and properties (fields that silently use accessors to
get/set their values, which can, for instance, allow the creation of a read-only field). It defines the
different kinds of "visibility" that these items can have (for instance, whether a method is public, and
can be called by any class, or private, and only callable by the same kind of class). And it describes
Page 38
how such things as inheritance work for the class, with some constraints; all classes must ultimately
derive from System.Object, and only single inheritance is supported.
There's detailed information about the types/classes provided by the assembly, along with
descriptions of methods, interfaces, and members. This is important for a number of reasons. It
makes the assemblies self-describing. This ensures that the descriptions are always accurate, unlike
mechanisms such as C/C++ header files, where the interface described in the header could become
out of date, and no longer an accurate description of how a library works — the "fragile interface"
problem. Similarly, it removes the need to have some kind of an interface description or type library
file, such as Interface Description Language (IDL) as is used in COM development. This
information is also important for language interoperability; it describes the classes in an assembly so
that other classes (perhaps in other languages) can inherit from them.
.NET provides a single-rooted hierarchy of classes: the root of the namespace is called System; this
contains basic types like Byte, Double, Boolean, and String, as well as Object. All objects derive
from System.Object. As well as objects, there are value types. Value types can be allocated on the
stack (which is generally quicker to some degree than allocation on the heap), which can provide
useful flexibility. There are also efficient means of converting value types to object types if and
when necessary.
The set of classes is pretty comprehensive, providing collections, file, screen, and network I/O,
threading, and so on, as well as XML and database connectivity. The class library is subdivided into
a number of sets, each providing distinct areas of functionality, with dependencies between the sets
kept to a minimum. The aim is to make stripped-down implementations (for small devices) easier to
create, as an implementation need only provide those sets of classes that it needs.
2.2.1.5 Sun EJB (Sun Enterprise Java Beans)
The basic idea behind Enterprise JavaBeans is to provide a framework for components that may be
"plugged in" to a server. The EJB specification calls out the various players in the EJB client/server
system, describes how EJB interoperates with the client and with existing systems, spells out EJB's
compatibility with CORBA, and defines the responsibilities for the various components in the
system.
Enterprise JavaBeans goals
The EJB Specification tries to meet several goals at once:
• EJB is designed to make it easy for developers to create applications, freeing them from lowlevel system details of managing transactions, threads, load balancing, and so on.
Application developers can concentrate on business logic and leave the details of managing
the data processing to the framework. For specialized applications, though, it's always
possible to get "under the hood" and customize these lower-level services.
• The EJBspecification defines the major structures of the EJB framework, and then
specifically defines the contracts between them. The responsibilities of the client, the server,
and the individual components are all clearly spelled out. A developer creating an Enterprise
JavaBean component has a very different role from someone creating an EJB-compliant
server, and the specification describes the responsibilities of each.
• EJB aims to be the standard way for client/server applications to be built in the Java
language. EJB server components from different vendors can be combined to produce a
custom server. EJB components, being Java classes, will of course run in any EJB-compliant
Page 39
server without recompilation. This is a benefit that platform-specific solutions can't hope to
offer.
• Finally, the EJB is compatible with and uses other Java APIs, can interoperate with non-Java
apps, and is compatible with CORBA.
How an EJB client/server system works
To understand how an EJB client/server system operates, it is necessary to understand the basic parts
of an EJB system:
• the EJB component;
• the EJB container;
• the EJB object.
The Enterprise JavaBeans Component
An Enterprise JavaBean is a component; Enterprise JavaBeans execute within an EJB container,
which in turn executes within an EJB server. Any server that can host an EJB container and provide
it with the necessary services can be an EJB server. (This means that many existing servers may be
extended to be EJB servers, and in fact many vendors have achieved this, or have announced the
intention to do so.)
An EJB component is the type of EJB class most likely to be considered an "Enterprise JavaBean."
It's a Java class, written by an EJB developer, that implements business logic. All the other classes
in the EJB system either support client access to or provide services (like persistence, and so on) to
EJB component classes.
The Enterprise JavaBeans Ccontainer
The EJB container is where the EJB component "lives." The EJB container provides services such as
transaction and resource management, versioning, scalability, mobility, persistence, and security to
the EJB components it contains. Since the EJB container handles all of these functions, the EJB
component developer can concentrate on business rules, and leave database manipulation and other
such fine details to the container. For example, if a single EJB component decides that the current
transaction should be aborted, it simply tells its container (in a manner defined by the EJB Spec, and
the container is responsible for performing all rollbacks, or doing whatever is necessary to cancel a
transaction in progress. Multiple EJB component instances typically exist inside a single EJB
container.
The EJB Object and the Remote Interface
Client programs execute methods on remote EJBs by way of an EJB object. The EJB object
implements the "remote interface" of the EJB component on the server. The remote interface
represents the "business" methods of the EJB component. The remote interface does the actual,
useful work of an EJB object, such as creating an order form or deferring a patient to a specialist.
We'll discuss the remote interface in more detail below.
EJB objects and EJB components are separate classes, though from the "outside" (that is, by looking
at their interfaces), they look identical. This is because they both implement the same interface (the
EJB component's remote interface), but they do very different things. An EJB component runs on
the server in an EJB container and implements the business logic. The EJB object runs on the client
and remotely executes the EJB component's methods.
Page 40
For example, call the addEmployee() method on an EJB object, it calls (indirectly, through the
network) the addEmployee() method on the remote EJB component.
In addition, Enterprise JavaBeans has the home interface (discussed below), which (to extend our
analogy) helps you to find your "remote control," even if it's wedged down between the couch
cushions.
The actual implementation of an EJB object is created by a code generation tool that comes with the
EJB container. The EJB object's interface is the EJB component's remote interface. The EJB object
(created by the container and tools associated with the container) and the EJB component (created
by the EJB developer) implement the same remote interface. To the client, an EJB object looks just
like an object from the application domain. But the EJB object is just a stand-in for the actual EJB,
running on the server inside an EJB container. When the client calls a method on an EJB object, the
EJB object method communicates with the remote EJB container, requesting that the same method
be called, on the appropriate (remote) EJB, with the same arguments, on the client's behalf. See
Figure 2.13 for a pictorial representation of this arrangement. This is the core concept behind how an
EJB client/server system works.
Client
EJB Server
EJB Containe r
EJB Object
re mote interface
EJB Instance
Persistance
Figure 2.13: Enterprise JavaBeans in the client and the server
Types of Enterprise JavaBeans
There are two basic types of Enterprise JavaBeans: session beans and entity beans. These two types
of beans play different roles in a distributed EJB application.
A session bean is an EJB instance associated with a single client. Session beans typically are not
persistent (although they can be), and may or may not participate in transactions. In particular,
session objects generally don't survive server crashes. One example of a session object might be an
EJB living inside a Web server that serves HTML pages to a user on a browser, and tracks that
user's path through the site. When the user leaves the site, or after a specified idle time, the session
object will be destroyed. Note that while this session object might be storing information to the
database, its purpose is not to represent or update existing database contents; rather, it corresponds
to a single client performing some actions on the server EJBs.
An entity bean represents information persistently stored in a database. Entity beans are associated
with database transactions, and may provide data access to multiple users. Since the data that an
entity bean represents is persistent, entity beans survive server crashes (this is because when the
server comes back online, it can reconstruct the bean from the underlying data.) In relational terms,
an entity bean might represent an underlying database row, or a single SELECT result row. In an
object-oriented database (OODB), an entity bean may represent a single object, with its associated
Page 41
attributes and relationships. An example of an entity bean might be an Employee object for a
particular employee in a company's Human Resources database.
An Enterprise JavaBeans client creates EJB objects on the server and manipulates them as if they
were local objects. This makes developing EJB clients almost as easy as writing a client that runs
locally: the developer simply creates, uses, and destroys objects, but these objects have counterparts
executing on a server that do the actual work. Session beans manage information relating to a
conversation between the client and the server, while entity beans represent and manipulate
persistent application domain data. One way to conceptualize this is that entity beans replace the
various sorts of queries used in a traditional two- or three-tier system, and session beans do
everything else.
Every EJB has a unique identifier. For entity beans, this unique identifier forms the identity of the
information. For example, an EmployeeIDNumber might uniquely identify an Employee object.
This is analogous to the concept of a primary key in a relational database system. A session bean's
unique identifier is whatever distinguishes it from other beans of its type: it may be the host name
and port number of a remote connection, or even just a randomly-generated key that the client uses
to uniquely identify a given bean.
Creating Server-Side Beans: the Home Interface
So, a client program contacts a server and requests that the server create an Enterprise JavaBean to
do data processing on its behalf. The server responds by creating the server-side object (the EJB
component instance), and returning a proxy object (the EJB object) whose interface is the same as
the EJB component's and whose implementation performs remote method invocations on the client's
behalf. The client then uses the EJB object as if it were a local object, "never knowing" that a remote
object is actually doing all the work.
How does a client program create objects on a server? Operations involving the life cycle of serverside beans are the responsibility of the EJB container. The client program actually contacts the
container and requests that a particular type of object be created, and the container responds with an
EJB object that can be used to manipulate the new EJB component.
Each EJB component class has what is called a home interface, which defines the methods for
creating, initializing, destroying, and (in the case of entity beans) finding EJB instances on the
server. The home interface is a contract between an EJB component class and its container, which
defines construction, destruction, and lookup of EJB instances.
An EJB home interface extends the interface javax.ejb.EJBHome, which defines base-level
functionality for a home interface. All methods in this interface must be Java RMI-compatible,
meaning that every method must be usable by the java.rmi package. (Going into what "RMIcompatible" means is beyond the scope of this article.) The EJB home interface also defines one or
more create() methods, whose names are all create, and whose signatures are distinct. The return
value of these object create methods is the remote interface for the EJB. As stated above, the remote
interface consists of the business methods the EJB provides. (We'll look at the remote interface
shortly.)
When a client wants to create a server-side bean, it uses the Java Naming and Directory Interface
(JNDI) to locate the home interface for the class of bean it wants. The JNDI is a standard extension
Page 42
to the Java core that provides a global service to any Java environment, allowing Java programs to
locate and use resources by name, to find out information about those resources, and to traverse
structures of resources. EJB's use of JNDI is an example of EJB meeting its goal of compatibility
with other Java APIs. We'll leave the nitty-gritty of how to use JNDI to locate a home interface to
another column, since this article is simply an overview.
Once the client has the home interface for the EJB class it wants to create, it calls one of the create()
methods on the home interface to create a server-side object. The client-side home interface object
does a remote method call to the EJB container on the server, which then creates the EJB component
and returns an EJB object to the client. The client may then call the EJB object's methods, which are
forwarded to the container. The container typically defers the implementation of the method to the
EJB component, although it is also responsible for detecting some error conditions (such as
nonexistence of the EJB component) and throwing appropriate exceptions.
Entity beans also have additional home interface finder methods that locate individual persistent
JavaBeans based on the bean's primary key. The home interface might be used, for example, to
create an instance of a ProductionFacility object, and then the finder method could be given the
ProductionFacilityCode number to locate the object representing a specific facility.
The home interface also includes a method telling the container to remove a server-side instance of
an EJB component. This method destroys the server-side instance. Trying to use the EJB object
corresponding to a removed EJB causes an exception to be thrown.
In Figure 2.14 is shown a simple client/server interaction.
3: create EJB
EJB
1: create()
EJBHomeClass
5: return handle
foo() .foo
7:7:handle
handle.
foo()
()
EJBHomeInterface
EJBObjectInterface
4: assign the
handle to the
EJB
EJBObjectClass
EJBHomeClass i s a class factory: it
creates an application object and
return an handle pointing to its
EJBObjectInterface
6: handle
handle..foo
foo()
()
All the next invocations
are intercepted by the
EJBObjectClass
Figure 2.14: EJB Client/Server interaction
Using Server-Side Beans: the Remote Interface
Once the client has an EJB object, it can call that object's methods, which are implementations of the
EJB component class's remote interface. An EJB remote interface extends the interface
javax.ejb.EJBObject, and can define any method it wishes. The only restrictions are that the
argument and return types for each method are RMI-compatible, and that each method must contain
java.rmi.RemoteException in its throws clause. Furthermore, each method in an EJB remote
interface must correspond exactly (that is, in name, argument number and type, return type, and
throws clause) to a matching method in the Enterprise JavaBean component class the interface
represents.
Page 43
2.2.1.6 CCM (CORBA Component Model)
The traditional CORBA object model, has the following limitations:
1. No standard way to deploy object implementations. The earlier CORBA specification did not
define a standard for deployment of object implementations in server processes. Deployment
involves distributing object implementations, installing those implementations in their
execution context, and activating the implementation in an Object Request Broker (ORB).
2. Limited standard support for common CORBA server programming patterns. The CORBA
family of specifications provides a rich set of features to implement servers.
3. Limited extension of object functionality. In the traditional CORBA object model, objects can
be extended only via inheritance. To support new interfaces, therefore, application
developers must (i) use CORBA’s Interface Definition Language (IDL) to define a new
interface that inherits from all the required interfaces, (ii) implement the new interface; and
(iii) deploy the new implementation across all their servers. Multiple inheritance in CORBA
IDL is fragile, because overloading is not supported in CORBA; therefore, multiple
inheritance has limited applicability.Multiple inheritance cannot expose the same interface
more than once, nor can it alone determine which interface should be exported to clients.
4. Availability of CORBA Object Services is not defined in advance. The CORBA specification
does not mandate which Object Services are available at run-time. Thus, object developers
used ad hoc strategies to configure and activate these services when deploying a system.
5. No standard object life cycle management. Although the CORBA Object Service defines a
Life cycle Service, its use is not mandated. Therefore, clients often manage the life cycle of
an object explicitly in ad hoc ways. Moreover, the developers of CORBA objects controlled
through the life cycle service must define auxiliary interfaces to control the object life cycle.
Defining these interfaces is tedious and should be automated when possible, but earlier
CORBA specifications lacked the capabilities required to implement such automation.
To address the limitations with the earlier CORBA object model, the OMG adopted the CORBA
Component Model (CCM) to extend and subsume the CORBA Object Model. The CCM is planned
for inclusion in the CORBA 3.0 specification.
CCM components are the basic building blocks in a CCM system. A major contribution of CCM
derives from standardizing the component development cycle using CORBA as its middleware
infrastructure. Component developers using CCM define the IDL interfaces that component
implementations will support. Next, they implement components using tools supplied by CCM
providers. The resulting component implementations can then be packaged into an assembly file,
such as a shared library, a JAR file, or a DLL, and linked dynamically. Finally, a deployment
mechanism supplied by a CCM provider is used to deploy the component in a component server that
hosts component implementations by loading their assembly files. Thus, components execute in
component servers and are available to process client requests. Figure 2.15 shows an example CCM
component implementing a stock exchange and its corresponding IDL definition.
To developer end-users, the format of a reference (IOR) to a Stock_Exchange component is
identical to the format of a reference to a Stock_Exchange interface. Thus, existing componentunaware software can invoke operations via an object reference to a component’s equivalent
interface, which is the interface that identifies the component instance uniquely. As with a regular
CORBA object, a component’s equivalent interface can inherit from other interfaces, called the
component’s supported interfaces.
Page 44
Component
Stock_Exchange Reference
(supported interface)
Provided
interface
(facet)
Stock_Quote
Component
Stock_Exchange
Facet
imple mentation
SEC
Receptacle
Buy_Offers
Event
Sinks
Price_Change
Sell_Offers
Attributes
Event
Source
Event Sink
imple mentations
Figure 2.15: An example CCM Component with IDL specification
CCM components provide four types of mechanisms called ports to interact with other CORBA
programming artifacts, such as clients or collaborating components. These port mechanisms specify
different views and required interfaces that a component exposes to clients. Along with component
attributes, these port mechanisms define the following capabilities of a component:
1. Facets: Facets, also known as provided interfaces, are interfaces that a component provides,
yet which are not necessarily related to its supported interfaces via inheritance. Facets allow
component to expose different views to its clients by providing different interfaces that can
be invoked in different manner. CCM facets are similar to component interfaces in
Microsoft's COM.
2. Receptacles: Before a component can delegate operations to other components, it must
obtain the object reference to an instance of the other components it uses. In CCM, these
references are “object connections” and the port names of these connections are called
receptacles. Receptacles provide a standard way to specify interfaces required for the
component to function correctly.
3. Event sources/sinks: Components can also interact by monitoring asynchronous events. A
component can declare its interest to publish or subscribe to events by specifying event
sources and event sinks in its definition.
4. Attributes: To enable component configuration, CCM extends the notion of attributes
defined in the traditional CORBA object model. Attributes can be used by configuration
tools to preset configuration values of a component. Unlike previous versions of CORBA,
CCM allows operations that access and modify attribute values to raise exceptions. The
component developer can use this feature to raise an exception if an attempt is made to
change a configuration attribute after the system configuration has completed. As with
previous versions of the CORBA specification, component developers must decide whether
an attribute implementation is part of the transient or persistent state of the component.
These new port mechanisms significantly enhance component reusability when compared to the
traditional CORBA object model. For instance, an existing component can be replaced by a new
component that extends the original component definition by adding new interfaces without
affecting existing clients of the component. Moreover, new clients can check whether a component
provides a certain interface by using the CCM Navigation interface, which enumerates all
facets provided by a component. In addition, since CCM allows the binding of several unrelated
Page 45
interfaces with a component implementation entity, clients need not have explicit knowledge of a
component’s implementation details to access the alternative interfaces that it offers.
To standardize the component life cycle management interface, CCM introduces the home IDL
keyword that specifies the life cycle management strategy of each component. Each home interface
is specific to the component it is defined for and manages exactly one type of component. A client
can access the home interface to control the life cycle of each component instance it uses. For
example, the home interface can create and remove components instances.
To use a component, a client first acquires the home interface of the component.Naturally, there
must be a standard bootstrapping mechanism to locate the home interface of a specific component.
To simplify this bootstrapping process, references to available component homes can be stored in a
centralized database accessed through a HomeFinder interface similar to the CORBA
Interoperable Naming Service.
CCM defines common techniques to implement CORBA servers. Component developers use IDL
definitions to specify the operations a component supports, just as object interfaces are defined in
the traditional CORBA object model. A CCM component can compose together unrelated interfaces
and support interface navigation. Components can be deployed in component servers that have no
advance knowledge of how to configure and instantiate these deployed components. Therefore,
components need generic interfaces to assist component servers that install and manage them. CCM
components can interact with external entities, such as services provided by an ORB, other
components, or clients via ports, which can be enumerated using the introspection mechanism. Ports
enable standard configuration mechanisms to modify component configurations.
CCM defines several interfaces to support the structure and functionality of components. Many of
these interfaces can be generated automatically via tools supplied by CCM Providers. Moreover, life
cycle management and the state management implementations can be factored out and reused. The
CORBA Component Implementation Framework (CIF) is designed to shield component developers
from these tedious tasks by automating common component implementation activities.
Page 46
CIDL
compiler
CIDL
Files
Component
Descriptions
Component
Implementation
Source Code
Source Code
Generated Code
component-aware
IDL compiler
Interface
Repository
Component
Implementation
Skeletons
Server
Skeletons
IDL
Files
Client
Stubs
C++
compiler
C++
compiler
Component
Program (DLL)
Client
Program
Client Source
Code
Executable Code
Figure 2.16: Implementing Components using the CIDL
The CIF defines a set of APIs that manage the persistent state of components and construct the
implementation of a software component . CCM also defines a declarative language, the Component
Implementation Definition Language (CIDL), to describe implementations and persistent state of
components and component homes. As shown in Figure 2.16, the CIF uses the CIDL descriptions to
generate programming skeletons that automate core component behaviors, such as navigation,
identity inquiries, activation, and state management.
Implementations generated by a CIDL compiler are called executors. Executors contain the
aforementioned auto-generated implementations and provide hook methods that allow component
developers to add custom component-specific behavior. Executors can be packaged in so-called
assembly files and installed in a component server that supports a particular target platform, such as
Windows NT or Linux, and programming language, such as C++ or Java. In addition, the CIDL is
responsible for generating component descriptors that define component capabilities, such as
descriptions of component’s interfaces, threading policy, or transaction policy, along with the type
of services required by the component being described.
The CCM component model implementation uses the component description to create and configure
the POA hierarchy automatically and to locate the common services defined by CCM: component
servers instantiate containers, which perform these tasks on behalf of components they manage. The
CCM container programming model defines a set of interface APIs that simplify the task of
developing and/or configuring CORBA applications. A container encapsulates a component
implementation and provides a run-time environment for the component it manages that can:
1. Activate or deactivate component implementations to preserve limited system resources,
such as main memory.
2. Forward client requests to the four commonly used CORBA Object Services (COS):
Transaction, Security, Persistent State, and Notification services, thereby freeing clients from
having to locate these services.
Page 47
3. Provide adaptation layers for callbacks used by the container and ORB to inform the
component about interesting events, such as messages from the Transaction or the
Notification Service.
4. Manage POA policies to determine how to create component references. Figure 2.17 shows
the CCM container programming model in more detail.
Clients directly access external component interfaces, such as the equivalent interface, facets, and
the home interface. In contrast, components access the ORB functionality via their container APIs,
which include the internal interfaces that the component can invoke to access the services provided
by the container, as well as the callback interfaces that the container can invoke on the component.
Each container manages one component implementation defined by the CIF. A container creates its
own POA for all the interfaces it manages.
Component
Home
Component
Home
Container
External
Interfaces
CORBA
Component
Container
Callback
Interfaces
External
Interfaces
Internal
Intefaces
CORBA
Component
Callback
Interfaces
Internal
Intefaces
POA
POA
ORB
Transactions
Security
Persistent State
Notification
Figure 2.17: The CORBA Component Model's Container Programming Model
CCM containers also manage the lifetime of component servants. A CCM provider defines a
ServantLocator that is responsible for supporting these policies. When a ServantLocator
is installed, a POA delegates the responsibility of activating and deactivating` servants to it. Four
types of servant lifetime policies control the timing of activating and deactivating components:
method, session, component, and container. Method and session policies cause
ServantLocators to activate and passivate components on every method invocation or session,
whereas component and container policies delegate the servant lifetime policies to components and
containers, respectively. In large-scale distributed systems, component implementations may be
deployed across multiple servers, often using different implementation languages, operating
systems, and programming language compilers. In addition, component implementations may
depend on other software component implementations. Thus, the packaging and deploying of
components can become complicated. To simplify the effort of developing components, CCM
defines standard techniques that developers can apply to simplify component packaging and
deployment. CCM describes components, and their dependencies using Open Software Description
(OSD), which is an XML Document Type Definition (DTD) defined by the WWW Consortium.
Components are packaged in assembly files and package descriptors are XML documents
Page 48
conforming to the Open Software Description DTD that describe the contents of an assembly file
and their dependencies. A component may depend on other components and may require these
components to be collocated in a common address space.
2.2.2 Message Oriented Middleware
MOM can be seen as a natural extension of the packet paradigm of communications prevalent in the
lower layers of the OSI network model. Unlike RPC and object-orientation it is an asynchonrous
form of communication, i.e. the sender does not block waiting for the recipient to participate in the
exchange. If the message service offers persistence and reliability then the receiver need not be up
and running when the message is sent. Unlike OOM, in MOM, messages are generally untyped and
the internal structure of messages is the responsibility of the application.
In traditional MOM, messages are addressed to their recipients, although sender and receiver are
loosely coupled and need not synchronise to communicate. This may be less suitable for wide-area,
large-scale systems and so it may be advantageous to decouple sources and sinks with respect to
naming, so they may be mutually anonymous to each other. A typical way of designing this is (so
called) publish-subscribe systems, where sources "publish" to the entire network and interested sinks
"subscribe" to messages. The network then only forwards them downstream if there is at least on
subscriber on that path. This requires the message transport service to understand the messsage
internals, although some systems are "topic-based" where each message has a subject line which the
transport system reads and can ignore the rest of the message.
MOM has a larger share of the market than Object-Oriented Middleware, being used for database
access in large business applications. Examples of MOM are IBM's MQseries (reliable, MOM
service), TIBCO/Rendezvous (topic-based, publish-subscribe), and Sun JMS (general messaging
service).
2.2.2.1 IBM Websphere MQ (MQ Series)
Introduction
The IBM MQSeries range of products provides application programming services that enable
application programs to communicate with each other using messages and queues.
The programs that comprise an MQSeries application can be running on different computers, on
different operating systems, and at different locations. The applications are written using a common
programming interface known as the Message Queue Interface (MQI), so that applications
developed on one platform can be transferred to another.
Queue Managers
In MQSeries, queues are managed by a component called a Queue Manager. The queue manager
provides messaging services for the applications and processes the MQI calls they issue. The queue
manager ensures that messages are put on the correct queue or that they are routed to another queue
manager. Before applications can send any messages, must be created a queue manager and some
queues.
Any MQSeries application must make a successful connection to a queue manager before it can
make any other MQI calls. When the application successfully makes the connection, the queue
manager returns a connection handle. This is an identifier that the application must specify each time
Page 49
it issues an MQI call. An application can connect to only one queue manager at a time (known as its
local queue manager), so only one connection handle is valid (for that particular application) at a
time. When the application has connected to a queue manager, all the MQI calls it issues are
processed by that queue manager until it issues another MQI call to disconnect from that queue
manager.
Queue Opening
Before an application can use a queue for messaging, it must be opened. If an application is putting a
message on a queue, it must open the queue for putting. Similarly, if an applciation is getting a
message from a queue, it must open the queue for getting. It is possible to specify that a queue is
opened for both getting and putting, if required. The queue manager returns an object handle if the
open request is successful. The application specifies this handle, together with the connection
handle, when it issues a put or a get call. This ensures that the request is carried out on the correct
queue.
Putting and Getting Messages
When the open request is confirmed, an application can put a message on the queue. To do this, it
uses another MQI call on which you have to specify a number of parameters and data structures.
These define all the information about the message you are putting, including the message type, its
destination, which options are set, and so on. The message data (that is, the application-specific
contents of the message your application is sending) is defined in a buffer, which you specify in the
MQI call. When the queue manager processes the call, it adds a message descriptor, which contains
information that is needed to ensure the message can be delivered properly. The message descriptor
is in a format defined by MQSeries; the message data is defined by your application (this is what
you put into the message data buffer in your application code).
The program that gets the messages from the queue must first open the queue for getting messages.
It must then issue another MQI call to get the message from the queue. On this call, you have to
specify which message you want to get.
Messaging and Queue Managers
In a real application, the putting and getting programs would probably be on different computers,
and so connected to different queue managers.
The Figure 2.18 shows how messaging works where the program putting the message and the
program getting the message are on the differnt computers and are connected to different queue
managers.
Program A makes an MQPUT call specifying not a local queue but a local definition of a remote
queue. This definition identifies a queue on another queue manager. The queue manager to which
program A is connected puts the message on a special queue called a transmission queue. The
message is then automatically sent along the channel connecting the two queue managers. (If the
channel is running). The receiving queue manager puts the message on the queue that was originally
specified by program A. This message is stored on the queue until it is retrieved by program B, after
program B has issued an MQGET call. In this situation, there is also the need to create message
channels to carry MQSeries messages between the queue managers.
Page 50
Program A
(MQPUT)
Program B
(MQGET)
A
Local Definition of QUEUE 1
QUEUE 1
Message
Channel
PC1
B
PC2
Queue Manager
Queue Manager
Figure 2.18: MQSeries messaging with more that one queue manager
2.2.2.2 Sun JMS (Java Messaging Service)
Introduction
The JavaTM Message Service (JMS) API is a JavaTM technology application programming interface
(API) for interclient communication among distributed applications. JMS is a service-oriented API
specification. That is, the JMS API prescribes messaging functionality in terms of interfaces, which
JMS vendors then implement; thus, programmers work with JMS through these interfaces. Although
the JMS specification is still rather new, it has been implemented by several vendors.
There is a growing presence of large-scale distributed computing frameworks such as Java
application servers, as well as smaller frameworks for specific distributed computing tasks such as
mail handling and message passing. This presence, and from a business perspective, the market
success of these products, further signals the now-obvious trend toward intranet- and extranetresident, as well as enterprise-oriented software development.
One of the nicest aspects of the JMS API is that programmers can be productive with it very
quickly, especially for rather straightforward communication tasks among distributed application
components. At the same time, the technology is quite general allowing creative programmers to
develop specialized, perhaps, enterprise-specific, communication frameworks.
One of the keys to the power of JMS is the core message types, which provide the capability for
sending various types of data among distributed components, for example, a serialized object,
Extensible Markup Language (XML) text, a byte array, and others.
The JMS Environment
JMS is typically implemented by Java application servers, which provide a host of Java technologybased services, as well as by message-oriented middleware that operates either alone or in concert
with other distributed computing software.
The advantages and disadvantages of common topologies for distributing resources have been
documented for many years, especially in areas such as networking and operating systems. Common
topologies include, for example, bus, star, ring, hierarchical, and partially and fully connected.
Server-oriented distributed application topologies often resemble star (often called hub-and-spoke)
resource topologies.
Page 51
Historically, enterprise computing has been built on a client-server model in which applications
(clients) require access to a scarce resource, usually available via a centralized server, for example,
database servers, file servers, and transaction-processing servers. Direct client interaction with lowlevel servers can be problematic, for example, server upgrades often leads to broken clients.
Middleware application servers are invaluable because they operate in the so-called middle tier, that
is, between a client and a server. Java application servers, however, are more than simple
intermediaries that insulate clients from versioning issues in the server APIs. Today's sophisticated
application servers employ clustering strategies that encourage enterprise-level load balancing and
offer other performance and reliability enhancements.
In designing and implementing distributed software systems for enterprises, it's important to use an
application topology that fits the enterprise, as opposed to fitting the enterprise to the server
environment by implementing a thin software layer on top of the application server framework.
Depending on the enterprise scenario, the optimal distributed application design could be built on
one or more large-scale application servers, or in conjunction with service-specific middleware, for
example, MOM servers.
Messaging systems, in particular, have the potential to "empower clients." JMS vendors will likely
provide embedded messaging functionality that can be incorporated into each application (or at least
a designated subset of distributed applications). That is, each distributed "client" provides, in turn,
services to other clients. Ultimately, messaging systems enable participating applications to initiate
service requests as well as honor service requests from other clients.
JMS Essentials
JMS supports two common interclient messaging models:
• Publish/subscribe scenarios
• Basic point-to-point communication
There are quite a few messaging systems in widespread use that implement one or both of these
interclient, object-oriented communication strategies. JMS, however, has the advantage of being the
Sun Microsystems-managed Java messaging API that has been endorsed and is being implemented
by a broad range of distributed computing software vendors.
Publish/Subscribe Messaging
With publish/subscribe scenarios, an application registers with a JMS-capable server as a publisher
of messages for some topic, while one or more other applications subscribe to messages on that
topic (see Figure 2.19). For example, consider an application that tracts employee hirings in the
human resources department and publishes a message describing each such hiring. The server is the
intermediary; hence, each message is disseminated by the JMS-capable server to each application
that subscribes to that topic. That is, for each message published relative to a given topic, there is
potentially a one-to-many relationship between the publisher and the subscriber(s).
Point-to-Point Messaging
With point-to-point messaging, one application produces a message and another application
consumes it (see Figure 2.19). Thus, for each message produced relative to a particular queue, there
is a one-to-one relationship between the sender and the registered receiver.
Page 52
In a sense, with both messaging models there is a producer/sender and a consumer/receiver of each
message. Historically, with the publish/subscribe model it's more common to use the publisher,
subscriber, and topic terminology and with the point-to-point model it's more common to speak of a
sender, receiver, and queue.
Quality of Service
Two somewhat-related issues arise with messaging systems: durability and persistence. With JMS,
the durable connection issue applies only to the publish/subscribe model. Message subscribers
register with the server as durable or nondurable via either the session's createDurableSubscriber()
or createSubscriber() method, respectively. In the latter case, published messages are only delivered
to applications with an active session. In the former case, published messages are held in persistent
storage until delivered to each subscriber, or until some arbitrary time-out period expires.
Persistence, on the other hand, is a message-level, publishing-oriented issue. Applications that
publish messages for topics or send messages to queues can set the delivery mode for each messagesending operation to either PERSISTENT or NON_PERSISTENT (along with priority and time-tolive values):
Message Selectors
You can restrict, or qualify, message delivery with what are commonly called message selectors.
That is, an application can request that the JMS framework filter the messages based on Boolean
expressions, similar to row selection in a SQL query's where clause.
Message selectors use a message's property functionality, which will be discussed in a subsequent
article. For now, each message can be assigned application-specific properties, and these properties
can be referenced in message selectors.
JMS Publish & Subscribe
JMS Point-to-Point Communication
Figure 2.19: JMS Messaging models
Page 53
2.2.2.3 TIB/Rendezvous
The TIB/Rendezvous is both a point-to-point and a publish/subscribe system originally described in
terms of an information bus, a minimal communication system for a collection of processes based
on the design principles that the core communication system is highly application independent,
exchanged messages are self describing and processes are referentially uncoupled.
To ensure application independency the basic system does not offer any support to complex message
ordering semantics or to atomic transactions. The former should be dealt with at the application
level, the latter are supported by means of an additional service. Besides the key idea underlying the
TIB/Rendezvous referentially uncoupled processes is the subject-based addressing. In this
approach a process that wants to send a message does not specify the actual destination but instead
tags the message with a subject name and subsequently passes it to the communication system for
transmission across the network. Receivers, in turn, do not specify from which processes they are
prepared to accept incoming messages. Instead they tell the communication system about the subject
they are interested in. The communication system then ensure that only those messages that carry
data on the subject a receiver is interested are delivered to that receiver.
Architecture
The architecture of a TIB/Rendezvous system is relatively simple. Fundamental to its
implementation is the use of a multicast network, although it uses more efficient communication
facilities as point-to-point messages when it is known exactly where a subscriber resides. Each host
on such a network runs a rendezvous daemon, which take care that messages are sent and delivered
according to their subject. Whenever a message is published, it is multicast, using the facilities
offered by the underlying network, such as IP-multicasting or hardware broadcasting, to each host
on the network running a rendezvous daemon Figure 2.20. Processes that subscribe to a subject pass
their subscription to their local daemon. The daemon constructs a table of (process, subject)-entries
and whenever a message on subject S arrives, the daemon simply checks in its table for local
subscribers, and forward the message to each one. If there are no subscribers for S, the message is
discarded immediately.
Publ.on A
Subs.to A
Subs.to A
Publ.on A
Subs.to A
Subs.to B
Subs.to B
RV lib
RV lib
RV lib
RV lib
RV lib
RV
daemon
RV
daemon
RV
daemon
RV
daemon
RV
daemon
Subj:A
Subj:B
Multicast message
on A to subscribers
Network
Multicast message on B to subscribers
Figure 2.20: The TIB/Rendezvous daemon architecture
To allow the system to expand across larger network such as a WAN, there are also rendezvous
router daemons. Normally each local network will have a single router daemon. This daemon
communicates with router daemons on other remote network, as shown in Figure 2.21. Router
daemon together form a point-to-point overlay network, i.e. an application-level network of routers,
in which pairs of routers are connected through a TCP connection. Each router knows about the
topology of the overlay network and computes a multicast tree for publishing messages to other
Page 54
networks. A router multicasts only those messages that are published on the local network it is
representing. A message from another network is forwarded along the multicast tree for the network
from which the message comes from. For reason of performance, whenever a message is published
it is delivered only to those remote networks that have been explicitly configured to accept such
messages, and which currently have a subscriber to that message.
Router
daemon
Local-area
network
TCP point-to-point
connection
Figure 2.21: The overall architecture of a wide area TIB/Rendezvous system
Communication
Each message can be constructed as an arbitrary number of fields that are constructed dynamically
by the sending process. Before a message can be sent, it is necessary to associate a subject with it by
calling a separate operation. A subject itself is expressed as a character-string name. It is also
possible to associate a reply subject with a message. This subject name can thus be used by a
recipient to return reply to the sending process. Of course the sender will have to subscribe to its
own reply subject. For performance reasons, each process can use specially created, process specific
subject name, called an inbox name. If a published P uses the inbox name of another process Q
when publishing a message, the message is sent directly to Q using point to point communication
facilities instead of a multicasting. In order to send and receive messages, processes create what are
called transports. A transport is a local object similar to a socket as introduced in Berkeley UNIX.
A transport is used to send rendezvous daemon listening to a specific port and using a particular
communication protocol. For example there are different transport for using broadcasting, link-level
network multicasting or IP multicasting.
Primitives
There are only three communication primitives associated with a transport. A send operation takes a
message and passes it to the local rendezvous daemon which in turn, will take care that the message
is properly published; send is a nonblocking operation. Likewise, there is a non blocking sendreply
operation, which can be called in reaction to the receipt of a message containing a reply subject.
Page 55
Finally there is a blocking sendrequest operation, which passes a message to a local rendezvous
daemon for transmission across the underlying network, and then blocks the calling thread until a
reply message is received. The reply is sent back to a (dynamically created) inbox name using pointto-point communication. Note that there are no separate receive operation.
2.2.3 Web Oriented Middleware
Emerging standards such as SOAP, WSDL and UDDI will enable a new generation of "web
services" that allow systems to communicate with other systems over the open protocols of the
Internet. For example, a corporate inventory management system might publish a web service that
lets a customer's system check real-time inventory levels.
A classification of how much the market offers at the moment, can be outlined in Figure 2.22, where
the two dimensions of grouping are:
• the problematic covered from the language or the technology;
• the technology that uses the services.
Figure 2.22: Service Oritented Architecture
2.2.3.1 XML (eXensible Markup Language)
The eXtensible Markup Language (XML) was born as a W3C Recommendation for marking up
screen presentable data that cannot be marked up using the simple set of document presentation
elements defined in the HyperText Markup Language (HTML). Whilst designed initially for the
display of documentation distributed via the World Wide Web (WWW), XML has been widely
adopted as a means of interchanging information between computer programs.
XML is an extremely simple dialect of the Standard Generalized Markup Language (SGML1). The
goal of XML is to enable SGML-coded data to be served, received, and processed on the Web in the
way that is as easy as that currently made possible by use of the fixed SGML tag set provided by
HTML. XML has been designed for ease of implementation and for interoperability with both
SGML and HTML. Unlike early versions of SGML and HTML, XML has been based from the very
start on the ISO 10646 Universal Multi-Octet Coded Character Set (UCS, which includes the codes
that make up the Unicode character set) so that it can be used in all major trading nations.
1
SGML has been defined in ISO Standard 8879. It is a formal definition of the component parts of publishable information set designed as a tool to enable technical documentation
and other forms of publishable data to be interchanged between authors, publishers and printers.
Page 56
An XML document instance must be created and stored as a set of properly nested data storage
entities, each of which is made up of a number of logical elements which contain data or define
processes to be performed. The outermost storage entity is referred to as the document entity: it
contains both the start and the end of the root or document element of the document instance.
Elements can be nested to create hierarchies (information trees), and may contain references to
embedded entities. Elements can be assigned attributes (properties) which indicate how the contents
of the element should be interpreted.
Each XML element starts with a named start-tag and ends with an end-tag with a matching name.
Outward pointing angle brackets are used to delimit these markup tags (e.g. <title>). An end-tag
is distinguished from a start-tag by having a slash immediately preceding the name (e.g.
</title>). Elements that have no contents are distinguished by having a slash immediately after
the name in the start-tag to indicate that the end-tag has been omitted (e.g. <image/>). Because each
element of an XML document has clearly marked limits, it is easy to determine when its contents
have been received over a network.
Attributes of XML elements are defined as part of its start-tag (e.g. <image title="Front
view" source="entity1"/>). Each XML attribute must be fully defined, with the attribute
name followed by a value indicator (=) and a quote delimited string containing the attribute value.
Attributes can be assigned a default value if an attribute list declaration is associated with the
formal declaration for the element in the document type declaration.
XML requires that data that is not coded in XML characters be stored in a named binary entity,
which may have associated with it the name of the notation in which its contents have been encoded.
The location and notation of each uniquely named binary entity must be declared in an entity
declaration (e.g. <!ENTITY entity1 SYSTEM "http://www.dis.uniroma1.it/
figs/figure1.gif" NDATA GIF>).
The location of a processor for a notation can (optionally) be identified using a notation declaration
(e.g. <!NOTATION GIF SYSTEM "show-gif.dll">). XML uses Internet Uniform Resource
Locators (URLs) to identify locations of external entities and other types of files. Relative URLs can
be used to identify locally stored information.
Parts of an XML document instance can be stored in separate files that will be referenced as external
text entities. Such entities are declared in the same way as binary entities, except that there is no
associated notation name. Alternatively internal text entities can be used to define the replacement
text for an entity reference. For example, addition of an entity declaration of the form <!ENTITY
university "UNIROMA1"> to a document type declaration will allow an entity reference of the
form & university; to be entered in the associated document instance. This reference will be replaced
by the quoted replacement text defined in the entity declaration when the file is processed (parsed).
The set of elements, attributes, entities and notations that can be used within an XML document
instance can (optionally) be formally defined in a document type definition (DTD) that is associated
with the document instance through the addition of a document type declaration that forms part of
the prolog of a document instance. The declarations that make up the document type definition can
form part of a file referenced as the external subset of the document type declaration, or can be
embedded, or referenced, within the internal subset of the declaration. Comment declarations must
be used for any explanations required as part of the document type definition.
Page 57
XML is a general-purpose markup language and can be used in several different ways:
• XML can Separate Data from HTML: HTML pages are used to display data which often is
stored inside HTML pages. With XML this data can be stored in a separate XML file. This
way you developers concentrate on using HTML for formatting and display, and be sure that
changes in the underlying data will not force changes to any of their HTML code;
• XML can be used as a format to exchange information: In the real world, computer systems
and databases contain data in incompatible formats. One of the most time-consuming
challenges for developers has been to exchange data between such systems over the Internet.
Converting the data to XML can greatly reduce this complexity and create data that can be
read by many different types of applications;
• XML is used in B2B applications: XML is going to be the main language for exchanging
financial information between businesses over the Internet. With XML, in fact, financial
information can be exchanged over the Internet;
• XML can be used to Share and Store Data: Since XML data is stored in plain text format,
XML provides a software- and hardware-independent way of sharing data. This makes it
much easier to create data that different applications can work with. It also makes it easier to
expand or upgrade a system to new operating systems, servers, applications, and new
browsers. XML can also be used to store data in files or in databases. Applications can be
written to store and retrieve information from the store, and generic applications can be used
to display the data. Since XML is independent of hardware, software and application, data
can be made available to other than only standard HTML browsers. Other clients and
applications can access XML files as data sources, like they are accessing databases.
Actually XML formatted data can be made available to all kinds of "reading machines"
(agents).
2.2.3.2 SOAP (Simple Object Application Protocol)
SOAP is a lightweight and simple XML-based protocol designed to exchange structured and typed
information between peers in a decentralized, distributed environment as the Web is. The purpose of
SOAP is to enable rich and automated Web services based on a shared and open Web infrastructure.
It is an important protocol for application development to allow Internet communication between
applications.
SOAP can be used in combination with a variety of existing Internet protocols and formats, in
particular HTTP, and can support a wide range of applications from messaging systems to Remote
Procedure Calls (RPC). Today's applications communicate using RPC between objects like DCOM
and CORBA but RPC represents a compatibility and security problem; firewalls and proxy servers
will normally block this kind of traffic.
A better way to communicate between applications is thus over HTTP, even if it was not designed to
support RPC, because it is supported by all Internet browsers and servers. HTTP does not natively
support RPC interaction paradigm and SOAP has been created to accomplish this requirement. It
will be developed as a W3C standard providing a way to communicate between applications running
on different operating systems, with different technologies and programming languages.
It consists of three parts:
• an envelope that defines a framework for describing what is in a message exchanged and
how to process it;
Page 58
• a set of encoding rules for expressing instances of application-defined format (datatypes);
• a convention for representing remote procedure calls and response.
A SOAP message is an ordinary XML document containing the following elements:
• A SOAP <Envelope>, that defines the content of the message;
• A SOAP <Header> (optional), that contains header information;
• A SOAP <Body>, that contains call and response information.
The <Envelope> element is mandatory and represents the root element of a SOAP message. It
defines an XML document as a SOAP message, the other are its child elements.
More specifically the optional <Header> element contains additional, application specific
information about the SOAP message such as for example the language used in the SOAP message;
it provides a generic mechanism for adding features to a SOAP message in a decentralized manner
without prior agreement between the communicating parties.
The mandatory <Body> element contains the actual SOAP message; it may contain a <Fault>
element used to provide information about errors that occurred while processing the message. By
nature this element can only appear in answers (response messages).
SOAP elements can have three attributes:
• actor: the actor attribute defines the URI for which the header elements are intended;
• encodingStyle: the encodingStyle element is used to define the datatypes that is used in the
document;
• mustUnderstand:the mustUnderstand attribute is used to define if the receiver of a message
must process a header element.
2.2.3.3 Language for Web-Services
WSDL and WSCL (Web Services Description and Conversation Language)
WSDL is a XML-based language for describing services, specifically their static interfaces. A
service is a collection of ports (i.e., network endpoints); operations consists of messages, which are
abstract descriptions of the data being exchanged, and sets of operations constitute port types. The
concrete protocol and data format specifications for a particular port type constitute a reusable
binding; currently bindings are provided for SOAP, HTTP GET and POST, and MIME. A port is
defined specifying its type and associating a network address with a binding. With WSDL, the
interface of the Web-Service is described in a way conceptually analogous to the use of Interface
Definition Language (IDL) specifications in distributed object middleware.
WSCL is a very novel proposal, based on XML, for describing the “conversations” a service
supports; a conversation is the sequence of message exchanges. Whereas WSDL specifies which
messages to send to a service, WSCL specifies the order in which such messages can be sent. A
conversation is described as an activity diagram, in which interactions (i.e., the actions of the
conversation as message exchanges) are represented as action states, and transitions represent
ordering relationships between interactions.
As an example, Figure 2.23 depicts the activity diagram of a simple purchase conversation, from the
perspective of the seller. A service that supports this conversation expects a conversation to begin
Page 59
with the receipt of a LoginRQ or a RegistrationRQ document. Once the service has received
one of these documents, it answers with a ValidLoginRS, an InvalidLoginRS, or a
RegistrationRS, depending on the type and content of the message received, and so forth.
Figure 2.23: WSCL activity diagram of a “Seller” Web-Service
ebXML CPP and CPA (Collaboration Protocol and Agreement)
In ebXML, a party is an entity that engages in business transactions with another business party,
even though they may procure application software and run-time support software from di_erent
vendors. A Collaboration Protocol (CPP) defines a party's message exchange capabilities and the
business collaborations that it supports. A Collaboration Protocol Agreement (CPA) defines the way
two parties will interact in performing the chosen business collaboration.
A CPA can be composed by intersecting the respective CPP's of the parties involved; the resulting
CPA contains only those elements that are in common, or compatible, between the two parties;
variable quantities, such as number of retries of errors, are then negotiated between the two parties.
A CPA describes all the valid visible, and hence enforceable, interactions between the parties and
the way these interactions are carried out. It is independent of the internal processes executed at each
party. Each party executes its own internal processes and interfaces them with the business
collaboration described by the CPA and process speci_cation document. The CPA does not expose
Page 60
details of a party's internal processes to the other party. Both CPP's and CPA's are speci_ed as XML
documents conform to a standard DTD. Parties use identical copies of the CPA to configure their
run-time systems; this assures that they are compatibly configured to exchange messages whether or
not they have obtained their run-time systems from the same vendor (see Section 2.2.3.5).
2.2.3.4 Repositories for Web-Services
UDDI (Universal Description, Discovery and Integration)
In UDDI, the repository is referred to as UDDI Business Registry; it is a logically centralized,
physically distributed service with multiple nodes (referred to as operator sites) that replicate data
with each other on a regular basis.
A registration in the Business Registry consists of three components: “white pages” including
business information about the service provider organization, “yellow pages" including
classifications based on various taxonomies, and “green pages" providing technical information
about provided services.
This is obtained through four data structures defined according to an appropriate XML schema:
businessEntity, businessService, bindingTemplate and tModel, as shown in
Figure 2.24.
Contact
personName
description
address
0...
phone
email
businessEntity
name
businessKey
1 descript ion
tModel
name
description
tModelKey
1
1
1...
0...
busines sService
serviceKey
name
description
OverviewDoc
description
overviewURL
0...
1
AccessPoint
URLType
URL
0...
1
0...
bindingTemplate
bindingKey
description
1
1
1
0...
0...
tModelInfo
description
instanceParams
Figure 2.24: UDDI (simplified) data model in UML
The businessEntity objects describe information about a business; businessService ones
provide descriptive details on each service being offered; each service can have multiple
bindingTemplate objects, each describing a technical entry point for that service (i.e., the
network endpoint address). Finally, through tModel objects, the service is technically described.
Page 61
tModel objects actually do not contain specifications, but taking advantages of URI mechanisms,
simply reference specifications located on service providers: they are meta-data about a
specification, including its name, publishing oroganization and pointers to the actual specification.
Therefore the Business Registry is not a real repository (it does not store specifications) but a
registry: it can not be queried based on contents of tModel objects.
Specifically a bindingTemplate object publishes a list of tModelInfo elements that refer to
the tModel objects that the service supports. A tModel data structure includes a unique key, a
name element, an optional description and an overviewDoc element in which a URL for the
actual specification document is stored. Best practices suggest to use WSDL and WSCL for
specifying a service, but conceptually any other service specification language can be used instead
without impacting on the repository.
Data access and manipulation are based on SOAP for transport, and are provided through specific
API's with limited expressive power.
ebXML Registry
ebXML defines a Registry as a store for meta-data describing generic documents (such asWebService specifications) and a Repository as a store for the documents. Possible repositories' data
models are not described, whereas the meta-meta-model of the Registry, referred to as Registry
Information Model (RIM), is defined; it consists of different entities, such as RegistryEntry,
Association, ClassificationNode, ClassificationSchema, etc. (as shown in
Figure 2.25).
RIM does not deal with the actual content of the repositories: all elements of the RIM represent
meta-data about the content and not the content itself; data models are to be hidden in the
objectType attribute of RegistryEntry and in the associationType attribute of the
Association.
As an example, in order to simulate the UDDI Data Model, we should introduce objectType
values of “businessEntity” and “businessService”, as well an associationType
with “busEntbusSvc”. Data access and manipulation is provided for both registry and repository,
through a proprietary XML query language.
Page 62
Bas e class for
all data in
registry. Any
data in regist ry
that has a
unique identit y
is a
Regist ryObject
.
RegistryObject
id
name
descript ion
User
Base class for content
or metadata managed
by registry
Metadata describing
content whose type
is not known to
registry
RegistryEntry
status
objectType
AuditableEvent
Base class for content or
metadata whose type is
known to the registry
ExtrinsicObject
ExternalIdentifier
IntrinsicObject
Organization
Association
associationType
sourceRole
targetRole
bidirectional
ClassificationNode
ClassificationNode
Classification
ExternalLink
Association
0.. .
0...
0.. .
1
0...
1
0...
1
RegistryEntry
Classification
1
0...
0...
1...
1
1
0...
ExternalLink
ExternalIdentifier
1...
Audit ableEvent
User
0...
1
Organization
1...
1
Figure 2.25: ebXML RIM in UML (inheritance and relationship views)
Page 63
2.2.3.5 Coordination of Web-Services
Coordination of Web-Services, which is often referred to either as orchestration or as choreography,
is considered in this subsection, for each of the two competing framework proposals.
WSFL (Web Service Flow Language)
Web-Service Flow Language (WSFL) is a XML-based language for the composition of WebServices. A WSFL speci_cation of a composite Web-Service consists of two parts: (i) the flow
model (also referred to as flow composition, orchestration or choreography), which describes the
execution sequence (control and data flow) of the composed services; and (ii) the global model,
which describes how services are composed: interactions are modeled as links between endpoints of
services' interfaces, each link representing the interaction of one service with an operation of another
one. The relation between global and ow meta-models can be stated as follows: the ow meta-model
allows to describe the internal behavior of a composite Web-Service, whereas the global meta-model
allows to define the interactions between (composed) Web-Services.
Flow meta-model. In WSFL, a flow model/schema is a directed graph in which nodes are activities
and edges represent control and data links. Each activity has a signature (input, output and
fault messages) that is related to the signature of the operation that is used as implementation
of; edges can be labeled with transition conditions. Fork and join nodes are provided,
whereas loops are possible only in a restricted way, that basically corresponds to a “repeat
. . . until . . .”. Therefore with the WSFL flow meta-model it is possible to
define schemas of the class RLWFM.
Global meta-model. The global meta-model is based on WSDL for describing services, port types
and operations. A service provider type defines the interface of a service; it represents a set
of port types declaring operations supported by the service. Interactions between service
providers are represented as a special type of link, a plug link. A plug link can be interpreted
as:
• an invocation of a “serving” operation by a “requesting” operation; this analogy is
especially useful for request-response/solicitresponse operation pairs;
• an event propagation between two components: the source component sends a
triggering event to the target and thereby triggers some action to take place on the
receiving end. The receiver may or may not respond to this event. The latter
interpretation is useful for notification/one-way interactions.
Interactions take place between “dual” operations on the service provider types involved in
the composition. The interaction between service providers is conducted through the
operations defined by their public interfaces. These operations need to be connected to each
other for the interaction to take place; source and target operations of the connection must
have “dual” signatures: a solicit-response operation can be connected to a request-response
operation, and notification operations to one-way operations.
For each activity in a ow model/schema, a WSDL operation is defined that provides the
implementation of the activity. This operation defines the interface of a proxy that is used by
the activity to interact with the actual realization of the business function represented by the
activity. The actual realization is defied by another WSDL operation that is dual to the proxy
(e.g., notify is dual to one-way). The association of a proxy and the proper realization is
defined using plug links.
Page 64
ebXML BPSS (ebXML Business Process Specification Schema)
ebXML Business Process Specification Schema (eBPSS) provides a metamodel to specify a
collaboration between business partners. In eBPSS, a specification is referred to as an ebXML
Business Process Specification (BPS). A BPS specifies a collaboration between business partners,
and it is the input (and the reference schema) for the design of CPP's and CPA's among them (see
Section 2.2.3.3).
The aim of the overall ebXML framework is both to describe interoperable business processes that
allow business partners to collaborate, and to turn business process models into software
components that collaborate on behalf of the business( partners. ebBPSS provides a standard
framework for business process specification; as such, it works with CPP and CPA speci_cations to
bridge the gap between business process modeling and the configuration of ebXML-compliant
software (e.g., an ebXML Business Service Interface). A BPS contains the specification of business
transactions and the choreography of business transactions into collaborations; it is then the input to
the formation of CPP's and CPA's, which in turn serve as configuration files for ebXML Business
Service Interface software.
The ebBPSS is available in two stand-alone representations, a UML version, and an XML version:
(i) the UML version is merely a UML Class Diagram, whereas (ii) the XML version provides the
specification for XML-based BPS's, and as a target for production rules from other representations;
both a DTD and a W3C Schema are provided. The UML- and XML-based versions of ebBPSS are
unambiguously mapped to each other.
In the ebXML BPSS many (sub)meta-models are defined, e.g., for document exchanges,
transactions, etc. As regards the orchestration (sub)meta-model (shown in Figure 2.26), it is
equivalent to UML Activity Diagrams: it is an ordering and sequencing of BusinessActivity
elements within a BinaryCollaboration element. The orchestration is specified in terms of
BusinessState elements, and Transition elements between them. A BusinessActivity
element
is
an
abstract
kind
of
BusinessState.
Its
two
subtypes
BusinessTransactionActivity and CollaborationActivity are concrete. The
purpose of an orchestration is to order and sequence BusinessTransactionActivity and/or
CollaborationActivity elements. There are a number of auxiliary types that facilitate the
orchestration; these include Start, CompletionState (which comes in a Success and
Failure avor), Fork and Join. Transitions can be gated by conditionGuard elements.
Page 65
<<enumerat ion>>
Status
Success
BusinessFailure
TechnicalFailure
AnyFailure
Business Partner Role
name : String
1
Binary Collaboration
n
name : String
patt ern : String
t imeToPerform : Time
preCondit ion : String
1 postCondit ion : String
beginsWhen : String
endsWhen : String
Transition
n
onInitiation : Boolean
conditionGuard : Status
conditionExpression : Expression
n
+entering
+exiting
n
+collaboration
1
out
+to
in
1 +from
1
+uses
1
n +states
Business State
Start
Completion State
Success
Join
Fork
name
:
String
name : String
waitForAll : Boolean
Failure
Business Activity
name : String
Business Transaction Activity
timeToPerfom : Time
isConcurrent : Boolean
isLegallyBinding : Boolean
+usedBy n
Collaboration Activity
Figure 2.26: ebXML BPSS: details concerning orchestration
2.3 Security
2.3.1 Introduction
The EU-PUBLI.COM project aims at implementing the Unitary European Network, that is a “secure
Intranet” interconnecting the ISs of public administrations across several European countries. In the
EU-PUBLI.COM approach, thus, security is a crucial issue.
In the UEN architecture, standard TCP/IP protocols have been recognized as the protocols providing
transport service, TCP/IP actually provide feat flexibility and are at the basis of several Internet and
intranet protocols. However the fact that TCP/IP allows information to pass through intermediate
computers makes it possible for a third party to interfere (attack) with communications in the
following ways:
Page 66
•
•
•
Eavesdropping. Information remains intact, but its privacy is compromised.
Tampering. Information in transit is changed or replaced and then sent on to the recipient.
Impersonation. Information passes to a person who poses as the intended recipient.
Impersonation can take two forms:
o Spoofing. A person can pretend to be someone else.
o Misrepresentation. A person or organization can misrepresent itself.
Normally, users of the many cooperating computers that make up the Internet or other networks
don't monitor or interfere with the network traffic that continuously passes through their machines.
However, many sensitive personal and business communications over the Internet, such as the one
relative to public administrations’ ISs, require precautions that address the threats listed above. In
literature these precautions are referred as security services.
More specifically security services replicate in electronic documents the type of functions normally
associated with physical documents, the most relevant are:
• Confidentiality. It protects information stored in a system or transmitted over a computer
network from eavesdropping providing their read-only accesses exclusively to authorized
parties. Accesses include several forms of disclosure including simple revealing the
existence of an information exchange.
• Integrity. It protects information from tampering ensuring that only authorized parties are
able to modify in transit or transmitted information.
• Authentication. It protects information exchange from spoofing ensuring that the sender or
the receiver is who he claims to be.
• Nonrepudiation. It protects information exchange from misrepresentation ensuring that
neither the sender nor the receiver can deny their transmission.
• Access control. It ensures that access rights rule the access to information resources.
A security service thus enhances the security of data processing systems and the information
transfers of an organization. However this is a general approach and to frame all the matters
involved in network security in a systematic way two different security models of protection must be
introduced.
2.3.1.1 Network Security Model
The network security model considers data exchange between two parties, the principals, through an
unsecure network. Abstracting from their physical nature (individual, Web server, etc) this model
focalises on the procedures necessary to protect the information exchange; these procedures are all
characterized by the use of a security mechanism coherent with the protection required and the use
of some secret information shared by the two principals and unknown to possible opponents (Figure
2.27)
Page 67
trusted third
part
principal
principal
message
(information)
message
(information)
channel
secret
information
secret
information
security
transformation
security
transformation
opponent
Figure 2.27: Network security model
The network security model, however, does not take into account another important security aspect,
that is how to protect an information system logically closed to undesired accesses. For this reason
in the access security model (Figure 2.28) a gatekeeper is placed between the protected system and
the private network access point; its function is to allow access to the only authorizes principals (and
their messages) and to reject third parties’ messages and attacks.
Information System
opponent
−
channel
−
−
−
Computing resources (processors,
memory, I/O)
Data
Processes
Software
gatekeeper
internal security controls
Figure 2.28: Access security model
These two models are orthogonal, that is independently applicable one from the other. as an example
if the two principals are two different closed information systems, they can defend themselves from
external intrusion through the access security model and protect their communication through to the
network security model. Besides, in a closed information system, each time two principals exchange
information, they can need to adopt the network security model, or, more presumably, they can
communicate with no particular precautions, because reasonably they cannot endure attacks (except
those coming from inner principal).
In both the security model, some or all the security services are arranged to provide the level of
security required.
Page 68
Security services are physically provided by technological security mechanisms. Nevertheless no
mechanism can currently offer all the security services and face all the possible attacks at once, for
this reason securing a system requires an engineering approach that, using the right mix of
mechanisms, obtains the wished level of security. Thus, securing a system does not mean only
employ specific countermeasures (of technological and organizational nature) to neutralize all the
hypothetical attacks for that system; it means also to place each countermeasure in an organic
security policy that takes into account constraint (technical, logistic, administrative, lawyers and
politic) imposed from the structure in which the system operates, and that justifies each
countermeasure in a global outline.
The basic building block of the network security mechanisms are cryptography, digital signature and
certificate.
2.3.1.2 Cryptography
Cryptographic algorithms are mathematical algorithms that transform (encrypt) original intelligible
information, plaintext, in random data, ciphertext, not intelligible to anyone but the intended
recipient. With most modern cryptography, the ability to keep encrypted information secret is based
not on the cryptographic algorithm, which is widely known, but on a number called a key that must
be used with the algorithm to produce an encrypted result or to decrypt previously encrypted
information. Decryption with the correct key is simple. Decryption without the correct key is very
difficult, and in some cases impossible for all practical purposes. Moreover the same cryptographic
algorithm can work with keys of different length. The length of a used key is always the result of a
compromise between the security requirement and the power of calculation demanded from theirs
use; in fact, the longer is the used key the stronger is the protection provided - in term of difficulty to
guess plaintext from ciphertext - but the bigger is the computational effort required to transform
plaintext in ciphertext and vice versa.
In literature cryptographic algorithms are classified according to two functional type as we will see
below.
Symmetric encryption
With symmetric encryption, or secret-key encryption, the same key is used for both encryption and
decryption. Implementations of symmetric-key encryption (DES, 3DES, IDEA, BLOWFISH, RC5,
CAST-128) can be highly efficient, so that users do not experience any significant time delay as a
result of the encryption and decryption. Symmetric-key encryption provides confidentiality (Figure
2.29) and also a degree of authentication and integrity, since information encrypted with one
symmetric key cannot be decrypted and then modified with any other symmetric key. Symmetrickey encryption is thus effective only if the two parties involved keep the symmetric key secret,
moreover requiring the two parties to share the same key, suffer the problem of key distribution.
Figure 2.29: Symmetric key encryption
Page 69
Asymmetric encryption
Asymmetric encryption, or public-key encryption involves a pair of keys - a public key and a private
key - associated with an entity that needs to authenticate its identity electronically or to sign or
encrypt data. Each public key is published, and the corresponding private key is kept secret; partially
solving the secret-key algorithms’ key distribution problem. Data encrypted with a key can be
decrypted only with the paired key, so that in public-key algorithms confidentiality is reached
encrypting information with the recipient’s secret-key (Figure 2.30).
Compared with secret-key encryption, public-key encryption (RSA, Diffie-Hellman Key Exchange,
ECC) requires more computation and is therefore not always appropriate for large amounts of data.
Thus public-key encryption is commonly used in exchanging a symmetric key, which can then be
used to encrypt additional data providing confidentiality or combined with hash coding algorithms
to provide authentication and integrity.
Figure 2.30: Asymmetric key encryption
2.3.1.3 Digital Signature
Digital signature is a security technique, which combining public-key cryptography and hash coding
algorithms provides information integrity.
Hash coding algorithms relies on a mathematical function called one-way hash function. These
functions produce as results message digest, which are strings of fixed length with the following
characteristics: (i) the value of a message digest is unique for the hashed data, any change in the
data, even deleting or altering a single character, results in a different value; (ii) the content of the
hashed data cannot, for all practical purposes, be deduced from the message digest. Operationally
one-way hash functions concur to verify message integrity through the comparison of the message
digest calculated by the sender with the one calculated by the receiver; message digest have short
and fixed length, turning out more manageable to handle than the original messages, moreover the
digest can be rendered public without revealing the content of the document. Hash algorithms
widely used are MD5 and SHA-1, moreover particular hash algorithms work combining hash
function with secret-key. These algorithms receive as input, further than the message to be
compressed, a secret key so that the digest depends both from the message and the key. In this case
the digest is called Message Authentication Code (MAC).
A digital signature is thus calculated encrypting a message digest with the sender’s private key.
Figure 2.31 shown how it works.
Page 70
Figure 2.31: Digital signature schema
Two items are transferred to the recipient of some signed data: the original data and the digital
signature, which is basically a one-way hash (of the original data) that has been encrypted with the
signer's private key. To validate the integrity of the data, the receiving software first uses the signer's
public key to decrypt the hash. It then uses the same hashing algorithm that generated the original
hash to generate a new one-way hash of the same data. Finally, the receiving software compares the
new hash against the original hash. If the two hashes match, the data has not changed since it was
signed. If they don't match, the data may have been tampered with since it was signed, or the
signature may have been created with a private key that doesn't correspond to the public key
presented by the signer.If the two hashes match, the recipient can be certain that the public key used
to decrypt the digital signature corresponds to the private key used to create the digital signature.
Certificate
Basically, public key cryptography requires access to users' public keys. Confirming the identity of
the signer thus requires some way of confirming that the public key really belongs to a particular
person or other entity. In a large-scale networked environment it is impossible to guarantee that prior
relationships between communicating entities have been established or that a trusted repository
exists with all used public keys. Public key cryptography (and in particular RSA) imposed thus to
create an authentication infrastructure that effectively ties the public keys to the identity of the
principal who declares to be. Such infrastructure is referred as Public Key Infrastructure (PKI) and is
made of two fundamental elements:
• Certificate that is electronic documents used to identify a principal and to attest that the
principal is the effective owner of the public key to which the certificate is referred.
• Certification Authority (CA) which are entities trusted to sign (issue) certificates for other
entities. It is assumed that CAs will only create valid and reliable certificates as they are
bound by legal agreements. Security Protocols.
In large organizations, it may be appropriate to delegate the responsibility for issuing certificates to
several different certificate authorities. For example, the number of certificates required may be too
large for a single CA to maintain; different organizational units may have different policy
requirements; or it may be important for a CA to be physically located in the same geographic area
as the people to whom it is issuing certificates. Each certificate is coupled with a pair of keys
specifies the issuer certification authority so that to check the owner of a public key is sufficient to
contact the issuer authority.
Page 71
More details about certificate will be provided in the section about the certificate x509v3
2.3.2 Security Protocols
2.3.2.1 IPSec (Internet Protocol Security)
IPSec is a mechanism providing cryptographic security at IP layer. It offers the capabilities to secure
communications across a LAN, across private and public wide area network and across the Internet.
Using this mechanism it is possible to protect IP and all the protocols over IP (for example TCP,
UDP), so that all distributed applications, including remote logon, e-mail, file transfer, Web access
can be secured in term of confidentiality, integrity and authenticity.
IPSec operates inserting data structures, called AH and ESP, in the common IP packet to be
protected providing the security features required. Moreover it defines a mechanism, called
ISAKMP, to manage the logical connection to be protected.
IPSec supports two mode of use:
• Transport Mode provides protection for upper-layer protocols. In this case, in the IP packet,
the payload (comprising both data to transmit and AH or ESP) immediately follows the
original IP header and the packet is transported from a point to another of the network with
no modifications. In practice the security data structures are encapsulated in the original
packet.
• Tunnel Mode provides protection to the entire IP packet encapsulating it in a new packet.
The whole packet to be protected, consisting in the header and payload of the original IP and
the possible AH or ESP data structure, becomes the payload of a new IP packet. This new
packet can have completely different source and destination from those of the original
packet. This mode is used by a couple of gateway, located in the entry and exit point of an
unsecure network, which modify, encrypt, authenticate and encapsulate the traffic outcoming
towards the unsecure network and authenticates the traffic incoming from the unsecure
network.
IPSec defines two different data structures to provide the security features:
• Authentication Header (AH)
AH supplies integrity and authentication of IP packet but not confidentiality; this allows its
use even in network located in geographical areas where cryptographic protocols are
forbidden or ruled by local laws. It is based on the use of a message authentication code
(MAC) so it requires that a secret key be shared among principals. The AH has a variable
length and it is placed between the header and payload of the original IP packet. AH consists
of six different field (Figure 2.32) among which a security protocol identifier (SPI Security
Parameter Index), a field identifying the type of data contained in the payload (NH Next
Header) and the Authentication Data. This field holds a value, referred as the Integrity
Check Value (ICV), which is used to verify the packet integrity for means of algorithms
bases on MAC. The authentication provided by the ICV regards all the fixed fields of the
packet (all those fields that do not change along the packet routing), comprised those of the
same AH.
Page 72
Figure 2.32: Structure of the Authentication Header protocol
•
Encapsulating Security Payload (ESP)
ESP supplies integrity, authentication and confidentiality of IP packet. An ESP data
structure consists of a header, a payload and a trailer.
The header contains an identifier of the security protocol (Security Parameter Index SPI)
and a monotonically increasing counter value (Sequence Number SN): The payload, further
than the header (in tunnel mode) and the payload of the original IP packet, contains an
optional field (Initial Vector IV) required in specific encryption algorithms to synchronize
data. The trailer contains a Padding Field, to lengthen the entire packet to the right size, and
a variable Authentication Data field containing the ICV computed over the ESP packet
minus the Authentication Data field. Fields from the Payload Data to the Next Header are
encrypted by the ESP service.
Figure 2.33: Structure of the Encapsulating Security Payload protocol
ISAKM (Internet Security Association and Key Management Protocol) is an application level
protocol, coupled with IPSec, providing a framework for the key management and the specific
protocol support, including formats, to negotiate security attributes in IPSec connections (Security
Page 73
Association SA). The key management, based on a key exchange protocol, assumes principals
identified and authenticated through digital certificate or a secret key shared by the principals and
owned somehow.
ISAKM acts in two phases: In the first one the cryptographic and secure protocols employable are
defined; moreover a master key, from which the encryption and hash key are derived, is exchanged.
Besides, in the second phase the real communication is handled through the establishment of
common protocols (AH or ESP), one for each session, and the keys, one for each cryptographic
algorithm supported by the chosen protocol, to be used for a secure communication.
2.3.2.2 SSL/TSL (Secure Socket Layer / Transport Layer Security)
The Secure Sockets Layer (SSL), originally developed by Netscape, is a protocol, universally
accepted on the World Wide Web for authenticated and encrypted communication between clients
and servers. The SSL protocol runs above transport layer protocols (TCP/IP) and below application
level protocols such as HTTP or IMAP using TCP/IP on behalf of the higher-level protocols. It
provides authentication between principals, based on the public-key encryption, and confidentiality,
integrity and authenticity of their data traffic.
These capabilities address fundamental concerns about communication over the Internet and other
TCP/IP networks:
• SSL server authentication allows a user to confirm a server's identity. SSL-enabled client
software can use standard techniques of public-key cryptography to check that a server's
certificate and public ID are valid and have been issued by a certificate authority (CA) listed
in the client's list of trusted CAs.
• SSL client authentication allows a server to confirm a user's identity. Using the same
techniques as those used for server authentication, SSL-enabled server software can check
that a client's certificate and public ID are valid and have been issued by a certificate
authority (CA) listed in the server's list of trusted CAs.
• An encrypted SSL connection requires all information sent between a client and a server to
be encrypted by the sending software and decrypted by the receiving software, thus
providing a high degree of confidentiality. Confidentiality is important for both parties to any
private transaction. In addition, all data sent over an encrypted SSL connection is protected
with a mechanism for detecting tampering, that is, for automatically determining whether the
data has been altered in transit.
The SSL protocol includes two sub-protocols: the SSL Record Protocol and the SSL Handshake
Protocol. The SSL Record Protocol defines the format used to transmit data. The SSL Handshake
Protocol involves using the SSL Record Protocol to exchange a series of messages between an SSLenabled server and an SSL-enabled client when they first establish an SSL connection. This
exchange of messages is designed to facilitate the following actions: (1) authenticate the server to
the client; (2) allow the client and server to select the cryptographic algorithms, or ciphers, that they
both support; (3) optionally authenticate the client to the server; (4) use public-key encryption
techniques to generate shared secrets; (5) establish an encrypted SSL connection.
The Handshake Protocol is the most complex part of SSL. It allows the server and client to
authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys
to be used to protect data sent in an SSL record. The handshake protocol is used before any
application data is transmitted. The action of the Handshake Protocol are shown in Figure 2.34
Page 74
Client initiates a
connection
Hello
The server responds,
sending the client its
Digital ID. The server
may also request the
client’s Digital ID for
client authentication
Server Digital ID
The client verifies the
server’s digital ID. If
requested, the client
sends the Digital ID in
response to the server’s
request.
Client Digital ID
When authentication
is complete, the client
sends the server a
session key encrypted
using the server’s
public key
Send Session key
Once a session is established, secure communications
commence between the client and the server.
Figure 2.34: SSL handshake protocol
The SSL protocol supports the use of a variety of different cryptographic algorithms, for use in
operations such as authenticating the server and client to each other, transmitting certificates, and
establishing session keys. Clients and servers may support different cipher suites, or sets of ciphers,
depending on factors such as the version of SSL they support, company policies regarding
acceptable encryption strength, and government restrictions on export of SSL-enabled software.
Among its other functions, the SSL handshake protocol determines how the server and client
negotiate which cipher suites they will use to authenticate each other, to transmit certificates, and to
establish session keys. Cipher suites include DES and 3DES as secret-key algorithms, RSA as a
public-key algorithm and MD5 and SHA-1 as hashing algorithms.
Version 3 of the SSL protocol was designed with public review and input from industry and was
published as an Internet draft document. Subsequently when a consensus was reached to submit the
protocol for Internet standardization, the TSL working group was formed within IETF to develop a
common standard. The current work on TSL is aimed at producing an initial version as an Internet
Standard. This first version of TSL can be viewed as essentially an SSLv3.1 and is very close to and
backward compatible with SSLv3. For reason of brevity the small difference between SSL and TSL
protocols would not be shown.
SHTTP (Secure HTTP)
SHTTP is an extension to the HTTP protocol, developed by the Enterprise Integration Inc. (EIT), to
support sending data securely over the WWW. Whereas SSL is designed to establish a secure
connection between two computers, S-HTTP is designed to send individual messages securely.
Page 75
Secure-HTTP provides a wide variety of mechanisms to provide for confidentiality, authentication,
and integrity. It allows messages to be encapsulated in various ways. Encapsulations can include
encryption, signing, or MAC based authentication. This encapsulation can be recursive, and a
message can have several security transformations applied to it. SHTTP also includes header
definitions to provide key transfer, certificate transfer, and similar administrative functions. S HTTP
also offers the potential for substantial user involvement in, and oversight of, the authentication &
encryption activities. SHTTP does not rely on a particular key certification scheme. It includes
support for RSA, in-band, out-of-band and Kerberos key exchange. Key certifications can be
provided in a message, or obtained elsewhere. Like SSL, client public keys are not required.
The format of a Secure HTTP message consists of a request or a status line, followed by other
headers and some content that can be raw data, a SHTTP message or an HTTP message.
The request line, replacing the standard HTTP request line, and the correspondent response, are
defined as follow:
Secure * Secure-HTTP/1.1
Secure-HTTP/1.1 200 OK
These lines are defined to preclude an attacker from seeing the success or failure of a given request.
Secure HTTP takes a generally paranoid attitude to all information, leaking as little as possible.
The mandatory SHTTP headers are:
• Content-Privacy-Domain that contains a reference of the used cryptography mechanism;
• Content-Type that is a standard header, and should generally be application/http.
Other optional headers are:
• Content-Transfer-Encoding explaining how the content of the message is encoded;
• Prearranged-Key-Info containing information about the keys used in the encapsulation of this
message. Fields are for the type of cipher, a DEK (Data Exchange Key) used to encrypt this
message, and the identity of the key used to encrypt the DEK;
• MAC-Info containing a message authentication code to ensure that a message has not been
tampered with, without the expense of signatures.
To offer flexibility in the cryptographic enhancements used, client and server negotiate about what
enhancements each is willing to use, unwilling to use, or will require be used. Negotiations blocks
have four parts, property, value, direction (always with respect to the negotiator), and strength (of
preference). If principals are unable to discover a common set of algorithms, appropriate actions
should be taken. Continuing to request a refused option is considered ineffectual and inappropriate.
Negotiating options can be included in the header of Request/Response HTTP messages or in these
HTML instructions that link to web site requiring security mechanisms.
The available directions for a message are (recv||orig). The keywords recv and orig indicate receive
or originate, respectively. The strength of each preference can be (optional||required||refused).
Variable key length ciphers are referred to as cipher[length], or cipher[L1-L2], where length of key
is length, or in the case of L1-L2, is between L1 and L2, inclusive. Cipher without a length notation
shall indicate a willingness to accept any defined key length for a cipher.
Among others the headers in a negotiation can be:
• SHTTP-Privacy-Domains specifies which security mechanism is being used to encrypt
outcoming messages and which security mechanism is tolerated for incoming messages;
Page 76
• SHTTP-Certificate-Types is related to the SHTTP-Privacy-Domains and specifies which
certificate standard is considered valid;
• SHTTP-Key-Exchange-Algorithms specifies which can be Outband, Inband, RSA, or Krb-kv
(for Kerberos-version). Outband refers to any external, or prearranged key;
• SHTTP-Signature-Algorithms specifies which digital signature algorithms are supported;
• SHTTP-Message-Digest-Algorithms specifies the supported message digest algorithm;
• SHTTP-Privacy-Enhancements specifies the enhancement that can be carried out. These can
be any or all of 'sign,' 'encrypt,' or 'auth.' Auth differs from sign in that auth provides a keyed
hash of the message in a MAC, while sign provides a digital signature.
Secure HTTP defines defaults for all these values that may be negotiated upwards or downwards
and are PKCS-7 (Public-Key Cryptography Standards 7) to encode messages, to exchange keys, and
sign messages using RSA; MD5 as the message digest, and (single) DES, in various modes, as the
bulk cipher.
The format of the body of a message is indicated by the Content-Privacy-Domain SHTTP header
line. There are several acceptable Content-Privacy-Domains, which are PGP, and PKCS- 7. Under
PKCS-7, the most interesting option is a self signed signature certificate in a message body. This is
permitted, and no assertions are made to its reliability. This allows implementers a great deal of
flexibility. Other PKCS-7 options include encryption (with a public key, or some prearranged set).
Using a domain of PGP, the messages are encoded with 'straight' PGP.
2.3.2.3 PGP (Pretty Good Privacy) and S/MIME (Secure MIME)
There are two major protocols currently in use for securing electronic mail: PGP (Pretty Good
Privacy) and S/MIME (Secure/MIME).
S/MIME is a secure standard, developed by RSA Data Security Inc., adding confidentiality,
authentication and integrity to electronic mail exchanged. Based on the unsecure standard MIME, it
combines together secret-key encryption (DES or 3DES), public-key encryption (RSA), hashing
algorithms (SHA-1 or MD5) and certificates(X509v3).
PGP is an application designed by Phil Zimmerman providing confidentiality and authentication
service that can be used for electronic mail and also for file storage applications. The package
includes RSA, and Diffie-Hellman key exchange for public-key encryption, CAST-128, IDEA and
3DES for conventional encryption and SHA-1 for hash coding.
Though the protocols both use encryption and digital signature to achieve an e-mail message that is
verifiably authentic and intact, private, and non-reputable, their implementations are significantly
different.
S/MIME evolved from several older secure messaging technologies, including early versions of
PGP, and is intended to work within an Internet or enterprise-wide security infrastructure. PGP
instead has been available primarily in the form of freeware for most of its existence and is now a
product owned and distributed by Network Associates, Inc. Moreover S/MIME integrates with
Public Key Infrastructure (PKI) technology while the OpenPGP architecture is more focused on user
self-administration and control.
Page 77
Due to its enterprise focus, S/MIME has been able to garner a significant amount of industry
support. It is recognized as the protocol of choice to bring secure messaging to the business world
and is positioned to become the de facto standard for securing email. Besides PGP will become
increasingly less relevant as encryption moves from academia and small pilots to interorganizational security and its use will be limited to personal use.
The key distinguishing factor of these competing protocols is not the algorithm used to encrypt, as
rather the technology used to establish trust. In cryptographic terms, trust is the belief that the e-mail
address and public encryption key combination that is being used can be trusted to secure messages
to the intended recipient. OpenPGP defines trust through a ‘web of trust’ that places the burden of
trust on the end user. The web of trust is a transitive relationship based on individual experience and
decisions. For example, if A trusts B, and B trusts C, then A can decide whether he trusts C based on
B’s experience. The problem arises when this trust model maps to an organization rather than an
individual.
In a S/MIME implementation, a Certificate Authority (CA) can be used to establish trust. Every user
is issued a certificate that contains his public key and is signed by a CA. Because the CA establishes
a common point of reference, or trusted third party, trust is established automatically. By controlling
trust centrally, organizations are able to reduce the burden on the end users and improve the inherent
security of the system. Since there are a number of options available when choosing a CA, S/MIME
supports the concept of cross certifying or "cross-trusting" CAs. This provides the flexibility for
creating a secure messaging trust structure across organizations that have chosen different CAs
whether on-site or outsourced.
2.3.2.4 WS-Security (Web Services-Security)
WS-Security 1.0 is a specification from IBM, Microsoft and Verisign proposing a standard set of
SOAP extensions that can be used when building secure Web services. These extensions can be used
to provide confidentiality, authentication and integrity security services.
Specifically WS-Security provides support for multiple security tokens, multiple trust domains,
multiple signature formats, and multiple encryption technologies through the SOAP
<wsse:Security> header block.
WS-Security is flexible and is designed to be used as the basis for the construction of a wide variety
of security models including PKI, Kerberos, and SSL. Three main mechanisms are provided:
credentials exchange, message integrity, and message confidentiality.
Credential Exchange
WS-Security defines a simple mechanism for exchanging credentials between communicating
parties (can be client to service or service to client). Credentials can be anything that uniquely
asserts the identity of the credential owner. For example, X.509 certificates and Kerberos tickets are
both considered means of asserting identity. To account for the fact that credentials can be a variety
of things, WS-Security defines three different elements for three different credential types:
• Username Token can be used for sending a username and an optional password. In the
attributes is specified if the password is sent as plaintext or as ciphertext.
• Binary Security Token is a generic element to be used to communicate a binary security
token such as an X.509 or a Kerberos certificate. Because an XML document can’t contain
Page 78
arbitrary binary data, the contents of this binary security token need to be encoded and the
type of encoding as well the type of security token encoded are specified in the attributes.
• Security Token Reference is used when the sender, instead of sending security token, ask the
recipient to go pull that token from a specific location to embed the URI Reference of the
location in the SOAP message.
Message Integrity
The message integrity element of WS-Security has two objectives: (i) enabling a message recipient
to detect if a message was altered in transit; (ii) enabling a message recipient to verify that a
message was sent by a particular license owner, that is, the owner of a particular X.509 certificate or
Kerberos ticket. To achieve these two objectives, WS-Security relies on XML Signature to digitally
sign either the entire SOAP message or parts of it.
According to the XML Signature specification, the digital signature (along with other information)
must be contained in a SOAP message in an element called Signature, which has the same algorithm
requirements of those specified in XML Signature itself.
WS-Security also takes into account problem that could arise combining its use with other Web
service specification such as WS- Routing. According to WS-Routing, a client may send a message
to a Web service through other intermediary Web services. Along the way, the intermediate Web
services will modify certain routing SOAP headers contained in the message. WS-Security thus
points out that care should be taken when signing messages because some parts of the message
might be legitimately altered along the way to the ultimate recipient. For example, mutable WSRouting headers should not be included in the digitally signed component of the message.
Message Confidentiality
Digitally signing a message does not guarantee confidentiality: The message itself is still transmitted
in clear text and can be viewed by anyone along the way. To provide confidentiality, WS-Security
relies on XML Encryption to encrypt sensitive parts of the SOAP message. The power of XML
Encryption compared with, say, SSL is that you can encrypt portions of the message rather than the
entire message. You might for example encrypt on a credit card number and leave the rest of a
purchase order document in clear text. Depending on the size of the message and the size of the
encrypted parts, this might result in better performance compared to encrypting the entire message.
Another benefit to using XML Encryption is the fact that it operates at the SOAP message level
which means you can get end-to-end encryption even if your message has to travel through
intermediaries. WS-Security defines how XML Encryption can be used within the context of SOAP.
First, each element in the SOAP message (that is, each element that you want to encrypted) is
encrypted according to XML Encryption rules. The original element is then replaced with an
<xenc:EncryptedData> element and the contents of the original element is replaced by a
<xenc:CipherData> element which contains the encrypted information
WS-Security is thus a building block that can be used in conjunction with other Web service
extensions and higher-level application-specific protocols to accommodate a wide variety of security
models and encryption technologies. These mechanisms can be used independently (e.g., to pass a
security token) or in a tightly integrated manner (e.g., signing and encrypting a message and
providing a security token hierarchy associated with the keys used for signing and encryption).
Page 79
2.3.2.5 SAML (Security Assertion Markup Languange)
Security Assertions Markup Language (SAML) is a new standard, promoted by the OASIS working
group, which uses XML to encode authentication and authorization information. It provides a
framework for interoperability among Web services products.
SAML replaces two previous efforts independently developed by OASIS to create an authorization
and authentication protocol called S2ML and AuthXML. AuthXML is a specification for encoding
authentication and authorization information in transport-independent XML allowing security
authorities in separates organizations to communicate about security including authentication,
authorization, user profiles and authenticates user session. Similarly, S2ML is a standard for
enabling e-commerce transactions through XML allowing companies to exchange authentication,
authorization and profile information securely regardless of platform.
All these functionalities have been collapsed in SAML to address the need to have a unique industry
standard way of representing assertions of authentication and authorization for users and
interactions.
One of the main features of SAML 1.0 is the specification of SOAP-based interactions among
security and policy domains, supporting Web single sign-on (SSO), authentication and
authorization. The standard defines request and response "assertion" messages that security domains
exchange to witness for authentication decisions, authorization decisions, and attributes that pertain
to named users and resources. SAML 1.0 also defines functional entities such as authentication
authorities, attribute authorities, policy decision points and policy enforcement points.
In a SAML-enabled Web SSO scenario, users log on to their home or "source" domains through
authentication techniques such as ID/password. The source domain communicates this
authentication decision, plus other information that provides a security context for that decision, to
one or more affiliated or federated destination domains through messages that contain SAML
"authentication assertions" and "attribute assertions." In the most basic SAML 1.0 interoperability
scenario supporting Web SSO, the browser/artifact profile, a user interacts with SAML-enabled
Web sites in four steps as follows:
Step 1
• User's browser accesses source site (which functions as a SAML authentication
authority), usually via HTTP/Secure Sockets Layer (SSL).
• Source site challenges browser for user ID and password.
Step 2
• Browser responds to challenge by entering user ID and password.
• Source site authenticates browser through call to external authenticating server, such as a
Lightweight Directory Access Protocol directory.
Step 3
• Browser requests, via clicking on a universal resource indicator (URI) posted on source
site, a particular resource residing on destination server, thereby redirecting to the source
site's "intersite transfer service" URL.
Page 80
•
•
•
Source site holds session and produces a short-lived SAML authentication to assert that
an event has taken place (subject to conditions on the authentication assertion, along with
policies defined by the requested destination server and resource).
Source site holds assertion message locally in cache.
Source site returns to browser, via SSL, a URI that includes an appended SAML
"artifact" (an eight-byte Base64 string) that points to the authentication assertion and
redirects the browser to the requested destination site and resource.
Step 4
• Destination site uses the SAML artifact to query/retrieve the referenced authentication
assertion from the source site (usually over SSL sessions).
• Destination site holds session, parses/ verifies authentication assertion message (and
validates optional XML Signature on message, if this technique has been used), and
grants browser access to requested resources.
LDAP
Directory
1
2
3
4
PC
Authentication server
Figure 2.35: SAML scenario
2.3.3 Access Control
2.3.3.1 Firewall
A firewall is a mechanism to isolate a private network from other unsecure network, such as
Internet, blocking uncontrolled accesses. More specifically a firewall is a single device through
which all traffic from inside to outside and vice versa must pass. It defines a single choke point that
keeps unauthorized users out of the protected network, prohibits potential vulnerable services from
entering or leaving the network, and provides several kind of protection. The use of a single choke
point simplifies security management since security capabilities are consolidates on a single system
or set of systems. Three common type of firewalls are:
• router or packet-filtering
• application-level gateway or proxy-server
• circuit-level gateway
A router applies a set of rules to each incoming IP packet and then forwards or discards the packet.
The router is typically configured to filter packet in both directions (from and to the internal
network) (Figure 2.36). Filtering rules are based on fiels in the IP and transport header including
source and destination IP address and TCP or UDP port number. The packet filter is typically set up
as a list of rules based on matches to fields in the IP or TCP header. If there is a match to one of the
rules, that rules is invoked to determine whether to forward or discard the packet. If there is no
match to any rule, than a default action is taken. Two default policies are possible: (i) discart, that is
which is not expressly permitted is prohibited; (ii) forward, that is which is not expressly permitted
is permitted. The default discard policy is the more conservative, besides the default forward policy
increases ease of use for end users but provides reduced security.
Page 81
security perimeter
Private Network
Internet
Packetfiltering
router
Figure 2.36: Packet filtering router
A proxy-server or application level gateway acts as a relay of application-level traffic (Figure 2.37).
The user contacts the gateway using a TCP/IP application, such as Telnet or FTP, and the gateway
asks the user for the name of the remote host to be accessed. When the user responds and provides a
valid user ID and authentication information, the gateway contacts the application on the remote
host and relays TCP segments containing the application data between the two endpoints. If the
gateway does not implement the proxy code for a specific application, the service is not supported
and cannot be forwarded across the firewall. Further the gateway can be configured to support only
specific features of the application that the network administrator considers acceptable while
denying all other features. Application-level gateways tend to be more secure that packet filters.
Rather that trying to deal with the numerous possible combinations that are allowed and forbidden at
the TCP and IP level, the application-level gateway need only scrutinize a few allowable
applications. A prime disadvantage of this type of gateway is the additional processing overhead on
each connection. In effect there are two spliced connections between end users, with the gateway at
the splice point, and the gateway must examine and forward all traffic in both directions.
Outside
connection
Application-Level
Gateway
Inside
connection
TELNET
FTP
SMTP
HTTP
Outside Host
Inside Host
Figure 2.37: Application level gateway
A circuit-level gateway can be a stand-alone system or it can be a specialized function performed by
an application-level gateway for certain applications. A circuit-level gateway does not permit and
end-to-end TCP connection (Figure 2.38); rather, the gateway sets up two TCP connections, one
between itself and a TCP user or inner host and one between itself and a TCP user on an outside
host. Once the two connections are established, the gateway typically relays TCP segments from one
connection to the other without examining the contents. The security function consists of
determining which connections will be allowed. A typical use if circuit-level gateways is a situation
in which the system administrator trusts the internal users. The gateway can be configured to support
application-level or proxy service on inbound connections and circuit-level functions for outbound
connections. In the configuration, the gateway can incur the processing overhead of examining
incoming application data for forbidden functions but does not incur that overhead on outgoing data.
Page 82
Outside
connection
Circuit-Level
Gateway
out
in
out
in
out
in
Inside
connection
Outside Host
Inside Host
Figure 2.38: Circuit level gateway
A firewall can serve as the platform for IPSec and using its tunnel capability provided can be used to
implement virtual private network as described in the following section.
2.3.3.2 VPN (Virtual Private Network)
VPNs supply network connectivity over a possibly long physical distance. In this respect, VPNs are
a form of Wide Area Network (WAN). The key feature of a VPN, however, is its ability to use
public networks like the Internet rather than rely on private leased lines. VPN technologies
implement restricted-access networks that use the same cabling and routers as does a public
network, and they do so without sacrificing features or basic security.
VPNs support at least three different modes of use:
• Remote access client connections;
• LAN-to-LAN internetworking;
• Controlled access within an intranet;
Remote access client connections
A VPN can support the same intranet/extranet services as a traditional WAN, but VPNs have also
grown in popularity for their ability to support remote access service.
Figure 2.39 illustrates a VPN remote access solution. A remote node (client) wanting to log into the
company VPN calls into a local server connected to the public network. The VPN client establishes
a connection to the VPN server maintained at the company site. Once the connection has been
established, the remote client can communicate with the company network just as securely over the
public network as if it resided on the internal LAN itself.
Page 83
VPN Client
Local ISP
Public
network
internal LAN
VPN Server
Figure 2.39: Remote access client connections
LAN-to-LAN internetworking
A simple extension of the VPN remote access architecture shown in Figure 2.39 allows an entire
remote network (rather than just a single remote client) to join the local network. Rather than a
client-server connection, a server-server VPN connection joins two networks to form an extended
intranet or extranet.
Controlled access within an intranet
Intranets can also utilize VPN technology to implement controlled access to individual subnets on
the private network. In this mode, VPN clients connect to a VPN server that acts as a gateway to
computers behind it on the subnet. Note that this type of VPN use does not involve ISPs or public
network cabling. However, it does take advantage of the security features and convenience of VPN
technology.
VPN Protocols
VPN technology is based on a tunneling strategy. Tunneling involves encapsulating packets
constructed in a base protocol format within some other protocol. In the case of VPNs run over the
Internet, packets in one of several VPN protocol formats are encapsulated within IP packets.
Several interesting network protocols have been implemented for use with VPNs. These protocols
attempt to close some of the security holes inherent in VPNs. These protocols continue to compete
with each other for acceptance in the industry.
PPTP (Point-to-Point Tunneling Protocol)
PPTP is a protocol specification developed by several companies among which Microsoft. PPTP's
primary strength is its ability to support non-IP protocols. The primary drawback of PPTP is its
failure to choose a single standard for encryption and authentication. Two products that both fully
comply with the PPTP specification may be totally incompatible with each other if they encrypt data
differently, for example.
Page 84
L2TP (Layer Two Tunneling Protocol)
L2TP is a protocol working at the data link layer (layer two) in the OSI model .
Like PPTP, L2TP supports non-IP clients. It also fails to define an encryption standard. However,
L2TP supports non-Internet based VPNs including frame relay and ATM.
IPSec (Internet Protocol Security)
IPsec is actually a collection of multiple related protocols. It can be used as a complete VPN
protocol solution, or it can used simply as the encryption scheme within L2TP or PPTP. IPsec exists
at the network layer (layer three) in OSI.
IPsec extends standard IP for the purpose of supporting more secure Internet-based services
(including, but not limited to, VPNs).
SOCKS Network Security Protocol
The SOCKS system provides a unique alternative to other protocols for VPNs. SOCKS functions at
the session layer (layer five) in OSI, compared to all of the other VPN protocols that work at layer
two or three. This implementation offers advantages and disadvantages over the other protocol
choices. Functioning at this higher level, SOCKS allows administrators to limit VPN traffic to
certain applications. To use SOCKS, however, administrators must configure SOCKS proxy servers
within the client environments as well as SOCKS software on the clients themselves.
VPN Hardware and Software
Literally dozens of vendors offer VPN-related products. These products sometimes do not work with
each other because of the choice of incompatible protocols (as described above) or simply because
of lack of standardized testing.
Some VPN products are hardware devices. Most VPN devices are effectively routers that integrate
encryption functionality. Other types of VPN products are software packages. VPN software installs
on top of a host operating system and can require significant customization for the local
environment. Many vendor solutions comprise both server-side hardware and client-side software
designed for use with the hardware.
2.3.4 Authentication and Indentification
In the access security model the system must identify and authenticate the principal who is trying to
access. As we will see soon to realize these services: Certificate X509 v3, on which the public key
infrastructure is based, and Kerberos are two viable mechanisms.
If the principal is a human, he is usually identified by the system through its initial registered
username and other data proving its identity. A principal identity can be authenticated by the system
according to the following factors:
• what he knows: password
• what he has: smartcard
• what he is: biomedical data
2.3.4.1 Password
A password is a string to be supplied in order to show its knowledge. In general a password,
thought to be used by humans, should be sufficiently complex to be difficult guessable and
Page 85
sufficiently simple, at the same time, to be remembered from its user (This is the secret key used in
Kerberos ).
2.3.4.2 Smartcard
A smartcard is a plastic card, similar to a credit card, containing a microchip.
On its surface can be impressed a magnetic strip, a barcode and some information such as the name
and address of its owner and its due date. Its inner microchip communicates with the outside for
means of eight golden contacts through which it receives power, instructions and data. Its size is
established in the standard ISO 7816 which also specifies the plastic’s physical composition, the
contacts’ position and the communication protocols. Two types of smartcard exist: smartcards that
can only store data and intelligent smartcards whose chip is, at all the effects, a CPU and, further to
store and protect data, it can execute software programs (usually cryptographic algorithms).
In both cases the chip concur, differently from the magnetic supports, to protect the information
access through two security mechanisms:
• allowing the information access only to authorized users. In this case the card carry out an
operation of identification between the user and the system that must recognize him. The
identification is carried out in two phases: on one side the customer identifies itself with the
smartcard through its Personal Identification Number (PIN), formed by of 4 or 5 digit and
provided through an appropriate numerical keyboard, which is compared with its images
stored in the card; from the other the card is identified by the system;
• allowing the information access only in particular modalities: in read only mode, preventing
the cancellation of any data, allowing only data updates, not allowing any access to the data.
Among the data stored in a smartcard there can be the digital certificate of its owner; in this case the
user identifies itself within the workstation using the smartcard itself; once recognized and qualified,
the workstation, from which the user is operating, incarnates its role of principal and uses his
certificate in authentication and authorization operations for securing communications towards
remote systems.
2.3.4.3 Biomedical Data
Recognition mechanisms using biomedical data require the employment of complex hardware
devices in order to recognize a principal from its voice, its digital fingerprint, or the pattern of
colours of its eyes.
2.3.4.4 Certificate X509 v3
The contents of certificates widely accepted by many software companies are organized according
to the X.509 v3 certificate specification, which has been recommended by the International
Telecommunications Union (ITU), an international standards body, since 1988.
Every X.509 certificate consists of two sections:
• The data section includes the following information:
o the version number of the X.509 standard supported by the certificate;
Page 86
o the certificate's serial number. Every certificate issued by a CA has a serial number
that is unique among the certificates issued by that CA;
o information about the user's public key, including the algorithm used and a
representation of the key itself;
o the DN of the CA that issued the certificate, i.e. a series of name-value pairs that
uniquely identifies an entity;
o the period express with date and time during which the certificate is valid;
o the DN of the certificate subject also called the subject name;
o optional certificate extensions, which may provide additional data used by the client
or server;
• The signature section includes the following information:
o the cryptographic algorithm, or cipher, used by the issuing CA to create its own
digital signature;
o the CA's digital signature, obtained by hashing all of the data in the certificate
together and encrypting it with the CA's private key.
As seen in the introduction a CA is an entity that validates identities and issue certificates. A CA can
be either an independent third party or an organization running its own certificate-issuing server
software. A list of third-party certificate authorities is available at Certificate Authority Services.
Any client or server software that supports certificates maintains a collection of trusted CA
certificates. These CA certificates determine which other certificates the software can validate--in
other words, which issuers of certificates the software can trust. In the simplest case, the software
can validate only certificates issued by one of the CAs for which it has a certificate. It's also possible
for a trusted CA certificate to be part of a chain of CA certificates, each issued by the CA above it in
a certificate hierarchy. Actually, in large organizations, it may be appropriate to delegate the
responsibility for issuing certificates to several different certificate authorities. For example, the
number of certificates required may be too large for a single CA to maintain; different
organizational units may have different policy requirements; or it may be important for a CA to be
physically located in the same geographic area as the people to whom it is issuing certificates. A
model for setting up a hierarchy of CAs is included in the standard X509v3.
(a) Certification Authorities hierarchy
(b) Certificate chain
Figure 2.40: Certification Authorities structure
Page 87
In this model, the root CA is at the top of the hierarchy. The root CA's certificate is a self-signed
certificate: that is, the certificate is digitally signed by the same entity--the root CA--that the
certificate identifies. The CAs that are directly subordinate to the root CA have CA certificates
signed by the root CA. CAs under the subordinate CAs in the hierarchy have their CA certificates
signed by the higher-level subordinate CAs. Moreover, CA hierarchies are reflected in certificate
chains. A certificate chain is series of certificates issued by successive CAs. Figure 2.40 (b) shows a
certificate chain leading from a certificate that identifies some entity through two subordinate CA
certificates to the CA certificate for the root CA (based on the CA hierarchy shown in Figure 2.40
(a)).
A certificate chain traces a path of certificates from a branch in the hierarchy to the root of the
hierarchy. In a certificate chain, the following occur:
• ech certificate is followed by the certificate of its issuer;
• ech certificate contains the name (DN) of that certificate's issuer, which is the same as the
subject name of the next certificate in the chain;
• each certificate is signed with the private key of its issuer. The signature can be verified with
the public key in the issuer's certificate, which is the next certificate in the chain.
Certificate chain verification is then possible walking back the certificate chain trace from the leaf to
the root. Expired validity dates, an invalid signature, or the absence of a certificate for the issuing
CA at any point in the certificate chain causes authentication to fail.
Interactions between entities identified by certificates and CAs are then an essential part of
certificate management These interactions include operations such as registration for certification,
certificate retrieval, certificate renewal and certificate revocation. In general, a CA must be able to
authenticate the identities of entities before responding to the requests. In addition, some requests
need to be approved by authorized administrators before being services; an example it is revoking a
certificate before it has expired. Certificates, as any other licence, might be revoked before its due
date. To avoid improper use of faked or revoked certificates, each CA have to provide, further than a
directory containing all the not expired certificate ever issued, a Certificate Revocation List (CRL),
i.e. an additional directory where all the revoked certificate are maintained. Consulting these CRL
directory becomes and intermediate step in the authentication process. The directories are accessible
through protocols that are LDAP compliant.
2.3.4.5 Kerberos
Kerberos is an authentication system based on private-key cryptography. It is designed to provide
authentication of user identity in a networked computing environment consisting of workstations
(used directly by one or more users) and servers (providing services such as email and shared file
systems).
A basic assumption is that network traffic is highly susceptible to interception and is the weak link
in system security, rather than direct access to servers, which can be protected by physical means.
The more often a specific cryptographic key is reused, the more susceptible it becomes to decoding.
For this reason, each session of interactions between a user and a specific service should be
encrypted using a short-lived "session key". To make the system usable in practice, however, it must
be convenient, and to the greatest extent possible, transparent to the user.
Starting with those assumptions, the system's key goals are:
1. never transmit unencrypted passwords over the network;
Page 88
2. do not require the user to repeatedly enter a password to access routine services.
An essential conflict exists between the need to communicate the encryption key, and the need to
keep the key secret. There is also a trade-off between using a unique key for every message and reusing a single key for an extended session of interactions (this trade-off potentially impacts both
efficiency and convenience, vs. the level of protection provided).
The Kerberos system's approach involves several layers of messages. Although these multiple layers
may seem overly elaborate at first glance, they represent a reasonable attempt to address the design
trade-offs.
The following is a simplified description of the Kerberos message scheme (illustrated in Figure
2.41). In this discussion, the term "client" refers to a user or to a client-side application program
operating on behalf of a user. As noted above, the term "application" server refers to a remote
computer which provides a shared service. The term "password" refers to the user's password or to a
cryptographic key derived from it (since the process of deriving the key from the password is
transparent to the user). The term "session" key refers to a cryptographic key issued for use in
communication between a client and an application server, which is valid for some defined interval
of time.
Two basic elements are used in Kerberos messages: a ticket and an authenticator. A ticket is
acquired by a client from the authentication server, and sent to the application server as part of the
request for a service. An authenticator is constructed by the client, is sent to the application server
along with the ticket, and is used by the application server to verify that the request was sent by the
client to whom the ticket was issued. As noted above, the goals of the system include:
1. avoiding repeated re-entry of passwords;
2. sending unencrypted passwords over the network
To address these goals, the initial exchange with the Kerberos authentication server issues the user a
"ticket-granting ticket" (TGT) containing a session key to be used for subsequent ticket requests.
Each TGT is good for a fixed life span, typically set to 8 hours. The TGT effectively serves as a
proxy for the user with the Ticket Granting Service over the life of the TGT. This prevents the user
from having to authenticate themselves every time they wish to access a service on the network.
The initial message from the client to the Authentication Server (AS) is typically sent automatically
at the time of login. The initial message contains the user's name (but not password) and request for
a ticket granting ticket (TGT). AS replies with a message encrypted with the user's password and
containing a TGT. ecause the TGT message is encrypted with the user's password, it is protected if
intercepted. When received by the client, the TGT message can be decoded to obtain the session key
to be used for subsequent ticket requests.
Once the client has a TG key, the subsequent requests for a specific service will take the form shown
in Figure 2.41.
The client sends a request to the Ticket Granting Service (TGS) to obtain a ticket for the service.
The Ticket Granting Service can compare the client identification information embedded in the
message with its record of issuing the TG key. The timestamp helps to protect against any attempt to
re-use an intercepted message; typically, a request will be considered invalid if received more than 5
Page 89
minutes after the embedded timestamp. This prevents messages from being intercepted, cracked
offline, and then used at a later time. After confirming the client's identity, the Ticket Granting
Service responds with a message containing a new session key. The ticket itself contains
information identifying the client and the newly generated session key. Note that the client cannot
decode or alter the ticket, only forward it to the application server.
The client then sends a message to the application server containing the ticket and an authenticator
(Figure 2.41).
2. AS verifies user's access right in
database, creates ticket-granting
ticket and session key. Results are
encrypted using key derived from
user's password.
Once per
user logon
session
1. User logs on to
workstation and
requests service on host.
Kerberos
e tt ic k
u e s t t ic k e t
q
e
g
R
nt in
g ra
key
io n
s e ss
+
et
tic k
Authentication
Server (AS)
r v ic e
est se ket
Req u
ic
t
ing
g r a nt
k ey
s s io n
t + se
e
k
c
i
T
Workstation prompts user
for password and uses
password to decrypt
incoming messages, then
sends ticket and
authenticator that contains
user's name, network
address, and time to TGS.
3.
5. Workstation sends
ticket and authenticator to
server.
Re
Once per ty pe
of service
qu
es
ts
Pr
a u o v id
th e
en ser
t ic v e
at r
or
er
vi
Ticket-Granting
Server (TGS)
4. TGS decrypts ticket and
authenticator, verifies
request, then creates ticket
for requested server.
ce
Once per
service session
6. Server verifies that
ticket and authenticator
match, then grants access
to service. If mutual
authentication is required,
server returns an
authenticator.
Figure 2.41: Kerberos message exchange
As noted above, the authenticator is constructed by the client, and contains identifying information
and a timestamp. When this message is received by the application server, it can decode the ticket,
because it is encrypted with the server's own key (known only to itself and the authentication
server). The ticket contains the session key which is used to decode the authenticator. For the
request to be considered valid, the data embedded in the authenticator must match that in the ticket.
Subsequent messages between the client and the application server may be encrypted using the
session key.
In a system that crosses organizational boundaries, it is not appropriate for all users to be registered
with a single authentication server. Instead, multiple authentication servers will exist, each
responsible for a subset of the users or servers in the system. The subset of the users and servers
registered with a particular authentication server is called a realm (if a realm is replicated, users will
Page 90
be registered with more than one authentication server). Cross-realm authentication allows a
principal to prove its identity to a server registered in a different realm.
In Figure 2.42 it is shown that a user have to follow to request services from a server in.
Realm A
Kerberos
ca l TGS
et fo r lo
est tick
1. Req u
al TGS
t for loc
2. Ticke
Authentication
Server (AS)
3. Request ticket for remote TGS
4. Ticket for remote TGS
Ticket-Granting
Server (TGS)
5.
Re
qu
e st
7. Request remote service
tic
6.
or
et
tf
ck
ke
Ti
Kerberos
re
for
te
te
ser
mo
mo
re
ve
se r
r
ve
r
Authentication
Server (AS)
Ticket-Granting
Server (TGS)
Realm B
Figure 2.42: Request for service in another realm
2.4 High Availability and Fault Tolerance
A distributed application is fault-tolerant if it can be properly executed despite the occurrence of
faults. Many different classes of distributed applications may require fault-tolerance, such as air
traffic control systems, e-commerce applications, WEB services, telecommunication systems, etc.
However, such applications can need different levels of reliability, availability and replicated data
consistency. For example, stateless services like replicated web servers, need, at client side, simple
failover mechanisms; stateful services, like telecommunication ones, require no downtime of the
service along with strong data consistency.
2.4.1 Replication Logic
Fault-tolerance can be obtained by software redundancy: a service can survive to a fault if it is
provided by a set of server replicas. If some replicas fail, the others can continue to offer the service.
At this end, servers can be replicated according to one of the following replication techniques: active
replication or passive replication (primary-backup approach).
Page 91
In active replication a client sends a service request to a set of deterministic replicas, and waits for a
certain number of identical replies. This number depends on the type of faults a replica can exhibit
and on the consistency criterion we want to ensure on replicated data, i.e., the desired level of
availability, consistency and reliability of the service. As an example, a stateless service (no data
consistency is required) needs only a failover mechanism. Hence, the client can return the result
when receiving the first reply. If replicated data consistency is required, at least the majority of
replicas has to be aware of the request done by the client. If replicas can exhibit an arbitrary
behaviour, the number of replicas that should be aware of the request goes to two-thirds.
In passive replication, a client sends a request only to a particular replica, namely the primary.
Replicas, different from the primary, are called backup replicas (backups). If the pri mary fails, the
backups elect a new primary. When the primary receives a request, (i) it performs the service, (ii)
multicasts a message to the backups to notify the occurrence of the service and the update of
replicated data and (iii) it sends back the reply to the client. If the service is stateless, step (ii) is not
required.
We want to remark that both active and passive replication require several mechanisms in order to
work properly: a reliable multicast protocol, a failure detection mechanism and an agreement
protocol.
The multicast and the agreement protocols can be combined to provide a total order multicast
primitive that can be used in active replication to have a consistent evolution of the deterministic
replicas.
The failure detection mechanism and the agreement protocol can be used, in passive replication, to
detect when a primary fails and for the election of a new one. Moreover, in both replication
schemes, the usage of all these mechanisms can provide the nice notion of group abstraction with
the relative services such as group abstraction, membership, state transfer, etc.
From an operational point of view, these mechanisms and protocols can be implemented by group
toolkits, such as Isis, Ensemble/Maestro, Totem, etc.
A replication logic is the set of protocols, mechanisms and services that have to be used in order to
implement a replication technique, i.e., to offer fault-tolerance of a specific entity.
A significant body of work exists in the area of fault-tolerant distributed object systems. These
include systems that are not based on CORBA, such as Arjuna, FRIENDS, and COMERA (for
Microsoft’s DCOM model). However more different approaches have been developed for providing
reliability specifically for applications based on CORBA standard. These approaches differ in a
number of aspects, such as the degree of transparency on the CORBA application, the degree of
modification to the CORBA ORB, the specific mechanisms for achieving replica consistency, and
the level of replica consistency provided.
2.4.2 Non-CORBA Fault Tolerant Systems
2.4.2.1 Arjuna
Arjuna is an object-oriented programming system, implemented in C++, that provides a set of tools
for the construction of fault-tolerant distributed applications. Arjuna supports the computational
model of nested atomic actions (nested atomic transactions) controlling operations on persistent
Page 92
(long-lived) objects. Arjuna objects can be replicated on distinct nodes in order to obtain high
availability.
In Arjuna, the first goal has been met by dividing the overall system functionality into a number of
modules which interact with each other through well defined narrow interfaces. This facilitates the
task of implementing the architecture on a variety of systems with differing support for distributed
computing.
The main modules of Arjuna and the services they provide for supporting persistent objects are:
1. Atomic Action module. Provides atomic action support to application programs in the form
ofoperations for starting, committing and aborting atomic actions;
2. RPC module. Provides facilities to clients for connecting (disconnecting) to object servers
and invoking operations on objects;
3. Naming and Binding module. Provides a mapping from user-given names of objects to
unique, system given identifier (UID), and a mapping from UIDs to location information
such as the identity of the host where the server for the object can be made available;
4. Object Store module. Provides a stable storage repository for objects; these objects are
assigned unique identifiers (UIDs) for naming them.
The relationship amongst these modules is depicted in Figure 2.43. Every node in the system will
provide the RPC and Atomic Action modules. Any node capable of providing stable object storage
will in addition contain an Object Store module. Nodes without stable storage may access these
services via their local RPC module. The Naming and Binding module is not necessary on every
node since its services can also be utilised through the services provided by the RPC module.
Application
Naming,
Binding
Application
Application
Object and Action Module
Object Store
RPC
Operating System
Figure 2.43: Components of Arjuna
2.4.2.2 FRIENDS
The objective of the FRIENDS system was to provide to programmers a metalevel architecture for
implementing distributed fault tolerant applications.
The architecture of the system is composed of several layers:
Page 93
1. the kernel layer which can be either a Unix kernel or better a microkernel;
2. the system layer composed of several dedicated sub-systems;
3. the user layer dedicated to the implementation of applications and mechanisms as
metaobjects.
A simplified static view of the overall system architecture is given in Figure 2.44. The
implementation environment provided by FRIENDS corresponds to the whole set of sub-systems
and libraries of metaobject classes.
The implementation of any type of mechanism (fault tolerance, secure communication, distribution)
is thus spanning partially the user and system layers.
application sub-layer
metaobject sub-layer
application
dependent
sub-system
libft
libsc
libgd
FTS
SCS
GDS
microkernel
user
layer
system
layer
kernel
layer
Figure 2.44: Overall FRIENDS system architecture
The system layer is organised as a set of sub-systems.
In FRIENDS three sub-system provide services for fault tolerance, secure communication and
group-based distribution. Any sub-system may be hardware- and software-implemented:
1. FTS provides basic services mandatory for fault-tolerant metaobjects, in particular error
detection and failure suspectors which must be implemented as low level entities. Failure
detection and configuration management services in FTS are shared with the communication
sub-system. Another fundamental service, also located into FTS, is the replication domains
management service: it provides information describing static and dynamic information
related to the available nodes and provides facilities to allocate a node to anewly created
object.
2. SCS provides basic services that must obviously be implemented: these services should
include in particular an authentication server, but also an authorisation server, a directory
server, an audit server.
3. GDS provides basic services implementing a distribution support for object-oriented
applications where objects can be replicated.
The user layer is divided into two sub-layers, the application layer and the metaobject layer
controlling the behaviour of application objects. Some libraries of metaobject classes for the
implementation of fault-tolerant and secure distributed applications are implemented on top of the
corresponding sub-system and provide the user with mechanisms that can be adjusted, using objectoriented techniques.
Page 94
2.4.2.3 COMERA (COM Exensible Remoting Architecture)
COMERA is an extensible remoting architecture for COM. By componentizing the architecture into
COM objects, COMERA makes the low-level distributed objects infrastructure itself as dynamic,
flexible, and reusable as the applications that it supports.
The COMERA approach consists to first use COM custom marshaling to rebuild the standard
remoting architecture, and then redesign parts of it to enhance extensibility. Figure 2.45 shows the
overall COMERA architecture.
server object
client
extensible
up here
Interface
Proxy
NDR calls
COMERA
Object
proxy
NDR calls
Interface
Stub
COMERA
marshaler
create and init
custom channel
COMERA
stub manager
limited extensible
down here
COMERA
channel
COMERA
Endpoint
Figure 2.45: The COMERA architecture
Since the original interface proxies and stubs are packaged as binary COM objects, COMERA can
reuse them without requiring a new IDL compiler or any recompilation. COMERA improves upon
current COM remoting architecture in the following aspects:
• COMERA stub manager is a COM object and that offers two advantages. First, applications
can replace the stub manager with a custom one to control IPID assignment and call
dispatching. Second, COMERA marshaler interacts with the stub manager through a
specified COM interface, and so replacing stub manager does not require the marshaler to be
replaced as well.
• COMERA endpoint is also a COM object. It can be replaced to enable pre-dispatching
message processing such as message logging and decryption. Since it provides
communication endpoint information through a specified COM interface, a custom endpoint
object can work with a COMERA marshaler.
• COMERA extends the IMarshal interface to include one more method call
GetChannelClass() that allows a server object to specify the CLSID of a custom
channel. When COMERA object proxy receives the OBJREF (standard or custom), it creates
a channel object of the specified CLSID and initializes it with the OBJREF through a
specified COM interface.
• The CLSID (the COM identifiers of the RPC COM Object) of the COMERA RPC channel
object is specified so that any custom proxy can reuse this standard channel.
Page 95
2.4.3 CORBA Fault Tolerant Systems
Fault-tolerant CORBA systems can be classified acccording to the degree of “intrusiveness” of the
replication logic with respect to the standard ORB (Figure 2.46)2:
• Intrusive design: a system is intrusive if its design requires to embed a part (or all) of the
replication logic inside the ORB. Intrusive systems differ on how many components of the
replication logic are embedded into the ORB (“deep” vs. “shallow” intrusion).
• Non-intrusive design: a system is non-intrusive if its design decouples the replication logic
from the ORB. Non-intrusive systems differ on whether the replication logic is located
“above” the ORB (i.e., the replication logic exploits only ORB features) or not. In the latter
case we say that the replication logic is “below” the ORB3.
Client
Object
G
r
o
u
p
Object Object
Replica Replica
ORB
Replication Logic
intrusion level
Figure 2.46: Intrusive and non-intrusive design
Intrusive design has been followed by systems as Orbix+Isis and Electra (“deep” intrusion), and
AQuA (“shallow” intrusion).
Orbix+Isis has been the first commercial product offering fault-tolerance and high availability to
CORBA compliant applications. The Orbix ORB core has been modified in order to distinguish
between invocations to object groups and to standard objects. These invocations are handled by the
Isis group toolkit and by the Orbix ORB core respectively. Moreover, the modified ORB exploits
functionalities offered by the Isis group toolkit such as process group creation/deletion, reliable
multicast, ordering of events, fault monitoring, all embedded in a virtual synchrony model. A
CORBA object, in order to become member of a group, overrides some methods inherited from a
proprietary base class, and exposes these methods in its interface. These methods are invoked
directly from the modified ORB both to perform specific action (i.e., state transfer, fault monitoring)
and to notify events (i.e., view changes).
Electra differs from Orbix+Isis mainly for the possibility of integrating different group toolkits by
rewriting an adaptation layer. In both systems replication logic is embedded both into the ORB
(group abstraction) and into the group toolkit (multicast protocol, failure detection and agreement
protocol). This makes the intrusion “deep”.
AQuA achieves availability and reliability by replacing the ORB IIOP implementation with a
proprietary gateway. This gateway wraps IIOP calls made by the ORB to object groups into
invocations to Maestro/Ensemble group toolkit. In this case the replication logic is handled by the
2
A previous classification of fault-tolerant CORBA systems was proposed by Felber: this taxonomy classifies approaches into integration, interception and service, according to some
architectural issues and service specification aspects.
3
Note that a non-intrusive replication logic that uses even a single mechanism which is not provided by the ORB is considered “below” the ORB.
Page 96
gateway and by the group toolkit. As it is necessary only to rewrite the IIOP modules of the ORB,
AQuA is a “shallow” intrusion system.
Client
Object
G
r
o
u
p
Object Object
Replica Replica
ORB
Interception layer
Replication Logic
Figure 2.47: Replication logic “below” the ORB: the Eternal system
Non-intrusive design has been followed by systems as Eternal (replication logic “below” the ORB),
Object Group Service (OGS) and DOORS (replication logic “above” the ORB).
The rationale behind Eternal is to intercept all network system calls made to the OS and to
distinguish between non-IIOP and IIOP messages. IIOP messages are forwarded to a group toolkit
(e.g. Totem). In Eternal the replication logic is entirely managed by the group toolkit while the
interception of IIOP messages is done by a “thin” interception layer (Figure 2.47).
Contrarily to previous systems, OGS defines a Common Object Service (COS) with IDL interfaces
designed to invoke the functionalities of a group toolkit. It is a non-intrusive system whose
replication logic is “above” the ORB (Figure 2.48). OGS is designed as a modular set of services,
thus, a client can invoke the service it needs; OGS is not limited to handling fault tolerance: it can be
exploited for load balancing, multiversion object management, fault monitoring and control.
Client
Object
Object Object
Replica Replica
Replication Logic
G
r
o
u
p
ORB
Figure 2.48. Replication logic “above” the ORB: OGS and DOORS systems
DOORS is a COS offering failure detection and recovery mechanisms to fault-tolerant applications.
DOORS is implemented by two main components, namely the ReplicaManager and the WatchDog
(a distributed failure detector). The former component handles group definition, replica consistency
and uses the latter to detect failures and to determine when a recovery action on a set of replicas has
to start. IRL and FTS are also two approach of replication logic “above” the ORB.
Page 97
2.4.3.1 Interoperability limitations
With the term interoperability we mean the possibility of run-time interactions of application
objects deployed on top of distinct ORBs (this notion does not include the issue of the interaction of
different replication logics). This scenario is shown in Figure 2.49. In particular, we address the
following issue: the replication logic is able to manage application objects running on top of distinct
ORBs (possibly different from the one where the replication logic runs), or, conversely, the
replication logic and the application objects need to run on the same ORB platform. In the
following, we give an idea of the cost that fault-tolerant CORBA systems have to pay to get such an
interoperability. This cost takes into account the amount of modifications that application objects
and the ORBs need.
Getting interoperability depends on how the interactions among remote objects (i.e., among server
replicas, non-replicated objects and replication logic components) are implemented. A system is
interoperable only if it uses as communication mechanisms the standard remote method invocations
offered by the ORB via IIOP. As a consequence, non-intrusive fault-tolerant CORBA systems (e.g.
OGS, DOORS) developed “above” the ORB are interoperable without any modification (i.e., free
interoperability).
Client
Object
Object
Replica 1
ORB 1
ORB 2
Object
Replica 2
G
r
o
u
p
ORB 3
Fault Tolerant CORBA system
Figure 2.49. Interoperability in an heterogeneous multi ORB environment
Isis+Orbix and Electra (i.e., “deep” intrusive fault-tolerant CORBA systems) do not get
interoperability as it is necessary to provide the same ORB (e.g. Isis+Orbix) to all computing
resources.
AQuA (i.e., “shallow” intrusive fault-tolerant CORBA system) can be interoperable provided that
we develop one gateway for each distinct pair <OS, ORB> included in the heterogeneous
environment.
Eternal (i.e., non-intrusive “below” the ORB fault-tolerant CORBA system) requires to write a
interception layer for each distinct OS.
This comparison is shown in the first row of Table 2.1.
FT Corba Overview
FT-CORBA achieves fault tolerance through CORBA object redundancy, fault detection and
recovery. Replicas of a CORBA object are deployed on different hosts of a fault tolerance domains
(FT-domain). Replicas of an object are called members as they are collected into an object group,
which is a logical addressing facility allowing clients to transparently access the object group
Page 98
members as if they were a singleton, non-replicated, highly-available object. If the replicated object
is stateful then strong replica consistency has to be enforced among the states of the object group
members. The main FT-CORBA modifications and extensions to CORBA concerns object group
addressing, a new client failover semantic and new mechanisms and architectural components
devoted to replication management, fault management and recovery management.
Object Group Addressing. To identify and to address object groups, FT-CORBA introduces
Interoperable Object Group References (IOGRs). An IOGR is a CORBA Interoperable Object
Reference (IOR) composed by multiple profiles. Each profile points either (i) to an object group
member (e.g., in the cases of passive and stateless replication) or (ii) to a gateway orchestrating
accesses to the object group members (e.g., in the case of active replication). IOGRs are used by FTCORBA compliant client ORBs to access, in a transparent way, object groups.
Extensions to the CORBA Failover Semantic. To provide applications with failure and replication
transparency, FT-CORBA compliant client ORBs have to implement the transparent client
reinvocation and redirection mechanisms. These mechanisms consist of: (i) upon receiving an
outgoing request from a client application, a client ORB uniquely identifies the request by the
REQUEST service context and uses the IOGR to send the request to a single group member, (ii) a
client ORB receiving a failover exception (e.g. a CORBA TRANSIENT or NO RESPONSE
exception) exploits another (possibly different) IOGR profile to perform the request again until
either a result is received or all of the IOGR profile had returned a failover exception (in this case
the client ORB throws a NO RESPONSE exception to the client application).
Replication management includes the creation, and the modification of object groups and of object
group members. The ReplicationManager component is responsible for carrying out such activities.
In particular, when requested for object group creation, ReplicationManager exploits local factories
(implemented by application developers) to create members, collects the members’ references and
returns the object group reference. ReplicationManager allows to select a replication technique (e.g.,
stateless, active or passive) for a group and to choose if consistency among stateful group members
has to be maintained by the application or by the infrastructure.
Fault Management concerns the detection of object group members’ failures, the creation and the
notification of fault reports and the fault report analysis. These activities are carried out by the
FaultDetectors, FaultNotifier and by the FaultAnalyzer component respectively. A replicated object
can be monitored for failures by a FaultDetector if it implements the PullMonitorable interface.
FaultNotifier is based on the publish-and-subscribe paradigm. FaultNotifier receives object fault
reports from the FaultDetectors (publishers) and propagates these fault notifications to the
ReplicationManager and other clients (subscribers).
Recovery Management is based on two mechanisms, namely logging and recovery. Recoverable
objects implement two IDL interfaces (Checkpointable and Updateable) to let logging and
recovery mechanisms read and write their internal state. More specifically, the logging mechanism
periodically stores on a log information (e.g., member’s state/state update, received requests,
generated replies etc.) of recoverable objects while the recovery mechanism retrieves this
information from the log when, for example, setting the initial internal state of a new group member.
A FT-domain has to contain one logical instance of the ReplicationManager and one of the
FaultNotifier. FaultDetectors are spread over the domain to detect failures of monitorable object
Page 99
group members. The overall software infrastructure is commonly referred to as a fault tolerance
infrastructure(FT-infrastructure).
2.4.3.2 IRL (Interoperable Replication Logic)
IRL FT-infrastructure is the middle-tier of a three-tier architecture for software replication of
(stateless and stateful) CORBA objects. Figure 2.50 illustrates the main IRL FT-infrastructure
components, implemented as standard CORBA objects.
OGH
IRL Object Group Handler
IRL Replication Manager
IRL Fault Notifier
FN
RM
Client-tier
Mid-tier
End-tier
Partially
Synchronous
Asynchronous
OGH
OGH
Client Client
Client
Client
Intra-component
message bus
OGH
RM
RM
RM
Asynchronous
FN
FN
FN
Stateful
Object Group
Obj
Obj
Obj
Obj
Obj
Obj
Stateless
Object Group
Obj
Obj
Obj
Obj
Obj
Object Request Broker
Figure 2.50: IRL Architecture
To preserve infrastructure portability and interoperability communications among clients, middletier and object group members (i.e., end-tier server replicas) occur through standard CORBA
invocations. More specifically, clients of a stateful object group interact with the IRL OGH
component that master the interactions with object group members. In the case of stateless
replication, clients directly connects to a single member.
To get both the termination of client/server interactions and highly available management and
monitoring services, IRL components i.e., OGH, RM (ReplicationManager), and FN (FaultNotifier)
are replicated. These components implement stateful services. Consistency among the state of the
component replicas is maintained through common 2T replication techniques and tools. Therefore
replicas of each IRL component interact through an intra-component message bus (not necessarily
the ORB) that provides group communications based on the TCP/IP protocol stack.
2.4.3.3 FTS (Fault Tolerance Service)
The Fault-Tolerance Service is designed to provide fault-tolerance by active replication of server
objects. As in the FT-CORBA standard, it only handles server crashes and communication failures.
The FTS architecture is completely distributed and symmetric, guaranteeing no single point of
failure. Consistency is provided by using an underlying group communication subsystem. FTS
guarantees that as long as at least one server is alive, the objects it replicates will continue to exist.
Unlike the FT-CORBA standard, FTS can survive network partitions. To avoid “split brain”
behavior, FTS uses a quorum resource. This guarantees that updates only occur in one partition and
that isolated partitions remain alive until they can rejoin the other replicas.
Page 100
FTS also guarantees the survivability of a client's access to servers. In case of a failure, the client
automatically gets a reference to a live server and communication with the object resumes through
the newly obtained reference.
FTS can be implemented and used on top of any fully CORBA-compliant ORB without changing
any of the ORB vendor's supplied components4.
A Design Overview of FTS
Figure 2.51 presents a top-level view of the FTS infrastructure.
Figure 2.51: A top-level view of FTS
In FTS, every object belongs to a replication group. The objects in each replication group are
replicated on the same set of servers, and there can be multiple replication groups, each spanning a
possibly different set of servers. Moreover, a single application process can participate in multiple
replication groups. All replication management is performed at the replication group level,
encapsulated within a GOA implemented on top of a standard POA. The GOA hides from the
replicated object implementation all details associated with replication, with the exception of state
transfer and probing methods (which the object must implement). The GOA relies on a standard
server-side portable interceptor and a group communication subsystem. The latter is responsible for
detecting view changes—that is, servers failing, joining, or leaving the group. It is also used to
reliably multicast messages in total order, which helps the GOA maintain replica consistency
throughout view changes. The group communication subsystem is abstracted behind an
implementation-independent group communication interface.
Since FTS is designed mainly for active replication, each replica may directly communicate with
clients and execute requests. For scalability reasons clients obtain a handle to one of the replicas and
communicate with that replica only, using normal IIOP requests and replies. The GOA captures each
request and multicasts it in total order to all replicas who then execute it. If the replica with which
the client communicates fails, a standard client-side portable interceptor transparently catches the
4
FTS is based completely on CORBA's dynamic invocation mechanisms.
Page 101
exception. This interceptor is then responsible for obtaining a reference to a live replica and
initiating actions that will automatically forward the request to the new replica.
A communication failure during client-server interaction might cause a client to reissue a request
that has already executed, thus possibly violating at-most-once semantics. To avoid this, all replicas
cache the results of recent requests. When a request arrives from a client, the GOA first checks if it
is cached. If the reply is found in the cache, it is immediately returned to the client. Otherwise, it is
multicast to all replicas to be executed, and the result of the execution is returned.
A client request might cause its target object to issue further invocations to a secondary object.
However, if a secondary object is invoked multiple times by each replica of the primary target, atmost-once semantics might be violated. If the secondary object is also replicated by FTS, all replicas
will produce the same request identification, and thus the redundant requests will be recognized as
duplicates, and suppressed. In this case correctness will be preserved, but redundant messages will
be generated.
2.4.3.4 Discussion
Let us start this discussion by comparing IRL with other fault-tolerant CORBA systems according to
three architectural issues, i.e., interoperability, replication logic implementation and replication
logic visibility. This comparison is summarized in Table 2.1.
• Interoperability. IRL gets interoperability, such as OGS and DOORS, without any
modification to its design, as it is based on a non-intrusive approach “above” the ORB;
• Replication logic implementation. Intrusive systems and Eternal rely on a specialized,
proprietary group toolkit. Conversely, OGS offers a completely distributed replication logic
implemented “above” the ORB. IRL centralizes the replication logic in its Core, providing
dependability by passive replication;
• Replication logic visibility, i.e., what a distributed application “sees” of the services provided
by the replication logic. A system is “black box” if its replication logic offers to applications
only property management interfaces (i.e., the mechanisms implementing fault-tolerance are
not accessible from outside); a system is “white box” if its replication logic is composed by a
set of services offered to applications. IRL, Eternal and intrusive systems offer “black box”
replication logics. OGS, instead, is a “white box” replication logic system: it offers interfaces
to use a set of services. Note that the black box approach is the one adopted by FT CORBA
specification.
Intrusive
Non-intrusive
“deep”
“shallow”
“below” the ORB
“above” the ORB
(Isis+Orbix, Electra)
(AQuA)
(Eternal)
(OGS)
(IRL / FTS)
Interoperability
Impossible
Very Expensive
Expensive
Free
Free
Replication Logic
Implementation
Group Toolkit
Group Toolkit
Group Toolkit
Distributed
Distributed5
Replication Logic
Visibility
Black box
Black box
Black box
White box
(fine grained services)
Black box
Table 2.1: Comparison among fault tolerant CORBA systems
5
Let us finally consider a more close comparison with OGS, which is historically the first non-intrusive system from which IRL has inherited some design ideas.
Page 102
2.5 References
2.5.1 Basic Protocols
J.Kurose, K.Ross, Computer Networking: A Top-Down Approach Featuring the Internet by Addison
Wesley (1999)
RFC 793,
Transmission Control Protocol, http://www.ietf.org/rfc/rfc793.txt
RFC 854,
Telnet Protocol Specification, http://www.ietf.org/rfc/rfc854.txt
RFC 959,
A File Transfer Protocol, http://www.ietf.org/rfc/rfc959.txt
RFC 1180,
A TCP/IP Tutorial, http://www.ietf.org/rfc/rfc1180.txt
RFC 1939,
Post Office Protocol - Version 3, http://www.ietf.org/rfc/rfc1939.txt
RFC 2045,
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies, http://www.ietf.org/rfc/rfc2045.txt
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,
http://www.ietf.org/rfc/rfc2046.txt
Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header
Extensions for Non-ASCII Text, http://www.ietf.org/rfc/rfc2047.txt
Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures,
Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and
Examples, http://www.ietf.org/rfc/rfc2049.txt
RFC 2046,
RFC 2047,
RFC 2048,
RFC 2049,
RFC 2060,
INTERNET MESSAGE ACCESS
PROTOCOL
-
VERSION
RFC 2616,
Hypertext Transfer Protocol HTTP/1.1, http://www.ietf.org/rfc/rfc2616.txt
4rev1,
2.5.2 Middleware and Web-Services
IEEE Distributed Systems Online: Middleware area: http://dsonline.computer.org/middleware
[OMG CORBA]
Introduction to OMG's specifications, http://www.omg.org/gettingstarted/specintro.htm
Corba Basis, http://www.omg.org/gettingstarted/corbafaq.htm#TotallyNew
Object Management Group, Inc., Request Broker Architecture and Specifications. Revision 2.6,
OMG Document formal edition, December 2001.
Object Management Group, Inc., CORBA Component Model Joint Revised Submission, 1999b.
N. Wang, D. C. Schmidt, C. O’Ryan, Overview of the CORBA Component Model.
D. Harkey and R. Orfali, Client/Server Programming with Java and CORBA (2nd Edition), Wiley &
Sons, 1998.
Page 103
V. Natarajan, S. Reich, and B. Vasudevan, Programming With Visibroker : A Developer's Guide to
Visibroker for Java (2nd Edition), Wiley & Sons, 2000.
[Enterprise JavaBeans]
Enterprise JavaBeans Technology Fundamentals,
http://developer.java.sun.com/developer/onlineTraining/EJBIntro/EJBIntro.html
Enterprise JavaBeans Specification, Version 2.0 final release,
http://java.sun.com/products/ejb/docs.html
R. Monson-Haefel, Enterprise JavaBeans (3nd Edition), O'Reilly, 2002.
[Microsoft Technologies]
MS .NET basis, http://www.microsoft.com/net/basics/
COM/DCOM Specification, http://www.microsoft.com/com/resources/specs.asp
The Microsoft Transaction Server (MTS): Transaction Meet Components,
http://www.microsoft.com/com/wpaper/mtscomp.asp
C. Trepper, e-Commerce Strategies, Microsoft Press, 2000.
R. Sessions. COM and DCOM: Microsoft's Vision for Distributed Objects. New York, 198.
[IBM WebSphere MQSeries]
MQSeries basis, http://www-3.ibm.com/software/ts/mqseries/messaging/
B. Blakely, H. Harris, and R. Lewis. Messaging and Queuing using the MQI. McGraw-Hill Inc.,
1995.
[Java Messaging Service]
Messaging Systems and the Java Message Service:
http://developer.java.sun.com/developer/technicalArticles/Networking/messaging/
Java Message Service API Tutorial: http://java.sun.com/products/jms/tutorial/
R. Monson-Haefel, D.A. Chappell, and M. Loukides, Java Message Service, O'Reilly, 2000.
[TIB/Rendezvous]
A.Tanenbaum, M.van Steen. Distributed Systems: Principles and Paradigms. Prentice Hall edition,
2002.
Tibco Rendezvous homepage:
http://www.tibco.com/solutions/products/active_enterprise/rv/default.jsp
[XML]
E. Rusty Harold and W. Scott Means. XML in a Nutshell. O'Reilly, 2001.
Page 104
W3C, XML Protocol, http://www.w3.org/2000/xp/
[SOAP]
SOAP: Simple Object Access Protocol 1.1 specification (May 2000), http://www.w3.org/TR/SOAP/
[WSDL]
Ariba, Microsoft, and IBM. Web Services Description Language (WSDL) 1.1, W3C Note.
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[UDDI - ebXML]
UDDI.org, UDDI Technical White Paper,
http://www.uddi.org/pubs/lru_UDDI_Technical_Paper.pdf
Using WSDL in a UDDI Registry 1.05, UDDI Working Draft Best Practices Document.
http://www.uddi.org/pubs/wsdlbestpractices-V1.05-Open-20010625.pdf,
ebXML.org, Business Process Specication Schema (Version 1.01),
http://www.ebXML.org/specs/ebBPSS.pdf
Registry Information Model (Version 1.0), http://www.ebXML.org/specs/ebRIM.pdf
[WSCL - WSFL]
F. Leymann, Web Service Flow Language (WSFL 1.0), IBM Document.
http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf, May 2001
2.5.3 Security
R.Baldoni, M.Mecella. “Sicurezza nelle Reti e nei Sistemi Distribuiti” in G. Cioffi, V. Falzone (a
cura di): Manuale di Informatica - 4a Edizione. Edizioni Calderini, 2002. In Italian
W.Stallings. Cryptography and Network Security: Principles and Practice (2nd Edition). Prentice
Hall (1999)
[IPSec]
RFC 2411,
IP Security Document Roadmap. (Nov 1998), http://www.ietf.org/rfc/rfc2411.txt
[SSL]/[TSL]
Draft SSL Protocol Version 3.0 (Nov 1996), http://wp.netscape.com/eng/ssl3/draft302.txt
RFC 2246,
The TLS Protocol Version 1.0. (Jan 1999), http://www.ietf.org/rfc/rfc2246.txt
[HTTPS]
RFC 2660, The Secure HyperText Transfer Protocol. (Aug 1999),
[WS-Security]
WS-Security version 1.0 (Apr 2002), http://www.verisign.com/wss/wss.pdf
[SAML]
Page 105
SAML 1.0 Specification Set (May 2002),
http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf
[Kerberos]
RFC 1510, The Kerberos Network
Authentication
Service
(Version5),
(Sept
1993),
Kerberos at MIT, homepage http://web.mit.edu/kerberos/www/
[PGP]
RFC 2440,
OpenPGP Message Format (Nov 1998), http://www.ietf.org/rfc/rfc2440.txt
PGP homepage, http://www.pgp.com/
[S/MIME]
S/MIME Internet Drafts and RFCs, http://www.ietf.org/html.charters/smime-charter.html
[Firewall]
Internet Firewalls and Security: A Technology Overview. 3Com Technical Paper (July 1996),
http://www.firstvpn.com/papers/3com/50061901.pdf
[VPN]
D.Kosiur. Building and Managing Virtual Private Networks. Wiley and Sons, Inc edition, 1998.
[X.509]
ITU-T X.509 Recommendation, http://www.itu.int
X.509 Internet Drafts and RFCs, http://www.ietf.org/html.charters/pkix-charter.html
2.5.4 High Availability and Fault Tolerance
[Arjuna]
G. Parrington, S. Shrivastava, S. Wheater, and M. Little. The design and implemen-tation of Arjuna.
USENIX Computing Systems Journal, 8(3): 255-308, Summer 1995.
[FRIENDS]
J. C. Fabre and T. Perennou. A metaobject architecture for fault-tolerant distributed systems: The
FRIENDS approach. IEEE Transactions on Computers, 47(1): 78-95, 1998.
J. C. Fabre: Design and Implementation of the FRIENDS System. IPPS/SPDP Workshops 1998:
604-622
[COMERA]
Y. M. Wang and W. J. Lee. COMERA: COM Extensible Remoting Architecture. In Proceedings of
the Fourth USENIX Conference on Object-Oriented Technologies and Systems, pages 79-88, Santa
Fe, NM, April 1998.
[Fault Tolerant CORBA Specification]
Object Management Group, Inc., Request Broker Architecture and Specifications. Revision 2.6,
Chapter 25, OMG Document formal edition, December 2001
Page 106
[OGS]
P. Felber. The CORBA Object Group Service: A Service Approach to Object Groups in CORBA.
PhD thesis (no. 1867), École Polytechnique Fédérale de Lausanne, Switzerland, 1998.
[Eternal]
L. Moser, P. Melliar-Smith, P. Narasimhan, L. Tewksbury, and V. Kalogeraki. The Eternal System:
an Architecture for Enterprise Applications. In Proceedings of the 3rd International Enterprise
Distributed Object Computing Conference (EDOC’99), pages 214–222, Mannheim, Germany, July
1999.
[DOORS]
B. Natarajan, A. Gokhale, S. Yajnik, and D. Schmidt. DOORS: Towards High-Performance Fault
Tolerant CORBA. In Proceedings of the 2nd Intenational Symposium on Distributed Objects and
Applications, pages 39–48, Antwerpen, Belgium, September 2000.
[AQuA]
M. Cukier, J. Ren, C. Sabnis, W. H. Sanders, D. E. Bakken, M. E. Berman, D. A. Karr, and R.
Schantz. AQuA: An adaptive architecture that provides dependable distributed objects. In
Proceedings of the IEEE 17th Symposium on Reliable Distributed Systems, pages 245--253, West
Lafayette, IN, October 1998.
[Isis+Orbix]
Isis Distributed Systems Inc. and Iona Technologies Limited. Orbix+Isis Programmer's Guide,
1995.
[FTS]
R. Friedman and E. Hadad. A Group Object Adaptor-Based Approach to CORBA Fault-Tolerance.
IEEE Distributed Systems Online, Vol. 2, No. 7, Special Issue on Middleware 2001, November
2001.
[IRL]
R.Baldoni, C. Marchetti, M. Mecella, A. Virgillito. An Interoperable Replication Logic for CORBA
Systems, in Proceeding of the 2nd International Symposium on Distributed Objects and Applications
(DOA 2000), Antwerp, Belgium, September 2000.
R.Baldoni, C.Marchetti, A.Termini. Active Software Replication Through a Three-Tier Approach, in
Proceeding of the 21st Symposium on Reliable Distributed Systems (SRDS 2002), Osaka, Japan,
October 2002
Page 107
3 Legal issue
This chapter is structured in three sections. Section 3.1 and Section 3.2 contain the list of the legal
disposition respectively in force in Italy and in Greece that might take into account in the EUPUBLI.COM design. The full text of these dispositions can be found in the enclosed legal annex.
According with the previous two sections, Section 3.3 comprises a survey of the legal requirements
that must be taken into account in the development of the EU-PUBLI.COM project.
3.1 Italian Law
Legal type: Presidential Decree
Official title: Decreto del Presidente della Repubblica recante il testo unico delle disposizioni
legislative e regolamentari in materia di documentazione amministrativa Presidential Decree containing the unified body of laws on legislative and
regulating dispositions relative to administrative documentation.
Number:
D.P.R. 445-28/12/2000
Date of Publication in the Official Gazette: S.O. G.U. n.42 20/02/2001
Level of Enforcement: European.
Relation to EU legislation: Abstract:
This decree regulates the filling in, the issuing, the storing, the management and the transferring of
documents by public administrations. It incorporates and abrogates several previous decrees on the
same questions among which the Presidential Decree 513/97 and the Presidential Decree 428/98.
Dealing with documents in general, terms such as administrative document and electronic document
(e-document) are defined. In particular this decree recognizes legal validity to “well formed” edocuments, as original version as well as copies of paper version of administrative documents, and
its electronic transmission.
Specific terms for e-documents such as public-key, private-key, digital signature, electronic
certificate (e-certificate) and certification service provider are also defined. The decree establishes
that those e-documents to which a digital signature is postponed have the same legal strength of
handwritten signed paper documents. The digital signature must be referred to a single e-document
and a single signatory subject. Each subject who aims to use digital signature or other encryption
mechanisms based on public-key encryption must equip himself with a pair of public/private key
properly issued by a certification service provider. The certificate corresponding to the private key
used to produce the digital signature must not be expired or suspended or revoked by the issuing
certificate service provider. Digital signatures also replace, when required, marks, stamps and seals.
In public administrations e-documents the digital signature is mandatory and replaces handwritten
signature, marks, stamps and seals. Moreover public administrations provide by themselves in
issuing, maintaining and certifying their own public keys.
Requests and declarations to be forwarded to public administrations can be sent by fax or via
electronic transmission; in the latter case a digital signature is mandatory for their legal validity.
An e-document exchanged via electronic transmission is considered sent if it is addresses to the email address provided by the receiver. Date and time of the e-document’s filling in and transmission
have legal validity. Sent e-documents are assured to be legally received by the destinations if their
delivery ensures an acknowledgement from the receiver itself.
Each public administration must provide to modernize their information system and more to
specifically their paper protocol register through the automatic register. The automatic register must
ensure the record of all the incoming and outcoming documents in compliance with the adopted
classification that have to follow uniform criteria. A registered document must be endowed with a
Page 108
not modifiable protocol signature that must contain the protocol progressive number, the registering
date, the sender or the receiver of the transmitted documents and an identification of the
administrative office involved. The record of a document in the automatic register must thus be
equipped with the protocol signature, the not modifiable document subject and its digest that
univocally identifies its content.
E-documents exchanged among public administration, in respect with the law 675/96, can contain
the sole information required to complete the purpose for which they are acquired and the electronic
correspondence of documents must be kept secret if not related to information of public domain.
This decree also establishes the duties of a certification service provider’s which are: identifying
with no doubts the applicant before issuing the keys; issuing and publishing the corresponding
electronic certificate; timely publishing the certificate’s revocation in case of lost, compromised,
suspended or revoked keys.
Technical rules for “well-formed” e-documents are established by Government Decrees in agree
with the Authority for Information Technologies in the Public Administration (Autorità per
l’Informatica nella Pubblica Amministrazione AIPA) and the Data Protection Commission.
Entity responsible for the application: Public Sector generally
Legal type: Government Decree
Official title: Regole tecniche per la formazione, la trasmissione, la conservazione, la
duplicazione, la riproduzione e la validazione, anche temporale, dei documenti
informatici ai sensi dell'art. 3, comma 1, del decreto del Presidente della
Repubblica 10 novembre 1997, n. 513. – Technical rules for the filling in, the
transferring the storing, the duplication, the reproduction and the validation,
even temporal, of electronic documents, in respect to the Presidential Decree
513/97.
Number:
D.P.C.M. 08/02/1999
Date of Publication in the Official Gazette: G.U. 87-15/04/1999
Level of Enforcement: European
Abstract:
This decree incorporates a technical enclosure in which technical rules for the filling in, the
transferring, the storing, the duplication, the reproduction and the validation, even temporal, of
electronic documents are specified. These rules prescribes that document digest have to be
calculated with Dedicated Hash-Function1, corresponding to RIPEMD-160, or Dedicated HashFunction1, corresponding to SHA-1 and digital signatures have to be generated and validated with
RSA or DSA algorithm. Public-keys are classified in subscription keys, certification keys and
temporal validation keys. Subscription keys are addressed to be used for generating and verifying
digital signatures coupled with documents; certification keys for generating and verifying digital
signatures coupled with certificate and the relative certificate revocation list (CRL); temporal
marking keys for generating and verifying digital signatures coupled with temporal marks. Key
addressed for one of these uses cannot be used for the others. In any case a key’s smallest length is
fixed in 1024 bits. The holder of a pair of public/private keys must preserve with the greatest care
the confidentiality and integrity of his private key, he must immediately ask for the revocation of the
paired certificate if these properties are compromised in some way, this request must be issued
physically or via electronic delivery if a secure communication can be established with the
certificate service provider. Certificates and CRLs must be compliant to the rule ISO/IEC 95948:1995 with the extension included in Variation 1.Each certificate service provider have to keep upto-date a certificate directory containing the certificate he has issued and the certificate revocation
Page 109
list (CRL). Certificate directories of each certificate service provider can be accessed to well known
web site following electronic modalities compliant with the LDAP protocol.
Temporal marks are used to temporally validate e-documents and can be used to extend the temporal
validity of an e-document longer than the subscription key validity with which it has been signed.
Temporal marks are generated by specific electronic device able to keep the date and time compliant
with UTC (Coordinated Universal Time), to format a data structure in which the time and date does
not differ more than a minute from the time of its generation and to postpone a digital signature to
the data structure itself.
Legal type: Government Decree
Official title: Regole tecniche per il protocollo informatico di cui al decreto del Presidente della
Repubblica 20 ottobre 1998, n. 428. – Tecnical rules for the automatic register in
respect to the Presidential Decree 428/98
Number:
D.P.C.M. 31/10/2000
Date of Publication in the Official Gazette: G.U. n. 272-21/11/2000
Level of Enforcement: National
Abstract:
This decree provides technical rules and criteria for the filling of specific information needed for
storing e-documents in the automatic register and their data structure. This decree institutes a
directory about the public administrations and the homogenous organizational areas. This directory
is published and maintained up-to-date in a web site accessible via protocols LDAT compliant
To provide newer form of cooperation it establishes that the exchange of e-documents, among
public administrations within or cross the homogenous organizational areas and subject to the
automatic register, is through e-mail mechanisms compliant to the SMTP/MIME protocols.
The digests required to postpone the digital signature for each e-documents registered in the
automatic register, must be calculated for each files attached in an e-mail through the Dedicated
Hash-Function1, corresponding to SHA-1. Data related with the protocol signature are included in a
file compliant to XML and more specifically compliant to a DTD specification maintained in the
web site accessible through a protocol LDAT compliant.
Legal type: Legislative Decree
Official Title: Attuazione della Direttiva 1999/93/CE relativa ad un quadro comunitario per le
firme elettroniche - Actuation of the directive 99/93/EK of the European Council
about the European Framework for electronic signatures.
Number:
D.L. 10-23/01/2002
Date of Publication to the Official Gazette: G.U. n.39 15/02/2002
Level of Enforcement: European
Relation to EU legislation: 99/93/ΕC of European Parliament and Council of December 13th
1999 “About the european framework for electronic signatures” (EEL
13/19.1.2000)
Abstract:
Digital signature, electronic certificate (e-certificate), qualified electronic certificate (qualified ecertificate) and certification service provider are the subjects of this legislative decree.
The term qualified e-certificate is referred to e-certificate compliant with those requirements
specified in the directive 99/93/EC. Qualified e-certificate are issued or guaranteed by a certification
Page 110
service provided established in countries of the EC or compliant with the 99/93/EC’s requirement
and credited in an EC country.
The terms digital signature and advanced digital signature are distinguished in such only the
advanced digital signature is based on qualified e-certificate. This distinction is used to specify that
requests and declarations forwarded to public administration via electronic transmission are legally
valid if underwritten by means of advanced digital signature (art.9) Legal validity of simple digital
signature in other applications is not denied (art.6).
Entities responsible for the application: Department for Innovation and Technologies and
Authority for Information Technology in the Public Administrations.
Legal type: Law
Offcial title: Trattamento dei dati personali – Processing personal data.
Number:
L. 675-31/12/1996
Date of Publication in the Official Gazette: S.O G.U. n.5 08/01/1997
This law ensures fundamental right on the processing of personal data with regard to privacy and
personal identity. It defines as personal data any information relating to natural or legal persons,
bodies or associations that directly or indirectly allows his identification. It states that personal data
processing by private entities or economical public authorities is admitted only in consequence of an
explicit consensus from the interested party. Moreover the interested party must be previously aware
on the processing, its purpose and modalities, possible diffusion and the obligatory or optional
nature in providing the data. Collected data must be protected by disruption and unauthorized
accesses with adequate security countermeasures. This law establishes also a proper authority, the
Italian Data Protection Commission, defines its functions and prescribes that sensitive data, such as
racial, religious, political, health and sexual details can be threat only with the additional
authorization of the Commission. Personal data transfer towards countries member of the EU is free,
while transfer towards other countries must be previously notified to the Commission. A set of
exceptions is provided for each rule. Finally the processing of personal data carried out without
electronic or automated means is governed by the same provisions applying to the processing carried
out with manual means (art. 5).
Entity responsible for the application: Italian Data Protection Commission.
Legal type: Law
Offcial title: Norme in materia di procedimento amministrativo e di diritto di accesso ai
documenti amministrativi – Rules on administrative procedures and access
rights to administrative documents.
Number:
L. 241- 07/08 /1990
Date of Publication in the Official Gazette: G.U. 192 18/08/1990
This law rules public administrations’ procedures and defines rights and duties of citizens toward the
latter. It states (art. 2) that each administrative procedure must be concluded with a proper provision;
public administrations can set a specific deadline for each type of procedure; the deadline starts from
Page 111
the beginning of an official statement or from the receipt of a request. If not specifically set by other
laws or dispositions, the deadline is set in thirty (30) days.
Administrations must inform the involved subjects, one or more, about the beginning of the
procedure and the announcement must contain the matter in hand, the nominated responsible unit
and the site where it is possible to check the procedure’s progression. Involved subjects have
actually the right to access to all those documents, except classified once, related with the procedure.
The final provision must be notified to the involved subject, together with details to appeal such as
the deadline and the addressable authority for the appeal’s application. This law establish also a
specific Commission whose function is to cope on the complete knowablity of the public
administrations’activities.
Entity responsible for the application: Commission for the access of administrative documents
3.2 Greek Law
Legal type:
Law
Official Title: Οικονοµικοί πόροι της Νοµαρχιακής Αυτοδιοίκησης και άλλες διατάξεις Financial resources of Prefectures and other provisions.
Number:
2672/1998
Date of Publication to the Official Gazette: ΦΕΚ 290 Α, 28/12/1998
Relation to EU legislation: Abstract (of the article 14 of the Law):
Document distribution with the use of fax or e-mail is permitted between Public Sector, Prefectures,
Local Government (Ο.Τ.Α.) or between those and individuals, unions of individuals and Legal
Entities of Private Law (Νοµικά Πρόσωπα Ιδιωτικού ∆ικαίου).
There are definitions of the terms: fax function, fax, e-mail, e-mail message and digital signature.
Then the types of documents which can be sent by fax and e-mail are defined. As far as e-mail is
concerned, between Public Sector, Prefectures, Organizations of Local Self-Administration (Ο.Τ.Α.)
the types of documents that can be sent are: messages with the content of: opinions
(γνωµοδοτήσεις), queries, application forms, replies, law-explanatory - organizational documents
(εγκύκλιοι), directions, reports, studies, proceedings, statistical data, notes (υπηρεσιακά
σηµειώµατα), written counsels (έγγραφες εισηγήσεις). The types of documents which can be sent
between public organizations mentioned above and individuals, unions of individuals and Legal
Entities of Private Law (Νοµικά Πρόσωπα Ιδιωτικού ∆ικαίου) are only application forms requesting
information and related replies. This might be extended to other types documents that do or do not
have digital signature by a Presidential Decree.
The consent of the individuals, unions of individuals and Legal Entities of Private Law (Νοµικά
Πρόσωπα Ιδιωτικού ∆ικαίου) is necessary in order to use fax or e-mail to reply to their application
form. If they make their application form using one of these means, it is assumed that they consent
to the use of the same means for the reply.
When an e-mail comes from Public Sector, Prefectures, Local Government (Ο.Τ.Α.) it should at
least contain:
• sender’s and recipient’s e-mail addresses
• the full title of the sender
• subject, date, protocol number of the message (if one exists)
• name, surname, professional position, telephone number of the person in charge of the e-mail
correspondence
• if there are attached files, the type and the identity characteristics of the attached file
When the e-mail comes from an individual, unions of individuals and Legal Entities of
Private Law (Νοµικά Πρόσωπα Ιδιωτικού ∆ικαίου) it should at least contain:
Page 112
•
•
•
•
•
sender’s name, surname (physical or commercial) (ονοµατεπώνυµο - επωνυµία)
sender’s home / headquarters address
sender’s e-mail address
sender’s telephone number
if there are attached files, the type and the identity characteristics of the attached file
If the e-mail software automatically presents some of the data above, it does not have to be written
again in the text.
An e-mail is considered delivered to the recipient when an electronic receipt has been received by
the sender, or, if this is not possible, when the delivery has been confirmed by the recipient through
other means.
Digital signature inflicts the results of handwritten signature. An e-mail with digital signature is a
legally valid document.
E-mails should be stored electronically for as long as the current laws define.
Entities responsible for the application: Public Sector, Prefectures, Organizations of Local
Self-Administration – (that is Prefectures, Municipalities) (Ο.Τ.Α.)
Legal type:
Law
Official Title: Κύρωση του κώδικα ∆ιοικητικής ∆ιαδικασίας και άλλες διατάξεις – Sanction
of Administrative Procedure code and other provisions
Number:
2690/1999
Level of Enforcement: national
This is a law that defines general procedures in the public sector, some duties of the public
administration to the citizen and vice versa. The articles that concern us are the following:
Article 4: When an application form is submitted, the administrative authorities should respond
within the period set by special relevant articles, otherwise (if no deadline is set specifically) within
sixty (60) days.
Article 10: In case of a deadline set by the public authority to citizens for a submission of
applications forms or other types of documents, the citizen has the right to submit, within the
permitted period, the document using a mechanical mean. This mean should «leave a fingerprint»,
which not only does make indubitable the recognition of this machine used for sending and
receiving, but also defines precisely the exact time the document was sent and received. However,
within five (5) days after the deadline, the citizen should submit a document with the same content
as the one submitted before to the public service, but this time with his/her handwritten signature.
Article 12: All incoming documents in a public service, regardless of the way they are imported,
should be recorded in the «book of incoming documents» the day they are imported according to
their increasing number (protocol). Other information is also recorded in this «book» concerning this
document: characterization, subject, number of attached elements, recipient and date of import. The
authority should provide the citizen with a certification that the document has been recorded - the
certification should contain the data mentioned above.
Entities responsible for the application: Public Sector generally
Page 113
Legal type:
Law
Official Title: Οργάνωση και Λειτουργία Τηλεπικοινωνιών και άλλες διατάξεις –
Telecommunications Organisation and Functions and other provisions
Number:
2867/2000
This law defines all procedures related to telecommunication activities. It also sets as responsible for
all telecommunication activities in Greece the National Telecommunications and Post Commission
(Εθνική Επιτροπή Τηλεπικοινωνιών και Ταχυδροµείων). In case Eu-publi.com needs to develop a
private telecommunications network, the article 2 should be taken into account. In the article 2, it is
defined that “Substantial Requirements” are non-financial reasons of public interest, based on which
the installation and/or function of Telecommunication Networks and/or the offer of
Telecommunication Services can be permitted under constraints. These reasons can only be a) the
security of network function b) the maintenance of its integrity and by exception and only if required
the interaction in the functions of services c) data protection, including private type data, secrecy of
information and private life protection. There are also two reasons concerning the environment and
radiocommunication system frequencies.
Entities responsible for the application: Public sector in general, National Telecommunications
and Post Commission (Εθνική Επιτροπή Τηλεπικοινωνιών και Ταχυδροµείων)
Legal type:
Law
Official Title: Προστασία του ατόµου από την επεξεργασία δεδοµένων προσωπικού
χαρακτήρα – People’s protection from private type data processing
Number:
2472/1997
Date of Publication to the Official Gazette: ΦΕΚ 50, 10/4/1997
This is the basic law concerning data protection. It defines the restrictions technology should have
concerning the way and types of data to be processed. The following terms are defined: “Personal
data”, “sensitive data”, “personal data process”, “Personal data archive”, etc.
One of the basic settings of this law is this: When someone’s personal data is used for processing,
this person should be aware of that and should have given his/her consent to it. There are a number
of exceptions to this article. Furthermore, sensitive data collection or processing is not permitted.
This article also has certain exceptions.
As far as the personal data flow outside the frontiers of a country, it is defined that it is free when
countries are members of the EU. When they are not EU members, Data Protection Authority should
issue a license, only when certain conditions are met. In both cases, when Data Protection Authority
considers that a country does not ensure a satisfying level of protection it should inform the
European Commission and the respective authorities of the EU members.
The law defines that Data Protection Authority is established, and states its responsibilities.
Entities responsible for the application: Data Protection Authority (Αρχή προστασίας
δεδοµένων προσωπικού χαρακτήρα)
Page 114
Legal type:
Law
Official Title: Για την προστασία της ελευθερίας της ανταπόκρισης και επικοινωνίας και
άλλες διατάξεις - About the protection of freedom of correspondence and
communication
Number:
2225/1994
This law defines the framework about the confidential character of communications. The National
Commission for the Protection of the confidential character of Communications is being established.
The ways of control that the previous Commission can use are set. It defines the different situations
that can cause the abrogation of confidentiality (Άρση απορρήτου) (case of national reasons, crime
detection, etc), the procedure of abrogation of confidentiality. Finally, the law defines the
nomination of employees and the infrastructure of this Commission.
Entities responsible for the application: National Commission for the Protection of the
confidential character of Communications (Εθνική Επιτροπή Προστασίας του
Απορρήτου των Επικοινωνιών).
Legal type:
Law
Official Title: Προστασία ∆εδοµένων προσωπικού χαρακτήρα στον τηλεπικοινωνιακό τοµέα
– Personal type data protection in telecommunications
Number:
774/1999
This law has a tight relation with law No 2472/1997. This law is applied in the case of personal data
processing in the framework of providing services on public telecommunication networks that are
available to the public, especially through ISDN and public digital mobile networks. On the other
hand, for processing personal data in the framework of services not available to the public, law No
2472/1997 is used. The current law defines the following terms: subscriber, user, public
telecommunications network and telecommunication services.
In a few words, it defines that personal data processing is permitted when the subscriber or the user
has given his consent after being informed about the type of data, the purpose and length of the
process and the recipients or categories of recipients of the data. It is also permitted when it is
necessary for the execution of a contract («σύµβαση»), in which the subscriber or user is an
interested part.
The use of data for commercial or advertising purposes is prohibited, unless the user or subscriber
has explicitly declared his agreement on it.
There are articles concerning missed calls, bills that are accompanied with analytical charges per
call and include the numbers that have been dialed, call recognition, automatic call forwarding.
The provider of telecommunication services should take all appropriate measures in order to protect
the security of the services offered.
Finally, the law defines the responsibilities of the Data Protection Authority.
Entities responsible for the application: Data Protection Authority (Αρχή προστασίας
δεδοµένων προσωπικού χαρακτήρα), in certain cases decisions are issued after
Page 115
consultancy from National Telecommunications and Post Commission (Εθνική
Επιτροπή Τηλεπικοινωνιών και Ταχυδροµείων)
Legal type:
Oficial Title:
Presidential Decree
Προσαρµογή στην Οδηγία 99/93/ΕΚ του Ευρωπαϊκού Κοινοβουλίου σχετικά
µε το κοινοτικό πλαίσιο για ηλεκτρονικές υπογραφές. – Adaption to the
directive 99/93/EK of the European Council about the european framework
for electronic signatures.
Number:
50/2001
Relation to EU legislation: 99/93/ΕΚ of European Parliament and Council of December 13th
1999 “About the european framework for electronic signatures” (EEL
13/19.1.2000)
Abstract:
The presidential decree deals with matters of digital signature and security certificates. It doesn’t
refer to technical requirements, but it is widely considered that it implies the use of asymmetric
encryption for the creation of digital signatures. Specifically, it implies the use of Public Key
Infrastructure – (PKI). The decree defines terms such as electronic and digital signature. It also
states that digital signature based on a widely accepted certificate and created by a secure structure
responsible for signature creation (a secure computer console, for instance) is equivalent to (“επέχει
θέση”) a handwritten signature, both for procedural (“δικονοµικό”) and substantial (“ουσιαστικό”)
law.
It also defines the responsibilities for certification services providers, and some restrictions
concerning the use of personal data they possess.
Entities responsible for the application: National Telecommunications and Post Commission
(Εθνική Επιτροπή Τηλεπικοινωνιών και Ταχυδροµείων)
Legal Type:
Guidelines
Official Title: Σχέδιο ασφαλείας και έκτακτης ανάγκης – Security plan / disaster recovery
and contingency plan
Number:
Date of Publication to the Official Gazette: Level of Enforcement: national
The Hellenic Data Protection Authority has developed the respective document as a template of
general rules and guidelines that could be used to help Greek Public Administration officers to take
measures for the security and protection of their Information Systems (henceforth: ISs). It pertains to
every officer responsible for processing of personal data.
The security plan is defined as the documentation of an organization’s security requirements. It is
proposed to consist of the security policy, a description of the present situation of the ISs, the
security requirements, implementation and revision plans. Its objective is to set the role and
responsibilities, the scope and the way of application of the security measures, taking into account
the organization’s existing legal framework and policies. The security measures that are proposed to
be determined and implemented concern the following ISs issues: development, maintenance,
administration and infrastrcuture safety.
Page 116
The disaster recovery and contingency plan determines the strategy that will be implemented in
order to protect the ISs critical functions. It is proposed to contain a time schedule that arranges the
sequence of actions and the officer responsible for the recovery of damages. The security and the
disaster recovery –contingency plans are proposed to be developed after a risk analysis review of
information and telecommunication assets. The risk analysis review determines the weaknesses of
and the threats faced by the ISs.
Links to relevant documents are shown in the guidelines conclusion as examples of possible
instantiations.
Entities responsible for the application: Hellenic Data Protection Authority (Αρχή προστασίας
δεδοµένων προσωπικού χαρακτήρα)
3.3 EU-PUBLI.COM Legal Requirements
From the legal disposition listed above it emerges that both Italy and Greece recognize the edocuments legal validity if a digital signature is postponed to the e-document itself. Moreover
both the Italian and the Greek laws specify as e-mails protocol compliant SMTP/MIME the
mean to exchange request/reply with citizens and e-documents within public administrations. No
dispositions are currently in force for other electronic transmission means.
Both countries, adopting the European disposition 93/99/EC, recognize the need of a PKI
infrastructure that, through the management of certificate and certificate revocation lists,
authenticates the validity of the used key and grants the identity of the signing subject. Italian
administration provides by their own on issuing and managing their certificate, so the Greek
administration should recognize Italian administration as accepted certificate service provider.
The duties of a trusted certificate service provider are in both countries compliant to the
European disposition 93/99/EC.
Both countries have in force specific laws for the Personal Data Protection. These laws state that
documents exchanged among public administration of countries belonging to the European
Community are free. The exchanged information is restricted to the sole information necessary
to complete the procedure for which the information is acquired. Special provisions must be
realized to physically and electronically protect data and administrative documents storages.
If not explicated by other specific disposition, the deadline to escape a request is fixed in sixty
days for the Greek public administrations and in thirty days for the Italian public
administrations.
Documents exchanged within a national administration are subject to a registration protocol.
Therefore to allow cross-national administration interoperability, a common format for the
information, that can be exchanged, should be established.
Moreover a set of law dictating technical rules relatively to digital signature format and
registration procedure are in force in Italy.
Page 117
4 Case Study
This chapter presents three different case study that can be used as references in the management
and design of the EU-PUBLI.COM project. It is structured in six sections as follows:
• Section 4.1 presents an introductive overview of the e-Government and the guidelines, in
term of classifications and methodologies, defined in literature to face this complex
arguments.
• Section 4.2 presents the Italian experience describing the approach and the results achieved
in the development of the Italian Unitary Network (Rete Unitaria per la Pubblica
Amministrazione RUPA)
• Section 4.3 presents the UK experience in e-Government through the UK On Line Project
and the related e-Government Interoperability Framework (e-Gif) (subsection 4.3.4)
• Section 4.4 refers to administrative guideline that should be followed in the management of
the EU-PUBLI.COM project and in the possible future experiences of e-Government that
will follow. In it the U.S Federal Enterprise Architecture Framework (FEAF) is described.
• Section 4.5 presents a picture of the advancement in e-Government through the classification
model introduced in section 4.1
• Section 4.6 encloses, organized in sections, the reference to the arguments dealt with in the
chapter.
4.1 Introduction to e-Government
In literature, e-Government is defined as “the civil and political conduct of government, including
service provision, using information and communication technologies”.
The previous definition implies that modernizing government by using new technologies can be
carried out along three main directions:
• Electronic Service Delivery: provision of services to citizens and businesses; it often
requires the integration of different information systems, in ways possibly more complex
than in other application domains.
• Electronic Democracy: the opportunity of on-line consultations with citizens; as an
example, new legislatures in Scotland and Wales are experimenting electronic voting
systems in their chambers.
• Electronic Governance: digital support for policy and decision making, group work
between ministers and their senior civil servants working on policy formulation,
development and management, and with policy advisors who are contracted to provide
confidential policy support.
e-Government systems targeted to electronic service delivery are currently investigated both by
researchers and practitioners, as they constitute the basis for supporting efforts in any other
direction. This is the focus of the EU-PUBLI. COM project.
The first step in the establishment of an e-Government strategy is to address government specific
constraints and issues:
• autonomous administrations must be able to cooperate with other administrations since they
do not have complete control over data and services needed to reach their own goals; such
goals are typically set up by external entities or events (e.g. the passage of a law);
• many administrations own legacy information systems, and as these systems were designed
to support vertical (stovepipe) applications, exporting their services requires substantial
Page 118
reengineering; frequently, however, technological issues, internal organizational structures
and legal constraints limit progress. Moreover there is no real opportunity for forcing and/or
coordinating migrations away from legacy systems.
Therefore the goal is to establish an overall architecture that coordinates information exchange
among various government information systems while maintaining each organization's autonomy;
crafting such an architecture involves not only reengineering technological systems according to
each organization's needs, but also reengineering the administrative and business processes that
provide services to customers.
In a deep business process reengineering approach, redundant processes in specific organizational
units would be eliminated, and some activities would be reassigned to new organizational units: this
would eliminate many information exchanges, thus addressing the main issue of the excessive
fragmentation of responsibilities among administrations. Unfortunately, certain issues hamper largescale radical changes in the short and medium term, such as the impossibility of assigning new legal
responsibilities to given organizational units (due to the difficulty of changing existing laws), the
lack of specific skills and resources in some public administrations, the time needed to create such
skills, and so on.
In the technological improvement approach, technologies can be used to (semi)automate macroprocesses through cooperative applications, thus obtaining cooperative processes. An approach of
this type does not necessarily require initial radical changes, neither in the macro-process structure
nor in the internal processes. Each administration interfaces the others by offering specific services,
independently of their realization, and therefore internal changes do not impact on the macroprocess, as they are hidden by the service interfaces presented to other administrations. Separate
administrations are thus loosely coupled, and each can reengineer its own processes without
impacting on the cooperative process and related applications. Later, when the internal processes
have been improved and new services are ready to be offered, the cooperative process will be
modified, thus obtaining global and more substantial improvements through a more radical macroprocess reengineering.
In the reengineering mission, administrations have to decide which services should be delivered
electronically.
In this direction, the Australian National Audit Office (ANAO) and the Office of Government
Online (OGO) in Australia, developed in the report Electronic Service Delivery including Internet
Use, a model of government agencies’ service delivery via The Internet in which an agency’s
maturity is directly related to the technologies supported in the provision of its services.
The model has four stages, as follows:
• Stage 1 is a Website that publishes information about the agency and its services.
Stage 1 permits an agency with a Website to provide or publish information about
its services to those who access it. Publications are available online and can be
downloaded. There is a limited inquiry and search facility. The information is made
available in a static display. There are no limits to public access to the information.
• Stage 2 allows Internet users to browse and interact with the agency’s database(s).
Page 119
Stage 2 permits an individual who accesses a Website to access or interact with the
agency’s database. The individual can calculate an entitlement, subsidy or debt, or
do research using part or all of the database. Interactive facilities are limited. There
are no limits to public access to information on the Website.
• Stage 3 includes the first two stages and permits users to enter information on the Website,
exchanging or transacting secure information with the agency.
Stage 3 requires authentication or verification of the individual’s identity, used by
the agency to control access to its data, and to authenticate data being provided.
Stage 3 involves exchange of information between the agency and the individual
Internet user once the agency has verified his or her identity. The interaction can
have financial implications. This stage covers secure, authenticated financial
transactions. In future, financial transactions on the Internet will be more secure, so
more agencies might advance to it.
• Stage 4 is the same as Stage 3 but in addition the agency, with the user ’s prior approval,
shares that user’s information with other government agencies.
Stage 4 involves government agencies’ exchanging information provided by
individuals, organizations or businesses, with their prior consent. For example, an
agency notified of a change of address would recognize it as an event of which
other agencies should be notified, and would do so, with the prior knowledge of the
original provider of the data. A few agencies have or are proposing interchange of
information at this level.
Stage 4 Agencies receiving
authenticated information
share data with other
agencies with prior approval
of individual clients.
Stage 1 Website presence.
Basic information and
pubblications. All agencies
should be at least at this
‘publish’ level.
Functionality/service delivery
High
Level
Stage 3 Agency interaction
with clients, including client
entry of confidential data. All
agencies requiring
authenticated client information
should aim at this level.
Stage 2 Databases queries
online. Agencies with
public databases should be
at least at this level of
integration.
Low
Level
Low Level IT
Increasingly sophisticated technology
High Level IT
Figure 4.1: ANAO-OGO model of service delivery by the Internet
Page 120
The achievement of stage 4 is therefore the one in which the real automation of the macro-processes
is obtained. Moreover services and information exchange enables further improvement in eGovernment: the availability of integrated information from different governmental agencies is a
necessary factor for e-Governance; moreover processes’ cooperation requires the development of a
complex security infrastructure which can be subsequently used also for initiatives of e-Democracy.
In the next two sections we will describe two plans for the e-Government:
• the italian unitary network (Rete Unitaria per la Pubblica Amministrazione, RUPA)
approach;
• the UK project (ukonline.gov.uk).
For what concerns administrative guideline that should be followed in the design of the
EU-PUBLI.COM project the most relevant experience is the USA government’s initiative Federal
Enterprise Architecture Framework (FEAF)
4.2 The Italian Unitary Network (RUPA)
4.2.1 Introduction
In Italy, the need for a better coordination of efforts and investments in the area of government
information systems pushed the Italian Parliament in 1993 to create the Authority for Information
Technology in the Public Administration (Autorità per l'Informatica nella Pubblica
Amministrazione, AIPA) with the aim of promoting technological progress by defining criteria for
planning, implementation, management and maintenance of the information systems of the Italian
Public Administration (PA). More recently, the Italian Government has set up the e-Government
Action Plan, with the aim of achieving inter-administration cooperation by the end of 2002.
The establishment of an e-Government strategy requires that a number of government-specific
constraints and issues be addressed. Autonomous administrations must be able to cooperate with
other administrations since they do not have complete control over data and services needed to reach
their own goals; such goals are typically set up by external entities or events (e.g. the passage of a
law).
Many administrations own legacy information systems, and as these systems were designed to
support vertical (stovepipe) applications, exporting their services requires substantial reengineering;
frequently, however, technological issues, internal organizational structures and legal constraints
limit progress. Moreover there is no real opportunity for forcing and/or coordinating migrations
away from legacy systems.
Therefore the goal is to establish an overall architecture that coordinates information exchange
among various government information systems while maintaining each organization's autonomy;
crafting such an architecture involves not only reengineering technological systems according to
each organization's needs, but also reengineering the administrative and business processes that
provide services to customers.
In order to increase organization efficiency and overall effectiveness of administrative actions, given
the constraints discussed above, the development of a cooperative information system (CIS) has
been considered a viable solution. In such a way, it will be possible to consider the set of distributed,
yet independent systems of public administrations as a Nationwide Cooperative Information System
Page 121
(Nationwide CIS) of Italian PA, in which each subject can participate by exchanging services with
other subjects.
Among the various initiatives undertaken by AIPA and carried out through the e-Government
Action Plan, the definition, design and deployment of the Nationwide Public Administration
Network able to connect public administrations among them, is central in order to reach such an
objective. Currently the Nationwide PA Network is providing basic interconnection services (e.g.,
WWW access, e-mail, file transfer) to public administrations.
In the last few years some projects have been undertaken aiming at the development of specific
cooperative information systems in different areas (e.g., territorial and cadastral systems, services to
enterprises, etc.). Such CIS's of Area, and the others that will be developed in the next future, will be
integrated later in order to constitute the baseline of the Nationwide CIS.
Some studies have analyzed the Italian e-Government initiative, by comparing the various projects
focusing both on technological and architectural issues and on the characterization of their
organizational models of cooperation. Based on such studies, the aim of this chapter is to outline the
Italian e-Government initiative and the results stemming from the analysis of the various projects
undertaken during the years 1998 through 2001.
The Italian e-Government initiative constitutes a wide “real world” experience about the
development of cooperative information systems through a service-based approach; many of the
insights to the research work described in this thesis stem from the analysis of such an experience.
4.2.2 Cooperative Processes
The need of a common infrastructure for interconnecting the information systems of different public
administrations is based on the results of a general assessment on the use of information
technologies in the Italian PA, carried out in the years 1995 through 1998. The novelty of the
investigation has been to focus both on technological issues and on organizational ones, in order to
identify the structure and the relationships among different organizational units; the investigation
has been performed both on the units responsible for the computer-based information systems, and
on the other units responsible for administrative processes.
The Italian PA consists of different entities:
• Central PA, which consists of government Departments and Agencies (about 100, with
40,000 employees) located in Rome;
• Peripheral PA, which consists of branch offices (about 4,000 with 400,000 employees) of the
Central PA spread all over the country. The technological infrastructure of the Central and
Peripheral PA consists of 107 mainframes and over 9,500 servers, with about 300,000
workstations (17,000 of which are dump terminals). The application code consists of about
300 millions of lines, 77% of which are written in COBOL.
• Local PA, which consists of entities such as Regions, Districts and City Councils (20,000
with 1 million of employees), characterized by a high degree of autonomy with respect to the
Central PA; this autonomy is continuously increasing as a consequence of the
decentralization process presently going on. The situation of the Local PA is different from
the previous one: many large entities own mainframes and servers and are connected,
through networks, to some other entities, whereas medium and small entities do not have
anything else than simple office automation applications, scarcely integrated with others.
Page 122
Administrations provide services to customers (citizens and private organizations such as
companies, enterprises, no-profit organizations, etc.) and therefore they are typically involved
together in the execution of administrative processes, that is sequences of tasks executed inside
single organizational units. By analyzing processes, AIPA has tried to identify macro-processes, that
is sequences or aggregations of processes that are to be executed jointly in order to satisfy the
request of a service from a customer.
A macro-process is a complex business process involving different organizations;
unlike traditional processes where all the activities concerns the same organization, in
a macro-process the activities involve different organizations, since they exchange
services and information in a coordinated way.
Fragmentation of responsibilities, frequent interruptions of processes inside an administration, and
the absence of cooperation among different administrations result in inefficient provision of services
and execution of macro-processes. A typical macro-process starts in one public administration A,
then the workflow moves to administration B, and on to public administration C. In many cases, the
administration does not have all the information it needs, and a delay occurs while the missing
information is sought from another source; in other cases, legal constraints (e.g., a law) impose to
some other administration to carry out specific tasks. Currently, most information exchanges and
communications among public administrations require using hard-copy documents sent through
ordinary mail; often, the customer serves as a messenger, providing the information needed to
establish communications between administrations. It has been shown that in about 40% of the
cases, the operator of the process does not know all the information she needs in order to complete it
and, therefore, must request such information from other subjects. Conversely, in about 15% of the
cases other administrations are required to be involved in specific tasks. Finally, in 35% of the cases,
administrations are required to be notified of particular events when they occur in some other
administration.
As an example, Figure 4.2 shows a very fragmented macro-process for “providing aid to disabled
persons”, which requires several interactions with various PA's, including the Prefectures (peripheral
offices of the Department of Internal Affairs), the Department of Treasury, the Local Health
Authorities and the City Councils.
Page 123
Dis a ble d pe rs on
re que s ting a id
c us to m e r
c o o pe rative pro c e s s e nd
2
c o o pe rative pro c e s s s tart
3
4, 6
P re fe cture
City Council
12
5
11
p e rip he ral p ub lic
ad m inis tratio n
lo c al p ub lic
ad m inis tratio n
Loca l He a lth Autority
7
Proce s s (s e que nce of
tas ks ins ide a s ingle
organizational unit)
10
8
De pa rtme nt of
Tre a s ury
Italian Public Adminis tratio n
9
c e ntral p ub lic
ad m inis tratio n
Figure 4.2: A macro-process for “providing aid to disabled persons”
In order to obtain improvements, a radical Business Process Reengineering (BPR) of the macroprocesses would be the most appropriate solution; redundant processes in specific organizational
units should be eliminated, and some activities should be re-assigned to new organizational units:
this would eliminate many information exchanges, thus addressing the main issue of the excessive
fragmentation of responsibilities among administrations. Unfortunately some issues hamper radical
changes on a large scale in the short and medium term, such as the impossibility of assigning new
legal responsibilities to some organizational units (due to laws difficult to change), the lack of
specific skills and resources in some public administrations, the difficulties in creating such skills,
and so on.
Conversely a more gradual approach, referred to as macro-process technological improvement, uses
technologies to (semi-)automate macro-processes through cooperative applications, thus obtaining
cooperative processes; such an approach does not necessarily require initial radical modifications
either in the macro-process structure nor in the internal processes: each administration interfaces the
others by offering specific services, independently on how it realizes them, and therefore its
autonomy in changing its own processes is guaranteed. Internal changes do not impact on the macroprocess, as they are shielded by the service interfaces exported towards other administrations.
A cooperative process is the abstraction a complex business process involving different organizations;
each organizations cooperate with the others by offering services. The cooperative process is supported
by some applications that coordinate the services, through automated interfaces to be exported by the
organizations, that shield internal details.
In such a way, different administrations are loosely coupled, and each of them can reengineer its
own processes without impacting on the cooperative process and related applications; later, when
Page 124
the internal processes have been improved and there are possibilities
turn the cooperative process will be impacted and modified, thus
substantial improvements. The envisioned approach is therefore
improvement, and uses new technologies initially for automating and
services, then for supporting more radical changes.
of offering new services, in
obtaining global and more
based on the continuous
exchanging information and
4.2.3 The Cooperative Architecture
The Nationwide Public Administration Network is the network infrastructure enabling the
development of cooperative applications among administrations. Its architecture consists of three
layers, as shown in Figure 4.3, offering Transport Services, Basic Services and Cooperative
Services.
Customers
Italian Public Administration Processes
human-centered
automation
Nationwide CIS
CIS of
Area 1
CIS of
Area 2
CIS of
Area N
Basic service layer
Figure 4.3: The Architecture of the Nationwide PA Network
The Transport and Basic Service layers, which are currently deployed, offer the technological
infrastructure that allows the interconnection of different administrations. They are based on
standard Internet and Web protocols, thus making the Nationwide PA Network the “secure Internet”
of the Italian PA as a whole.
The term Cooperative Architecture refers to the distributed computing model on which the
development and deployment of all new cooperative applications among administrations will be
based. Some basic principles of the Cooperative Architecture (to be described in the following
subsections) have already been applied in the various CIS's of Area developed so far.
The Cooperative Service layer will offer the set of technologies, application protocols and services
(e.g., repositories, gateways, cooperative process managers, etc.) enabling the effective cooperation
among administrations. The design for this layer has not yet been completed, as different projects
Page 125
are validating and experimenting with different solutions. As current technological trends are
moving towards the merging of different technologies in an overall Web infrastructure, it is possible
that the Cooperative Service layer will overlap with the Basic Service layer. The Nationwide CIS
will be developed on top of the Cooperative Service layer based on the Cooperative Architecture.
4.2.3.1 Domains and Cooperative Gateways
The basic principle underlying the Cooperative Architecture is the one of domain. A domain
includes all of the computing resources, networks, applications and data that belong to a specific
administration, regardless of the technical nature of the information system.
Each domain is modeled as a single entity, regardless of its internal complexity, and is connected to
the Nationwide PA Network through the domain cooperative gateway, that exports the set of data
and application services offered by the domain through cooperative interfaces. The interfaces may
be designed according to different paradigms and modeling approaches and deployed through
various technologies.
The application components that export the cooperative interfaces through the different cooperative
gateways of the various administrations are the basic building blocks for the development of the
different CIS's (both of Area and Nationwide). New applications among administrations are built by
suitably assembling such components. Even if implementation details are very different in the
various projects, CIS's of Area consist of the different components hosted on the cooperative
gateways and of the “glue” applications necessary to integrate and coordinate such components.
4.2.3.2 Types of Cooperative Systems
In order to compare the different CIS's of Area that have been designed so far, in this subsection and
in the following one some classification criteria are introduced; the criteria introduced in this section
concern the type of interaction that a system can support, whereas the criteria of Section 4.2.3.3
concern the methodological approach that has been adopted in designing the system.
Cooperative systems can be classified into Administration-to-Administration (A2A) and
Administration-to-User (A2U); A2U systems are targeted towards customers (e.g. citizens, private
companies, non-profit organizations, etc.), whereas A2A systems are targeted towards operators
either of the same administration or of different ones.
A further classification can be made between human-centered-automation systems and applicationcentered-automation systems. The former type of systems require significant human intervention for
realizing the activities supported by the systems; whereas the latter type of systems operate
completely at the application level, requiring only a trigger from a human user. In order to further
clarify the differences between the two categories, the reader should consider the following
examples:
Example 1: Some administrations make their information accessible through web sites. Suppose an
operator of another administration then accesses these web sites during the execution of an
administrative activity, possibly “cutting\&pasting” data from different web pages into
others. The exposition of information through web sites is a human-centered-automation
system: operator intervention, acting as the ``glue'' for the different pages, is crucial in this
type of systems.
Page 126
Example 2: Some administrations make their information accessible as application components on
their cooperative gateways. Suppose another administration develops a workflow application
that supports the operator. In such a case, the different components are application-centeredautomation systems. The new workflow application is a cooperative application that needs
only to be triggered by the operator.
Both types of systems enable cooperative processes, with different degrees of support (higher in the
application-centered-automation case, lower in the human-centered-auto\-ma\-tion one), different
costs and need of coordination among administrations (higher in the application-centeredautomation case, lower in the human-centered-automation one).
4.2.3.3 Approaches to Cooperation
The design of CIS's of Area has been carried out through different approaches, which has been
classified as (i) workflow-based, (ii) lagging consistency-based and (iii) publish-based.
Workflow-based. The different cooperative components of the cooperative gateways export data
and application services necessary to carry out specific macro-processes. This approach
requires a strict agreement on technologies, schemas, etc. to be adopted for the cooperative
components by all the involved administrations.
Workflow-based cooperation is suitable when there is a clearly defined macro-process, and a
strong commitment (e.g., a new law) imposes the development of the cooperative system. In
a few cases, this approach has been also adopted by autonomous administrations, which
agree and develop the cooperative system for their own common benefit (e.g., expense
reduction). The components developed by each administration are targeted towards the
specific process-based application.
Lagging consistency-based. Cooperative components asynchronously notify updates to other
administrations; when an update is performed in an administration (e.g., the change of
address of a citizen that produces a change of data in the information system of the City
Council the citizen resides in), an update notification is sent to some other administrations
(e.g., the Department of Finance and the Department of Justice), as required by laws and
regulations. In such a way, a weak consistency of data spread over the cooperating
administrations is guaranteed.
The cooperation concerns only update notifications, not the coordination and the
synchronization of internal workflows with the external ones (as in the workflow-based
approach). The focus is therefore on the knowledge of events in opposition to their direct
control. Each administration remains autonomous, and the cooperative system manages the
propagation of updates; such update notifications can be propagated using different
architectures, including:
Publish\&Subscribe architecture: events are produced by publishers and received by
subscribers; a decoupling element able to route events is interposed among them; it is
referred to as Event Manager. In this way the subscribers do not tie themselves
Page 127
directly to the publishers, but to the Event Manager, which receives events from
publishers and in turn route them to subscribers; routing of events can be based either
on a classification of events according to a set of subjects, also known as groups,
channels, or topics (subject-based system), or on the content of published events
(content-based system); in the latter case an event has a schema (e.g., it can be
modeled as a tuple with attributes) and a subscription is a predicate over these
attribute .
By adopting such an architecture, administrations need to agree on (i) the schema of
the events (or on their subject-based classification), (ii) the languages/technologies to
be adopted both for event descriptions (e.g., XML) and (iii) the communication
infrastructure (message oriented middleware, distributed object middleware, etc.).
Access Key Warehouse architecture: a database of identifiers acts as an index of data
locations and access paths; this index enables the cooperative system to control the
dissemination of updates from sources to other databases distributed among different
administrations, by correlating data identifiers. Administrations have to agree on the
identifiers to be used.
Publish-based. Cooperative components are autonomously developed by an administration mainly
to export data and application services which might be interesting to some other subjects
(administrations or customers). Any coordination among administration is not considered,
nor specific applications to be supported.
Publish-based cooperation typically leverages the huge amount of data and application
services owned by a leader administration (e.g., the Department of Justice), which
autonomously decides to develop and export components. Generally, application services
offered by components allow only query access to the data exported by the administration.
The vision supporting this approach is that each administration, in a bottom-up fashion, will
be able to export, in successive iterations, more and more of its data and application services
by following some guidelines and common cooperative patterns. In turn, other
administrations will develop new applications or processes (not yet considered) by using
such application services. The availability of data and application services is the trigger for
new cooperative applications.
Experience shows that the publish-based cooperation approach is possible through an
autonomous initiative of an administration, which then becomes a leader administration. The
leadership of the exporting administration is required in order to have a critical mass of data
and application services enabling the exposition and the bottom-up adhesion of other minor
administrations to the initiative. In such a case, the development process of the components
inside the administration is not based only on user requirements (there are not clearly
identified users whose needs must be modeled as use cases), but on a bottom-up analysis of
its own data and application services. Moreover, reuse-oriented and “pluggability”-oriented
engineering methodologies for such components are crucial, as possibly new interadministration applications, yet to be designed, will be based on them. These issues may
imply high costs and risks of this approach.
Page 128
4.2.4 Cooperative Projects
In the context of the Italian e-Government initiative, during the years 1998 through 2001 several
pilot projects in different areas (e.g., territorial and cadastral systems, services to enterprises, etc.)
have been designed and developed, in order to experiment and validate different technologies,
architectures and approaches to cooperation; their aim has been to develop some CIS's of Area (i.e.,
cooperative information systems for specific areas). These projects are briefly outlined in Table 4.1.
All projects are based on the concepts of domain and cooperative gateway, but they have adopted
different approaches to cooperation, different technologies and types of target applications. In Table
4.1, each project is described along with its target CIS, typical project data (length, start date and
current phase), the adopted approach to cooperation (see Section 4.2.3.2) the interaction type of the
target applications (see Section 4.2.3.3) and some technological details.
Specifically, the technologies that have been evaluated in the cooperative projects are OMG
Common Object Request Broker Architecture (CORBA), SUN Enterprise JavaBeans (EJB),
Message Oriented Middleware and SUN Java Message Service (JMS), Microsoft Component Object
Projects
and
Features
Arconet
Project
Target
Prototype of
the
Cooperative
Gateway of
the Italian
Social
Security
Service
Start Date
SICAP
Internal CIS
and
Cooperative
Gateway of
the
Department of
Justice
WebArch
RAE
e-Payment
Order
SICC
SIM
SAIA
Document
register and
workflow
management
of the
Prefectures
CIS for the
notification of
events related
to enterprise
CIS for the
management
of employees
and suppliers
payment
orders
CIS for
cadastral data
exchange
among Italian
City Councils,
Deparment of
Finance,
Notaries and
Certified Land
Surveyors
CIS for data
exchange
among
Central
Administratio
n, Mountain
Communities,
Mountain City
Councils and
other local
administration
s located in
mountain
territory
CIS for access
and
interchange of
citizen data
among Italian
City Councils
and Central
Administratio
ns
Summer 1998 Spring 1998
(1st
prototype),
Summer 1999
(2nd prototype)
Late 1998
Autumn 2000
Spring 2000
1998
1998
1999
Length
10 months (1st
prototype), 8
months (2nd
prototype)
2 years
Less than 1
year
Expected 1
year
2 years
Over 1 year
2 years
Over 2 years
Current
Phase
Both
prototype are
ended off;
both did never
enter into
production
1st release
ended off; 2nd
release in the
implementatio
n phase
Operative
Implementation
Preliminary
Prototyping
Operative
Operative
Design and
Experimentati
on phase
Cooperation
type
Publish based
Publish based
Publish based
Workflow
based and
Publish based
Workflow
based
Lagging
consistency
based
Lagging
consistency
based
Workflow
based,
Pusblish
based and
Lagging
consistency
based
Page 129
Projects
and
Features
Interaction
Type
Arconet
A2A,
application
centered
automation
Architectures CORBA and
DCOM (1st
and
Technologies prototype),
EJB and
COM+ (2nd
prototype)
SICAP
WebArch
RAE
e-Payment
Order
SICC
SIM
SAIA
A2A,
application
centerd
automation
A2A,
application
centerd
automation
A2A and
A2U,
application
centered
automation
and human
centered
automation
A2A,
application
centered
automation
A2A and
A2U,
application
centered
automation
A2A and
A2U,
application
centered
automation
A2A and
A2U,
application
centered
automation
CORBA
CORBA
XML, EJB,
Message
Oriented
Middleware
and JMS,
Publish &
Subscribe
architecture
Traditional
technologies
(message
switching, file
transfer) and
proprietary
cooperative
gateway
AKW, Web
technologies,
TCP/IP,
socket
AKW, Web
technologies,
message
queuing with
dynamic
queues and
JMS
AKW, Web
technologies
and XML,
message
queuing with
dynamic
queues and
JMS
Table 4.1: Brief description of cooperative projects
Model (COM), traditional technologies (e.g., file transfer, message switching) and Web technologies
(e.g., servlets, script server pages, HTML/HTTP, XML) (see Chapter 2 for details).
The comparison shows that older projects, i.e., Arconet, SICAP and Web\-Arch, have chosen a
publish-based approach, by realizing components of specific administrations to be offered on their
cooperative gateways; they have not dealt with the development of a complete system and the
coordination of such components. Their failure rate is higher than the one of projects using different
approaches (e.g., Arconet failed and SICAP is out of its project time schedule); this is due to the
difficulties of a development process in which it is not clear which are the clients of the components,
and to the issue of integrating different components developed independently without a common
agreement (schemas, common semantics, agreed technologies, etc.). However these projects have
been using novel technologies, e.g., distributed object middleware, and therefore they have been
very useful for experimentation purposes.
Some other projects, i.e., SICC and SIM, have adopted a lagging consistency-based approach and
consolidated backbone technologies (message oriented middleware) with specific bridges for the
Web; their success rate is very high, as a consequence of the adopted approach.
Finally, RAE, SAIA and e-Payment Order are currently the most wide projects undertaken in the
context of the e-Government initiative; their objectives are ambitious, as they aim at automating
critical cooperative processes of the Italian PA. The technologies which are being used are quite
consolidated, especially in the case of e-Payment Order, which is the most critical in term of
involved organizations and mission-critical process.
4.2.5 Discussion
The experience gained so far in the Italian e-Government initiative allows to draw some
considerations regarding the development of service-based cooperative information systems.
Organizational Unit. The CIS's of Area developed in Italy during the years 1998 through 2001
have been designed with poor inter-project coordination, leading to different cooperation
approaches and adopted technologies, as pointed out in Table 4.1.
Page 130
On one hand, this lack of coordination has been partially helpful by allowing the
experimentation of different solutions and, therefore, a critical mass of experiences. On the
other hand, any specific organizational unit driving and controlling the cooperation has not
yet been established. This produced some issues regarding heterogeneity of the different
CIS's of Area, and the lack of a development process to be adopted.
Recently the e-Government Action Plan has defined a strategic vision towards the overall
Nationwide Cooperative Information System, by establishing priorities, milestones and
additional funding. Among the initiative established in such a plan, the establishment of a
specific technical and organizational unit (possibly different from AIPA) has been
considered critical for the development of the Nationwide CIS.
Heterogeneous Schemas. Different systems (e.g., cooperative components exported on the
cooperative gateways) typically differ in the adopted data schemas. In a context such as the
Italian PA, all administrations have the same semantic background on the “real world” they
are working on, but this does not assure that the data exported by the cooperative
components are homogeneous with respect to their schemas. Since long time, many research
has been carried out on the schema integration issue, both in (semi-)automatic and manual
way. However, after solving schema integration issues, data integration ones arise. CIS's of
Area and the Nationwide CIS assemble cooperative components, possibly autonomously
designed and deployed by different administrations, and need to resolve such issues.
Publish-based and lagging consistency-based approaches are critical with respect to these
issues: data schemas and event schemas exported by the cooperative components differ,
especially if any specific inter-administration unit has not been driving their definition
process, and therefore complex integration activities need to be considered when using such
components.
As an example, if we consider two projects, i.e., Arconet and SICAP; their target has been
the development of publish-based components to be exported by their cooperative gateways.
According to a publish-based approach, such components export (some portions of) the
information asset of the domain according to object oriented schemas. The exporting
schemas produced by the two projects are different, therefore cooperative applications,
acting as ``glue'' of such components, need to manage and resolve the integration of schemas
and data. However, such components are reusable in different applications.
The workflow-based approach aims at the development of specific applications supporting
specific macro-processes; thus the different components adopt the same conceptual schema,
that is the one underlying the process to be automated. But the cooperative components are
scarcely reusable.
Different Technologies. As regards the adopted technologies, from the comparison it stems that
new technologies, especially the distributed object and component-based ones, still represent
a risk, and therefore they are used in minor and not mission-critical projects; moreover they
have been coupled with not consolidated approaches. This is due to the lack of a framework
in which to unify component-based technologies with workflow-based approaches.
Page 131
Moreover, currently some issues hamper the definition of a “universal” technological
platform for the development of cooperative systems (both CIS's of Area and the Nationwide
CIS); technological platforms change very fast, and organizational and management issues,
due to the use of complex technologies in administrations with different dimensions and
abilities, are not focused enough. This impossibility of choosing a “universal” technology for
the cooperation in the Italian scenario, suggests that it is necessary to consider the
technological heterogeneity of the cooperative components exported by the single
organizations as a “strong constraint”.
On the basis of such considerations, it is possible to draw a general model, shown in Figure 4.4, for
the cooperation among administrations; such a model considers both architectural and organizational
issues.
Cooperative applications
(supporting macro/
cooperative processes)
Repository for
Cooperation
Central Unit of
Cooperation
?
Cooperative
Interfaces
implement
Cooperative
Components
Domain
Cooperative
Gateway
Organizational unit managing
cooperative interfaces,
components and gateways
(organizational interface
administration – outside)
Figure 4.5: General model of cooperation in the Italian scenario
Administrations interact through cooperative gateways, on which to deploy cooperative
components; such components offer services according to cooperative interfaces, which currently
are described with different languages (e.g., CORBA IDL, XML, simple I/O records, etc.): the
services (and the cooperative interfaces) are not described in a conceptual way, but the technologies
in which components are deployed strongly influence the service/interface description language.
Cooperative gateways, components and interfaces need to be managed by specific organizational
units inside administrations, which represent the “organizational interfaces” among administrations
(i.e., their internal structures) and the outside cooperating entities.
Some common infrastructure, consisting of (i) a repository of available services/interfaces and
components, and of (ii) a specific organizational unit which controls and coordinate the cooperative
developments, is needed to effectively support inter-organization cooperation.
Page 132
Finally cooperative applications, by assembling and coordinating components offered by different
administrations, automate macro-processes and constitute a cooperative process-based application
layer; unfortunately in the current Italian e-Government scenario, the relationships among services
offered by administrations, the common infrastructure and the cooperative application layer are not
yet defined either under the technological point of view nor under the methodological one.
The Italian e-Government initiative and the general model of cooperation constitute the starting
point for the research work presented in the next chapters. Specifically the thesis concentrates on an
approach to cooperation based on cooperative process coordination, and on the definition and
development of a framework for e-Services aiming at solving heterogeneity.
4.3 UK On Line Project
4.3.1 The Architectural Framework
ukonline.gov.uk is a strategic project in the governments Information Age Agenda. It is being
overseen by Ministers and senior officials. The Office of the e-Envoy is leading the delivery of
ukonline.gov.uk working in close partnership with public service providers, the private sector and
the Departmental Information Age Government Champions (IAGCs).
The primary objective of ukonline.gov.uk is to provide citizens with a simple, secure and fast way of
accessing a wide range of joined up government services online. ukonline.gov.uk will not replace
direct contact withpublic service providers. Instead, it offers citizenschoice in the way they access
government services.
ukonline.gov.uk is an Internet-based web-site that aggregates all government information and
services in one place. ukonline.gov.uk has been specifically designed to meet the needs of the citizen
and is expected to deliver many benefits. It is available 24 hours a day, 7 days a week, and provides
the easiest way to search for information and access services that citizens might need from
government.
ukonline.gov.uk aims to meet the government's commitment to enable electronic delivery of
government services, and to be the primary place where citizens go to get information about
government services and to transact with government online
The Government Gateway ensures that the respective roles of government departments in
providing joined up services are transparent to the end user. The Gateway provides the necessary
routing and connection services to departments for life episodes and also the security and
authentication to enable the different parts of government to conduct secure transactions with
citizens. Users of the ukonline.gov.uk need not be aware that the Gateway exists.
The initial pilot of ukonline.gov.uk went live in December 2000 at http://www.ukonline.gov.uk,
marking the beginning of a long process to provide a modern, efficient, citizen-centric government.
ukonline.gov.uk currently provides general information about the wider UK online campaign. It
brings together information and advisory services from a variety of sources to help citizens through
the following important experiences, called Life Episodes.
Information is organised in a way that helps citizens through key events such as moving house or
having a baby, when they may need to contact government. Quite often, information and services
Page 133
connected to a single 'life episode' are delivered by different government departments, and are not
available from one single place. By grouping online services linked to a particular life episode,
ukonline.gov.uk aims to make life easier and more straightforward for citizens to deal with
government. It also provides extensive search and query facilities called 'Quick find' to help citizens
navigate easily through the maze of government.
ukonline.gov.uk also gives descriptions and links to a range of government services that are
currently available to citizens and businesses. As government extends the scope of ukonline.gov.uk,
and embraces other government web-sites, descriptions and links to services and information will be
updated and extended so that citizens are informed of what's going on in government, including in
the Devolved Administrations.
Over time and with the support of the Government Gateway, ukonline.gov.uk will evolve into a
place where citizens can interact and transact with government online. This means, for instance, that
a citizen will be able to complete an application form online to access the appropriate service from
government. The range of Life Episodes will also be progressively expanded based on customer
feedback. In addition, new innovations to ukonline.gov.uk will be added as a result of partnership
with government, voluntary and private sector organisations where this has a clear benefit for the
citizen, government and the partnering organisation.
ukonline.gov.uk will be a key driver in transforming the way in which public services are organised
and delivered, and in leading the drive towards better integration of government services.
In achieving this vision, ukonline.gov.uk aims to be:
• a principal entry point for citizens to access all government information and services online
• dedicated to serving the citizen by providing easy and multi-channel access to interact with
government
• the main vehicle for coherent and relevant information and services that will enrich the
citizen experience and interaction with government
• a partner to private and public sector service providers. ukonline.gov.uk will not be the only
portal delivering government information and services
• a trustworthy environment where citizens can conduct secure transactions in confidence
• the best of its kind in the world.
The ukonline.gov.uk infrastructure will enable the coherent integration of government to join up
services to meet the needs of citizens.
At the front end, the principal point of entry is ukonline.gov.uk.
The middleware, the tier that enables government to join up in a coherent way is the Government
Gateway. This is a self-contained and immensely sophisticated piece of secure infrastructure with
intelligent routing and authentication software that supports ukonline.gov.uk and enables different
parts of government to conduct authenticated transactions with citizens. The Gateway will be
instrumental in opening up government departments and their information assets and services to the
public, private and voluntary sectors. It also supports transactions with government departments
from other government and third party portals.
The back end consists of government departments, local authorities, and other systems and rocesses
that are involved in service delivery.
Page 134
ukonline.gov.uk
Government Secure Intranet
UK Online
Citizen
Authentication, security
and routing
Government
Gateway
Inter medi ary
portals
Third party
portals
Citizen
Private
sector
portals
Other
government
portals
Departments, Devolved
Administrations, Local
Authorities, and other Public
Service Providers
Figure 4.6: ukonline.gov.uk architecture
4.3.2 Standards and protocols
Facilitating the flow of information between the public, private and voluntary sectors is critical if the
government is to meet its ambitious target to join up government and bring all services online by
2005. Inconsistency on technical compatibility need to be minimised if government is to meet the
opportunities that innovation in technology presents. Standards will facilitate enhanced
interoperability of systems and technologies within government.
The key standards for achieving interoperability and coherence across the public sector have already
been defined in the e-Government Interoperability Framework (e-GIF, described below)
Private sector portals are required to conform to these standards when wishing to connect to
government systems and services.
4.3.3 Security and trust
Security and Trust are two key issues confronting all Internet transactions, and for raising citizen
confidence in transacting with government on-line. The government is taking important steps to
ensure that all information is secure. ukonline.gov.uk uses secure Internet e-commerce techniques to
protect information sent over the Internet. A range of experts will test this continually to ensure
compliance. Both ukonline.gov.uk and the Government Gateway comply with current Data
Protection legislation. Further data security issues will be addressed as they arise. ukonline.gov.uk is
also security accredited by the Communication Electronics Security Group (CESG).
ukonline.gov.uk is currently defining a series of policies to ensure a consistent standard of security
across the Internet. These will include frameworks on topics such as, Authentication,
Confidentiality, Smartcards and Trust Services. The government is currently working closely with
TScheme, an industry organisation set up to regulate and promote the use of electronic trust
services. The government is also working on a 'Trust Charter' which will clearly set out the
relationships and rights of citizens with respect to the information held by government. Both
ukonline.gov.uk and the Government Gateway will work within this Charter.
Page 135
4.3.4 e-Government Interoperability Framework
The e-Government Interoperability Framework (e-GIF) sets out the government’s technical policies
and specifications for achieving interoperability and information systems coherence across the
public sector. The e-GIF defines the essential pre-requisites for joined-up and web enabled
government. It is a cornerstone policy in the overall e-Government strategy.
Adherence to the e-GIF specifications and policies is mandatory. They set the underlying
infrastructure, freeing up public sector organisations so that they can concentrate on serving the
customer through building value added information and services. It will be for the organisations
themselves to consider how their business processes can be changed to be more effective by taking
advantage of the opportunities provided by increased interoperability.
The main thrust of the framework is to adopt the Internet and World Wide Web specifications for all
government systems. Throughout this section use of the term "system" is taken to include its
interfaces. There is a strategic decision to adopt XML and XSL as the core standards for data
integration and management of presentational data. This includes the definition and central
provision of XML schemas for use throughout the public sector. The e-GIF also adopts
specifications that are well supported in the market place. It is a pragmatic strategy that aims to
reduce cost and risk for government systems whilst aligning them to the global Internet revolution.
The Framework also sets out policies for establishing and implementing metadata across the public
sector. The e-Government Metadata Standard will help citizens find government information and
resources more easily.
Stipulating policies and specifications in themselves is not enough. Successful implementation will
mean the provision of support, best practice guidance, toolkits and centrally agreed schemas. To
provide this, the government has launched the UK GovTalk™ web site (http://www.govtalk.gov.uk)
The e-GIF defines the minimum set of technical policies and specifications governing information
flows across government and the public sector. They cover interconnectivity, data integration,
information access and content management. This version of the e-GIF also incorporates policies
originally outlined in the e-Government Metadata Framework, published in May 2001.
These are the key policy decisions that have shaped the e-GIF:
• alignment with the Internet: the universal adoption of common specifications used on the
Internet and World Wide Web for all public sector information systems
• adoption of XML as the primary standard for data integration and presentation tools for all
public sector systems
• adoption of the browser as the key interface; all public sector information systems are to be
accessible through browser based technology; other interfaces are permitted but only in
addition to browser based ones
o the addition of metadata to government information resources
o the development and adoption of the e-GMS (e-Government Metadata Standard)
based on the international Dublin Core model
o the development and maintenance of the GCL (Government Category List)
• adherence to the e-GIF is mandated throughout the public sector.
The selection of e-GIF specifications has been driven by:
Page 136
• interoperability: only specifications that are relevant to systems interconnectivity, data
integration, information access and content management are specified;
• market support: the specifications selected are widely supported by the market, and are likely
to reduce the cost and risk of government information systems;
• scalability: specifications selected have capacity to be scaled to satisfy changed demands
made on the system, such as changes in data volumes, number of transactions or number of
users;
• openness: the specifications are documented and available to the public at large.
The e-GIF covers the exchange of information between government systems and the interactions
between:
• UK Government and citizens;
• UK Government and businesses (world wide);
• UK Government organisations;
• UK Government and other governments (UK/EC, UK/US etc).
It is recognised that compliance with the e-GIF cannot be imposed on citizens, businesses and
foreign governments, but UK Government will make it clear to all that this is their preferred method
of interface.
"UK Government" includes central government departments and their agencies, local government,
the devolved administrations as voluntary partners, and the wider public sector, e.g. nondepartmental public bodies (NDPBs) and the National Health Service.
4.4 Federal Enterprise Architecture Framework (FEAF)
In the 1996 the U.S. Federal government established the Chief Information Officers (CIO) Council
as the principal interAgency forum for improving practices in the design, modernization, use,
sharing, and performance of Agency information resources.
The CIO Council began developing the Federal Enterprise Architecture Framework in April 1998 to
promote shared development for common Federal processes, interoperability, and sharing of
information among the Agencies of the Federal Government and other Governmental entities. In
serving the strategic needs and direction of the Federal Government, the CIO Council seeks to
develop, maintain, and facilitate the implementation of the top-level enterprise architecture for the
Federal Enterprise.
The Framework consists of various approaches, models, and definitions for communicating the
overall organization and relationships of architecture components required for developing and
maintaining the Federal Enterprise Architecture. The CIO Council chose a segment architecture
approach that allows critical parts of the overall Federal Enterprise, called architectural segments, to
be developed individually, while integrating these segments into the larger Enterprise Architecture.
The Federal Enterprise Architecture would serve as a reference point to facilitate the efficient and
effective coordination of common business processes, information flows, systems, and investments
among Federal Agencies and other Governmental entities. In time, Government business processes
and systems will operate seamlessly in an enterprise architecture that provides models and standards
that identify and define the information services used throughout the Government.
Page 137
To model the Federal Architecture the CIO Council agreed to use, as a starting point, the widely
accepted National Institute of Standards and Technology (NIST) model Figure 4.7 and expand on
this foundation to meet the organizational and management needs of the Federal Enterprise
Architecture.
The NIST model had been promoted within the Federal Government as a management tool that
illustrates the interrelationship of enterprise business, Figure 4.7 information, and technology
environments. The five-layered model allows for organizing, planning, and building an integrated
set of information and information technology architectures. The five layers are defined separately
but are interrelated and interwoven.
Figure 4.7: NIST Enterprise Architecture Model
The CIO Council has adopted architecture layers similar to the NIST model for the Federal
Enterprise Architecture Framework with a slightly different concept of the Federal Enterprise that
reflects IT advancements. The Federal Enterprise Architecture is actually a strategic information
asset base that defines the business, the information necessary to operate the business, the
technologies necessary to support the business operations and transitional processes for
implementing new technologies in response to the changing needs of the business.
The Federal Enterprise Architecture vision and principles are based upon those laws that address the
importance of getting results, obtaining maximum return-on-investment and cost efficiency of
operations, providing quality information and technology, protecting privacy, maintaining secure
information, and providing service to the public.
The Federal Enterprise Architecture vision, adopted by the CIO Council, identifies what must be
done to serve the strategic needs and direction of the Federal Government. This top-level enterprise
architecture for the Federal Enterprise would serve as a reference point to facilitate the efficient and
Page 138
effective coordination of common business processes, information flows, systems, and investments
among Federal Agencies. In time, Government business processes and systems will operate
seamlessly in an enterprise architecture that provides models and standards that identify and define
the information services used throughout the Government.
The Federal Enterprise Architecture principles, adopted by the CIO Council, govern and represent
the criteria against which all potential investment and architectural decisions are weighed. These
principles comprise:
• Establishing Federal interoperability standards.
• Coordinating technology investments with the Federal business and architecture.
• Minimizing the data collection burden.
• Securing Federal information against unauthorized access.
• Taking advantage of standardization based on common functions and customers.
• Providing access to information.
• Selecting and implementing proven market technologies.
• Complying with the Act ruling Privacy Rights.
4.4.1 The Framework
The Federal Enterprise Architecture Framework is a conceptual model that begins to define a
documented and coordinated structure for cross-cutting businesses and design developments in the
Government.
FEAF is an organizing mechanism for managing the development and maintenance of architecture
descriptions, it also provides a structure for organizing Federal resources and describing and
managing Federal Enterprise Architecture activities.
FEAF articulates how the Federal Enterprise Architecture is developed and maintained through
continuingly evaluating current conditions and seeking target solutions. The Framework does not
contain architecture content, but rather, is a place-holder for the content once developed.
Eight components needed for developing and maintaining the Federal Enterprise Architecture were
identified. A decomposition or drill-down process was performed on each component to achieve a
further granularity of detail. The drill-down process resulted in a four-level Federal Enterprise
Architecture Framework. Each level provides an understanding or frame of reference for the next.
The first three levels, illustrate the progression of the eight increasingly detailed components leading
to a logical structure for classifying and organizing the descriptive representations of the Federal
Enterprise in level IV.
4.4.1.1 Level I
Level I is the highest level of the Federal Enterprise Architecture Framework and introduces the
eight components needed for developing and maintaining the Federal Enterprise Architecture.
Architecture Drivers is the sole component external to the Framework, the other seven are internal.
As shown in Figure 4.8, the flow of the Framework is from left to right and represents the
continuous process of the Federal Enterprise Architecture.
At this level Architecture Drivers represents external stimuli that cause the Federal Enterprise
Architecture to change; Strategic Direction ensures that changes are consistent with the overall
Federal direction; Current Architecture represents the current state of the enterprise, full
Page 139
characterization may be significantly beyond its worth and maintenance; Target Architecture
represents the target state for the enterprise within the context of the strategic direction;
Transitional Processes apply the changes from the current architecture to the target architecture in
compliance with the architecture standards, such as various decision making or governance
procedures, migration planning, budgeting, and configuration management and engineering change
control; Architectural Segments focus on a subset or a smaller enterprise within the total Federal
Enterprise; Architectural Models provide the documentation and the basis for managing and
implementing changes in the Federal Enterprise. Finally Standards include standards, voluntary
guidelines and best practices, all of which focus on promoting interoperability.
Figure 4.8: Federal Enterprise Architecture Framewrok, Level I
4.4.1.2 Level II
Level II (Figure 4.9) shows, at a greater level of detail, the business and design pieces of the Federal
Enterprise Architecture and how they are related. Viewed horizontally, the top half of the
Framework deals with the business of the enterprise, while the bottom half deals with the design
architectures used to support the business. The relationship of business and designs is push/pull
where the business pushes design and design (i.e., new developments in data, applications, and
technology) pulls business to new levels of service delivery in support of business operations.
Examples of design drivers are the Internet and electronic access to services by the public, creating
challenges for the design to support the business mission.
Page 140
Figure 4.9: Federal Enterprise Architecture Framewrok, Level II
At this level Architecture Drivers are split in two types:
• Business Drivers redefining core Federal business needs. For example, the need for public
access, laws requiring electronic access or use of electronic signature, and the various reinvention of Government activities.
• Design Drivers representing revolutionary ways of meeting Federal business needs. For
example, the Internet.
The two parts of the Current Architecture consist in:
• Current Business Architecture defining the current business needs being met by the current
design, i.e. the business functions and capabilities now in place.
• Current Design Architectures defining the currently implemented or "as built" data,
applications, and technologies used to support the current business needs, i.e. the data
structures, applications, and supporting technology in place that meet some or all of the
business needs.
The two parts of the Target Architecture consist in:
• Target Business Architecture defining the future business needs of the enterprise to be
addressed through new or future designs, i.e. the new or altered processes required by the
business.
• Target Design Architectures defining the future data, applications, and technology to be
used to support the future business needs, i.e. the new or “to-be-built” data structures,
applications, or supporting technology required to meet the above functionality or future
support needs.
Architectural Models representing the basis for managing and implementing changes in the Federal
Enterprise. They are the artifacts that describe, using appropriate notations, the detail specifications
from which the applications and technology will be designed and implemented or purchased and
installed.
• Business Models modeling the emerging business needs prompted by the business drivers
and involving a common set of definitions, diagrams, and, sometimes, automated tools that
facilitate understanding of business functions, information inputs, processes, and products.
Page 141
• Design Models modeling the data, applications, and technology required to support the
emerging business needs, including diagrams, specifications, and technical drawings to aid in
understanding data structures, applications, and supporting technologies.
Architectural Segments consisting of focused architecture efforts, such as a common
administrative systems architecture or major Federal business areas (such as trade or grants), and
representing a specific enterprise within the overall Federal Enterprise Architecture. Each
architecture segment is composed of a current and target architecture, limited in scope by the focus
of the segment.
Strategic Direction incorporating the vision, a succinct and strategic statement describing the
targeted end state for the architecture, principles for guiding the architecture evolution, and goals
and objectives for managing it and determining progress towards the vision.
Level II further elaborates on the transitional processes (e.g., configuration management and
engineering change control) that apply the changes from the current architecture to the target
architecture in adherence to or compliance with the architecture standards. The standards may
include mandatory standards, voluntary guidelines, and best practices that promote interoperability.
4.4.1.3 Level III
Level III (Figure 4.10) expands the design pieces of the framework to show the three design
architectures: data, applications, and technology.
Figure 4.10: Federal Enterprise Architecture Framewrok, Level III
Current Design Architectures represents the currently implemented designs used to support the
current business needs and consists of the following three architectures:
• Current Data Architecture defining what data is in place to support the business (i.e., data
models).
• Current Application Architecture defining which applications are in place to manage the
data and support the business functions (i.e., application models).
• Current Technology Architecture defining what supporting technology is in place to
provide an environment for applications that manage the data and support the business
functions (i.e., technology models).
Page 142
Target Design Architectures represents the future designs to be used to support the future business
needs and consisting of the following three architectures.
• Target Data Architecture defining the data needed to support the business (i.e., data
models).
• Target Applications Architecture defining the applications needed to manage the data and
support the business functions (i.e., applications models).
• Target Technology Architecture defining the supporting technology needed to provide an
environment for applications that manage the data and support the business functions (i.e.,
technology models).
Design Models consists of three types of models used to define the enterprise.
• Data Models defining the enterprise.
• Application Models defining the applications that control the data.
• Technology Models defining the current and target technology.
Each Architectural Segment represents a major business area of the overall Federal Enterprise. A
segment is selected and defined in accordance with the Framework and its architecture information
and models are loaded into the Federal Enterprise Architecture Repository. A segment can be
considered to be an event-driven process (such as grants) that crosses the Federal Enterprise and
possesses sufficient return-on-investment (ROI) to be considered for inclusion in the Federal
Enterprise Architecture.
Transitional Processes represent the processes that support the migration from the current
architecture to the target architecture. Examples include the following:
• Capital IT Investment Planning and Decision Making qualifying investments to be budgeted
based on funding projections, ROI, cost benefits, and other criteria.
• Investment Management Review providing architecture information to support the
investment review decision process.
• Segment Coordination coordinating the integration of the segment architectures into the
Federal Enterprise Architecture. Configuration management and engineering change control
processes must be in place.
• Market Research performing a periodic market scan to analyze and identify new and
advancing technologies with potential benefits to business processes not previously available
or are more efficient/cost effective.
• Asset Management managing all Federal Enterprise Architecture-based infrastructure assets.
• Procurement Practices aligning procurement activities with the architecture and other
transitional processes.
• Architecture Governance coordinating the effort to avoid confusion, gross misunderstanding,
and rework.
• Standards represent all standards (some of which may be made mandatory), guidelines, and
best practices. Some standards may be proven, while others are evolving. This component
also includes configuration options for implementing the standards. Examples include the
following:
• Security Standards applying to all levels of security from routine to classified.
• Data Standards applying to data, meta data, and related structures.
• Applications Standards applying to application software.
• Technology Standards applying to the operating systems and platforms.
Page 143
4.4.1.4 Level IV
Level IV identifies the kinds of models that describe the business architecture and the three design
architectures: data, applications, and technology; it also defines enterprise architecture planning. The
transitions from the general to a more specific set of methods and approaches is supported by two
worldwide accepted methodologies: the Framework for Information System Architecture by John
Zachman (Zachman Framework) and the Enterprise Architecture Planning by Steven Spewak
(EAP).
As it applies to enterprise, the Zachman Framework (Figure 4.11) is a logical structure for
classifying and organizing the descriptive representations (i.e., models) that are significant to the
enterprise’s management and the development of its systems.
The rows of the Zachman Framework represent different perspectives, which may be used to view a
business (i.e., Planner, Owner, Designer, Builder, and Subcontractor views). The columns represent
the product abstractions or the focus (i.e., Entities = what, Activities = how, Locations = where,
People = who, Time = when, and Motivation = why).
The Zachman Framework is a comprehensive, logical structure for descriptive representations (i.e.,
models) of any complex objects. It is neutral with regard to specific processes or tools used for
producing the descriptions. The Framework, as applied to enterprises, is helpful for sorting out
complicated technology and methodology choices and issues that are significant to general and
technology management and identifying the kinds of models for a given project.
Figure 4.11: The Zackman Framework
Besides the Enterprise Architecture Planning (EAP) methodology is the process of defining
architectures for the use of information in support of the business and the plan for implementing
those architectures. EAP represents how to approach for creating the top two rows of the Zachman
Framework, Planner and Owner (Figure 4.12). It focuses on defining what data, applications, and
technology architectures are appropriate for and support the overall enterprise.
Page 144
Figure 4.12: Components of EAP
At level IV the Federal Enterprise Architecture Framework uses the methodologies described above
incorporating the five perspective rows (i.e., views) and the first three architectural artifacts or
product abstraction columns of the Zachman Framework (Table 4.2).
Page 145
Perspectives
Planner
(scope)
Owner
(enterprise)
Designer
(information
Systems)
Builder
(technology)
Subcontractor
(detailed
specifications)
Data
Architecture
(entities = what)
List of Business Objects
A list of objects (or things, or assets) in
which the enterprise is interested. The
list is a fairly high level of aggregation.
The model defines the scope, or
boundaries, of the models of objects
significant to the enterprise (i.e., the
rows beneath it).
Semantic Model
A model of the actual enterprise objects
(i.e., things, assets) that are significant
to the enterprise. Typically, the
semantic model would be represented
as an entity/relationship model and
would be at a level of definition
expressing concepts (i.e., terms and
facts) used in the significant business
objectives/strategies that would later be
implemented as business rules.
Logical Data Model
A model of the logical representation of
the objects of the enterprise about
which it records information, in either
automated or nonautomated form. It
would be represented as a fully
attributed, keyed, normalized entity
relationship model reflecting the intent
of the semantic model.
Physical Data Model
A technology constrained, or physical
representation of the objects of the
enterprise. The representation style of
this model would depend on the
technology chosen for implementation.
If relational technology is chosen, this
would be a model of the table structure
required to support the logical data
model in a relationalstyle model. In an
object-oriented notation, this would be
a classhierarchy/association style
model.
Data Definition
“Library or Encyclopedia”
The definition of all the data objects
specified by the physical data model
and would include all the data
definition language required for
implementation.
Application
Architecture
(activities = how)
List of Business Processes
A list of processes or functions that the
enterprise performs, or the
transformation of enterprise inputs into
outputs. The list is a fairly high level of
aggregation. The model defines the
scope, or boundaries, of the models of
processes the enterprise performs (i.e.,
the rows beneath it).
Business Process Model
A model of the actual business
processes that the enterprise performs,
independent of any system or
implementation considerations and
organizational constraints. It can be
represented as a structured methodsstyle model expressing the business
transformations (processes) and their
inputs and outputs.
Technology
Architecture
(locations = where)
List of Business Locations
A list of locations in which the
enterprise operates. The list is a fairly
high level of aggregation. The model
defines the scope, or boundaries, of the
models of locations that are connected
by the enterprise (i.e., the rows beneath
it).
Application Architecture
A model of the logical systems
implementation (manual and/or
automated) supporting the business
processes. It expresses the human and
machine boundaries. The model could
include the controls and mechanisms, as
well as the inputs and outputs to the
logical systems representations of the
system functions/processes.
Systems Design
Technically, this would not be
considered a model but a design. At a
high level of abstraction, it would be a
structure chart and in its detail, action
diagram-style expressions that would
constitute the implementation of the
logical systems, or application
architecture. In object-oriented notation,
this would be the methods and their
realization.
System Geographic Deployment
Architecture
A logical model of the system
implementation of the business logistics
system depicting the types of systems
facilities and controlling software at the
nodes and lines e.g.,
processors/operating systems, storage
devices/DBMS, peripherals/drivers,
lines/line operation systems, etc.).
Technology Architecture
The physical depiction of the
technology environment for the
enterprise showing the actual hardware
and systems software at the nodes and
the lines and their systems software,
including operation systems and
middleware.
Business Logistics System
A model of the locations of the
enterprise and their connections (i.e.,
voice, data, post or truck, rail, ship,
etc.). It would include identification of
the types of facilities at the nodes like
branches, headquarters, warehouses,
etc.
Programs
Network Architecture
“Supporting Software Components (i.e., The specific definition of the node
Operating Systems)”
addresses and the line identification.
The programs derived from the action
diagramstyle or object-style
specifications for the implementation.
Given the appropriate engineering
design, these could become the
prefabricated components that could be
assembled into more than one
implementation.
Table 4.2: FEAF Models
Each row represents a total view of the solution from a particular perspective.
Each perspective must take into account the requirements of the other perspectives and the restraint
those perspectives impose. The constraints of each perspective are additive. For example, the
constraints of higher rows affect the rows below. The constraints of lower rows can, but do not
necessarily affect the higher rows. Understanding the requirements and constraints necessitates
communication of knowledge and understanding from perspective to perspective. The Framework
points the vertical direction for that communication between perspectives.
Page 146
Each column represents a different focus or product abstraction (i.e., Entities = what, Activities =
how, Locations = where) of these perspectives. Each focus asks a question. The way in which the
questions are answered depends heavily upon the perspective. Put another way, the perspective
necessitates the form and details required to make each answer explicit and understood. The success
of the Federal Enterprise Architecture depends on managing (enforcing) the development process
and implementing the architecture descriptions. Business rules must be enforced consistently from
implementation to implementation to coordinate and/or change behavior throughout the enterprise.
Models must be defined logically, independent of technology constraints, such that the
implementation technology can be changed with minimum disruption and cost. Change must be
incorporated as a design and management criteria, such that any aspect of the enterprise can be
maintained relevant in a dynamic environment.
The kinds of models or architectural descriptive representations are made explicit at the intersections
of the rows and columns. An intersection is referred to as a cell. As a cell is created by the
intersection of a perspective and a focus, each is distinctive and unique and its contents are
normalized and explicit per the perspective’s focus. Since the product development (i.e.,
architectural artifact) in each cell or the problem solution embodied by the cell is the answer to a
question from a perspective, typically, the models or descriptions are higher-level depictions or the
surface answers of the cell. The refined models or designs supporting that answer are the detailed
descriptions within the cell. Decomposition (i.e., drill down to greater levels of detail) takes place
within each cell.
The integration of all cell models in one row constitutes a complete architecture from the
perspective of that row. The solution (or proposed development) from that perspective is complete;
however, this does not mean the problem is solved or that the project is fully developed. A complete
solution of a problem or its complete development can only be viewed as complete when the
composite of all cells within the Framework are made explicit, as a whole. Complete models or
architectures, being different relative to perspective and focus, are also additive and complementary.
It would be optimal to have all models enterprisewide, horizontally and vertically integrated at an
excruciating level of detail. For the Federal Enterprise, this is not possible or feasible. As a segment
architecture description is developed, certain cells might not be developed because of determinate
constraints (e.g., time to complete the cell or devaluation of the contents of the cell).The incremental
and continuous further evolution of the Federal Enterprise Architecture will decrease overall risk
because cells will be made increasingly explicit over time. The adverse effect of making
assumptions can be minimal or overpowering. The challenge for every Federal segment is to
determine which cells (models) should be made explicit in support of the critical changing aspects of
the enterprise and assume the risk of leaving the rest of the cells implicit.
The kinds of models contained in the first two rows (i.e., Planner, Owner) of Table 4.2 define the
business architecture of the Federal Enterprise. These kinds of models are considered essential and
must be completed to develop a segment architecture description that can be commonly understood
and integrated within and across the Federal Enterprise. The business requirements must be
recognizable in the end product, and these kinds of business models must be developed by all
architecture segments. The models contained in the third, fourth, and fifth rows (i.e., Designer,
Builder, Subcontractor) define the design architectures (i.e., data, applications, and technology) and
support the business architecture. Appropriate models from these rows are developed depending on
the purpose and objectives of the specific architecture segment effort.
Page 147
Defined models are the basis for managing and implementing change in the enterprise in a timely
manner. The Framework provides a logical structure for classifying and organizing the kinds of
enterprise models that are significant to segment management and to the development of the
supporting systems.
The success of the Federal Enterprise Architecture depends on managing (enforcing) the
development process and implementing the architecture descriptions. Business rules must be
enforced consistently from implementation to implementation to coordinate and/or change behavior
throughout the enterprise. Models must be defined logically, independent of technology constraints,
such that the implementation technology can be changed with minimum disruption and cost. Change
must be incorporated as a design and management criteria, such that any aspect of the enterprise can
be maintained relevant in a dynamic environment.
4.5 Other countries
The state of the Electronic Service Delivery in the various industrializes countries is varied and in
continuous change.
In Figure 4.13 some of these countries are examine in greater detail, analysing the stage of
Electronic Services Delivery in which they are positioned. The selected countries are related thought
some fundamental functional areas, such as: (i) on-line professional training and employment; (ii)
health;(iii) e-Procurement; (iv) e-services for the enterprises; (v) social security; (vi) taxation ; (vii)
motor vehicles and driver's licenses.
Referring to the classification introduced by the ANAO no country, except Australia, Canada,
Singapore and USA, all restricted to the e-Procurement, is currently positioned into stage 4
(cooperative). For what concerns employment, the more advanced countries are positioned into
stage 3; analogous level of maturity is reached in initiatives of e-Government, social security,
taxation, motor vehicles and driving license; in the field of the health, instead, the greater part of the
countries is still positioned into stage 1.
Focusing on the e-services for the enterprises, that will be the driven test in the feasibility study of
the EUPUBLI.COM project, the more advanced countries are positioned into stage 2 or stage 3;
among them United Kingdom, Australia and Canada.
In the United Kingdom the Department of Trade and Business (DTI) is the principal body providing
services to enterprises. It is involved in more than 30 macro-processes that are planned to be fully
automated within the year 2005. Currently an enterprise can access information through several
web sites and submit its fiscal forms through software ad hoc. A further migration to web-based
services (stage 2-3) is currently in under deployment.
In Australia the portal Business Entry Point (BEP, www.business.gov.au) is accessible since 1998. It
provides legislative information as well as support to start a new business through the access of a
wide database and several transaction services (stage 2-3) interconnected with the Australian
Taxation Office, the Department of Transport and Regional Services and local agencies. Through
the BEP an enterprise can request a unique number (Number of Goods and Service Tax) that can be
used in all the fiscal transaction.
Page 148
In Canada an enterprise can have access to information and submit forms on-line through a portal
(www.strategic.gs.ca) (stage 2). Moreover some specific services such as the release of licenses
have been automated through transactional activities. (stage 3 for these services).
For what concerns European countries, also in France, Netherlands and Sweden initiatives to
provide on-line forms submission have been developed (stage 2-3). These initiatives have shown
that a great attention must be paid in the development of digital signature and certification authority
infrastructures.
Summarizing the initiative to support enterprise are currently restricted in providing information online and in few cases in transactional activities while no cooperative services have been deployed.
In a global perspective figure shows that the more advanced countries in supporting e-Government
are USA, Australia and Canada offering transactional services in several functional areas. For what
concerns Europe the more advanced countries is Sweden positioned into stage 3 for Employment
and into stage 2 for e-Procurement and Enterprise; besides other countries such as Japan and the
european Germany and Ireland are still positioned into stage 0 in all the functional areas depicted.
Page 149
Employment
Health
eProcurement
Enterprise
4
Social Security
Taxation
Driver's license
3
2
Driver's license
Taxation
Social Security
Enterprise
eProcurement
Health
Employment
USA
UK
Sweden
Singapore
Netherlands
Japan
Ireland
Germany
France
Finland
Canada
0
Australia
1
Figure 4.13: Electronic Service Delivery in the world
Page 150
4.6 References
M. Hammer. Reengineering Work: Don't Automate, Obliterate. Harvard Business Review (JulyAugust 1990), 104-112.
M. Hammer and J. Champy. Reengineering the Corporation : A Manifesto for Business Revolution.
Harper Business, 1993.
Audit Report No. 18 1999-2000 Electronic Service Delivery, including Internet use, by
Commonwealth Government Agencies
Austalian National Audit Office, homepage http://www.anao.gov.au/
[RUPA]
M. Mecella and C. Batini. Enabling Italian e-Government Through a Cooperative Architecture.
IEEE Computer 34 (2001), no. 2.
C.Batini, E.Cappadozzi, M.Mecella and M.Talamo. Cooperative Architectures:The Italian Way
Along e-Government. Published in Advances in Digital Government: Technology, Human Factors,
and Policy (Kluwer International Series on Advances in Database Systems, Adbs 26) by J. William
J., Jr. McIver, Ahmed K. Elmagarmid, 2002
M.Mecella and C.Batini. A Review of the First Cooperative Projects in the Italian e-Government
Initiative, in Proceedings of the 1st IFIP Conference on e-Business,e-Commerce, e-Government,
Zurich, Switzerland,2001
M.Mecella. Cooperative Processes and e-Services. PhD thesis, Università degli Studi di Roma "La
Sapienza", Rome, Italy. (Oct 2001),http://www.dis.uniroma1.it/~mecella/MECELLA_PhDthesis.pdf
[ukonline.gov.uk]
ukonline.gov.uk Overview,
http://www.e-envoy.gov.uk/ukonline/progress/ukonline_overview_reportv2.pdf
Ukonline.gov.uk, homepage http://www.ukonline.gov.uk
[UK GovTalk]
e-Government Interoperability Framework version 4.0 Part One:Framework and Part Two:
Technical Policies and Specifications (Apr 2002)
http://www.govtalk.gov.uk/documents/e-GIF4Pt1_2002-04-25.pdf,
http://www.govtalk.gov.uk/documents/e-GIF4Pt2_2002-04-25.pdf
UK GovTalk website, www.govtalk.gov.uk
[U.S. FEAF]
Federal Enterprise Architecture Framework version 1.1 (sept 1999),
http://www.cio.gov/Documents/fedarch1.pdf
Page 151
5 Appendix
5.1 List of Figures
Figure 1.1: A Common European Administration Space .....................................................................8
Figure 1.2: A macro-process.................................................................................................................9
Figure 1.3: EU-PUCLI.COM Showcase.............................................................................................11
Figure 1.4: Cooperative Architecture .................................................................................................12
Figure 2.1: TCP between IP and Clients.............................................................................................18
Figure 2.2: Telnet Server ....................................................................................................................19
Figure 2.3: Telnet Client .....................................................................................................................19
Figure 2.4: FTP Client and Server ......................................................................................................20
Figure 2.5: Examples of HTTP operation...........................................................................................21
Figure 2.6: Object Management Architecture ....................................................................................26
Figure 2.7: The CORBA Architecture ................................................................................................27
Figure 2.8: The CORBA IDL compiler ..............................................................................................27
Figure 2.9: Client using COM Object through an interface pointer ...................................................30
Figure 2.10: Clock COM Object.........................................................................................................31
Figure 2.11: Three methods for Accessing COM Objects..................................................................31
Figure 2.12: Creating a COM object pointer ......................................................................................32
Figure 2.13: Enterprise JavaBeans in the client and the server ..........................................................41
Figure 2.14: EJB Client/Server interaction.........................................................................................43
Figure 2.15: An example CCM Component with IDL specification..................................................45
Figure 2.16: Implementing Components using the CIDL ..................................................................47
Figure 2.17: The CORBA Component Model's Container Programming Model ..............................48
Figure 2.18: MQSeries messaging with more that one queue manager .............................................51
Figure 2.19: JMS Messaging models..................................................................................................53
Figure 2.20: The TIB/Rendezvous daemon architecture ....................................................................54
Figure 2.21: The overall architecture of a wide area TIB/Rendezvous system ..................................55
Figure 2.22: Service Oritented Architecture.......................................................................................56
Figure 2.23: WSCL activity diagram of a “Seller” Web-Service.......................................................60
Figure 2.24: UDDI (simplified) data model in UML .........................................................................61
Figure 2.25: ebXML RIM in UML (inheritance and relationship views) ..........................................63
Figure 2.26: ebXML BPSS: details concerning orchestration............................................................66
Figure 2.27: Network security model .................................................................................................68
Figure 2.28: Access security model ....................................................................................................68
Figure 2.29: Symmetric key encryption..............................................................................................69
Figure 2.30: Asymmetric key encryption ...........................................................................................70
Figure 2.31: Digital signature schema ................................................................................................71
Figure 2.32: Structure of the Authentication Header protocol ...........................................................73
Figure 2.33: Structure of the Encapsulating Security Payload protocol.............................................73
Figure 2.34: SSL handshake protocol.................................................................................................75
Figure 2.35: SAML scenario...............................................................................................................81
Figure 2.36: Packet filtering router.....................................................................................................82
Figure 2.37: Application level gateway ..............................................................................................82
Figure 2.38: Circuit level gateway......................................................................................................83
Figure 2.39: Remote access client connections ..................................................................................84
Figure 2.40: Certification Authorities structure..................................................................................87
Page 152
Figure 2.41: Kerberos message exchange...........................................................................................90
Figure 2.42: Request for service in another realm..............................................................................91
Figure 2.43: Components of Arjuna ...................................................................................................93
Figure 2.44: Overall FRIENDS system architecture ..........................................................................94
Figure 2.45: The COMERA architecture............................................................................................95
Figure 2.46: Intrusive and non-intrusive design .................................................................................96
Figure 2.47: Replication logic “below” the ORB: the Eternal system ...............................................97
Figure 2.48. Replication logic “above” the ORB: OGS and DOORS systems ..................................97
Figure 2.49. Interoperability in an heterogeneous multi ORB environment ......................................98
Figure 2.50: IRL Architecture...........................................................................................................100
Figure 2.51: A top-level view of FTS...............................................................................................101
Figure 4.1: ANAO-OGO model of service delivery by the Internet ................................................120
Figure 4.2: A macro-process for “providing aid to disabled persons” .............................................124
Figure 4.3: The Architecture of the Nationwide PA Network..........................................................125
On the basis of such considerations, it is possible to draw a general model, shown in Figure 4.4, for
the cooperation among administrations; such a model considers both architectural and
organizational issues. ................................................................................................................132
Figure 4.4: General model of cooperation in the Italian scenario.....................................................132
Figure 4.5: ukonline.gov.uk architecture ..........................................................................................135
Figure 4.6: NIST Enterprise Architecture Model .............................................................................138
Figure 4.7: Federal Enterprise Architecture Framewrok, Level I.....................................................140
Figure 4.8: Federal Enterprise Architecture Framewrok, Level II ...................................................141
Figure 4.9: Federal Enterprise Architecture Framewrok, Level III ..................................................142
Figure 4.10: The Zackman Framework ............................................................................................144
Figure 4.11: Components of EAP.....................................................................................................145
Figure 4.12: Electronic Service Delivery in the world .....................................................................150
5.2 List of Tables
Table 2.1: Comparison among fault tolerant CORBA systems........................................................102
Table 4.1: Brief description of cooperative projects.........................................................................130
Table 4.2: FEAF Models...................................................................................................................146
Page 153
INFORMATION SOCIETY TECHNOLOGIES
(IST)
PROGRAMME
EU-PUBLI.COM
Facilitating Co-operation amongst European Public Administration employees
through a Unitary European Network Architecture and the use of Interoperable
Middleware Components
D1.1 Annex
Legal Annex for Project Presentation and State of the Art
Prepared for the European Commission
under Contract No. IST-2001-35217 as a deliverable from
WP 1 – Overall Model Design and Specification
Date of issue: 31/07/2002
Table of Contents
ITALIAN LAW .............................................................................................................3
D.P.R. 445-28/12/2000 .................................................................................................................3
D.P.C.M. 08/02/1999 .................................................................................................................28
D.P.C.M. 31/10/2000 .................................................................................................................45
D.L. 10-23/01/2002.....................................................................................................................52
L. 675-31/12/1996.......................................................................................................................57
L. 241-07/08/1990.......................................................................................................................81
GREEK LAW .............................................................................................................91
2672/1998 ...................................................................................................................................91
2690/1999 ...................................................................................................................................99
2867/2000 .................................................................................................................................107
2472/1997 .................................................................................................................................123
2225/1994 .................................................................................................................................135
2774/1999 .................................................................................................................................143
150/2001 ...................................................................................................................................147
Decreto del Presidente della Repubblica 28 dicembre 2000 n. 445
Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa (S. O. alla
G. U. n. 42 del 20 febbraio 2001)
INDICE
Articolo unico
CAPO I Definizioni e ambito di applicazione
Art. 1 Definizioni
Art. 2 Oggetto
Art. 3 Soggetti
Art. 4 Impedimento alla sottoscrizione e alla dichiarazione
Art. 5 Rappresentanza legale
CAPO II Documentazione amministrativa
SEZIONE I Documenti amministrativi e atti pubblici
Art. 6 Riproduzione di documenti
Art. 7 Redazione e stesura di atti pubblici
SEZIONE II Documento informatico
Art. 8 Documento informatico
Art. 9 Documenti informatici delle pubbliche amministrazioni
Art. 10 Forma ed efficacia del documento informatico
Art. 11 Contratti stipulati con strumenti informatici o per via telematica
Art. 12 Pagamenti informatici
Art. 13 Libri e scritture
SEZIONE III Trasmissione di documenti
Art. 14 Trasmissione del documento informatico
Art. 15 Trasmissione dall’estero di atti agli uffici di stato civile
Art. 16 Riservatezza dei dati personali contenuti nei documenti trasmessi
Art. 17 Segretezza della corrispondenza trasmessa per via telematica
SEZIONE IV Copie autentiche, autenticazione di sottoscrizioni
Art. 18 Copie autentiche
Art. 19 Modalità alternative all’autenticazione di copie
Art. 20 Copie di atti e documenti informatici
Art. 21 Autenticazione delle sottoscrizioni
SEZIONE V Firma digitale
Art. 22 Definizioni
Art. 23 Firma digitale
Art. 24 Firma digitale autenticata
Art. 25 Firma di documenti informatici delle pubbliche amministrazioni
Art. 26 Deposito della chiave privata
Art. 27 Certificazione delle chiavi
Art. 28 Obblighi dell’utente e del certificatore
Art. 29 Chiavi di cifratura della pubblica amministrazione
SEZIONE VI Legalizzazione di firme e di fotografie
Art. 30 Modalità per la legalizzazione di firme
Art. 31 Atti non soggetti a legalizzazione
Art. 32 Legalizzazione di firme di capi di scuole parificate o legalmente riconosciute
Art. 33 Legalizzazione di firme di atti da e per l’estero
Art. 34 Legalizzazione di fotografie
SEZIONE VII Documenti di riconoscimento e di identità
Art. 35 Documenti di identità e di riconoscimento
Art. 36 Carta di identità e documenti elettronici
SEZIONE VIII Regime fiscale
Art. 37 Esenzioni fiscali
CAPO III Semplificazione della documentazione amministrativa
SEZIONE I Istanze e dichiarazioni da presentare alla pubblica amministrazione
Art. 38 Modalità di invio e sottoscrizione delle istanze
Art. 39 Domande per la partecipazione a concorsi pubblici
SEZIONE II Certificati
Art. 40 Certificazioni contestuali
Art. 41 Validità dei certificati
1
Art. 42 Certificati di abilitazione
SEZIONE III Acquisizione diretta di documenti.
Art. 43 Accertamenti d’ufficio
Art. 44 Acquisizione di estratti degli atti dello stato civile
SEZIONE IV Esibizione di documento
Art. 45 Documentazione mediante esibizione
SEZIONE V Norme in materia di dichiarazioni sostitutive
Art. 46 Dichiarazioni sostitutive di certificazioni
Art. 47 Dichiarazioni sostitutive dell’atto di notorietà
Art. 48 Disposizioni generali in materia di dichiarazioni sostitutive
Art. 49 Limiti di utilizzo delle misure di semplificazione
CAPO IV Sistema di gestione informatica dei documenti
SEZIONE I Disposizioni sulla gestione informatica dei documenti
Art. 50 Attuazione dei sistemi
Art. 51 Sviluppo dei sistemi informativi delle pubbliche amministrazioni
Art. 52 Il sistema di gestione informatica dei documenti
Art. 53 Registrazione di protocollo
Art. 54 Informazioni annullate o modificate
Art. 55 Segnatura di protocollo
Art. 56 Operazioni ed informazioni minime del sistema di gestione informatica dei documenti
Art. 57 Numero di protocollo
SEZIONE II Accesso ai documenti e alle informazioni del sistema
Art. 58 Funzioni di accesso ai documenti e alle informazioni del sistema
Art. 59 Accesso esterno
Art. 60 Accesso effettuato dalle pubbliche amministrazioni
SEZIONE III Tenuta e conservazione del sistema di gestione dei documenti
Art. 61 Servizio per la gestione informatica dei documenti, dei flussi documentali e degli archivi
Art. 62 Procedure di salvataggio e conservazione delle informazioni del sistema
Art. 63 Registro di emergenza
SEZIONE IV Sistema di gestione dei flussi documentali
Art. 64 Sistema di gestione dei flussi documentali
Art. 65 Requisiti del sistema per la gestione dei flussi documentali
Art. 66 Specificazione delle informazioni previste dal sistema di gestione dei flussi documentali
SEZIONE V Disposizioni sugli archivi
Art. 67 Trasferimento dei documenti all’archivio di deposito
Art. 68 Disposizioni per la conservazione degli archivi
Art. 69 Archivi storici
SEZIONE VI Attuazione ed aggiornamento dei sistemi
Art. 70 Aggiornamenti del sistema
CAPO V Controlli
Art. 71 Modalità dei controlli
Art. 72 Responsabilità dei controlli
CAPO VI Sanzioni
Art. 73 Assenza di responsabilità della pubblica amministrazione
Art. 74 Violazione dei doveri d’ufficio
Art. 75 Decadenza dai benefici
Art. 76 Norme penali
CAPO VII Disposizioni finali
Art. 77 Norme abrogate
Art. 78 Norme che rimangono in vigore
IL PRESIDENTE DELLA REPUBBLICA
VISTO l'articolo 87, comma quinto, della Costituzione;
VISTO l’articolo 7 della legge 8 marzo 1999, n. 50 come modificato dall'articolo 1, comma 6, lettera e) della legge 24
novembre 2000, n.340;
VISTO il punto 4) dell’allegato 3, della legge 8 marzo 1999, n. 50;
VISTO il decreto legislativo recante il testo unico delle disposizioni legislative in materia di documentazione
amministrativa;
VISTO il decreto del Presidente della Repubblica recante il testo unico delle disposizioni regolamentari in materia di
documentazione amministrativa;
2
VISTE le deliberazioni preliminari del Consiglio dei Ministri adottate nelle riunioni del 25 agosto 2000 e del 6 ottobre
2000;
VISTO il parere della Conferenza Stato-città, ai sensi dell’articolo 8 del decreto legislativo 28 agosto 1997 n.281,
espresso nella riunione del 14 settembre 2000;
UDITO il parere del Consiglio di Stato, espresso dalla Sezione consultiva per gli atti normativi nell’adunanza del 18
settembre 2000;
ACQUISITO il parere delle competenti Commissioni della Camera dei deputati e del Senato della Repubblica;
VISTA la deliberazione del Consiglio dei Ministri adottata nella riunione del 15 dicembre 2000;
SULLA PROPOSTA del Presidente del Consiglio dei Ministri e del Ministro per la funzione pubblica, di concerto con i
Ministri dell’interno e della giustizia;
EMANA
il seguente decreto:
CAPO I
DEFINIZIONI E AMBITO DI APPLICAZIONE
Articolo 1 (R)
Definizioni
1. Ai fini del presente testo unico si intende per:
a) DOCUMENTO AMMINISTRATIVO ogni rappresentazione, comunque formata, del contenuto di atti, anche interni,
delle pubbliche amministrazioni o, comunque, utilizzati ai fini dell'attività amministrativa. Le relative modalità di
trasmissione sono quelle indicate al capo II, sezione III del presente testo unico.
b) DOCUMENTO INFORMATICO la rappresentazione informatica di atti, fatti o dati giuridicamente rilevanti.
c) DOCUMENTO DI RICONOSCIMENTO ogni documento munito di fotografia del titolare e rilasciato, su supporto
cartaceo, magnetico o informatico, da una pubblica amministrazione italiana o di altri Stati, che consente
l’identificazione personale del titolare.
d) DOCUMENTO D’IDENTITÀ la carta di identità ed ogni altro documento munito di fotografia rilasciato, su
supporto cartaceo, magnetico o informatico, dall’amministrazione competente dello Stato italiano o di altri Stati, con la
finalità prevalente di dimostrare l’identità personale del suo titolare.
e) DOCUMENTO D’IDENTITÀ ELETTRONICO il documento analogo alla carta d’identità elettronica rilasciato dal
comune fino al compimento del quindicesimo anno di età.
f) CERTIFICATO il documento rilasciato da una amministrazione pubblica avente funzione di ricognizione,
riproduzione e partecipazione a terzi di stati, qualità personali e fatti contenuti in albi, elenchi o registri pubblici o
comunque accertati da soggetti titolari di funzioni pubbliche.
g) DICHIARAZIONE SOSTITUTIVA DI CERTIFICAZIONE il documento, sottoscritto dall’interessato, prodotto in
sostituzione dei certificati di cui alla lettera f).
h) DICHIARAZIONE SOSTITUTIVA DI ATTO DI NOTORIETA’ il documento, sottoscritto dall’interessato,
concernente stati, qualità personali e fatti, che siano a diretta conoscenza di questi, resa nelle forme previste dal presente
testo unico.
i) AUTENTICAZIONE DI SOTTOSCRIZIONE l’attestazione, da parte di un pubblico ufficiale, che la sottoscrizione è
stata apposta in sua presenza, previo accertamento dell’identità della persona che sottoscrive.
l) LEGALIZZAZIONE DI FIRMA l’attestazione ufficiale della legale qualità di chi ha apposto la propria firma sopra
atti, certificati, copie ed estratti, nonché dell’autenticità della firma stessa.
m) LEGALIZZAZIONE DI FOTOGRAFIA l’attestazione, da parte di una pubblica amministrazione competente, che
un’immagine fotografica corrisponde alla persona dell’interessato.
n) FIRMA DIGITALE il risultato della procedura informatica (validazione) basata su un sistema di chiavi asimmetriche
a coppia, una pubblica e una privata, che consente al sottoscrittore tramite la chiave privata e al destinatario tramite la
chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l’integrità di un documento
informatico o di un insieme di documenti informatici.
o) AMMINISTRAZIONI PROCEDENTI le amministrazioni e, nei rapporti con l’utenza, i gestori di pubblici servizi
che ricevono le dichiarazioni sostitutive di cui alle lettere g) e h) o provvedono agli accertamenti d’ufficio ai sensi
dell’art. 43.
p) AMMINISTRAZIONI CERTIFICANTI le amministrazioni e i gestori di pubblici servizi che detengono nei propri
archivi le informazioni e i dati contenuti nelle dichiarazioni sostitutive, o richiesti direttamente dalle amministrazioni
procedenti ai sensi degli articoli 43 e 71.
q) GESTIONE DEI DOCUMENTI l'insieme delle attività finalizzate alla registrazione di protocollo e alla
classificazione, organizzazione, assegnazione e reperimento dei documenti amministrativi formati o acquisiti dalle
amministrazioni, nell'ambito del sistema di classificazione d'archivio adottato; essa è effettuata mediante sistemi
informativi automatizzati.
3
r) SISTEMA DI GESTIONE INFORMATICA DEI DOCUMENTI l'insieme delle risorse di calcolo, degli apparati,
delle reti di comunicazione e delle procedure informatiche utilizzati dalle amministrazioni per la gestione dei
documenti.
s) SEGNATURA DI PROTOCOLLO l’apposizione o l'associazione, all'originale del documento, in forma permanente
e non modificabile delle informazioni riguardanti il documento stesso.
Articolo 2 (L)
Oggetto
1. Le norme del presente testo unico disciplinano la formazione, il rilascio, la tenuta e la conservazione, la gestione, la
trasmissione di atti e documenti da parte di organi della pubblica amministrazione; disciplinano altresì la produzione di
atti e documenti agli organi della pubblica amministrazione nonché ai gestori di pubblici servizi, nei rapporti con
l’utenza, e ai privati che vi consentono. Le norme concernenti i documenti informatici e la firma digitale, contenute nel
capo II, si applicano anche nei rapporti tra privati come previsto dall’articolo 15, comma 2 della legge 15 marzo 1997,
n. 59.
Articolo 3 (R)
Soggetti
1. Le disposizioni del presente testo unico si applicano ai cittadini italiani e dell’Unione europea, alle persone
giuridiche, alle società di persone, alle pubbliche amministrazioni e agli enti, alle associazioni e ai comitati aventi sede
legale in Italia o in uno dei Paesi dell’Unione europea. (R)
2. I cittadini di Stati non appartenenti all’Unione regolarmente soggiornanti in Italia, possono utilizzare le dichiarazioni
sostitutive di cui agli articoli 46 e 47 limitatamente agli stati, alle qualità personali e ai fatti certificabili o attestabili da
parte di soggetti pubblici italiani, fatte salve le speciali disposizioni contenute nelle leggi e nei regolamenti concernenti
la disciplina dell’immigrazione e la condizione dello straniero. (R)
3. Al di fuori dei casi previsti al comma 2, i cittadini di Stati non appartenenti all’Unione autorizzati a soggiornare nel
territorio dello Stato possono utilizzare le dichiarazioni sostitutive di cui agli articoli 46 e 47 nei casi in cui la
produzione delle stesse avvenga in applicazione di convenzioni internazionali fra l’Italia ed il Paese di provenienza del
dichiarante. (R)
4. Al di fuori dei casi di cui ai commi 2 e 3 gli stati, le qualità personali e i fatti, sono documentati mediante certificati o
attestazioni rilasciati dalla competente autorità dello Stato estero, corredati di traduzione in lingua italiana autenticata
dall’autorità consolare italiana che ne attesta la conformità all’originale, dopo aver ammonito l’interessato sulle
conseguenze penali della produzione di atti o documenti non veritieri.
Articolo 4 (R)
Impedimento alla sottoscrizione e alla dichiarazione
1. La dichiarazione di chi non sa o non può firmare è raccolta dal pubblico ufficiale previo accertamento dell’identità
del dichiarante. Il pubblico ufficiale attesta che la dichiarazione è stata a lui resa dall’interessato in presenza di un
impedimento a sottoscrivere. (R)
2. La dichiarazione nell’interesse di chi si trovi in una situazione di impedimento temporaneo, per ragioni connesse allo
stato di salute, è sostituita dalla dichiarazione, contenente espressa indicazione dell’esistenza di un impedimento, resa
dal coniuge o, in sua assenza, dai figli o, in mancanza di questi, da altro parente in linea retta o collaterale fino al terzo
grado, al pubblico ufficiale, previo accertamento dell’identità del dichiarante. (R)
3. Le disposizioni del presente articolo non si applicano in materia di dichiarazioni fiscali. (R)
Articolo 5 (L)
Rappresentanza legale
1. Se l’interessato è soggetto alla potestà dei genitori, a tutela, o a curatela, le dichiarazioni e i documenti previsti dal
presente testo unico sono sottoscritti rispettivamente dal genitore esercente la potestà dei genitori, dal tutore, o
dall’interessato stesso con l’assistenza del curatore.
4
CAPO II
DOCUMENTAZIONE AMMINISTRATIVA
SEZIONE I
DOCUMENTI AMMINISTRATIVI E ATTI PUBBLICI
Articolo 6 (L-R)
Riproduzione e conservazione di documenti
1. Le pubbliche amministrazioni ed i privati hanno facoltà di sostituire, a tutti gli effetti, i documenti dei propri archivi,
le scritture contabili, la corrispondenza e gli altri atti di cui per legge o regolamento è prescritta la conservazione, con la
corrispondente riproduzione fotografica o con altro mezzo idoneo a garantire la conformità agli originali. Con decreto
del Presidente del Consiglio dei Ministri sono stabiliti i limiti di tale facoltà, nonché le modalità tecniche della
riproduzione e dell’autenticazione. (L)
2. Gli obblighi di conservazione ed esibizione dei documenti di cui al comma 1 si intendono soddisfatti, sia ai fini
amministrativi che probatori, anche se realizzati su supporto ottico quando le procedure utilizzate sono conformi alle
regole tecniche dettate dall’Autorità per l’informatica nella pubblica amministrazione. (L)
3. I limiti e le modalità tecniche della riproduzione e dell’autenticazione dei documenti di cui al comma 1, su supporto
fotografico o con altro mezzo tecnico idoneo a garantire la conformità agli originali, sono stabiliti con decreto del
Presidente del Consiglio dei Ministri.
4. Sono fatti salvi i poteri di controllo del Ministero per i beni e le attività culturali sugli archivi delle amministrazioni
pubbliche e sugli archivi privati dichiarati di notevole interesse storico, ai sensi delle disposizioni del Capo II del
decreto legislativo 29 ottobre 1999, n. 490.
Articolo 7 (L)
Redazione e stesura di atti pubblici
1. I decreti, gli atti ricevuti dai notai, tutti gli altri atti pubblici, e le certificazioni sono redatti, anche promiscuamente,
con qualunque mezzo idoneo, atto a garantirne la conservazione nel tempo.
2. Il testo degli atti pubblici comunque redatti non deve contenere lacune, aggiunte, abbreviazioni, correzioni,
alterazioni o abrasioni. Sono ammesse abbreviazioni, acronimi, ed espressioni il lingua straniera, di uso comune.
Qualora risulti necessario apportare variazioni al testo, si provvede in modo che la precedente stesura resti leggibile.
SEZIONE II
DOCUMENTO INFORMATICO
Articolo 8 (R)
Documento informatico
1. Il documento informatico da chiunque formato, la registrazione su supporto informatico e la trasmissione con
strumenti telematici, sono validi e rilevanti a tutti gli effetti di legge, se conformi alle disposizioni del presente testo
unico.
2. Le regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la
validazione, anche temporale, dei documenti informatici sono definite con decreto del Presidente del Consiglio dei
Ministri sentite l’Autorità per l’informatica nella pubblica amministrazione e il Garante per la protezione dei dati
personali. Esse sono adeguate alle esigenze dettate dall'evoluzione delle conoscenze scientifiche e tecnologiche, con
cadenza almeno biennale.
3. Con il medesimo decreto del Presidente del Consiglio dei Ministri sono definite le misure tecniche, organizzative e
gestionali volte a garantire l'integrità, la disponibilità e la riservatezza delle informazioni contenute nel documento
informatico anche con riferimento all'eventuale uso di chiavi biometriche di cui all’articolo 22, lettera e).
4. Restano ferme le disposizioni di legge sulla tutela della riservatezza dei dati personali.
5
Articolo 9 (R)
Documenti informatici delle pubbliche amministrazioni
1. Gli atti formati con strumenti informatici, i dati e i documenti informatici delle pubbliche amministrazioni,
costituiscono informazione primaria ed originale da cui è possibile effettuare, su diversi tipi di supporto, riproduzioni e
copie per gli usi consentiti dalla legge.
2. Nelle operazioni riguardanti le attività di produzione, immissione, conservazione, riproduzione e trasmissione di dati,
documenti ed atti amministrativi con sistemi informatici e telematici, ivi compresa l'emanazione degli atti con i
medesimi sistemi, devono essere indicati e resi facilmente individuabili sia i dati relativi alle amministrazioni
interessate sia il soggetto che ha effettuato l'operazione.
3. Le pubbliche amministrazioni provvedono a definire e a rendere disponibili per via telematica moduli e formulari
elettronici validi ad ogni effetto di legge.
4. Le regole tecniche in materia di formazione e conservazione di documenti informatici delle pubbliche
amministrazioni sono definite dall'Autorità per l'informatica nella pubblica amministrazione d'intesa con
l'amministrazione degli archivi di Stato e, per il materiale classificato, con le Amministrazioni della difesa, dell’interno
e delle finanze, rispettivamente competenti.
Articolo 10 (R)
Forma ed efficacia del documento informatico
1. Il documento informatico sottoscritto con firma digitale, redatto in conformità alle regole tecniche di cui all’articolo
8, comma 2 e per le pubbliche amministrazioni, anche di quelle di cui all’articolo 9, comma 4, soddisfa il requisito
legale della forma scritta e ha efficacia probatoria ai sensi dell’articolo 2712 del Codice civile.
2. Gli obblighi fiscali relativi ai documenti informatici ed alla loro riproduzione su diversi tipi di supporto sono assolti
secondo le modalità definite con decreto del Ministro delle finanze.
3. Il documento informatico, sottoscritto con firma digitale ai sensi dell'articolo 23, ha efficacia di scrittura privata ai
sensi dell'articolo 2702 del codice civile.
4. Il documento informatico redatto in conformità alle regole tecniche di cui all’articolo 8, comma 2 soddisfa l'obbligo
previsto dagli articoli 2214 e seguenti del codice civile e da ogni altra analoga disposizione legislativa o regolamentare.
Articolo 11 (R)
Contratti stipulati con strumenti informatici o per via telematica
1. I contratti stipulati con strumenti informatici o per via telematica mediante l'uso della firma digitale secondo le
disposizioni del presente testo unico sono validi e rilevanti a tutti gli effetti di legge.
2. Ai contratti indicati al comma 1 si applicano le vigenti disposizioni in materia di contratti negoziati al di fuori dei
locali commerciali.
Articolo 12 (R)
Pagamenti informatici
1. Il trasferimento elettronico dei pagamenti tra privati, pubbliche amministrazioni e tra queste e soggetti privati è
effettuato secondo le regole tecniche definite col decreto di cui all'articolo 8, comma 2.
Articolo 13 (R)
Libri e scritture
1. I libri, i repertori e le scritture, ivi compresi quelli previsti dalla legge sull'ordinamento del notariato e degli archivi
notarili di cui sia obbligatoria la tenuta possono essere formati e conservati su supporti informatici in conformità alle
disposizioni del presente regolamento e secondo le regole tecniche definite col decreto di cui all'articolo 8, comma 2.
6
SEZIONE III
TRASMISSIONE DI DOCUMENTI
Articolo 14 (R)
Trasmissione del documento informatico
1. Il documento informatico trasmesso per via telematica si intende inviato e pervenuto al destinatario, se trasmesso
all'indirizzo elettronico da questi dichiarato.
2. La data e l'ora di formazione, di trasmissione o di ricezione di un documento informatico, redatto in conformità alle
disposizioni del presente testo unico e alle regole tecniche di cui agli articoli 8, comma 2 e 9, comma 4, sono opponibili
ai terzi.
3. La trasmissione del documento informatico per via telematica, con modalità che assicurino l'avvenuta consegna,
equivale alla notificazione per mezzo della posta nei casi consentiti dalla legge.
Articolo 15 (L)
Trasmissione dall'estero di atti agli uffici di stato civile
1. In materia di trasmissione di atti o copie di atti di stato civile o di dati concernenti la cittadinanza da parte delle
rappresentanze diplomatiche e consolari italiane, si osservano le disposizioni speciali sulle funzioni e sui poteri
consolari.
Articolo 16 (R)
Riservatezza dei dati personali contenuti nei documenti trasmessi
1. Al fine di tutelare la riservatezza dei dati personali di cui agli articoli 22 e 24 della legge 31 dicembre 1996, n. 675, i
certificati ed i documenti trasmessi ad altre pubbliche amministrazioni possono contenere soltanto le informazioni
relative a stati, fatti e qualità personali previste da legge o da regolamento e strettamente necessarie per il perseguimento
delle finalità per le quali vengono acquisite.
2. Ai fini della dichiarazione di nascita il certificato di assistenza al parto è sempre sostituito da una semplice
attestazione contenente i soli dati richiesti nei registri di nascita.
3. Ai fini statistici, i direttori sanitari inviano copia del certificato di assistenza al parto, privo di elementi identificativi
diretti delle persone interessate, ai competenti enti ed uffici del Sistema statistico nazionale, secondo modalità
preventivamente concordate. L'Istituto nazionale di statistica, sentito il Ministero della sanità e il Garante per la
protezione dei dati personali, determina nuove modalità tecniche e procedure per la rilevazione dei dati statistici di base
relativi agli eventi di nascita e per l'acquisizione dei dati relativi ai nati affetti da malformazioni e ai nati morti nel
rispetto dei princìpi contenuti nelle disposizioni di legge sulla tutela della riservatezza dei dati personali.
Articolo 17 (R)
Segretezza della corrispondenza trasmessa per via telematica
1. Gli addetti alle operazioni di trasmissione per via telematica di atti, dati e documenti formati con strumenti
informatici non possono prendere cognizione della corrispondenza telematica, duplicare con qualsiasi mezzo o cedere a
terzi a qualsiasi titolo informazioni anche in forma sintetica o per estratto sull'esistenza o sul contenuto di
corrispondenza, comunicazioni o messaggi trasmessi per via telematica, salvo che si tratti di informazioni per loro
natura o per espressa indicazione del mittente destinate ad essere rese pubbliche.
2. Agli effetti del presente testo unico, gli atti, i dati e i documenti trasmessi per via telematica si considerano, nei
confronti del gestore del sistema di trasporto delle informazioni, di proprietà del mittente sino a che non sia avvenuta la
consegna al destinatario.
7
SEZIONE IV
COPIE AUTENTICHE, AUTENTICAZIONE DI SOTTOSCRIZIONI
Articolo 18 (L-R)
Copie autentiche
1. Le copie autentiche, totali o parziali, di atti e documenti possono essere ottenute con qualsiasi procedimento che dia
garanzia della riproduzione fedele e duratura dell'atto o documento. Esse possono essere validamente prodotte in luogo
degli originali. (L)
2. L'autenticazione delle copie può essere fatta dal pubblico ufficiale dal quale è stato emesso o presso il quale è
depositato l'originale, o al quale deve essere prodotto il documento, nonché da un notaio, cancelliere, segretario
comunale, o altro funzionario incaricato dal sindaco. Essa consiste nell'attestazione di conformità con l'originale scritta
alla fine della copia, a cura del pubblico ufficiale autorizzato, il quale deve altresì indicare la data e il luogo del rilascio,
il numero dei fogli impiegati, il proprio nome e cognome, la qualifica rivestita nonché apporre la propria firma per
esteso ed il timbro dell'ufficio. Se la copia dell'atto o documento consta di più fogli il pubblico ufficiale appone la
propria firma a margine di ciascun foglio intermedio. Per le copie di atti e documenti informatici si applicano le
disposizioni contenute nell’articolo 20. (L)
3. Nei casi in cui l'interessato debba presentare alle amministrazioni o ai gestori di pubblici servizi copia autentica di un
documento, l'autenticazione della copia può essere fatta dal responsabile del procedimento o da qualsiasi altro
dipendente competente a ricevere la documentazione, su esibizione dell'originale e senza obbligo di deposito dello
stesso presso l'amministrazione procedente. In tal caso la copia autentica può essere utilizzata solo nel procedimento in
corso. (R)
Articolo 19 (R)
Modalità alternative all’autenticazione di copie
1. La dichiarazione sostitutiva dell’atto di notorietà di cui all’articolo 47 può riguardare anche il fatto che la copia di un
atto o di un documento conservato o rilasciato da una pubblica amministrazione, la copia di una pubblicazione ovvero la
copia di titoli di studio o di servizio sono conformi all'originale. Tale dichiarazione può altresì riguardare la conformità
all’originale della copia dei documenti fiscali che devono essere obbligatoriamente conservati dai privati.
Articolo 20 (R)
Copie di atti e documenti informatici
1. I duplicati, le copie, gli estratti del documento informatico, anche se riprodotti su diversi tipi di supporto, sono validi
a tutti gli effetti di legge se conformi alle disposizioni del presente testo unico.
2. I documenti informatici contenenti copia o riproduzione di atti pubblici, scritture private e documenti in genere,
compresi gli atti e documenti amministrativi di ogni tipo, spediti o rilasciati dai depositari pubblici autorizzati e dai
pubblici ufficiali, hanno piena efficacia, ai sensi degli articoli 2714 e 2715 del codice civile, se ad essi è apposta o
associata la firma digitale di colui che li spedisce o rilascia, secondo le disposizioni del presente testo unico.
3. Le copie su supporto informatico di documenti, formati in origine su supporto cartaceo o, comunque, non
informatico, sostituiscono, ad ogni effetto di legge, gli originali da cui sono tratte se la loro conformità all'originale è
autenticata da un notaio o da altro pubblico ufficiale a ciò autorizzato, con dichiarazione allegata al documento
informatico e asseverata secondo le regole tecniche di cui all’articolo 8, comma 2.
4. La spedizione o il rilascio di copie di atti e documenti di cui al comma 2 esonera dalla produzione e dalla esibizione
dell'originale formato su supporto cartaceo quando richieste ad ogni effetto di legge.
5. Gli obblighi di conservazione e di esibizione di documenti previsti dalla legislazione vigente si intendono soddisfatti
a tutti gli effetti di legge a mezzo di documenti informatici, se le procedure utilizzate sono conformi alle regole tecniche
dettate nell’articolo 8, comma 2.
Articolo 21 (R)
Autenticazione delle sottoscrizioni.
1. L’autenticità della sottoscrizione di qualsiasi istanza o dichiarazione da produrre agli organi della pubblica
amministrazione, nonché ai gestori di servizi pubblici è garantita con le modalità di cui all’art. 38, comma 2 e comma 3.
(R)
8
2. Se l’istanza o la dichiarazione sostitutiva di atto di notorietà è presentata a soggetti diversi da quelli indicati al comma
1 o a questi ultimi al fine della riscossione da parte di terzi di benefici economici, l’autenticazione è redatta da un
notaio, cancelliere, segretario comunale, dal dipendente addetto a ricevere la documentazione o altro dipendente
incaricato dal Sindaco; in tale ultimo caso, l’autenticazione è redatta di seguito alla sottoscrizione e il pubblico ufficiale,
che autentica, attesta che la sottoscrizione è stata apposta in sua presenza, previo accertamento dell’identità del
dichiarante, indicando le modalità di identificazione, la data ed il luogo di autenticazione, il proprio nome, cognome e la
qualifica rivestita, nonché apponendo la propria firma e il timbro dell’ufficio. (R)
SEZIONE V
FIRMA DIGITALE
Articolo 22 (R)
Definizioni
1. Ai fini del presente Testo unico si intende:
a) per sistema di validazione, il sistema informatico e crittografico in grado di generare ed apporre la firma digitale o di
verificarne la validità;
b) per chiavi asimmetriche, la coppia di chiavi crittografiche, una privata ed una pubblica, correlate tra loro, da
utilizzarsi nell'ambito dei sistemi di validazione o di cifratura di documenti informatici;
c) per chiave privata, l'elemento della coppia di chiavi asimmetriche, destinato ad essere conosciuto soltanto dal
soggetto titolare, mediante il quale si appone la firma digitale sul documento informatico o si decifra il documento
informatico in precedenza cifrato mediante la corrispondente chiave pubblica.
d) per chiave pubblica, l'elemento della coppia di chiavi asimmetriche destinato ad essere reso pubblico, con il quale si
verifica la firma digitale apposta sul documento informatico dal titolare delle chiavi asimmetriche o si cifrano i
documenti informatici da trasmettere al titolare delle predette chiavi;
e) per chiave biometrica, la sequenza di codici informatici utilizzati nell’ambito di meccanismi di sicurezza che
impiegano metodi di verifica dell’identità personale basati su specifiche caratteristiche fisiche dell’utente;
f) per certificazione, il risultato della procedura informatica, applicata alla chiave pubblica e rilevabile dai sistemi di
validazione, mediante la quale si garantisce la corrispondenza biunivoca tra chiave pubblica e soggetto titolare cui essa
appartiene, si identifica quest'ultimo e si attesta il periodo di validità della predetta chiave ed il termine di scadenza del
relativo certificato, in ogni caso non superiore a tre anni;
g) per validazione temporale, il risultato della procedura informatica, con cui si attribuiscono, ad uno o più documenti
informatici, una data ed un orario opponibili ai terzi;
h) per indirizzo elettronico, l'identificatore di una risorsa fisica o logica in grado di ricevere e registrare documenti
informatici;
i) per certificatore, il soggetto pubblico o privato che effettua la certificazione, rilascia il certificato della chiave
pubblica, lo pubblica unitamente a quest'ultima, pubblica ed aggiorna gli elenchi dei certificati sospesi e revocati;
l) per revoca del certificato, l’operazione con cui il certificatore annulla la validità del certificato da un dato momento,
non retroattivo, in poi;
m) per sospensione del certificato, l'operazione con cui il certificatore sospende la validità del certificato per un
determinato periodo di tempo;
n) per validità del certificato, l'efficacia, e l'opponibilità al titolare della chiave pubblica, dei dati in esso contenuti;
o) per regole tecniche, le specifiche di carattere tecnico, ivi compresa ogni disposizione che ad esse si applichi.
Articolo 23 (R)
Firma digitale
1. A ciascun documento informatico, o a un gruppo di documenti informatici, nonché al duplicato o copia di essi, può
essere apposta, o associata con separata evidenza informatica, una firma digitale.
2. L'apposizione o l'associazione della firma digitale al documento informatico equivale alla sottoscrizione prevista per
gli atti e documenti in forma scritta su supporto cartaceo.
3. La firma digitale deve riferirsi in maniera univoca ad un solo soggetto ed al documento o all'insieme di documenti cui
è apposta o associata.
4. Per la generazione della firma digitale deve adoperarsi una chiave privata la cui corrispondente chiave pubblica non
risulti scaduta di validità ovvero non risulti revocata o sospesa ad opera del soggetto pubblico o privato che l'ha
certificata.
9
5. L'uso della firma apposta o associata mediante una chiave revocata, scaduta o sospesa equivale a mancata
sottoscrizione. La revoca o la sospensione, comunque motivate, hanno effetto dal momento della pubblicazione, salvo
che il revocante, o chi richiede la sospensione, non dimostri che essa era già a conoscenza di tutte le parti interessate.
6. L'apposizione di firma digitale integra e sostituisce, ad ogni fine previsto dalla normativa vigente, l'apposizione di
sigilli, punzoni, timbri, contrassegni e marchi di qualsiasi genere.
7. Attraverso la firma digitale devono potersi rilevare nei modi e con le tecniche definiti con il decreto di cui all’articolo
8, comma 2, gli elementi identificativi del soggetto titolare della firma, del soggetto che l'ha certificata e del registro su
cui essa è pubblicata per la consultazione.
Articolo 24 (R)
Firma digitale autenticata
1. Si ha per riconosciuta, ai sensi dell'articolo 2703 del codice civile, la firma digitale, la cui apposizione è autenticata
dal notaio o da altro pubblico ufficiale autorizzato.
2. L'autenticazione della firma digitale consiste nell'attestazione, da parte del pubblico ufficiale, che la firma digitale è
stata apposta in sua presenza dal titolare, previo accertamento della sua identità personale, della validità della chiave
utilizzata e del fatto che il documento sottoscritto risponde alla volontà della parte e non è in contrasto con
l’ordinamento giuridico.
3. L'apposizione della firma digitale da parte del pubblico ufficiale integra e sostituisce ad ogni fine di legge la
apposizione di sigilli, punzoni, timbri, contrassegni e marchi comunque previsti.
4. Se al documento informatico autenticato deve essere allegato altro documento formato in originale su altro tipo di
supporto, il pubblico ufficiale può allegare copia informatica autenticata dell'originale, secondo le disposizioni
dell'articolo 20, comma 3.
5. Ai fini e per gli effetti della presentazione di istanze agli organi della pubblica amministrazione si considera apposta
in presenza del dipendente addetto la firma digitale inserita nel documento informatico presentato o depositato presso
pubbliche amministrazioni.
6. La presentazione o il deposito di un documento per via telematica o su supporto informatico ad una pubblica
amministrazione sono validi a tutti gli effetti di legge se vi sono apposte la firma digitale e la validazione temporale a
norma del presente testo unico.
Articolo 25 (R)
Firma di documenti informatici delle pubbliche amministrazioni
1. In tutti i documenti informatici delle pubbliche amministrazioni la firma autografa o la firma, comunque prevista, è
sostituita dalla firma digitale, in conformità alle norme del presente testo unico.
2. L'uso della firma digitale integra e sostituisce ad ogni fine di legge l'apposizione di sigilli, punzoni, timbri,
contrassegni e marchi comunque previsti.
Articolo 26 (R)
Deposito della chiave privata
1. Il titolare della coppia di chiavi asimmetriche può ottenere il deposito in forma segreta della chiave privata presso un
notaio o altro pubblico depositario autorizzato.
2. La chiave privata di cui si richiede il deposito può essere registrata su qualsiasi tipo di supporto idoneo a cura del
depositante e deve essere consegnata racchiusa in un involucro sigillato in modo che le informazioni non possano essere
lette, conosciute od estratte senza rotture od alterazioni.
3. Le modalità del deposito sono regolate dalle disposizioni dell'articolo 605 del codice civile, in quanto applicabili.
10
Articolo 27 (R)
Certificazione delle chiavi
1. Chiunque intenda utilizzare un sistema di chiavi asimmetriche di cifratura con gli effetti di cui all'articolo 8, comma 1
deve munirsi di una idonea coppia di chiavi e rendere pubblica una di esse mediante la procedura di certificazione.
2. Le chiavi pubbliche di cifratura sono custodite per un periodo non inferiore a dieci anni a cura del certificatore e, dal
momento iniziale della loro valutabilità, sono consultabili in forma telematica .
3. Salvo quanto previsto dall'articolo 29, le attività di certificazione sono effettuate da certificatori inclusi, sulla base di
una dichiarazione anteriore all'inizio dell'attività, in apposito elenco pubblico, consultabile in via telematica, predisposto
tenuto e aggiornato a cura dell'Autorità per l'informatica nella pubblica amministrazione, e dotati dei seguenti requisiti,
specificati con il decreto di cui all’articolo 8, comma 2:
a) forma di società per azioni e capitale sociale non inferiore a quello necessario ai fini dell'autorizzazione all'attività
bancaria, se soggetti privati;
b) possesso da parte dei rappresentanti legali e dei soggetti preposti all'amministrazione, dei requisiti di onorabilità
richiesti ai soggetti che svolgono funzioni di amministrazione, direzione e controllo presso banche;
c) affidamento che, per competenza ed esperienza, i responsabili tecnici del certificatore e il personale addetto
all'attività di certificazione siano in grado di rispettare le norme del presente regolamento e le regole tecniche di cui
all’articolo 8, comma 2;
d) qualità dei processi informatici e dei relativi prodotti, sulla base di standard riconosciuti a livello internazionale.
4. La procedura di certificazione di cui al comma 1 può essere svolta anche da un certificatore operante sulla base di
licenza o autorizzazione rilasciata da altro Stato membro dell'Unione europea o dello Spazio economico europeo, sulla
base di equivalenti requisiti.
Articolo 28 (R)
Obblighi dell'utente e del certificatore
1. Chiunque intenda utilizzare un sistema di chiavi asimmetriche o della firma digitale, è tenuto ad adottare tutte le
misure organizzative e tecniche idonee ad evitare danno ad altri.
2. Il certificatore è tenuto a:
a) identificare con certezza la persona che fa richiesta della certificazione;
b) rilasciare e rendere pubblico il certificato avente le caratteristiche fissate con il decreto di cui all’articolo 8, comma 2;
c) specificare, su richiesta dell'istante, e con il consenso del terzo interessato, la sussistenza dei poteri di rappresentanza
o di altri titoli relativi all'attività professionale o a cariche rivestite;
d) attenersi alle regole tecniche di cui all’articolo 8, comma 2;
e) informare i richiedenti, in modo compiuto e chiaro, sulla procedura di certificazione e sui necessari requisiti tecnici
per accedervi;
f) attenersi alle misure minime di sicurezza per il trattamento dei dati personali, emanate ai sensi dell’articolo 15,
comma 2 della legge 31 dicembre 1996, n. 675;
g) non rendersi depositario di chiavi private;
h) procedere tempestivamente alla revoca od alla sospensione del certificato in caso di richiesta da parte del titolare o
del terzo dal quale derivino i poteri di quest'ultimo, di perdita del possesso della chiave, di provvedimento dell'autorità,
di acquisizione della conoscenza di cause limitative della capacità del titolare, di sospetti abusi o falsificazioni;.20
i) dare immediata pubblicazione della revoca e della sospensione della coppia di chiavi asimmetriche;
l) dare immediata comunicazione all'Autorità per l'informatica nella pubblica amministrazione ed agli utenti, con un
preavviso di almeno sei mesi, della cessazione dell'attività e della conseguente rilevazione della documentazione da
parte di altro certificatore o del suo annullamento.
Articolo 29 (R)
Chiavi di cifratura della pubblica amministrazione
1. Le pubbliche amministrazioni provvedono autonomamente, con riferimento al proprio ordinamento, alla generazione,
alla conservazione, alla certificazione ed all'utilizzo delle chiavi pubbliche di competenza.
2. Con il decreto di cui all'articolo 8 sono disciplinate le modalità di formazione, di pubblicità, di conservazione,
certificazione e di utilizzo delle chiavi pubbliche delle pubbliche amministrazioni.
11
3. Le chiavi pubbliche dei pubblici ufficiali non appartenenti alla pubblica amministrazione sono certificate e pubblicate
autonomamente in conformità alle leggi ed ai regolamenti che definiscono l'uso delle firme autografe nell'ambito dei
rispettivi ordinamenti giuridici.
4. Le chiavi pubbliche di ordini ed albi professionali legalmente riconosciuti e dei loro legali rappresentanti sono
certificate e pubblicate a cura del Ministro di grazia e giustizia o suoi delegati.
SEZIONE VI
LEGALIZZAZIONE DI FIRME E DI FOTOGRAFIE.
Articolo 30 (L)
Modalità per la legalizzazione di firme
1. Nelle legalizzazioni devono essere indicati il nome e il cognome di colui la cui firma si legalizza. Il pubblico ufficiale
legalizzante deve indicare la data e il luogo della legalizzazione, il proprio nome e cognome, la qualifica rivestita,
nonché apporre la propria firma per esteso ed il timbro dell'ufficio.
Articolo 31 (L)
Atti non soggetti a legalizzazione
1. Salvo quanto previsto negli articoli 32 e 33, non sono soggette a legalizzazione le firme apposte da pubblici
funzionari o pubblici ufficiali su atti, certificati, copie ed estratti dai medesimi rilasciati. Il funzionario o pubblico
ufficiale deve indicare la data e il luogo del rilascio, il proprio nome e cognome, la qualifica rivestita, nonché apporre la
propria firma per esteso ed il timbro dell'ufficio.
Articolo 32 (L)
Legalizzazione di firme di capi di scuole parificate o legalmente riconosciute
1. Le firme dei capi delle scuole parificate o legalmente riconosciute sui diplomi originali o sui certificati di studio da
prodursi ad uffici pubblici fuori della provincia in cui ha sede la scuola sono legalizzate dal provveditore agli studi.
Articolo 33 (L)
Legalizzazione di firme di atti da e per l'estero
1. Le firme sugli atti e documenti formati nello Stato e da valere all'estero davanti ad autorità estere sono, ove da queste
richiesto, legalizzate a cura dei competenti organi, centrali o periferici, del Ministero competente, o di altri organi e
autorità delegati dallo stesso.
2. Le firme sugli atti e documenti formati all'estero da autorità estere e da valere nello Stato sono legalizzate dalle
rappresentanze diplomatiche o consolari italiane all'estero. Le firme apposte su atti e documenti dai competenti organi
delle rappresentanze diplomatiche o.22 consolari italiane o dai funzionari da loro delegati non sono soggette a
legalizzazione. Si osserva l'articolo 31.
3. Agli atti e documenti indicati nel comma precedente, redatti in lingua straniera, deve essere allegata una traduzione in
lingua italiana certificata conforme al testo straniero dalla competente rappresentanza diplomatica o consolare, ovvero
da un traduttore ufficiale.
4. Le firme sugli atti e documenti formati nello Stato e da valere nello Stato, rilasciati da una rappresentanza
diplomatica o consolare estera residente nello Stato, sono legalizzate a cura delle prefetture.
5. Sono fatte salve le esenzioni dall'obbligo della legalizzazione e della traduzione stabilite da leggi o da accordi
internazionali.
Articolo 34 (L)
Legalizzazione di fotografie
1. Le amministrazioni competenti per il rilascio di documenti personali sono tenute a legalizzare le prescritte fotografie
presentate personalmente dall’interessato. Su richiesta di quest’ultimo le fotografie possono essere, altresì, legalizzate
dal dipendente incaricato dal Sindaco.
2. La legalizzazione delle fotografie prescritte per il rilascio dei documenti personali non è soggetta all'obbligo del
pagamento dell'imposta di bollo.
12
SEZIONE VII
DOCUMENTI DI RICONOSCIMENTO E DI IDENTITA’
Articolo 35 (L - R)
Documenti di identità e di riconoscimento
1. In tutti i casi in cui nel presente testo unico viene richiesto un documento di identità, esso può sempre essere
sostituito dal documento di riconoscimento equipollente ai sensi del comma 2. (R)
2. Sono equipollenti alla carta di identità il passaporto, la patente di guida, la patente nautica, il libretto di pensione, il
patentino di abilitazione alla conduzione di impianti termici,.23 il porto d’armi, le tessere di riconoscimento, purché
munite di fotografia e di timbro o di altra segnatura equivalente, rilasciate da un’amministrazione dello Stato. (R)
3. Nei documenti d’identità e di riconoscimento non è necessaria l’indicazione o l’attestazione dello stato civile, salvo
specifica istanza del richiedente. (L)
Articolo 36 (L)
Carta d’identità e documenti elettronici
1. Le caratteristiche e le modalità per il rilascio della carta d’identità elettronica e del documento d’identità elettronico
sono definite con decreto del Presidente del Consiglio dei Ministri su proposta del Ministro dell'interno, di concerto con
il Ministro della funzione pubblica, sentito il Garante per la protezione dei dati personali.
2. La carta d’identità elettronica e l’analogo documento, rilasciato a seguito o della denuncia di nascita e prima del
compimento del quindicesimo anno, devono contenere:
a) i dati identificativi della persona;
b) il codice fiscale;
3. La carta d’identità e il documento elettronico possono contenere:
a) l’indicazione del gruppo sanguigno;
b) le opzioni di carattere sanitario previste dalla legge;
c) i dati biometrici indicati col decreto di cui al comma 1, con esclusione, in ogni caso, del DNA;
d) tutti gli altri dati utili al fine di razionalizzare e semplificare l’azione amministrativa e i servizi resi al cittadino, anche
per mezzo dei portali, nel rispetto della normativa in materia di riservatezza;
e) le procedure informatiche e le informazioni che possono o debbono essere conosciute dalla pubblica amministrazione
e da altri soggetti ivi compresa la chiave biometrica, occorrenti per la firma digitale;
4. La carta d’identità elettronica può altresì essere utilizzata per il trasferimento elettronico dei pagamenti tra soggetti
privati e pubbliche amministrazioni.
5. Con decreto del Ministro dell’interno, sentite l’Autorità per l’informatica nella pubblica amministrazione, il Garante
per la protezione dei dati personali e la Conferenza Stato-città ed autonomie locali, sono dettate le regole tecniche e di
sicurezza relative alle tecnologie e ai materiali utilizzati per la produzione delle carte di identità e dei documenti di
riconoscimento di cui al presente articolo. Le predette regole sono adeguate con cadenza almeno biennale in relazione
alle esigenze dettate dall’evoluzione delle conoscenze scientifiche e tecnologiche.
6. Nel rispetto della disciplina generale fissata dai decreti di cui al presente articolo e delle vigenti disposizioni in
materia di protezione dei dati personali, le pubbliche amministrazioni, nell’ambito dei rispettivi ordinamenti, possono
sperimentare modalità di utilizzazione dei documenti di cui al presente articolo per l’erogazione di ulteriori servizi o
utilità.
7. La carta di identità, ancorché su supporto cartaceo, può essere rinnovata a decorrere dal centottantesimo giorno
precedente la scadenza.
SEZIONE VIII
REGIME FISCALE
Articolo 37 (L)
Esenzioni fiscali
1. Le dichiarazioni sostitutive di cui agli articoli 46 e 47 sono esenti dall’imposta di bollo.
13
2. L'imposta di bollo non è dovuta quando per le leggi vigenti sia esente da bollo l'atto sostituito ovvero quello nel quale
è apposta la firma da legalizzare.
CAPO III
SEMPLIFICAZIONE DELLA DOCUMENTAZIONE AMMINISTRATIVA
SEZIONE I
ISTANZE E DICHIARAZIONI DA PRESENTARE ALLA PUBBLICA AMMINISTRAZIONE
Articolo 38 (L-R)
Modalità di invio e sottoscrizione delle istanze
1. Tutte le istanze e le dichiarazioni da presentare alla pubblica amministrazione o ai gestori o esercenti di pubblici
servizi possono essere inviate anche per fax e via telematica. (L)
2. Le istanze e le dichiarazioni inviate per via telematica sono valide se sottoscritte mediante la firma digitale o quando
il sottoscrittore è identificato dal sistema informatico con l'uso della carta d'identità elettronica.
3. Le istanze e le dichiarazioni da produrre agli organi della amministrazione pubblica o ai gestori o esercenti di
pubblici servizi sono sottoscritte dall’interessato in presenza del dipendente addetto ovvero sottoscritte e presentate
unitamente a copia fotostatica non autenticata di un documento di identità del sottoscrittore. La copia fotostatica del
documento è inserita nel fascicolo. Le istanze e la copia fotostatica del documento di identità possono essere inviate per
via telematica; nei procedimenti di aggiudicazione di contratti pubblici, detta facoltà è consentita nei limiti stabiliti dal
regolamento di cui all’articolo 15, comma 2 della legge 15 marzo 1997, n.59. (L)
Articolo 39 (L)
Domande per la partecipazione a concorsi pubblici
1. La sottoscrizione delle domande per la partecipazione a selezioni per l'assunzione, a qualsiasi titolo, in tutte le
pubbliche amministrazioni, nonché ad esami per il conseguimento di abilitazioni, diplomi o titoli culturali non è
soggetta ad autenticazione.
SEZIONE II
CERTIFICATI
Articolo 40 (L)
Certificazioni contestuali
1. Le certificazioni da rilasciarsi da uno stesso ufficio in ordine a stati, qualità personali e fatti, concernenti la stessa
persona, nell’ambito del medesimo procedimento, sono contenute in un unico documento.
Articolo 41 (L)
Validità dei certificati
1. I certificati rilasciati dalle pubbliche amministrazioni attestanti stati, qualità personali e fatti non soggetti a
modificazioni hanno validità illimitata. Le restanti certificazioni hanno validità di sei mesi dalla data di rilascio se
disposizioni di legge o regolamentari non prevedono una validità superiore.
2. I certificati anagrafici, le certificazioni dello stato civile, gli estratti e le copie integrali degli atti di stato civile sono
ammessi dalle pubbliche amministrazioni nonché dai gestori o esercenti di pubblici servizi anche oltre i termini di
validità nel caso in cui l'interessato dichiari, in fondo al documento, che le informazioni contenute nel certificato stesso
non hanno subìto variazioni dalla data di rilascio. Il procedimento per il quale gli atti certificativi sono richiesti deve
avere comunque corso, una volta acquisita la dichiarazione dell'interessato. Resta ferma la facoltà di verificare la
veridicità e la autenticità delle attestazioni prodotte. In caso di falsa dichiarazione si applicano le disposizioni di cui
all'articolo 76.
Articolo 42 (R)
Certificati di abilitazione
1. Tutti i titoli di abilitazione rilasciati al termine di corsi di formazione o di procedimenti autorizzatòri all’esercizio di
determinate attività, ancorché definiti "certificato", sono denominati rispettivamente "diploma" o "patentino".
14
SEZIONE III
ACQUISIZIONE DIRETTA DI DOCUMENTI
Articolo 43 (L-R)
Accertamenti d'ufficio
1. Le amministrazioni pubbliche e i gestori di pubblici servizi non possono richiedere atti o certificati concernenti stati,
qualità personali e fatti che risultino elencati all’art. 46, che siano attestati in documenti già in loro possesso o che
comunque esse stesse siano tenute a certificare. In luogo di tali atti o certificati i soggetti indicati nel presente comma
sono tenuti ad acquisire d'ufficio le relative informazioni, previa indicazione, da parte dell'interessato,
dell'amministrazione competente e degli elementi indispensabili per il reperimento delle informazioni o dei dati
richiesti, ovvero ad accettare la dichiarazione sostitutiva prodotta dall’interessato. (R)
2. Fermo restando il divieto di accesso a dati diversi da quelli di cui è necessario acquisire la certezza o verificare
l’esattezza, si considera operata per finalità di rilevante interesse pubblico ai fini del decreto legislativo 11 maggio
1999, n. 135 la consultazione diretta, da parte di una pubblica amministrazione o di un gestore di pubblico servizio,
degli archivi dell’amministrazione certificante effettuata, finalizzata all’accertamento d’ufficio di stati, qualità e fatti
ovvero al controllo sulle dichiarazioni sostitutive presentate dai cittadini. Per l’accesso diretto ai propri archivi
l’amministrazione certificante rilascia all’amministrazione procedente apposita autorizzazione in cui vengono indicati i
limiti e le condizioni di accesso volti ad assicurare la riservatezza dei dati personali ai sensi della normativa vigente. (L)
3. Quando l’amministrazione procedente opera l’acquisizione d’ufficio ai sensi del precedente comma, può procedere
anche per fax e via telematica. (R)
4. Al fine di agevolare l’acquisizione d’ufficio di informazioni e dati relativi a stati, qualità personali e fatti, contenuti in
albi, elenchi o pubblici registri, le amministrazioni certificanti sono tenute a consentire alle amministrazioni procedenti,
senza oneri, la consultazione per via telematica dei loro archivi informatici, nel rispetto della riservatezza dei dati
personali. (R)
5. In tutti i casi in cui l’amministrazione procedente acquisisce direttamente informazioni relative a stati, qualità
personali e fatti presso l’amministrazione competente per la loro certificazione, il rilascio e l’acquisizione del certificato
non sono necessari e le suddette informazioni sono acquisite con qualunque mezzo idoneo ad assicurare la certezza
della loro fonte di provenienza. (R)
6. I documenti trasmessi da chiunque ad una pubblica amministrazione tramite fax, o con altro mezzo telematico o
informatico idoneo ad accertarne la fonte di provenienza, soddisfano il requisito della forma scritta e la loro
trasmissione non deve essere seguita da quella del documento originale. (R)
Articolo 44 (R)
Acquisizione di estratti degli atti dello stato civile
1. Gli estratti degli atti di stato civile sono richiesti esclusivamente per i procedimenti che riguardano il cambiamento di
stato civile e, ove formati o tenuti dagli uffici dello stato civile in Italia o dalle autorità consolari italiane all’estero,
vengono acquisiti d'ufficio.
2. Al di fuori delle ipotesi di cui al comma 1 le amministrazioni possono provvedere all'acquisizione d'ufficio degli
estratti solo quando ciò sia indispensabile.
SEZIONE IV
ESIBIZIONE DI DOCUMENTO
Articolo 45 (L-R)
Documentazione mediante esibizione
1. I dati relativi a cognome, nome, luogo e data di nascita, la cittadinanza, lo stato civile e la residenza attestati in
documenti di identità o di riconoscimento in corso di validità, possono essere comprovati mediante esibizione dei
documenti medesimi. È fatto divieto alle amministrazioni pubbliche ed ai gestori o esercenti di pubblici servizi, nel caso
in cui all'atto della presentazione dell'istanza sia richiesta l'esibizione di un documento di identità o di riconoscimento,
di richiedere certificati attestanti stati o fatti contenuti nel documento esibito. È, comunque, fatta salva per le
amministrazioni pubbliche ed i gestori e gli esercenti di pubblici servizi la facoltà di verificare, nel corso del
procedimento, la veridicità dei dati contenuti nel documento di identità o di riconoscimento. (L)
15
2. Nei casi in cui l'amministrazione procedente acquisisce informazioni relative a stati, qualità personali e fatti
attraverso l'esibizione da parte dell'interessato di un documento di identità o di riconoscimento in corso di validità, la
registrazione dei dati avviene attraverso l'acquisizione della copia fotostatica non autenticata del documento stesso. (R)
3. Qualora l’interessato sia in possesso di un documento di identità o di riconoscimento non in corso di validità, gli stati,
le qualità personali e i fatti in esso contenuti possono essere comprovati mediante esibizione dello stesso, purché
l’interessato dichiari, in calce alla fotocopia del documento, che i dati contenuti nel documento non hanno subito
variazioni dalla data del rilascio. (R)
SEZIONE V
NORME IN MATERIA DI DICHIARAZIONI SOSTITUTIVE
Articolo 46 (R)
Dichiarazioni sostitutive di certificazioni
1. Sono comprovati con dichiarazioni, anche contestuali all'istanza, sottoscritte dall'interessato e prodotte in sostituzione
delle normali certificazioni i seguenti stati, qualità personali e fatti:
a) data e il luogo di nascita;
b) residenza;
c) cittadinanza;
d) godimento dei diritti civili e politici;
e) stato di celibe, coniugato, vedovo o stato libero;
f) stato di famiglia;
g) esistenza in vita;
h) nascita del figlio, decesso del coniuge, dell'ascendente o discendente;
i) iscrizione in albi, registri o elenchi tenuti da pubbliche amministrazioni;
l) appartenenza a ordini professionali;
m) titolo di studio, esami sostenuti;
n) qualifica professionale posseduta, titolo di specializzazione, di abilitazione, di formazione, di aggiornamento e di
qualificazione tecnica;
o) situazione reddituale o economica anche ai fini della concessione dei benefici di qualsiasi tipo previsti da leggi
speciali;
p) assolvimento di specifici obblighi contributivi con l'indicazione dell'ammontare corrisposto;
q) possesso e numero del codice fiscale, della partita IVA e di qualsiasi dato presente nell'archivio dell'anagrafe
tributaria;
r) stato di disoccupazione;
s) qualità di pensionato e categoria di pensione;
t) qualità di studente;
u) qualità di legale rappresentante di persone fisiche o giuridiche, di tutore, di curatore e simili;
v) iscrizione presso associazioni o formazioni sociali di qualsiasi tipo;
z) tutte le situazioni relative all'adempimento degli obblighi militari, ivi comprese quelle attestate nel foglio matricolare
dello stato di servizio;
aa) di non aver riportato condanne penali e di non essere destinatario di provvedimenti che riguardano l'applicazione di
misure di prevenzione, di decisioni civili e di provvedimenti amministrativi iscritti nel casellario giudiziale ai sensi della
vigente normativa;
bb) di non essere a conoscenza di essere sottoposto a procedimenti penali;
cc) qualità di vivenza a carico;
dd) tutti i dati a diretta conoscenza dell'interessato contenuti nei registri dello stato civile;
ee) di non traversi in stato di liquidazione o di fallimento e di non aver presentato domanda di concordato. (R)
Articolo 47 (R)
Dichiarazioni sostitutive dell’atto di notorietà
1. L'atto di notorietà concernente stati, qualità personali o fatti che siano a diretta conoscenza dell'interessato è sostituito
da dichiarazione resa e sottoscritta dal medesimo con la osservanza delle modalità di cui all’articolo 38. (R)
2. La dichiarazione resa nell’interesse proprio del dichiarante può riguardare anche stati, qualità personali e fatti relativi
ad altri soggetti di cui egli abbia diretta conoscenza. (R)
3. Fatte salve le eccezioni espressamente previste per legge, nei rapporti con la pubblica amministrazione e con i
concessionari di pubblici servizi, tutti gli stati, le qualità personali e i fatti non espressamente indicati nell'articolo 46
sono comprovati dall'interessato mediante la dichiarazione sostitutiva di atto di notorietà. (R)
16
4. Salvo il caso in cui la legge preveda espressamente che la denuncia all’Autorità di Polizia Giudiziaria è presupposto
necessario per attivare il procedimento amministrativo di rilascio del duplicato di documenti di riconoscimento o
comunque attestanti stati e qualità personali dell’interessato, lo smarrimento dei documenti medesimi è comprovato da
chi ne richiede il duplicato mediante dichiarazione sostitutiva. (R)
Articolo 48 (R)
Disposizioni generali in materia di dichiarazioni sostitutive
1. Le dichiarazioni sostitutive hanno la stessa validità temporale degli atti che sostituiscono.
2. Le singole amministrazioni predispongono i moduli necessari per la redazione delle dichiarazioni sostitutive, che gli
interessati hanno facoltà di utilizzare. Nei moduli per la presentazione delle dichiarazioni sostitutive le amministrazioni
inseriscono il richiamo alle sanzioni penali previste dall'articolo 76, per le ipotesi di falsità in atti e dichiarazioni
mendaci ivi indicate. Il modulo contiene anche l'informativa di cui all'articolo 10 della legge 31 dicembre 1996, n. 675.
3. In tutti i casi in cui sono ammesse le dichiarazioni sostitutive, le singole amministrazioni inseriscono la relativa
formula nei moduli per le istanze.
Articolo 49 (R)
Limiti di utilizzo delle misure di semplificazione
1. I certificati medici, sanitari, veterinari, di origine, di conformità CE, di marchi o brevetti non possono essere sostituiti
da altro documento, salvo diverse disposizioni della normativa di settore.
2. Tutti i certificati medici e sanitari richiesti dalle istituzioni scolastiche ai fini della pratica non agonistica di attività
sportive da parte dei propri alunni sono sostituiti con un unico certificato di idoneità alla pratica non agonistica di
attività sportive rilasciato dal medico di base con validità per l'intero anno scolastico.
CAPO IV
SISTEMA DI GESTIONE INFORMATICA DEI DOCUMENTI
SEZIONE I
DISPOSIZIONI SULLA GESTIONE INFORMATICA DEI DOCUMENTI
Articolo 50 (R)
Attuazione dei sistemi
1. Le pubbliche amministrazioni provvedono ad introdurre nei piani di sviluppo dei sistemi informativi automatizzati
progetti per la realizzazione di sistemi di protocollo informatico in attuazione delle disposizioni del presente testo unico.
2. Le pubbliche amministrazioni predispongono appositi progetti esecutivi per la sostituzione dei registri di protocollo
cartacei con sistemi informatici conformi alle disposizioni del presente testo unico.
3. Le pubbliche amministrazioni provvedono entro il 1° gennaio 2004 a realizzare o revisionare sistemi informativi
automatizzati finalizzati alla gestione del protocollo informatico e dei procedimenti amministrativi in conformità alle
disposizioni del presente testo unico ed alle disposizioni di legge sulla tutela della riservatezza dei dati personali,
nonché dell'articolo 15, comma 2, della legge 15 marzo 1997, n. 59 e dei relativi regolamenti di attuazione.
4. Ciascuna amministrazione individua, nell'ambito del proprio ordinamento, gli uffici da considerare ai fini della
gestione unica o coordinata dei documenti per grandi aree organizzative omogenee, assicurando criteri uniformi di
classificazione e archiviazione, nonché di comunicazione interna tra le aree stesse.
5. Le amministrazioni centrali dello Stato provvedono alla gestione informatica dei documenti presso gli uffici di
registrazione di protocollo già esistenti alla data di entrata in vigore del presente testo unico presso le direzioni generali
e le grandi ripartizioni che a queste corrispondono, i dipartimenti, gli uffici centrali di bilancio, le segreterie di
gabinetto.
17
Articolo 51(R)
Sviluppo dei sistemi informativi delle pubbliche amministrazioni
1. Le pubbliche amministrazioni adottano un piano di sviluppo dei sistemi informativi automatizzati in attuazione delle
disposizioni del presente testo unico e secondo le norme tecniche definite dall'Autorità per l'informatica della pubblica
amministrazione.
2. Le pubbliche amministrazioni provvedono a realizzare o revisionare sistemi informativi finalizzati alla totale
automazione delle fasi di produzione, gestione, diffusione ed utilizzazione dei propri dati, documenti, procedimenti ed
atti in conformità alle disposizioni del presente testo unico ed alle disposizioni di legge sulla tutela della riservatezza dei
dati personali.
3. Le pubbliche amministrazioni valutano in termini di rapporto tra costi e benefìci il recupero su supporto informatico
dei documenti e degli atti cartacei dei quali sia obbligatoria o opportuna la conservazione e provvedono alla
predisposizione dei conseguenti piani di sostituzione degli archivi cartacei con archivi informatici.
Articolo 52 (R)
Il sistema di gestione informatica dei documenti.
1. Il sistema di gestione informatica dei documenti, in forma abbreviata "sistema" deve:
a) garantire la sicurezza e l'integrità del sistema;
b) garantire la corretta e puntuale registrazione di protocollo dei documenti in entrata e in uscita;
c) fornire informazioni sul collegamento esistente tra ciascun documento ricevuto dall'amministrazione e i documenti
dalla stessa formati nell'adozione dei provvedimenti finali;
d) consentire il reperimento delle informazioni riguardanti i documenti registrati;
e) consentire, in condizioni di sicurezza, l'accesso alle informazioni del sistema da parte dei soggetti interessati, nel
rispetto delle disposizioni in materia di tutela delle persone e di altri soggetti rispetto al trattamento dei dati personali;
f) garantire la corretta organizzazione dei documenti nell’ambito del sistema di classificazione d’archivio adottato.
Articolo 53 (R)
Registrazione di protocollo
1. La registrazione di protocollo per ogni documento ricevuto o spedito dalle pubbliche amministrazioni è effettuata
mediante la memorizzazione delle seguenti informazioni:
a) numero di protocollo del documento generato automaticamente dal sistema e registrato in forma non modificabile;
b) data di registrazione di protocollo assegnata automaticamente dal sistema e registrata in forma non modificabile;
c) mittente per i documenti ricevuti o, in alternativa, il destinatario o i destinatari per i documenti spediti, registrati in
forma non modificabile;
d) oggetto del documento, registrato in forma non modificabile;
e) data e protocollo del documento ricevuto, se disponibili;
f) l’impronta del documento informatico, se trasmesso per via telematica, costituita dalla sequenza di simboli binari in
grado di identificarne univocamente il contenuto, registrata in forma non modificabile.
2. Il sistema deve consentire la produzione del registro giornaliero di protocollo, costituito dall’elenco delle
informazioni inserite con l'operazione di registrazione di protocollo nell’arco di uno stesso giorno.
3. L'assegnazione delle informazioni nelle operazioni di registrazione di protocollo è effettuata dal sistema in unica
soluzione, con esclusione di interventi intermedi, anche indiretti, da parte dell’operatore, garantendo la completezza
dell’intera operazione di modifica o registrazione dei dati.
4. Con decreto del Presidente del Consiglio dei Ministri, su proposta dell’Autorità per l’informatica nella pubblica
amministrazione di concerto con il Ministro per la funzione pubblica, sono specificate le regole tecniche, i criteri e le
specifiche delle informazioni previste nelle operazioni di registrazione di protocollo.
5. Sono oggetto di registrazione obbligatoria i documenti ricevuti e spediti dall’amministrazione e tutti i documenti
informatici. Ne sono esclusi le gazzette ufficiali, i bollettini ufficiali e i notiziari della pubblica amministrazione, le note
di ricezione delle circolari e altre disposizioni, i materiali statistici, gli atti preparatori interni, i giornali, le riviste, i libri,
i materiali pubblicitari, gli inviti a manifestazioni e tutti i documenti già soggetti a registrazione particolare
dell'amministrazione.
18
Articolo 54 (R)
Informazioni annullate o modificate
1. Le informazioni non modificabili di cui all’articolo 53 lett. a), b), c), d), e) e f) sono annullabili con la procedura di
cui al presente articolo. Le informazioni annullate devono rimanere memorizzate nella base di dati per essere sottoposte
alle elaborazioni previste dalla procedura.
2. La procedura per indicare l’annullamento riporta, secondo i casi, una dicitura o un segno in posizione sempre visibile
e tale, comunque, da consentire la lettura di tutte le informazioni originarie unitamente alla data, all’identificativo
dell’operatore ed agli estremi del provvedimento d'autorizzazione.
Articolo 55 (R)
Segnatura di protocollo
1. La segnatura di protocollo è l’apposizione o l’associazione all’originale del documento, in forma permanente non
modificabile, delle informazioni riguardanti il documento stesso. Essa consente di individuare ciascun documento in
modo inequivocabile. Le informazioni minime previste sono:
a) il progressivo di protocollo, secondo il formato disciplinato all’articolo 57;
b) la data di protocollo;
c) l'identificazione in forma sintetica dell’amministrazione o dell’area organizzativa individuata ai sensi dell'articolo 50,
comma 4.
2. L’operazione di segnatura di protocollo va effettuata contemporaneamente all'operazione di registrazione di
protocollo.
3. L'operazione di segnatura di protocollo può includere il codice identificativo dell’ufficio cui il documento è
assegnato o il codice dell’ufficio che ha prodotto il documento, l’indice di classificazione del documento e ogni altra
informazione utile o necessaria, qualora tali informazioni siano disponibili già al momento della registrazione di
protocollo.
4. Quando il documento è indirizzato ad altre amministrazioni ed è formato e trasmesso con strumenti informatici, la
segnatura di protocollo può includere tutte le informazioni di registrazione del documento. L'amministrazione che
riceve il documento informatico può utilizzare tali informazioni per automatizzare le operazioni di registrazione di
protocollo del documento ricevuto.
5. Con Decreto del Presidente del Consiglio dei Ministri, su proposta dell’Autorità per l’informatica nella pubblica
Amministrazione di concerto con il Ministro per la funzione pubblica, sono stabiliti il formato e la struttura delle
informazioni associate al documento informatico ai sensi del comma 4.
Articolo 56 (R)
Operazioni ed informazioni minime del sistema di gestione informatica dei documenti
1. Le operazioni di registrazione indicate all’articolo 53 e le operazioni di segnatura di protocollo di cui all’articolo 55
nonché le operazioni di classificazione costituiscono operazioni necessarie e sufficienti per la tenuta del sistema di
gestione informatica dei documenti da parte delle pubbliche amministrazioni.
Articolo 57 (R)
Numero di protocollo
1. Il numero di protocollo è progressivo e costituito da almeno sette cifre numeriche. La numerazione è rinnovata ogni
anno solare.
SEZIONE SECONDA
ACCESSO AI DOCUMENTI E ALLE INFORMAZIONI DEL SISTEMA
Articolo 58 (R)
Funzioni di accesso ai documenti e alle informazioni del sistema
1. L’accesso al sistema da parte degli utenti appartenenti all'Amministrazione, nonché la ricerca, la visualizzazione e la
stampa di tutte le informazioni relative alla gestione dei documenti sono disciplinati dai criteri di abilitazione stabiliti
dal responsabile della tenuta del servizio di cui all’articolo 61.
19
2. La ricerca delle informazioni del sistema è effettuata secondo criteri di selezione basati su tutti i tipi di informazioni
registrate. I criteri di selezione possono essere costituiti da espressioni semplici o da combinazioni di espressioni legate
tra loro per mezzo di operatori logici. Per le informazioni costituite da testi deve essere possibile la specificazione delle
condizioni di ricerca sulle singole parole o parti di parole contenute nel testo.
3. Il sistema deve offrire la possibilità di elaborazioni statistiche sulle informazioni registrate allo scopo di favorire le
attività di controllo.
Articolo 59 (R)
Accesso esterno
1. Per l’esercizio del diritto di accesso ai documenti amministrativi, possono essere utilizzate tutte le informazioni del
sistema di gestione informatica dei documenti anche mediante l’impiego di procedure applicative operanti al di fuori del
sistema e strumenti che consentono l’acquisizione diretta delle informazioni da parte dell’interessato.
2. A tal fine le pubbliche amministrazioni determinano, nel rispetto delle disposizioni di legge sulla tutela della
riservatezza dei dati personali, e nell’ambito delle misure organizzative volte ad assicurare il diritto di accesso ai
documenti amministrativi i criteri tecnici ed organizzativi per l’impiego, anche per via telematica, del sistema di
gestione informatica dei documenti per il reperimento, la visualizzazione e la stampa delle informazioni e dei
documenti.
3. Nel caso di accesso effettuato mediante strumenti che consentono l’acquisizione diretta delle informazioni e dei
documenti da parte dell’interessato, le misure organizzative e le norme tecniche indicate al comma 2 determinano,
altresì, le modalità di identificazione del soggetto anche mediante l’impiego di strumenti informatici per la firma
digitale del documento informatico, come disciplinati dal presente testo unico.
4. Nel caso di accesso effettuato da soggetti non appartenenti alla pubblica amministrazione possono utilizzarsi le
funzioni di ricerca e di visualizzazione delle informazioni e dei documenti messe a disposizione – anche per via
telematica – attraverso gli uffici relazioni col pubblico.
Articolo 60 (R)
Accesso effettuato dalle pubbliche amministrazioni
1. Le pubbliche amministrazioni che, mediante proprie applicazioni informatiche, accedono al sistema di gestione
informatica dei documenti delle grandi aree organizzative omogenee di cui al comma 4 dell’articolo 50, adottano le
modalità di interconnessione stabilite nell’ambito delle norme e dei criteri tecnici emanati per la realizzazione della rete
unitaria delle pubbliche amministrazioni.
2. Le pubbliche amministrazioni che accedono ai sistemi di gestione informatica dei documenti attraverso la rete
unitaria delle pubbliche amministrazioni utilizzano funzioni minime e comuni di accesso per ottenere le seguenti
informazioni:
a) numero e data di registrazione di protocollo dei documenti, ottenuti attraverso l’indicazione alternativa o congiunta
dell’oggetto, della data di spedizione, del mittente, del destinatario;
b) numero e data di registrazione di protocollo del documento ricevuto, ottenuti attraverso l’indicazione della data e del
numero di protocollo attribuiti dall’amministrazione al documento spedito.
3. Ai fini del presente articolo, le pubbliche amministrazioni provvedono autonomamente, sulla base delle indicazioni
fornite dall’Autorità per l'informatica nella pubblica amministrazione, alla determinazione dei criteri tecnici ed
organizzativi per l’accesso ai documenti e alle informazioni del sistema di gestione informatica dei documenti.
SEZIONE TERZA
TENUTA E CONSERVAZIONE DEL SISTEMA DI GESTIONE DEI DOCUMENTI
Articolo 61 (R)
Servizio per la gestione informatica dei documenti dei flussi documentali e degli archivi
1. Ciascuna amministrazione istituisce un servizio per la tenuta del protocollo informatico, della gestione dei flussi
documentali e degli archivi in ciascuna delle grandi aree organizzative omogenee individuate ai sensi dell’articolo 50. Il
servizio è posto alle dirette dipendenze della stessa area organizzativa omogenea.
20
2. Al servizio è preposto un dirigente ovvero un funzionario, comunque in possesso di idonei requisiti professionali o di
professionalità tecnico archivistica acquisita a seguito di processi di formazione definiti secondo le procedure prescritte
dalla disciplina vigente.
3. Il servizio svolge i seguenti compiti:
a) attribuisce il livello di autorizzazione per l’accesso alle funzioni della procedura, distinguendo tra abilitazioni alla
consultazione e abilitazioni all'inserimento e alla modifica delle informazioni;
b) garantisce che le operazioni di registrazione e di segnatura di protocollo si svolgano nel rispetto delle disposizioni del
presente testo unico;
c) garantisce la corretta produzione e la conservazione del registro giornaliero di protocollo di cui all'articolo 53;
d) cura che le funzionalità del sistema in caso di guasti o anomalie siano ripristinate entro ventiquattro ore dal blocco
delle attività e, comunque, nel più breve tempo possibile;
e) conserva le copie di cui agli articoli 62 e 63, in luoghi sicuri differenti;
f) garantisce il buon funzionamento degli strumenti e dell'organizzazione delle attività di registrazione di protocollo, di
gestione dei documenti e dei flussi documentali, incluse le funzionalità di accesso di cui agli articoli 59e 60 e le attività
di gestione degli archivi di cui agli articoli 67, 68 e 69;
g) autorizza le operazioni di annullamento di cui all’articolo 54;
h) vigila sull’osservanza delle disposizioni del presente regolamento da parte del personale autorizzato e degli
incaricati.
Articolo 62 (R)
Procedure di salvataggio e conservazione delle informazioni del sistema
1. Il responsabile per la tenuta del sistema di gestione informatica dei documenti dispone per la corretta esecuzione delle
operazioni di salvataggio dei dati su supporto informatico rimovibile.
2. E’ consentito il trasferimento su supporto informatico rimovibile delle informazioni di protocollo relative ai fascicoli
che fanno riferimento a procedimenti conclusi.
3. Le informazioni trasferite sono sempre consultabili. A tal fine, il responsabile per la tenuta del sistema di gestione
informatica dei documenti dispone, in relazione all’evoluzione delle conoscenze scientifiche e tecnologiche, con
cadenza almeno quinquennale, la riproduzione delle informazioni del protocollo informatico su nuovi supporti
informatici.
4. Le informazioni relative alla gestione informatica dei documenti costituiscono parte integrante del sistema di
indicizzazione e di organizzazione dei documenti che sono oggetto delle procedure di conservazione sostitutiva.
Articolo 63 (R)
Registro di emergenza
1. Il responsabile del servizio per la tenuta del protocollo informatico, della gestione dei flussi documentali e degli
archivi autorizza lo svolgimento anche manuale delle operazioni di registrazione di protocollo su uno o più registri di
emergenza, ogni qualvolta per cause tecniche non sia possibile utilizzare la normale procedura informatica. Sul registro
di emergenza sono riportate la causa, la data e l'ora di inizio dell'interruzione nonché la data e l'ora del ripristino della
funzionalità del sistema. (R)
2. Qualora l’impossibilità di utilizzare la procedura informatica si prolunghi oltre ventiquattro ore, per cause di
eccezionale gravità, il responsabile per la tenuta del protocollo può autorizzare l’uso del registro di emergenza per
periodi successivi di non più di una settimana. Sul registro di emergenza vanno riportati gli estremi del provvedimento
di autorizzazione. (R)
3. Per ogni giornata di registrazione di emergenza è riportato sul registro di emergenza il numero totale di operazioni
registrate manualmente. (R)
4. La sequenza numerica utilizzata su un registro di emergenza, anche a seguito di successive interruzioni, deve
comunque garantire l’identificazione univoca dei documenti registrati nell’ambito del sistema documentario dell’area
organizzativa omogenea. (R)
5. Le informazioni relative ai documenti protocollati in emergenza sono inserite nel sistema informatico, utilizzando
un'apposita funzione di recupero dei dati, senza ritardo al ripristino delle funzionalità del sistema. Durante la fase di
ripristino, a ciascun documento registrato in emergenza viene attribuito un numero di protocollo del sistema informatico
ordinario, che provvede a mantenere stabilmente la correlazione con il numero utilizzato in emergenza. (R)
21
SEZIONE QUARTA
SISTEMA DI GESTIONE DEI FLUSSI DOCUMENTALI
Articolo 64 (R)
Sistema di gestione dei flussi documentali
1. Le pubbliche amministrazioni provvedono in ordine alla gestione dei procedimenti amministrativi mediante sistemi
informativi automatizzati, valutando i relativi progetti in termini di rapporto tra costi e benefici, sulla base delle
indicazioni fornite dall’Autorità per l'informatica nella pubblica amministrazione.
2. I sistemi per la gestione dei flussi documentali che includono i procedimenti amministrativi di cui al comma 1 è
finalizzata al miglioramento dei servizi e al potenziamento dei supporti conoscitivi delle amministrazioni secondo i
criteri di economicità, di efficacia dell'azione amministrativa e di pubblicità stabiliti dalla legge.
3. Il sistema per la gestione dei flussi documentali include il sistema di gestione informatica dei documenti.
4. Le amministrazioni determinano autonomamente e in modo coordinato per le aree organizzative omogenee, le
modalità di attribuzione dei documenti ai fascicoli che li contengono e ai relativi procedimenti, definendo adeguati piani
di classificazione d’archivio per tutti i documenti, compresi quelli non soggetti a registrazione di protocollo.
Articolo 65 (R)
Requisiti del sistema per la gestione dei flussi documentali
1. Oltre a possedere i requisiti indicati all'articolo 52, il sistema per la gestione dei flussi documentali deve :
a) fornire informazioni sul legame esistente tra ciascun documento registrato, il fascicolo ed il singolo procedimento cui
esso è associato;.43
b) consentire il rapido reperimento delle informazioni riguardanti i fascicoli, il procedimento ed il relativo responsabile,
nonché la gestione delle fasi del procedimento;
c) fornire informazioni statistiche sull'attività dell'ufficio;
d) consentire lo scambio di informazioni con sistemi per la gestione dei flussi documentali di altre amministrazioni al
fine di determinare lo stato e l'iter dei procedimenti complessi.
Articolo 66 (R)
Specificazione delle informazioni previste dal sistema di gestione dei flussi documentali
1. Le regole tecniche, i criteri e le specifiche delle informazioni previste, delle operazioni di registrazione e del formato
dei dati relativi ai sistemi informatici per la gestione dei flussi documentali sono specificate con decreto del Presidente
del Consiglio dei Ministri, su proposta dell’Autorità per l’informatica nella pubblica amministrazione di concerto con il
Ministro della funzione pubblica.
SEZIONE QUINTA
DISPOSIZIONI SUGLI ARCHIVI
Articolo 67 (R)
Trasferimento dei documenti all’archivio di deposito
1. Almeno una volta ogni anno il responsabile del servizio per la gestione dei flussi documentali e degli archivi
provvede a trasferire fascicoli e serie documentarie relativi a procedimenti conclusi in un apposito archivio di deposito
costituito presso ciascuna amministrazione. (R)
2. Il trasferimento deve essere attuato rispettando l’organizzazione che i fascicoli e le serie avevano nell’archivio
corrente. (R)
3. Il responsabile del servizio per la gestione dei flussi documentali e degli archivi deve formare e conservare un elenco
dei fascicoli e delle serie trasferite nell’archivio di deposito. (R)
Articolo 68 (R)
Disposizioni per la conservazione degli archivi
1. Il servizio per la gestione dei flussi documentali e degli archivi elabora ed aggiorna il piano di conservazione degli
archivi, integrato con il sistema di classificazione, per la definizione dei criteri di organizzazione dell’archivio, di
22
selezione periodica e di conservazione permanente dei documenti, nel rispetto delle vigenti disposizioni contenute in
materia di tutela dei beni culturali e successive modificazioni ed integrazioni.
2. Dei documenti prelevati dagli archivi deve essere tenuta traccia del movimento effettuato e della richiesta di
prelevamento.
3. Si applicano in ogni caso, per l’archiviazione e la custodia dei documenti contenenti dati personali, le disposizioni di
legge sulla tutela della riservatezza dei dati personali.
Articolo 69 (R)
Archivi storici
1. I documenti selezionati per la conservazione permanente sono trasferiti contestualmente agli strumenti che ne
garantiscono l’accesso, negli Archivi di Stato competenti per territorio o nella separata sezione di archivio secondo
quanto previsto dalle vigenti disposizioni in materia di tutela dei beni culturali.
SEZIONE SESTA
ATTUAZIONE ED AGGIORNAMENTO DEI SISTEMI
Articolo 70 (R)
Aggiornamenti del sistema
1. Le pubbliche amministrazioni devono assicurare, per ogni aggiornamento del sistema, il pieno recupero e la
riutilizzazione delle informazioni acquisite con le versioni precedenti.
CAPO V
CONTROLLI
Articolo 71 (R)
Modalità dei controlli
1. Le amministrazioni procedenti sono tenute ad effettuare idonei controlli, anche a campione, e in tutti i casi in cui
sorgono fondati dubbi, sulla veridicità delle dichiarazioni sostitutive di cui agli articoli 46 e 47. (R)
2. I controlli riguardanti dichiarazioni sostitutive di certificazione sono effettuati dall’amministrazione procedente con
le modalità di cui all’articolo 43 consultando direttamente gli archivi dell’amministrazione certificante ovvero
richiedendo alla medesima, anche attraverso strumenti informatici o telematici, conferma scritta della corrispondenza di
quanto dichiarato con le risultanze dei registri da questa custoditi. (R)
3. Qualora le dichiarazioni di cui agli articoli 46 e 47 presentino delle irregolarità o delle omissioni rilevabili ’ufficio,
non costituenti falsità, il funzionario competente a ricevere la documentazione dà notizia all’interessato di tale
irregolarità. Questi è tenuto alla regolarizzazione o al completamento della dichiarazione; in mancanza il procedimento
non ha seguito. (R)
4. Qualora il controllo riguardi dichiarazioni sostitutive presentate ai privati che vi consentono di cui all’articolo 2,
l’amministrazione competente per il rilascio della relativa certificazione, previa definizione di appositi accordi, è tenuta
a fornire, su richiesta del soggetto privato corredata dal consenso del dichiarante, conferma scritta, anche attraverso
l’uso di strumenti informatici o telematici, della corrispondenza di quanto dichiarato con le risultanze dei dati da essa
custoditi. (R)
Articolo 72(R)
Responsabilità dei controlli
1. Ai fini dei controlli di cui all’articolo 71 le amministrazione certificanti individuano e rendono note le misure
organizzative adottate per l’efficiente, efficace e tempestiva esecuzione dei controlli medesimi e le modalità per la loro
esecuzione. (R)
2. La mancata risposta alle richieste di controllo entro trenta giorni costituisce violazione dei doveri d’ufficio. (R)
23
CAPO VI
SANZIONI
Articolo 73 (L)
Assenza di responsabilità della pubblica amministrazione
1. Le pubbliche amministrazioni e i loro dipendenti, salvi i casi di dolo o colpa grave, sono esenti da ogni responsabilità
per gli atti emanati, quando l’emanazione sia conseguenza di false dichiarazioni o di documenti falsi o contenenti dati
non più rispondenti a verità, prodotti dall’interessato o da terzi.
Articolo 74 (L-R)
Violazione dei doveri d’ufficio
1. Costituisce violazione dei doveri d’ufficio la mancata accettazione delle dichiarazioni sostitutive di certificazione o di
atto di notorietà rese a norma delle disposizioni del presente testo unico; (L)
2. Costituiscono altresì violazioni dei doveri d’ufficio:
a) la richiesta di certificati o di atti di notorietà nei casi in cui, ai sensi dell’articolo 43, ci sia l’obbligo del dipendente di
accettare la dichiarazione sostitutiva; (R)
b) il rifiuto da parte del dipendente addetto di accettare l’attestazione di stati, qualità personali e fatti mediante
l’esibizione di un documento di riconoscimento; (R)
c) la richiesta e la produzione, da parte rispettivamente degli ufficiali di stato civile e dei direttori sanitari, del certificato
di assistenza al parto ai fini della formazione dell’atto di nascita. (R).
Articolo 75 (R)
Decadenza dai benefici
1. Fermo restando quanto previsto dall'articolo 76, qualora dal controllo di cui all’articolo 71 emerga la non veridicità
del contenuto della dichiarazione, il dichiarante decade dai benefici eventualmente conseguenti al provvedimento
emanato sulla base della dichiarazione non veritiera.
Articolo 76 (L)
Norme penali
1. Chiunque rilascia dichiarazioni mendaci, forma atti falsi o ne fa uso nei casi previsti dal presente testo unico è punito
ai sensi del codice penale e delle leggi speciali in materia.
2. L'esibizione di un atto contenente dati non più rispondenti a verità equivale ad uso di atto falso.
3. Le dichiarazioni sostitutive rese ai sensi degli articoli 46 e 47 e le dichiarazioni rese per conto delle persone indicate
nell'articolo 4, comma 2, sono considerate come fatte a pubblico ufficiale.
4. Se i reati indicati nei commi 1, 2 e 3 sono commessi per ottenere la nomina ad un pubblico ufficio o l'autorizzazione
all'esercizio di una professione o arte, il giudice, nei casi più gravi, può applicare l'interdizione temporanea dai pubblici
uffici o dalla professione e arte.
CAPO VII
DISPOSIZIONI FINALI
Articolo 77 (L-R)
Norme abrogate
1. Dalla data di entrata in vigore del presente testo unico sono abrogati: la legge 4 gennaio 1968 n.15; l’articolo 2,
comma 15, primo periodo della legge 24 dicembre 1993 n.537; l’articolo 2 commi 3, 4, 7, 9 e 10 e l’articolo 3 commi 1,
4, 5, e 11 come sostituito dall’articolo 2, comma 10 della legge 16 giugno 1998, n. 191, della legge 15 maggio 1997 n.
127; l’articolo 2, comma 11 della citata legge 16 giugno 1998 n. 191; gli articoli 2 e 3 della legge 24 novembre 2000,
n.340; l’articolo 55, comma 3 della legge 21 novembre 2000, n.342. (L)
Articolo 78 (L-R)
Norme che rimangono in vigore
1. Dalla data di entrata in vigore del presente testo unico restano comunque in vigore:
24
a) le vigenti disposizioni legislative e regolamentari in materia di trasmissione delle dichiarazioni fiscali di cui al D.P.R.
22 luglio 1998, n.322, al D.P.R. 14 ottobre 1999, n.542, al D.P.R. 10 marzo 2000, n.100, al decreto direttoriale 31 luglio
1998, al decreto direttoriale 29 marzo 2000, al D.M.31 maggio 1999, n.164, e le disposizioni di cui al decreto
legislativo 31 marzo 1998, n. 109 concernenti la dichiarazione sostitutiva unica per la determinazione dell’indicatore
della situazione economica equivalente dei soggetti che richiedono prestazioni sociali agevolate;
b) il D.P.R.26 ottobre 1972 n.642 in materia di imposta di bollo;
c) gli articoli 18 e 30 della legge 7 agosto 1990 n. 241;
d ) l’articolo 2, comma 15, secondo periodo della legge 24 dicembre 1993 n.537;
e) le disposizioni in materia di dati personali di cui alla legge 31 dicembre 1996, n. 675 e ai decreti legislativi adottati in
attuazione delle leggi 31 dicembre 1996, n. 676 e 6 ottobre 1998, n. 344;
f) fino alla loro sostituzione, i regolamenti ministeriali, le direttive e i decreti ministeriali a contenuto generale, nonché
le regole tecniche già emanate alla data di entrata in vigore del presente testo unico;
g) tutte le disposizioni legislative in materia di conservazione di beni archivistici di cui al capo II del d.Lgs. 29 ottobre
1999, n. 490.
2. Per le forze di polizia, restano in vigore, con riferimento agli articoli 43, comma 4, 59 e 60, le particolari disposizioni
di legge e di regolamento concernenti i trattamenti di dati personali da parte delle forze dell’ordine, ai sensi dell’articolo
4 legge 31 dicembre 1996, n. 675.
25
Decreto del Presidente del Consiglio dei Ministri 8 febbraio 1999
Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la
validazione, anche temporale, dei documenti informatici ai sensi dell’articolo 3, comma 1, del Decreto del
Presidente della Repubblica, 10 novembre 1997, n. 513
(Gazzetta ufficiale n. 87 Serie generale parte prima del 15 aprile 1999)
Art. 1 - Art. 2 - Art. 3
Allegato tecnico:
Art. 1 - Definizioni
Art. 2 - Algoritmi di generazione e verifica delle firme digitali
Art. 3 - Algoritmi di hash
Art. 4 - Caratteristiche generali delle chiavi
Art. 5 - Generazione delle chiavi
Art. 6 - Modalità di generazione delle chiavi
Art. 7 - Generazione delle chiavi al di fuori del dispositivo di firma
Art. 8 - Conservazione delle chiavi
Art. 9 - Formato della firma
Art. 10 - Generazione e verifica delle firme
Art. 11 - Informazioni contenute nei certificati
Art. 12 - Formato dei certificati
Art. 13 - Modalità di accesso al registro dei certificati
Art. 14 - Chiavi dell’Autorità per l’informatica nella Pubblica Amministrazione
Art. 15 - Elenco pubblico dei certificatori
Art. 16 - Richiesta di iscrizione all’elenco pubblico dei certificatori
Art. 17 - Iscrizione nell’elenco pubblico dei certificatori
Art. 18 - Verifica dei requisiti dei certificatori
Art. 19 - Generazione delle chiavi di certificazione
Art. 20 - Cessazione dell’attività
Art. 21 - Certificazione tra certificatori
Art. 22 - Registrazione dei titolari
Art. 23 - Uso di pseudonimi
Art. 24 - Obbligo di informazione
Art. 25 - Comunicazione tra certificatore e titolare
Art. 26 - Personalizzazione del dispositivo di firma
Art. 27 - Richiesta di certificazione
Art. 28 - Generazione dei certificati
Art. 29 - Revoca dei certificati relativi a chiavi di sottoscrizione
Art. 30 - Revoca su iniziativa del certificatore
Art. 31 - Revoca su richiesta del titolare
Art. 32 - Revoca su richiesta del terzo interessato
Art. 33 - Sospensione dei certificati
Art. 34 - Sospensione su iniziativa del certificatore
Art. 35 - Sospensione su richiesta del titolare
Art. 36 - Sospensione su richiesta del terzo interessato
Art. 37 - Sostituzione delle chiavi di certificazione
Art. 38 - Revoca dei certificati relativi a chiavi di certificazione
Art. 39 - Sostituzione delle chiavi dell’Autorità
Art. 40 - Revoca dei certificati relativi alle chiavi dell’Autorità
Art. 41 - Requisiti di sicurezza dei sistemi operativi
Art. 42 - Caratteristiche del sistema di generazione dei certificati
Art. 43 - Registro dei certificati
Art. 44 - Requisiti del registro dei certificati
Art. 45 - Manuale operativo
Art. 46 - Piano per la sicurezza
Art. 47 - Giornale di controllo
Art. 48 - Sistema di qualità del certificatore
Art. 49 - Organizzazione del personale del certificatore
Art. 50 - Requisiti di onorabilità del certificatore
Art. 51 - Requisiti di competenza ed esperienza del personale
Art. 52 - Validazione temporale
1
Art. 53 - Informazioni contenute nella marca temporale
Art. 54 - Chiavi di marcatura temporale
Art. 55 - Precisione dei sistemi di validazione temporale
Art. 56 - Sicurezza dei sistemi di validazione temporale
Art. 57 - Registrazione delle marche generate
Art. 58 - Richiesta di validazione temporale
Art. 59 - Protezione dei documenti informatici
Art. 60 - Estensione della validità del documento informatico
Art. 61 - Archiviazione dei documenti informatici
Art. 62 - Certificazione da parte delle Pubbliche Amministrazioni
Art. 63 - Norme transitorie
Il PRESIDENTE DEL CONSIGLIO DEI MINISTRI
Visto l’articolo 15, comma 2, della legge 15 marzo 1997, n. 59;
Visto l’articolo 3 del decreto del Presidente della Repubblica 10 novembre 1997, n. 513;
Sentita l’Autorità per l’informatica nella Pubblica Amministrazione;
Visto il decreto del Presidente del Consiglio dei Ministri del 30 ottobre 1998, con il quale sono state conferite al
Sottosegretario di Stato alla Presidenza del Consiglio dei Ministri, sen. prof. Franco Bassanini, le funzioni di
coordinamento delle attività, anche di carattere normativo, inerenti all'attuazione delle leggi 15 marzo 1997 n. 59, 15
maggio 1997 n. 127 e 16 giugno 1998 n. 191, nonché i compiti inerenti alla disciplina dei sistemi informatici presso le
pubbliche amministrazioni;
DECRETA:
Art. 1
1. Il presente decreto stabilisce le regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione,
la riproduzione e la validazione, anche temporale, dei documenti informatici, di cui all’art. 3, comma 1, del decreto del
Presidente della Repubblica 10 novembre 1997, n. 513 e detta altresì le misure tecniche, organizzative e gestionali di
cui all’art. 3, comma 3, dello stesso decreto del Presidente della Repubblica 10 novembre 1997, n. 513.
Art. 2
1. Le regole tecniche, di cui all’articolo 1, sono riportate nell’allegato tecnico del presente decreto, suddivise in cinque
titoli recanti: Regole tecniche di base, regole tecniche per la certificazione delle chiavi, regole tecniche sulla validazione
temporale e per la protezione dei documenti informatici, regole tecniche per le pubbliche amministrazioni e disposizioni
finali.
Art. 3
1. Le firme digitali certificate ai sensi dell'articolo 8, comma 4, del decreto del Presidente della Repubblica 10
novembre 1997, n. 513, sono considerate equivalenti a quelle generate in conformità con le regole tecniche stabilite dal
presente decreto.
2. I prodotti sviluppati o commercializzati in uno degli Stati membri dell'Unione Europea o dello Spazio economico
europeo in conformità dei regolamenti ivi vigenti, sono ritenuti conformi alle regole tecniche stabilite dal presente
decreto se tali regolamenti assicurano livelli equivalenti di funzionalità e sicurezza.
3. I commi 1 e 2 del presente articolo si applicano anche agli Stati non appartenenti all'Unione Europea con i quali siano
stati stipulati specifici accordi di riconoscimento reciproco.
p. il Presidente: Bassanini
2
ALLEGATO TECNICO
Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la
validazione, anche temporale, dei documenti informatici ai sensi dell’articolo 3, comma 1, del Decreto del
Presidente della Repubblica, 10 novembre 1997, n. 513.
TITOLO I
Regole tecniche di base
Art. 1 - Definizioni
1. Ai fini delle presenti regole tecniche si applicano le definizioni contenute nell’art. 1 del decreto del Presidente della
Repubblica 10 novembre 1997, n. 513. S’intende, inoltre:
a. per "titolare" di una coppia di chiavi asimmetriche, il soggetto a cui è attribuita la firma digitale generata con la
chiave privata della coppia, ovvero il responsabile del servizio o della funzione che utilizza la firma mediante
dispositivi automatici;
b. per "impronta" di una sequenza di simboli binari, la sequenza di simboli binari di lunghezza predefinita generata
mediante l’applicazione alla prima di una opportuna funzione di hash;
c. per "funzione di hash", una funzione matematica che genera, a partire da una generica sequenza di simboli binari, una
impronta in modo tale che risulti di fatto impossibile, a partire da questa, determinare una sequenza di simboli binari
che la generi, ed altresì risulti di fatto impossibile determinare una coppia di sequenze di simboli binari per le quali la
funzione generi impronte uguali.
d. per "dispositivo di firma", un apparato elettronico programmabile solo all’origine, facente parte del sistema di
validazione, in grado almeno di conservare in modo protetto le chiavi private e generare al suo interno firme digitali;
e. per "evidenza informatica", una sequenza di simboli binari che può essere elaborata da una procedura informatica;
f. per "marca temporale", un’evidenza informatica che consente la validazione temporale;
Art. 2 - Algoritmi di generazione e verifica delle firme digitali
1. Per la generazione e la verifica delle firme digitali possono essere utilizzati i seguenti algoritmi:
a. RSA (Rivest-Shamir-Adleman algorithm).
b. DSA (Digital Signature Algorithm).
Art. 3 - Algoritmi di hash
1. La generazione dell’impronta si effettua impiegando una delle seguenti funzioni di hash, definite nella norma
ISO/IEC 10118-3:1998:
a. Dedicated Hash-Function 1, corrispondente alla funzione RIPEMD-160;
b. Dedicated Hash-Function 3, corrispondente alla funzione SHA-1.
Art. 4 - Caratteristiche generali delle chiavi
1. Una coppia di chiavi può essere attribuita ad un solo titolare.
2. Se la firma del titolare viene apposta per mezzo di una procedura automatica, deve essere utilizzata una chiave
diversa da tutte le altre in possesso del sottoscrittore.
3. Se la procedura automatica fa uso di più dispositivi per apporre la firma del medesimo titolare, deve essere utilizzata
una chiave diversa per ciascun dispositivo.
4. Ai fini del presente decreto, le chiavi ed i correlati servizi, si distinguono secondo le seguenti tipologie:
a. chiavi di sottoscrizione, destinate alla generazione e verifica delle firme apposte o associate ai documenti;
b. chiavi di certificazione, destinate alla generazione e verifica delle firme apposte ai certificati ed alle loro liste di
revoca (CRL) o sospensione (CSL);
c. chiavi di marcatura temporale, destinate alla generazione e verifica delle marche temporali.
3
5. Non è consentito l’uso di una chiave per funzioni diverse da quelle previste dalla sua tipologia.
6. La lunghezza minima delle chiavi è stabilita in 1024 bit.
7. Il soggetto certificatore determina il termine di scadenza del certificato ed il periodo di validità delle chiavi in
funzione degli algoritmi impiegati, della lunghezza delle chiavi e dei servizi cui esse sono destinate.
Art. 5 - Generazione delle chiavi
1. La generazione della coppia di chiavi deve essere effettuata mediante apparati e procedure che assicurino, in rapporto
allo stato delle conoscenze scientifiche e tecnologiche, l’unicità e la robustezza della coppia generata, nonché la
segretezza della chiave privata.
2. Il sistema di generazione delle chiavi deve comunque assicurare:
a. la rispondenza della coppia ai requisiti imposti dagli algoritmi di generazione e di verifica utilizzati;
b. l’equiprobabilità di generazione di tutte le coppie possibili;
c. l’identificazione del soggetto che attiva la procedura di generazione.
3. La rispondenza dei dispositivi di generazione delle chiavi ai requisiti di sicurezza specificati nel presente articolo
deve essere verificata secondo i criteri previsti dal livello di valutazione E3 e robustezza dei meccanismi HIGH
dell’ITSEC o superiori.
Art. 6 - Modalità di generazione delle chiavi
1. La generazione delle chiavi di certificazione e marcatura temporale può essere effettuata esclusivamente dal
responsabile del servizio che utilizzerà le chiavi.
2. Le chiavi di sottoscrizione possono essere generate dal titolare o dal certificatore.
3. La generazione delle chiavi di sottoscrizione effettuata autonomamente dal titolare deve avvenire all’interno del
dispositivo di firma.
Art. 7 - Generazione delle chiavi al di fuori del dispositivo di firma
1. Se la generazione delle chiavi avviene su un sistema diverso da quello destinato all’uso della chiave privata, il
sistema di generazione deve assicurare:
a. l’impossibilità di intercettazione o recupero di qualsiasi informazione, anche temporanea, prodotta durante
l’esecuzione della procedura;
b. il trasferimento della chiave privata, in condizioni di massima sicurezza, nel dispositivo di firma in cui verrà
utilizzata.
2. Il sistema di generazione deve essere isolato, dedicato esclusivamente a questa attività ed adeguatamente protetto
contro i rischi di interferenze ed intercettazioni.
3. L’accesso al sistema deve essere controllato e ciascun utente preventivamente identificato. Ogni sessione di lavoro
deve essere registrata nel giornale di controllo.
4. Prima della generazione di una nuova coppia di chiavi, l’intero sistema deve procedere alla verifica della propria
configurazione, dell’autenticità ed integrità del software installato e dell’assenza di programmi non previsti dalla
procedura.
5. La conformità del sistema ai requisiti di sicurezza specificati nel presente articolo deve essere verificata secondo i
criteri previsti dal livello di valutazione E3 e robustezza dei meccanismi HIGH dell’ITSEC, o superiori.
Art. 8 - Conservazione delle chiavi
1. Le chiavi private sono conservate e custodite all’interno di un dispositivo di firma. È possibile utilizzare lo stesso
dispositivo per conservare più chiavi.
2. È vietata la duplicazione della chiave privata o dei dispositivi che la contengono.
4
3. Per fini particolari di sicurezza, è consentita la suddivisione della chiave privata su più dispositivi di firma.
4. Il titolare delle chiavi deve:
a. conservare con la massima diligenza la chiave privata e il dispositivo che la contiene al fine di garantirne l’integrità e
la massima riservatezza;
b. conservare le informazioni di abilitazione all’uso della chiave privata in luogo diverso dal dispositivo contenente la
chiave;
c. richiedere immediatamente la revoca delle certificazioni relative alle chiavi contenute in dispositivi di firma di cui
abbia perduto il possesso o difettosi.
Art. 9 - Formato della firma
1. Le firme generate secondo le regole contenute nel presente decreto debbono essere conformi a norme emanate da enti
riconosciuti a livello nazionale od internazionale ovvero a specifiche pubbliche (Publicly Available Specification –
PAS).
2. Alla firma digitale deve essere allegato il certificato corrispondente alla chiave pubblica da utilizzare per la verifica.
Art. 10 - Generazione e verifica delle firme
1. Gli strumenti e le procedure utilizzate per la generazione, l’apposizione e la verifica delle firme digitali debbono
presentare al sottoscrittore, chiaramente e senza ambiguità, i dati a cui la firma si riferisce e richiedere conferma della
volontà di generare la firma.
2. Il comma 1 non si applica alle firme apposte con procedura automatica, purché l’attivazione della procedura sia
chiaramente riconducibile alla volontà del sottoscrittore.
3. La generazione della firma deve avvenire all’interno di un dispositivo di firma così che non sia possibile
l’intercettazione del valore della chiave privata utilizzata.
4. Prima di procedere alla generazione della firma, il dispositivo di firma deve procedere all’identificazione del titolare.
5. La conformità degli strumenti utilizzati per la generazione delle firme ai requisiti di sicurezza imposti dal presente
decreto deve essere verificata secondo i criteri previsti dal livello di valutazione E3 e robustezza dei meccanismi HIGH
6. La conformità degli strumenti utilizzati per la verifica delle firme ai requisiti di sicurezza imposti dal presente decreto
deve essere verificata secondo i criteri previsti dal livello di valutazione E2 e robustezza dei meccanismi HIGH
Art. 11 - Informazioni contenute nei certificati
1. I certificati debbono contenere almeno le seguenti informazioni:
a. numero di serie del certificato;
b. ragione o denominazione sociale del certificatore;
c. codice identificativo del titolare presso il certificatore;
d. nome cognome e data di nascita ovvero ragione o denominazione sociale del titolare;
e. valore della chiave pubblica;
f. algoritmi di generazione e verifica utilizzabili;
g. inizio e fine del periodo di validità delle chiavi;
h. algoritmo di sottoscrizione del certificato.
2. Dal certificato deve potersi desumere in modo inequivocabile la tipologia delle chiavi.
3. Se il certificato è relativo ad una coppia di chiavi di sottoscrizione, in aggiunta alle informazioni prescritte dal comma
1, possono essere indicati:
a. eventuali limitazioni nell’uso della coppia di chiavi;
b. eventuali poteri di rappresentanza;
5
c. eventuali abilitazioni professionali.
4. Se il certificato è relativo ad una coppia di chiavi di certificazione, in aggiunta alle informazioni prescritte dal comma
1, deve essere altresì indicato l’uso delle chiavi per la certificazione.
5. Se il certificato è relativo ad una coppia di chiavi di marcatura temporale, in aggiunta alle informazioni prescritte dal
comma 1, debbono essere indicati:
a. uso delle chiavi per la marcatura temporale;
b. identificativo del sistema di marcatura temporale che utilizza le chiavi.
Art. 12 - Formato dei certificati
1. I certificati e le relative liste di revoca debbono essere conformi alla norma ISO/IEC 9594-8:1995 con le estensioni
definite nella Variante 1, ovvero alla specifica pubblica PKCS#6 e PKCS#9 e successive modificazioni o integrazioni.
Art. 13 - Modalità di accesso al registro dei certificati
1. L’accesso al registro dei certificati mantenuto da ciascun certificatore avviene secondo una modalità compatibile con
il protocollo LDAP definito nella specifica pubblica RFC 1777 e successive modificazioni o integrazioni.
2. Il certificatore ha facoltà di fornire modalità di accesso al registro dei certificati aggiuntive rispetto a quella prevista
dal comma 1.
3. Ciascun certificatore deve pubblicare gli indirizzi elettronici e telefonici attraverso cui è possibile accedere al
registro, attraverso l’elenco pubblico di cui all’articolo 8 comma 3 del decreto del Presidente della Repubblica 10
novembre 1997, n. 513.
TITOLO II
Regole tecniche per la certificazione delle chiavi
Art. 14 - Chiavi dell’Autorità per l’informatica nella Pubblica Amministrazione
1. L’Autorità per l’informatica nella Pubblica Amministrazione può delegare la certificazione delle proprie chiavi al
Centro Tecnico per l’assistenza ai soggetti che utilizzano la rete unitaria della pubblica amministrazione, istituito
dall'articolo 17, comma 19, della legge 15 maggio 1997, n. 127.
2. Per ciascuna coppia di chiavi sono pubblicati sulla Gazzetta Ufficiale della Repubblica Italiana uno o più codici
identificativi idonei per la verifica del valore della chiave pubblica.
Art. 15 - Elenco pubblico dei certificatori
1. L’elenco pubblico tenuto dall’Autorità ai sensi dell’articolo 8, comma 3 del decreto del Presidente della Repubblica
10 novembre 1997, n. 513, contiene per ogni certificatore le seguenti informazioni:
a. Ragione o denominazione sociale,
b. Sede legale,
c. Rappresentante legale,
d. Nome X.500,
e. Indirizzo Internet,
f. Elenco numeri telefonici di accesso,
g. Lista dei certificati delle chiavi di certificazione,
h. Manuale operativo,
i. Data di cessazione e certificatore sostitutivo.
L’elenco pubblico è sottoscritto dall’Autorità per l’informatica nella Pubblica Amministrazione.
6
Art. 16 - Richiesta di iscrizione all’elenco pubblico dei certificatori
1. Chiunque intenda esercitare l’attività di certificatore deve inoltrare all’Autorità per l’informatica nella Pubblica
Amministrazione, secondo le modalità da questa definite con apposita circolare, domanda di iscrizione nell’elenco
pubblico di cui all’articolo 8, comma 3, del decreto del Presidente della Repubblica 10 novembre 1997, n. 513.
2. Alla domanda debbono essere allegati:
a. copia del manuale operativo;
b. copia del piano per la sicurezza;
c. profilo del personale responsabile della generazione delle chiavi, della emissione dei certificati e della gestione del
registro delle chiavi;
d. copia della polizza assicurativa a copertura dei rischi dell’attività e dei danni causati a terzi.
3. L’Autorità ha facoltà di chiedere integrazioni della documentazione presentata.
4. Entro 60 giorni dalla presentazione la domanda di iscrizione nell’elenco pubblico è accettata ovvero respinta con
provvedimento motivato. La richiesta di documentazione integrativa sospende il decorso dei termini.
5. Il Centro Tecnico per l’assistenza ai soggetti che utilizzano la rete unitaria della pubblica amministrazione è iscritto
nell’elenco pubblico dei certificatori con riferimento ai compiti definiti dal decreto del Presidente della Repubblica 23
dicembre 1997, n. 522 ed è tenuto all’osservanza delle disposizioni delle presenti regole tecniche.
Art. 17 - Iscrizione nell’elenco pubblico dei certificatori
1. Il certificatore, la cui domanda di iscrizione sia stata accettata, deve predisporre con l’Autorità per l’informatica nella
Pubblica Amministrazione un sistema di comunicazione sicuro attraverso il quale scambiare le informazioni previste
dal presente decreto.
2. Il certificatore deve fornire le informazioni di cui al comma 1 dell’articolo 15, nonché i certificati relativi alle proprie
chiavi di certificazione, generati conformemente alle modalità previste dall’articolo 19.
3. Il certificatore deve generare un proprio certificato per ciascuna delle chiavi di firma dell’Autorità per l’informatica
nella Pubblica Amministrazione e pubblicarlo nel proprio registro dei certificati.
4. Il certificatore deve mantenere copia della lista, sottoscritta dall’Autorità per l’informatica nella Pubblica
Amministrazione, dei certificati relativi alle chiavi di certificazione di cui all’articolo 15, comma 1, lettera g), che deve
rendere accessibile per via telematica.
Art. 18 - Verifica dei requisiti dei certificatori
1. Al verificarsi di ogni variazione dei requisiti di cui all’art. 16 o, comunque, allo scadere di un anno dalla data della
precedente richiesta o comunicazione, il certificatore deve confermare per iscritto all’Autorità per l’informatica nella
Pubblica Amministrazione la permanenza dei requisiti per l’esercizio dell’attività di certificazione.
2. Il venir meno di uno o più requisiti tra quelli indicati all’art. 16 è causa di cancellazione dall’elenco.
3. Le modalità di esecuzione delle disposizioni del presente articolo sono stabilite con circolare dell’Autorità per
l’informatica nella Pubblica Amministrazione.
4. Per l’esercizio delle attività di verifica e controllo previste dalle presenti disposizioni, l’Autorità per l'informatica
nella Pubblica Amministrazione può corrispondere con tutte le amministrazioni e chiedere ad esse notizie ed
informazioni utili allo svolgimento dei propri compiti, ai sensi dell’articolo 7, comma 4, del decreto legislativo 12
febbraio 1993, n. 39.
Art. 19 - Generazione delle chiavi di certificazione
1. La generazione delle chiavi di certificazione deve avvenire in modo conforme a quanto previsto dagli articoli 5, 6 e 7.
2. Per ciascuna chiave di certificazione il certificatore deve generare un certificato sottoscritto con la chiave privata
della coppia cui il certificato si riferisce.
7
Art. 20 - Cessazione dell’attività
1. Il certificatore che intende cessare l’attività è tenuto a comunicare all’Autorità per l’informatica nella Pubblica
Amministrazione la data di cessazione con un anticipo di almeno 6 mesi, indicando il certificatore sostitutivo ovvero il
depositario del registro dei certificati e della relativa documentazione.
2. L’Autorità per l’informatica nella Pubblica Amministrazione rende nota nell’elenco pubblico la data di cessazione
con l’indicazione del certificatore sostitutivo ovvero del depositario del registro dei certificati e della relativa
documentazione.
3. Con un anticipo di almeno 6 mesi rispetto alla cessazione dell’attività, il certificatore deve informare i possessori di
certificati da esso emessi, specificando che tutti i certificati non scaduti al momento della cessazione debbono essere
revocati.
Art. 21 - Certificazione tra certificatori
1. È consentito ai certificatori definire accordi di certificazione.
2. Con l’accordo di certificazione, un certificatore emette a favore dell’altro un certificato relativo a ciascuna chiave di
certificazione che viene riconosciuta nel proprio ambito.
3. I certificati di cui al comma 2 debbono definire la corrispondenza tra le clausole dei rispettivi manuali operativi
considerate equivalenti.
Art. 22 - Registrazione dei titolari
1. Per ottenere la certificazione di una chiave pubblica il titolare deve essere preventivamente registrato presso il
certificatore. La richiesta di registrazione deve essere redatta per iscritto e deve essere conservata a cura del certificatore
per almeno 10 anni.
2. Al momento della registrazione il certificatore deve verificare l’identità del richiedente. È data facoltà al certificatore
di definire, pubblicandole nel manuale operativo, le modalità di identificazione degli utenti.
3. Il certificatore deve attribuire a ciascun titolare registrato un codice identificativo di cui garantisce l’univocità
nell’ambito dei propri utenti. Al medesimo soggetto sono attribuiti codici identificativi distinti per ciascuno dei ruoli per
i quali egli può firmare.
Art. 23 - Uso di pseudonimi
1. I dati di cui all’art. 11, comma 1, lettera d) possono essere sostituiti, nel certificato, da uno pseudonimo.
2. La presenza di uno pseudonimo in luogo dei dati anagrafici deve essere esplicitamente indicata nel certificato.
3. Il certificatore ha l’obbligo di conservare le informazioni relative alla reale identità del titolare per almeno 10 anni
dopo la scadenza del certificato.
Art. 24 - Obbligo di informazione
1. Il certificatore deve informare espressamente il richiedente la registrazione riguardo agli obblighi da quest’ultimo
assunti in merito alla protezione della segretezza della chiave privata ed alla conservazione ed all’uso dei dispositivi di
firma.
2. Il certificatore deve informare espressamente il titolare in ordine agli accordi di certificazione stipulati con altri
certificatori ai sensi dell'articolo 21.
Art. 25 - Comunicazione tra certificatore e titolare
1. Al momento della registrazione il certificatore può fornire al titolare gli strumenti necessari per realizzare un sistema
di comunicazione sicuro che consenta, quando il titolare non disponga di ulteriori chiavi utilizzabili per la sua
autenticazione, di effettuare per via telematica le seguenti operazioni:
a. personalizzazione dei dispositivi di firma;
8
b. richiesta della certificazione di chiavi generate al di fuori dell’ambiente del certificatore;
c. richiesta di revoca immediata di un certificato.
2. In assenza del sistema di comunicazione sicuro le operazioni di cui al comma 1 debbono essere effettuate presso il
certificatore.
Art. 26 - Personalizzazione del dispositivo di firma
1. La personalizzazione del dispositivo di firma consiste in:
a. acquisizione da parte del certificatore dei dati identificativi del dispositivo di firma utilizzato e loro associazione al
titolare;
b. registrazione, nel dispositivo di firma, dei dati identificativi del titolare presso il certificatore;
c. registrazione, nel dispositivo di firma, dei certificati relativi alle chiavi di certificazione del certificatore.
2. Durante la personalizzazione del dispositivo di firma il certificatore ne verifica il corretto funzionamento.
3. La personalizzazione del dispositivo di firma è registrata nel giornale di controllo.
Art. 27 - Richiesta di certificazione
1. Il titolare che intende ottenere la certificazione di una coppia di chiavi deve inoltrare la richiesta, attraverso il sistema
di comunicazione di cui all’articolo 25, o con altro meccanismo previsto dal manuale operativo.
2. Nella richiesta debbono essere esplicitamente indicate le informazioni che il soggetto non desidera che siano inserite
nel certificato.
3. La richiesta di certificazione deve essere conservata a cura del certificatore per un periodo non inferiore ai 10 anni.
Art. 28 - Generazione dei certificati
1. Prima di emettere il certificato il certificatore deve:
a. accertarsi dell’autenticità della richiesta;
b. verificare che la chiave pubblica di cui si richiede la certificazione non sia stata certificata da uno dei certificatori
iscritti nell’elenco.
c. richiedere la prova del possesso della chiave privata e verificare il corretto funzionamento della coppia di chiavi,
eventualmente richiedendo la sottoscrizione di uno o più documenti di prova.
2. Qualora la verifica di cui alla lettera b) del comma 1 evidenzi la presenza di certificati relativi alla chiave di cui viene
richiesta la certificazione rilasciati ad un titolare diverso dal richiedente, la richiesta di certificazione deve essere
rigettata. L’evento deve essere registrato nel giornale di controllo e segnalato al titolare della chiave già certificata. Se è
stata fornita la prova di possesso di cui al comma 1 lettera c), per la chiave già certificata deve essere avviata la
procedura di revoca dei certificati secondo quanto previsto dall’articolo 30.
3. Il certificato deve essere generato con un sistema conforme a quanto previsto dall’articolo 42.
4. Il certificato deve essere pubblicato mediante inserimento nel registro dei certificati gestito dal certificatore. Il
momento della pubblicazione deve essere attestato mediante generazione di una marca temporale, che deve essere
conservata fino alla scadenza della validità della chiavi.
5. Il certificato emesso e la relativa marca temporale debbono essere inviati al titolare.
6. Per ciascun certificato emesso il certificatore deve fornire al titolare un codice riservato, da utilizzare in caso di
emergenza per l’autenticazione della eventuale richiesta di revoca del certificato.
7. La generazione dei certificati è registrata nel giornale di controllo.
Art. 29 - Revoca dei certificati relativi a chiavi di sottoscrizione
1. La revoca di un certificato determina la cessazione anticipata della sua validità.
9
2. La revoca può avvenire su richiesta del titolare o del terzo interessato di cui all’articolo 9, comma 2, lettera c) del
decreto del Presidente della Repubblica 10 novembre 1997, n. 513, ovvero su iniziativa del certificatore.
3. La revoca del certificato viene effettuata dal certificatore mediante il suo inserimento in una delle liste di certificati
revocati (CRL) da lui gestite. La revoca del certificato è efficace a partire dal momento della pubblicazione della lista
che lo contiene ed è definitiva.
4. Il momento di pubblicazione della lista deve essere asseverato mediante l’apposizione di una marca temporale.
5. Se la revoca avviene a causa della possibile compromissione della segretezza della chiave privata, il certificatore
deve procedere immediatamente alla pubblicazione dell’aggiornamento della lista di revoca.
6. La revoca dei certificati è annotata nel giornale di controllo.
Art. 30 - Revoca su iniziativa del certificatore
1. Salvo i casi di motivata urgenza, il certificatore che intende revocare un certificato deve darne comunicazione al
titolare, specificando i motivi della revoca nonché la data e l’ora a partire dalla quale il certificato non è più valido.
Art. 31 - Revoca su richiesta del titolare
1. La richiesta di revoca deve essere redatta per iscritto dal titolare specificando la motivazione della revoca e la sua
decorrenza.
2. La richiesta viene di norma inoltrata attraverso il sistema di comunicazione sicuro di cui all’articolo 25.
3. Modalità alternative di inoltro della richiesta debbono essere specificate dal certificatore nel manuale operativo.
4. Il certificatore deve verificare l’autenticità della richiesta e procedere alla revoca entro il termine richiesto. Sono
considerate autentiche le richieste inoltrate con la modalità prevista dal comma 2.
5. Se il certificatore non ha la possibilità di accertare in tempo utile l’autenticità della richiesta, procede alla sospensione
del certificato.
Art. 32 - Revoca su richiesta del terzo interessato
1. La richiesta di revoca da parte del terzo interessato di cui all’articolo 9, comma 2, lettera c) del decreto del Presidente
della Repubblica 10 novembre 1997, n. 513, deve essere inoltrata per iscritto e corredata della documentazione
giustificativa.
2. Il certificatore deve notificare la richiesta al titolare.
Art. 33 - Sospensione dei certificati
1. La validità di un certificato può essere sospesa su richiesta del titolare o del terzo interessato di cui all’articolo 9,
comma 2, lettera c) del decreto del Presidente della Repubblica 10 novembre 1997, n. 513, ovvero su iniziativa del
certificatore.
2. La sospensione del certificato è effettuata dal certificatore attraverso il suo inserimento in una delle liste dei certificati
sospesi e diviene efficace dal momento della pubblicazione della lista che lo contiene. La data e l’ora di pubblicazione
sono garantite dall’apposizione di una marca temporale.
3. La sospensione dei certificati è annotata nel giornale di controllo.
Art. 34 - Sospensione su iniziativa del certificatore
1. Il certificatore che intende sospendere un certificato deve darne preventiva comunicazione al titolare, specificando i
motivi della sospensione e la sua durata.
2. L’avvenuta sospensione del certificato deve essere notificata al titolare specificando la data e l’ora a partire dalla
quale il certificato risulta sospeso.
10
3. Se la sospensione è causata da una richiesta di revoca motivata dalla possibile compromissione della chiave, il
certificatore deve procedere immediatamente alla pubblicazione della sospensione.
Art. 35 - Sospensione su richiesta del titolare
1. La richiesta di sospensione deve essere redatta per iscritto dal titolare, specificando la motivazione ed il periodo
durante il quale la validità del certificato deve essere sospesa.
2. La richiesta viene di norma inoltrata attraverso il sistema di comunicazione sicuro di cui all’articolo 25.
3. Modalità alternative di inoltro della richiesta debbono essere specificate dal certificatore nel manuale operativo.
4. Il certificatore deve verificare l’autenticità della richiesta e procedere alla sospensione entro il termine richiesto. Sono
considerate autentiche le richieste inoltrate con la modalità prevista dal comma 2.
5. In caso di emergenza è possibile richiedere la sospensione immediata di un certificato utilizzando il codice previsto
dal comma 6 dell’articolo 28. La richiesta deve essere successivamente confermata utilizzando una delle modalità
previste dal certificatore.
Art. 36 - Sospensione su richiesta del terzo interessato
1. La richiesta di sospensione da parte del terzo interessato di cui all’articolo 9, comma 2, lettera c) del decreto del
Presidente della Repubblica 10 novembre 1997, n. 513, deve essere inoltrata per iscritto e corredata della
documentazione giustificativa.
2. Il certificatore deve notificare la richiesta al titolare.
Art. 37 - Sostituzione delle chiavi di certificazione
1. Almeno 90 giorni prima della scadenza del certificato relativo ad una chiave di certificazione il certificatore deve
avviare la procedura di sostituzione, generando, con le modalità previste dall’articolo 19, una nuova coppia di
chiavi.
2. In aggiunta al certificato previsto dal comma 1, il certificatore deve generare un certificato relativo alla nuova chiave
pubblica sottoscritto con la chiave privata della vecchia coppia ed uno relativo alla vecchia chiave pubblica sottoscritto
con la nuova chiave privata.
3. I certificati generati secondo quanto previsto dai commi 1 e 2 debbono essere forniti all’Autorità per l’informatica
nella Pubblica Amministrazione, la quale provvede all’aggiornamento della lista di cui all’articolo 15, comma 1, lettera
g) ed al suo inoltro ai certificatori per la pubblicazione ai sensi dell’articolo 17, comma 4.
Art. 38 - Revoca dei certificati relativi a chiavi di certificazione
1. La revoca del certificato relativo ad una coppia di chiavi di certificazione è consentita solo nei seguenti casi:
a. compromissione della chiave segreta;
b. guasto del dispositivo di firma;
c. cessazione dell’attività.
2. La revoca deve essere notificata entro 24 ore all’Autorità per l’informatica nella Pubblica Amministrazione ed a tutti
i possessori di certificati sottoscritti con la chiave segreta appartenente alla coppia revocata.
3. Il certificato revocato deve essere inserito in una lista di revoca aggiornata immediatamente.
4. I certificati per i quali risultino contemporaneamente compromesse sia la chiave di certificazione con cui sono stati
sottoscritti, sia quella utilizzata per la generazione della marca temporale di cui al comma 4 dell’articolo 28 debbono
essere revocati.
5. L’Autorità per l’informatica nella Pubblica Amministrazione provvede all’aggiornamento della lista di cui
all’articolo 15, comma 1, lettera g) ed al suo inoltro ai certificatori per la pubblicazione ai sensi dell’articolo 17, comma
4.
11
Art. 39 - Sostituzione delle chiavi dell’Autorità
1. Almeno 90 giorni prima della scadenza della coppia di chiavi utilizzata per la sottoscrizione dell’elenco pubblico dei
certificatori, l’Autorità per l’informatica nella Pubblica Amministrazione provvede alla generazione e certificazione di
una nuova coppia di chiavi.
2. Copia degli elementi contenuti nell’elenco pubblico dei certificatori viene sottoscritta con la nuova coppia di chiavi.
3. La lista di cui all’articolo 15, comma 1, lettera g) è inviata ai certificatori per la pubblicazione ai sensi dell’articolo
17, comma 4.
Art. 40 - Revoca dei certificati relativi alle chiavi dell’Autorità
1. I certificati relativi alle chiavi dell’Autorità per l’informatica nella Pubblica Amministrazione possono essere revocati
solo in caso di compromissione della chiave segreta ovvero di guasto del dispositivo di firma.
2. Nell’ipotesi di cui al comma 1, l’Autorità per l’informatica nella Pubblica Amministrazione richiede a ciascun
certificatore la revoca immediata del certificato ad essa rilasciato ai sensi dell’art. 17 .
3. L’Autorità per l’informatica nella Pubblica Amministrazione provvede alla sostituzione della chiave revocata
secondo quanto previsto dall’articolo 39.
Art. 41 - Requisiti di sicurezza dei sistemi operativi
1. Il sistema operativo dei sistemi di elaborazione utilizzati nelle attività di certificazione per la generazione delle
chiavi, la generazione dei certificati e la gestione del registro dei certificati, deve essere conforme almeno alle
specifiche previste dalla classe ITSEC F-C2/E2 o a quella C2 delle norme TCSEC.
2. Il requisito di cui al comma 1 non si applica al sistema operativo dei dispositivi di firma.
Art. 42 - Caratteristiche del sistema di generazione dei certificati
1. La generazione dei certificati deve avvenire su un sistema utilizzato esclusivamente per tale funzione, situato in locali
adeguatamente protetti.
2. L’entrata e l’uscita dai locali protetti deve essere registrata sul giornale di controllo.
3. L’accesso ai sistemi di elaborazione deve essere consentito, limitatamente alle funzioni assegnate, esclusivamente al
personale autorizzato, identificato attraverso un’opportuna procedura di riconoscimento da parte del sistema al
momento di apertura di ciascuna sessione.
4. L’inizio e la fine di ciascuna sessione sono registrate sul giornale di controllo.
Art. 43 - Registro dei certificati
1. Nel registro dei certificati debbono essere presenti i seguenti elementi:
a. i certificati emessi dal certificatore;
b. la lista dei certificati revocati;
c. la lista dei certificati sospesi.
2. Il certificatore può suddividere le liste dei certificati revocati e sospesi in più liste distinte.
3. Il certificatore può replicare il registro dei certificati su più siti, purché sia garantita la consistenza e l’integrità delle
copie.
4. Il registro dei certificati è accessibile a qualsiasi soggetto secondo le modalità previste dall’articolo 13.
12
Art. 44 - Requisiti del registro dei certificati
1. Il certificatore deve mantenere una copia di riferimento del registro dei certificati inaccessibile dall’esterno, allocata
su un sistema sicuro istallato in locali protetti.
2. Il certificatore deve sistematicamente verificare la conformità tra la copia operativa e la copia di riferimento del
registro dei certificati, qualsiasi discordanza deve essere immediatamente segnalata ed annotata nel registro operativo.
3. L’effettuazione delle operazioni che modificano il contenuto del registro dei certificati deve essere possibile solo per
il personale espressamente autorizzato.
4. Tutte le operazioni che modificano il contenuto del registro debbono essere registrate sul giornale di controllo.
5. La data e l’ora di inizio e fine di ogni intervallo di tempo nel quale il registro dei certificati non risulta accessibile
dall’esterno, nonché quelle relative a ogni intervallo di tempo nel quale una sua funzionalità interna non risulta
disponibile debbono essere annotate sul giornale di controllo.
6. Almeno una copia di sicurezza della copia operativa e di quella di riferimento del registro dei certificati deve essere
conservata in armadi di sicurezza distinti, situati in locali diversi.
Art. 45 - Manuale operativo
1. Il manuale operativo definisce le procedure applicate dal certificatore nello svolgimento della propria attività.
2. Il manuale operativo deve essere depositato presso l’Autorità per l’informatica nella Pubblica Amministrazione e
pubblicato a cura del certificatore in modo da essere consultabile per via telematica.
3. Il manuale deve contenere almeno le seguenti informazioni:
a. dati identificativi del certificatore;
b. dati identificativi della versione del manuale operativo;
c. responsabile del manuale operativo;
d. definizione degli obblighi del certificatore, del titolare e di quanti accedono per la verifica delle firme;
e. definizione delle responsabilità e delle eventuali limitazioni agli indennizzi;
f. tariffe;
g. modalità di identificazione e registrazione degli utenti;
h. modalità di generazione delle chiavi;
i. modalità di emissione dei certificati;
l. modalità di sospensione e revoca dei certificati;
m. modalità di sostituzione delle chiavi;
n. modalità di gestione del registro dei certificati;
o. modalità di accesso al registro dei certificati;
p. modalità di protezione della riservatezza;
q. procedure di gestione delle copie di sicurezza;
r. procedure di gestione degli eventi catastrofici.
Art. 46 - Piano per la sicurezza
Il responsabile della sicurezza deve definire un piano per la sicurezza nel quale debbono essere contenuti almeno i
seguenti elementi:
a. struttura generale, modalità operativa e struttura logistica dell’organizzazione;
b. descrizione dell’infrastruttura di sicurezza per ciascun immobile rilevante ai fini della sicurezza;
c. allocazione dei servizi e degli uffici negli immobili dell’organizzazione;
d. elenco del personale e sua allocazione negli uffici;
e. attribuzione delle responsabilità;
f. algoritmi crittografici utilizzati;
g. descrizione delle procedure utilizzate nell’attività di certificazione;
h. descrizione dei dispositivi istallati;
i. descrizione dei flussi di dati;
l. procedura di gestione delle copie di sicurezza dei dati;
m. procedura di gestione dei disastri;
13
n. analisi dei rischi;
o. descrizione delle contromisure;
p. specificazione dei controlli.
2. Il piano per la sicurezza deve essere conforme a quanto previsto dall’articolo 9, comma 2, lettera f) del decreto del
Presidente della Repubblica 10 novembre 1997, n. 513, con riguardo alla sicurezza dei dati personali.
Art. 47 - Giornale di controllo
1. Il giornale di controllo è costituito dall’insieme delle registrazioni effettuate automaticamente dai dispositivi istallati
presso il certificatore, allorché si verificano le condizioni previste dal presente decreto.
2. Le registrazioni possono essere effettuate indipendentemente anche su supporti distinti e di tipo diverso.
3. A ciascuna registrazione deve essere associata la data e l’ora in cui essa è stata effettuata.
4. Il giornale di controllo deve essere tenuto in modo da garantire l’autenticità delle annotazioni e consentire la
ricostruzione con la necessaria accuratezza di tutti gli eventi rilevanti ai fini della sicurezza.
5. L’integrità del giornale di controllo deve essere verificata con frequenza almeno mensile.
6. Le registrazioni contenute nel giornale di controllo debbono essere archiviate con le modalità previste dal presente
decreto e conservate per un periodo non inferiore a 10 anni.
Art. 48 - Sistema di qualità del certificatore
1. Entro un anno dall'avvio dell'attività di certificazione, il sistema di qualità del certificatore deve essere certificato
secondo le norme ISO 9002.
2. Il manuale della qualità deve essere depositato presso l’Autorità per l’informatica nella Pubblica Amministrazione e
disponibile presso il certificatore.
Art. 49 - Organizzazione del personale del certificatore
1. L’organizzazione del personale del certificatore deve prevedere almeno le seguenti funzioni:
a. responsabile della sicurezza;
b. responsabile della generazione e custodia delle chiavi;
c. responsabile della personalizzazione dei dispositivi di firma;
d. responsabile della generazione dei certificati;
e. responsabile della gestione del registro dei certificati;
f. responsabile della registrazione degli utenti;
g. responsabile della sicurezza dei dati;
h. responsabile della crittografia;
i. responsabile dei servizi tecnici;
l. responsabile dell’auditing.
2. È possibile attribuire al medesimo soggetto più funzioni tra quelle previste dal comma 1 purché tra loro compatibili.
3. Sono compatibili tra loro le funzioni specificate nei sottoindicati raggruppamenti:
a. generazione e custodia delle chiavi, generazione dei certificati, personalizzazione dei dispositivi di firma, crittografia,
sicurezza dei dati;
b. registrazione degli utenti, gestione del registro dei certificati, crittografia, sicurezza dei dati.
Art. 50 - Requisiti di onorabilità del certificatore
1. I requisiti di onorabilità richiesti dall’art. 8, comma 3, lettera b) del decreto del Presidente della Repubblica 10
novembre 1997, n. 513, sono quelli stabiliti con il decreto del Ministro del Tesoro, del Bilancio e della Programmazione
economica 18 marzo 1998, n. 161.
14
Art. 51 - Requisiti di competenza ed esperienza del personale
1. Il personale cui sono attribuite le funzioni previste dall’articolo 49 deve aver maturato una esperienza almeno
quinquennale nella analisi, progettazione e conduzione di sistemi informatici.
2. Per ogni aggiornamento apportato al sistema di certificazione deve essere previsto un apposito corso di
addestramento.
TITOLO III
Regole per la validazione temporale e per la protezione dei documenti informatici
Art. 52 - Validazione temporale
1. Una evidenza informatica è sottoposta a validazione temporale con la generazione di una marca temporale che le si
applichi.
2. Le marche temporali sono generate da un apposito sistema elettronico sicuro in grado di:
a. mantenere la data e l’ora conformemente a quanto richiesto dal presente decreto;
b. generare la struttura di dati contenente le informazioni specificate dall’articolo 53;
c. sottoscrivere digitalmente la struttura di dati di cui alla lettera b).
Art. 53 - Informazioni contenute nella marca temporale
1. Una marca temporale deve contenere almeno le seguenti informazioni:
a. identificativo dell’emittente;
b. numero di serie della marca temporale;
c. algoritmo di sottoscrizione della marca temporale;
d. identificativo del certificato relativo alla chiave di verifica della marca;
e. data ed ora di generazione della marca;
f. identificatore dell’algoritmo di hash utilizzato per generare l’impronta dell’evidenza informatica sottoposta a
validazione temporale;
g. valore dell’impronta dell’evidenza informatica.
2. La marca temporale può inoltre contenere un identificatore dell’oggetto a cui appartiene l’impronta di cui alla
lettera g) del comma 1.
3. La data e l’ora contenute nella marca temporale sono specificate con riferimento al Tempo Universale
Coordinato UTC.
Art. 54 - Chiavi di marcatura temporale
1. Ogni coppia di chiavi utilizzata per la validazione temporale deve essere univocamente associata ad un sistema
di validazione temporale.
2. Al fine di limitare il numero di marche temporali generate con la medesima coppia, le chiavi di marcatura
temporale debbono essere sostituite dopo non più di un mese di utilizzazione, indipendentemente dalla durata del
loro periodo di validità e senza revocare il corrispondente certificato.
3. Per la sottoscrizione dei certificati relativi a chiavi di marcatura temporale debbono essere utilizzate chiavi di
certificazione diverse da quelle utilizzate per i certificati relativi alle normali chiavi di sottoscrizione.
Art. 55 - Precisione dei sistemi di validazione temporale
1. L’ora assegnata ad una marca temporale deve corrispondere, con una differenza non superiore ad un minuto secondo
rispetto alla scala di tempo UTC(IEN), di cui al Decreto del Ministro dell’Industria, del Commercio e dell’Artigianato
30 novembre 1993, n. 591, al momento della sua generazione.
15
Art. 56 - Sicurezza dei sistemi di validazione temporale
1. Ogni sistema di validazione temporale deve produrre un registro operativo su di un supporto non riscrivibile nel quale
sono automaticamente registrati gli eventi per i quali tale registrazione è richiesta dal presente decreto.
2. Qualsiasi anomalia o tentativo di manomissione che possa modificare il funzionamento dell’apparato in modo da
renderlo incompatibile con i requisiti del presente decreto, ed in particolare con quello di cui al comma 1 dell’articolo
55, deve essere annotato sul registro operativo e causare il blocco del sistema.
3. Il blocco del sistema di validazione temporale può essere rimosso esclusivamente con l’intervento di personale
espressamente autorizzato.
4. La conformità ai requisiti di sicurezza specificati nel presente articolo deve essere verificata secondo i criteri previsti
dal livello di valutazione E2 e robustezza dei meccanismi HIGH dell’ITSEC o superiori. Per le componenti destinate
alla sottoscrizione delle marche temporali si applicano in ogni caso le disposizioni dell’articolo 10.
Art. 57 - Registrazione delle marche generate
1. Tutte le marche temporali emesse da un sistema di validazione debbono essere conservate in un apposito archivio
digitale fino alla scadenza della chiave pubblica della coppia utilizzata per la loro generazione.
Art. 58 - Richiesta di validazione temporale
1. Il certificatore stabilisce, pubblicandole nel manuale operativo, le procedure per l’inoltro della richiesta di
validazione temporale.
2. La richiesta deve contenere l’evidenza informatica alla quale le marche temporali debbono fare riferimento.
3. L’evidenza informatica può essere sostituita da una o più impronte, calcolate con funzioni di hash previste dal
manuale operativo. Debbono essere comunque accettate le funzioni di hash di cui all’articolo 3.
4. La richiesta può specificare l’emissione di più marche temporali per la stessa evidenza informatica. In tal caso
debbono essere restituite marche temporali generate con chiavi diverse.
5. La generazione delle marche temporali deve garantire un tempo di risposta, misurato come differenza tra il momento
della ricezione della richiesta e l’ora riportata nella marca temporale, non superiore al minuto primo.
Art. 59 - Protezione dei documenti informatici
1. Al solo fine di assicurare l’associazione tra documento informatico e le relative marche temporali, il certificatore può
conservare, dietro richiesta del soggetto interessato, copia del documento informatico cui la marca temporale si
riferisce.
2. Nel manuale operativo debbono essere definite le modalità di conservazione e le procedure per la richiesta del
servizio.
Art. 60 - Estensione della validità del documento informatico
1. La validità di un documento informatico, i cui effetti si protraggano nel tempo oltre il limite della validità della
chiave di sottoscrizione, può essere estesa mediante l’associazione di una o più marche temporali.
2. Prima della scadenza della marca temporale, il periodo di validità può essere ulteriormente esteso associando una
nuova marca all’evidenza informatica costituita dal documento iniziale, dalla relativa firma e dalle marche temporali già
ad esso associate.
3. La presenza di una marca temporale valida associata ad un documento informatico secondo quanto previsto dal
comma 2, garantisce la validità del documento anche in caso di compromissione della chiave di sottoscrizione, purché
la marca temporale sia stata generata antecedentemente a tale evento.
16
Art. 61 - Archiviazione dei documenti informatici
1. L’archiviazione dei documenti informatici, anche se formati secondo quanto previsto dall’articolo 6, comma 3, del
decreto del Presidente della Repubblica 10 novembre 1997, n. 513, può essere effettuata con le modalità previste dalla
deliberazione 30 luglio 1998, n. 24 dell’Autorità per l’informatica nella Pubblica Amministrazione e successive
modificazioni ed integrazioni.
2. Per i documenti informatici si applicano le procedure previste per i documenti formati all’origine su supporto
informatico di cui all’articolo 6, comma 1, lettera b) della deliberazione indicata al comma 1.
3. Ai documenti informatici non si applicano le restrizioni di formato previste dall’articolo 6, comma 1, lettera b) della
deliberazione. Il responsabile dell’archiviazione può convertire il documento informatico in uno di tali formati,
mantenendo nell’archivio il documento originale come versione iniziale del documento archiviato.
TITOLO IV
Regole tecniche per le pubbliche amministrazioni
Art. 62 - Certificazione da parte delle Pubbliche Amministrazioni
1. Secondo quanto previsto dall’articolo 17 del decreto del Presidente della Repubblica 10 novembre 1997, n. 513, le
pubbliche amministrazioni provvedono autonomamente alla certificazioni delle chiavi pubbliche dei propri organi ed
uffici, nell'attività amministrativa di loro competenza, osservando le regole tecniche e di sicurezza previste dagli articoli
precedenti. A tal fine possono avvalersi dei servizi offerti da certificatori inclusi nell’elenco pubblico di cui all’articolo
8 dello stesso decreto, nel rispetto delle norme vigenti per l'aggiudicazione delle pubbliche forniture.
2. Restano salve le disposizioni del decreto del Presidente della Repubblica 23 dicembre 1997, n. 522, con riferimento
ai compiti di certificazione e di validazione temporale del Centro Tecnico per l'assistenza ai soggetti che utilizzano la
rete unitaria delle pubbliche amministrazioni, in conformità alle disposizioni dei regolamenti previsti dall'articolo 15,
comma 2, della legge 15 marzo 1997, n. 59.
3. Restano salve le disposizioni contenute nel decreto del Ministero delle finanze 31 luglio 1998, pubblicato nella
Gazzetta Ufficiale n. 187 del 12 agosto 1998, concernente le modalità tecniche di trasmissione telematica delle
dichiarazioni e successive modificazioni ed integrazioni.
TITOLO V
Disposizioni finali
Art. 63 - Norme transitorie
1. Le disposizioni che richiedono verifiche secondo i criteri previsti da livelli di valutazione ITSEC non si applicano nei
diciotto mesi successivi alla data di entrata in vigore delle presenti regole tecniche. Durante il periodo transitorio, il
fornitore o il certificatore, secondo le rispettive competenze, devono tuttavia attestare, mediante autodichiarazione, la
rispondenza dei dispositivi ai requisiti di sicurezza imposti dalle suddette disposizioni.
17
Decreto del Presidente del Consiglio dei Ministri 31 ottobre 2000
Regole tecniche per il protocollo informatico di cui al decreto del Presidente della Repubblica 20
ottobre 1998, n. 428.
(Gazz. Uff. n. 272 del 21 novembre 2000)
IL PRESIDENTE DEL CONSIGLIO DEI MINISTRI
Visto l'art. 15 comma 2, della legge 15 marzo 1997, n. 59, e successive modificazioni ed integrazioni;
Visto l'art. 17, comma 19, della legge 15 maggio 1997, n. 127 e successive modificazioni ed
integrazioni;
Visti gli articoli 4, 6 e 17 del decreto del Presidente della Repubblica 20 ottobre 1998, n. 428;
Visto il decreto legislativo 3 febbraio 1993, n. 29, e successive modificazioni ed integrazioni;
Visto il decreto legislativo 12 febbraio 1993, n. 39;
Visto l'art. 1, lettera h) del decreto del Presidente del Consiglio dei Ministri dell'8 maggio 2000, recante
delega di funzioni in materia di innovazione tecnologica e dei sistemi informatici e telefonici al
Ministro per la funzione pubblica sen. prof. Franco Bassanini;
Sentita l'Autorità per l'informatica nella pubblica amministrazione;
Decreta:
Titolo I
Ambito di applicazione, definizioni ed obiettivi di adeguamento delle pubbliche amministrazioni
Articolo 1.
Ambito di applicazione
1. Il presente decreto stabilisce le regole tecniche, i criteri e le specifiche delle informazioni previste
nelle operazioni di registrazione di protocollo, di cui all'art. 4, comma 4, del decreto del Presidente
della Repubblica 20 ottobre 1998, n. 428, nonché il formato e la struttura delle informazioni associate
al documento informatico, di cui all'art. 6, comma 5, del medesimo decreto.
2. Il presente decreto stabilisce altresì le regole tecniche, i criteri e le specifiche delle informazioni
previste, delle operazioni di registrazione e del formato dei dati relativi ai sistemi informatici per la
gestione dei flussi documentali, di cui all'art. 17, comma 1, del decreto del Presidente della Repubblica
20 ottobre 1998, n. 428.
Articolo 2.
Definizioni
1. Ai fini del presente decreto si intendono per:
a. "decreto del Presidente della Repubblica n. 428/1998", il decreto del Presidente della Repubblica 20
ottobre 1998, n. 428;
b. "decreto n. 29/1993", il decreto legislativo 3 febbraio 1993, n. 29, e successive modificazioni ed
integrazioni;
c. "legge n. 127/1997", la legge 15 maggio 1997, n. 127, e successive modificazioni ed integrazioni;
d. "decreto del Presidente della Repubblica n. 513/1997", il decreto del Presidente della Repubblica 10
novembre 1997, n.513;
e. "delibera AIPA 24/98", la deliberazione 30 luglio 1998, n. 24, dell'Autorità per l'informatica nella
pubblica amministrazione recante regole tecniche per l'uso di supporti ottici;
f. "funzionalità minima", la componente del sistema di protocollo informatico che rispetta i requisiti di
operazioni ed informazioni minime di cui all'art. 7 del decreto del Presidente della Repubblica n.
428/1998;
g. "funzionalità aggiuntive", le ulteriori componenti del sistema di protocollo informatico necessarie
alla gestione dei flussi documentali, alla conservazione dei documenti nonché alla accessibilità delle
informazioni;
h. "sistema di classificazione", lo strumento che permette di organizzare tutti i documenti secondo un
ordinamento logico con riferimento alle funzioni e alle attività dell'amministrazione interessata;
i. "funzionalità interoperative", le componenti del sistema finalizzate a rispondere almeno ai requisiti di
interconnessione di cui all'art. 11 del decreto del Presidente della Repubblica n. 428/1998;
l. "sessione di registrazione", ogni attività di assegnazione delle informazioni nella operazione di
registrazione di protocollo effettuata secondo le modalità previste dall'art. 4, comma 3, del decreto del
Presidente della Repubblica n. 428/1998;
m. "responsabile del servizio", il responsabile del servizio per la tenuta del protocollo informatico, per
la gestione dei flussi documentali e degli archivi di cui all'art. 12 del decreto del Presidente della
Repubblica n. 428/1998;
n. "area organizzativa omogenea", un insieme di funzioni e di strutture, individuate
dall'amministrazione, che opera su tematiche omogenee e che presenta esigenze di gestione della
documentazione in modo unitario e coordinato ai sensi dell'art. 2, comma 2, del decreto del Presidente
della Repubblica n. 428/1998;
o. "ufficio utente" di una area organizzativa omogenea, un ufficio dell'area stessa che utilizza i servizi
messi a disposizione dal sistema di protocollo informatico;
Articolo 3.
Obiettivi di adeguamento delle pubbliche amministrazioni
1. Le pubbliche amministrazioni di cui al decreto n. 29/1993 perseguono, ciascuna nell'ambito del
proprio ordinamento, nel tempo tecnico necessario, e comunque entro i termini indicati dall'art. 21 del
decreto del Presidente della Repubblica n. 428/1998, i seguenti obiettivi di adeguamento organizzativo
e funzionale:
a) l'individuazione delle aree organizzative omogenee e dei relativi uffici di riferimento ai sensi dell'art.
2 del decreto del Presidente della Repubblica n. 428/1998;
b) la nomina del responsabile del servizio per la tenuta del protocollo informatico, della gestione dei
flussi documentali e degli archivi, ai sensi dell'art. 12 del decreto del Presidente della Repubblica n.
428/1998, e conseguentemente la nomina di un suo vicario, per casi di vacanza, assenza o impedimento
del primo su proposta del medesimo;
c) l'adozione, dopo la nomina del responsabile del servizio e sulla sua proposta, del manuale di gestione
di cui all'art. 5 del presente decreto;
d. la definizione, su indicazione del responsabile del servizio, dei tempi, delle modalità e delle misure
organizzative e tecniche finalizzate alla eliminazione dei protocolli di settore e di reparto, dei protocolli
multipli, dei protocolli di telefax, e, più in generale, dei protocolli diversi dal protocollo informatico
previsto dal decreto del Presidente della Repubblica n. 428/1998.
Articolo 4.
Obiettivi e compiti particolari del responsabile del servizio
1. In attuazione dell'art. 12 del decreto del Presidente della Repubblica n. 428/1998, le pubbliche
amministrazioni di cui al decreto n. 29/1993 provvedono a definire le attribuzioni del responsabile del
servizio in modo da assicurargli, in particolare, il compito di:
a) predisporre lo schema del manuale di gestione di cui all'art. 5 del presente decreto, che deve essere
adottato dalle pubbliche amministrazioni di cui al decreto n. 29/1993 ai sensi dell'art. 2, comma 1,
lettera c), del presente decreto;
b) proporre i tempi, le modalità e le misure organizzative e tecniche di cui all'art. 3, comma 1, lettera
d), del presente decreto;
c) predisporre il piano per la sicurezza informatica relativo alla formazione, alla gestione, alla
trasmissione, all'interscambio, all'accesso, alla conservazione dei documenti informatici d'intesa con il
responsabile dei sistemi informativi automatizzati e con il responsabile della sicurezza dei dati
personali di cui alla legge 31 dicembre 1996, n. 675, e successive modificazioni ed integrazioni, e nel
rispetto delle misure minime di sicurezza previste dal regolamento di attuazione emanato con decreto
del Presidente della Repubblica 28 luglio 1999, n. 318, in attuazione dell'art. 15, comma 2, della citata
legge n. 675/1996.
Articolo 5.
Manuale di gestione
1. Il manuale di gestione descrive il sistema di gestione e di conservazione dei documenti e fornisce le
istruzioni per il corretto funzionamento del servizio.
2. Nel manuale di gestione sono riportati, in particolare:
a) la pianificazione, le modalità e le misure di cui all'art. 3, comma 1, lettera d), del presente decreto;
b) il piano di sicurezza dei documenti informatici di cui all'art. 4, comma 4, del presente decreto;
c. le modalità di utilizzo di strumenti informatici per lo scambio di documenti all'interno ed all'esterno
dell'area organizzativa omogenea;
d) la descrizione del flusso di lavorazione dei documenti ricevuti, spediti o interni, incluse le regole di
registrazione per i documenti pervenuti secondo particolari modalità di trasmissione, tra i quali, in
particolare, documenti informatici di fatto pervenuti per canali diversi da quelli previsti dall'art. 15 del
presente decreto, nonché fax, raccomandata, assicurata;
e) l'indicazione delle regole di smistamento ed assegnazione dei documenti ricevuti con la specifica dei
criteri per l'ulteriore eventuale inoltro dei documenti verso aree organizzative omogenee della stessa
amministrazione e/o verso altre amministrazioni;
f) l'indicazione delle unità organizzative responsabili delle attività di registrazione di protocollo, di
organizzazione e tenuta dei documenti all'interno dell'area organizzativa omogenea;
g) l'elenco dei documenti esclusi dalla registrazione di protocollo, ai sensi dell'art. 4, comma 5, del
decreto del Presidente della Repubblica n. 428/1998;
h) l'elenco dei documenti soggetti a registrazione particolare e le relative modalità di trattamento;
i) il sistema di classificazione, con l'indicazione delle modalità di aggiornamento, integrato con le
informazioni relative ai tempi, ai criteri e alle regole di selezione e conservazione, anche con
riferimento all'uso di supporti sostitutivi;
l) le modalità di produzione e di conservazione delle registrazioni di protocollo informatico ed in
particolare l'indicazione delle soluzioni tecnologiche ed organizzative adottate per garantire la non
modificabilità della registrazione di protocollo, la contemporaneità della stessa con l'operazione di
segnatura ai sensi dell'art. 6 del decreto del Presidente della Repubblica n. 428/1998, nonché le
modalità di registrazione delle informazioni annullate o modificate nell'ambito di ogni sessione di
attività di registrazione;
m) la descrizione funzionale ed operativa del sistema di protocollo informatico con particolare
riferimento alle modalità di utilizzo;
n) i criteri e le modalità per il rilascio delle abilitazioni di accesso interno ed esterno alle informazioni
documentali;
o) le modalità di utilizzo del registro di emergenza ai sensi dell'art. 14 del decreto del Presidente della
Repubblica n. 428/1998, inclusa la funzione di recupero dei dati protocollati manualmente.
3. Il manuale di gestione è reso pubblico dalle pubbliche amministrazioni di cui al decreto n. 29/1993
secondo le modalità previste dai singoli ordinamenti. Esso può altresì essere reso accessibile al
pubblico per via telematica ovvero su supporto informatico o cartaceo.
Titolo II
Il sistema di protocollo informatico
Articolo 6.
Funzionalità
1. Il sistema di protocollo informatico comprende almeno la "funzionalità minima".
2. Le pubbliche amministrazioni di cui al decreto n. 29/1993 valutano l'opportunità di acquisire o
realizzare le funzionalità aggiuntive sulla base del rapporto tra costi e benefici nell'ambito dei propri
obiettivi di miglioramento dei servizi e di efficienza operativa.
3. Le funzionalità aggiuntive condividono con la funzionalità minima almeno i dati identificativi dei
documenti.
Articolo 7.
Requisiti minimi di sicurezza dei sistemi di protocollo informatico
1. Il sistema operativo dell'elaboratore, su cui viene realizzato il sistema di protocollo informatico, deve
assicurare:
a) l'univoca identificazione ed autenticazione degli utenti;
b) la protezione delle informazioni relative a ciascun utente nei confronti degli altri;
c) la garanzia di accesso alle risorse esclusivamente agli utenti abilitati;
d) la registrazione delle attività rilevanti ai fini della sicurezza svolte da ciascun utente, in modo tale da
garantirne la identificazione.
2. Il sistema di protocollo informatico deve consentire il controllo differenziato dell'accesso alle risorse
del sistema per ciascun utente o gruppo di utenti.
3. Il sistema di protocollo informatico deve consentire il tracciamento di qualsiasi evento di modifica
delle informazioni trattate e l'individuazione del suo autore.
4. Le registrazioni di cui ai commi 1, lettera d), e 3 del presente articolo devono essere protette da
modifiche non autorizzate.
5. Al fine di garantire la non modificabilità delle operazioni di registrazione, il contenuto del registro
informatico di protocollo, almeno al termine della giornata lavorativa, deve essere riversato su supporti
informatici non riscrivibili e deve essere conservato da soggetto diverso dal responsabile del servizio
appositamente nominato da ciascuna amministrazione.
6. La Autorità per l'informatica nella pubblica amministrazione compila e mantiene aggiornata la lista
dei sistemi operativi disponibili commercialmente che soddisfano i requisiti minimi di sicurezza e la
rende pubblica sul proprio sito internet.
Articolo 8.
Annullamento delle informazioni registrate in forma non modificabile
1. Fra le informazioni generate o assegnate automaticamente dal sistema e registrate in forma non
modificabile l'annullamento anche di una sola di esse determina l'automatico e contestuale
annullamento della intera registrazione di protocollo.
2. Delle altre informazioni, registrate in forma non modificabile, l'annullamento anche di un solo
campo, che si rendesse necessario per correggere errori intercorsi in sede di immissione di dati, deve
comportare la rinnovazione del campo stesso con i dati corretti e la contestuale memorizzazione, in
modo permanente, del valore precedentemente attribuito unitamente alla data, l'ora e all'autore della
modifica; così analogamente per lo stesso campo, od ogni altro, che dovesse poi risultare errato.
3. Le informazioni originarie, successivamente annullate, vengono memorizzate secondo le modalità
specificate nell'art. 5, comma 1, del decreto del Presidente della Repubblica n. 428/1998.
Articolo 9.
Formato della segnatura di protocollo
1. Le informazioni apposte o associate al documento mediante la operazione di segnatura di cui all'art.
6, comma 1, del decreto del Presidente della Repubblica n. 428/1998 sono espresse nel seguente
formato:
a) codice identificativo dell'amministrazione;
b)codice identificativo dell'area organizzativa omogenea;
c) data di protocollo secondo il formato individuato in base alle previsioni di cui art. 18 secondo
comma del presente decreto;
d) progressivo di protocollo secondo il formato specificato all'art. 8 del decreto del Presidente della
Repubblica n. 428/1998.
Titolo III
Formato e modalità di trasmissione dei documenti informatici tra pubbliche amministrazioni
Articolo 10.
Principi generali
1. Le amministrazioni pubbliche di cui al decreto n. 29/1993, ai fini della trasmissione di documenti
informatici soggetti alla registrazione di protocollo e destinati ad altra amministrazione, adottano i
formati e le modalità definiti nel presente titolo.
2. Le amministrazioni pubbliche di cui all'art. 1 primo comma decreto legislativo n. 39/1993 realizzano
nei propri sistemi di protocollo informatico, oltre alla "funzionalità minima", anche funzionalità
interoperative che rispondono almeno ai requisiti di accesso di cui all'art. 11 del decreto del Presidente
della Repubblica n. 428/1998.
Articolo 11.
Indice delle amministrazioni pubbliche e delle aree organizzative omogenee
1. Per facilitare la trasmissione dei documenti informatici tra le amministrazioni è istituito l'indice delle
amministrazioni pubbliche e delle aree organizzative omogenee .
2. L'indice è destinato alla conservazione e alla pubblicazione dei dati di cui all'art. 12, comma 1, del
presente decreto relativi alle pubbliche amministrazioni di cui al decreto n. 29/1993 ed alle loro aree
organizzative omogenee.
3. L'indice delle amministrazioni di cui al comma 2 è gestito da un sistema informatico accessibile
tramite un sito internet in grado di permettere la consultazione delle informazioni in esso contenute da
parte delle amministrazioni e di tutti i soggetti pubblici o privati anche secondo una modalità
compatibile con il protocollo LDAP definito nella specifica pubblica RFC 1777 e successive
modificazioni o integrazioni.
4. Il sistema informatico di cui al comma 3 assicura altresì la conservazione dei dati storici relativi alle
variazioni intercorse nell'indice delle amministrazioni e delle rispettive aree organizzative omogenee,
onde consentire il corretto reperimento delle informazioni associate ad un documento protocollato
anche a seguito delle variazioni intercorse nella struttura delle aree organizzative omogenee
dell'amministrazione mittente o destinataria del documento.
Articolo 12.
Informazioni sulle amministrazioni e le aree organizzative omogenee
1. Ciascuna pubblica amministrazione di cui al decreto n. 29/1993 che intenda trasmettere documenti
informatici soggetti alla registrazione di protocollo deve accreditarsi presso l'indice di cui all'art. 11 del
presente decreto fornendo almeno le seguenti informazioni identificative relative alla amministrazione
stessa:
a) denominazione della amministrazione;
b) codice identificativo proposto per la amministrazione;
c) indirizzo della sede principale della amministrazione;
d) elenco delle proprie aree organizzative omogenee.
2. L'elenco di cui al comma 1, lettera d), comprende, per ciascuna area organizzativa omogenea:
a) la denominazione;
b) il codice identificativo;
c) la casella di posta elettronica dell'area prevista dall'art. 15, comma 3 del presente decreto;
d) il nominativo del responsabile del servizio per la tenuta del protocollo informatico, per la gestione
dei flussi documentali e degli archivi;
e) la data di istituzione;
f) la eventuale data di soppressione;
g) l'elenco degli uffici utente dell'area organizzativa omo genea.
3. Il codice associato a ciascuna area organizzativa omogenea è generato ed attribuito autonomamente
dalla relativa amministrazione.
Articolo 13.
Codice identificativo della amministrazione
1. Il codice identificativo della amministrazione viene attribuito a seguito della richiesta di
accreditamento della amministrazione nell'indice delle amministrazioni pubbliche e delle aree
organizzative omogenee di cui all'art. 11 del presente decreto.
2. Il codice identificativo della amministrazione coincide con il codice identificativo proposto di cui
all'art. 12, comma 1, lettera b) qualora esso risulti univoco.
Articolo 14.
Modalità di aggiornamento dell'indice delle amministrazioni
1. Ciascuna amministrazione comunica tempestivamente all'indice ogni successiva modifica delle
informazioni di cui all'art. 12, del presente decreto e la data di entrata in vigore delle modifiche.
2. Con la stessa tempestività ciascuna amministrazione comunica la soppressione ovvero la creazione
di una area organizzativa omogenea specificando tutti i dati previsti dall'art. 12, comma 2, del presente
decreto.
3. Le amministrazioni possono comunicare ciascuna variazione nell'insieme delle proprie aree
organizzative omogenee di cui ai commi 1 e 2 anche utilizzando i servizi telematici offerti dal sistema
informatico di gestione dell'indice delle amministrazioni pubbliche.
Articolo 15.
Modalità di trasmissione e registrazione dei documenti informatici
1. Lo scambio dei documenti soggetti alla registrazione di protocollo è effettuato mediante messaggi
conformi ai sistemi di posta elettronica compatibili con il protocollo SMTP/MIME definito nelle
specifiche pubbliche RFC 821-822, RFC 2045-2049 e successive modificazioni o integrazioni.
2. Ad ogni messaggio di posta elettronica ricevuto da una area organizzativa omogenea corrisponde
una unica operazione di registrazione di protocollo. Detta registrazione si può riferire sia al corpo del
messaggio sia ad uno o più dei file ad esso allegati.
3. Ciascuna area organizzativa omogenea istituisce una casella di posta elettronica adibita alla
protocollazione dei messaggi ricevuti. L'indirizzo di tale casella è riportato nell'indice delle
amministrazioni pubbliche.
4. I messaggi di posta elettronica ricevuti da una amministrazione che sono soggetti alla registrazione
di protocollo, vengono indirizzati, preferibilmente, alla casella di posta elettronica della area
organizzativa omogenea destinataria del messaggio.
5. L'eventuale indicazione dell'ufficio utente, ovvero del soggetto, destinatario del documento, va
riportata nella segnatura di protocollo secondo le modalità ed i formati previsti agli articoli 18 e 19 del
presente decreto.
6. Ciascuna amministrazione stabilisce autonomamente le modalità di inoltro ed assegnazione dei
documenti al singolo ufficio utente e le descrive nel manuale di gestione.
7. Qualora un documento informatico pervenga ad un ufficio utente di una area organizzativa
omogenea per canali diversi da quello previsto al comma 1, è responsabilità dell'ufficio stabilire,
secondo quanto previsto dal manuale di gestione di cui al precedente art. 5, comma 2, lettera d), se il
documento sia soggetto alla registrazione di protocollo ovvero a registrazione particolare di cui all'art.
4, comma 5, del decreto del Presidente della Repubblica n. 428/1998.
8. In aggiunta alle modalità di cui al presente titolo le amministrazioni possono utilizzare altre modalità
di trasmissione di documenti informatici purché descritte nel manuale di gestione.
Articolo 16.
Leggibilità dei documenti
1. Ciascuna amministrazione garantisce la leggibilità nel tempo di tutti i documenti trasmessi o ricevuti
adottando i formati previsti all'art. 6, comma 1, lettera b), della delibera AIPA n. 24/98 ovvero altri
formati non proprietari.
Articolo 17.
Impronta del documento informatico
1. Nell'effettuare l'operazione di registrazione di protocollo dei documenti informatici l'impronta di cui
all'art. 4, comma 1, lettera f), del decreto del Presidente della Repubblica n. 428/1998 va calcolata per
tutti i file inclusi nel messaggio di posta elettronica.
2. La generazione dell'impronta si effettua impiegando la funzione di hash, definita nella norma
ISO/IEC 10118-3:1998, Dedicated Hash-Function 3, corrispondente alla funzione SHA-1.
Articolo 18.
Segnatura di protocollo dei documenti trasmessi
1. I dati relativi alla segnatura di protocollo di un documento trasmesso da una area organizzativa
omogenea sono contenuti, un'unica volta nell'ambito dello stesso messaggio, in un file, conforme alle
specifiche dell'Extensible Markup Language (XML) 1.0 (raccomandazione W3C 10 febbraio 1998),
compatibile con un file DTD (Document Type Definition) reso disponibile attraverso il sito internet di
cui all'art. 11, comma 3 del presente decreto. Il file contiene le informazioni minime di cui al comma 1
del successivo art. 19. Le ulteriori informazioni definite al comma 2 del predetto articolo sono incluse
nello stesso file.
2. L'Autorità per l'informatica definisce ed aggiorna periodicamente con apposita circolare gli standard,
le modalità di trasmissione, il formato e le definizioni dei tipi di informazioni minime ed accessorie
comunemente scambiate tra le pubbliche amministrazioni e associate ai documenti protocollati; ne cura
la pubblicazione attraverso il proprio sito internet.
3. Per l'utilizzo di strumenti di firma digitale o di tecnologie riferibili alla realizzazione e gestione di
una PKI, si applicano le regole di interoperabilità definite con la circolare AIPA/CR/24 del 19 giugno
2000.
Articolo 19.
Informazioni da includere nella segnatura
1. Oltre alle informazioni specificate all'art. 9 le informazioni minime previste comprendono:
a) l'oggetto;
b) il mittente;
c) il destinatario o i destinatari.
2. Nella segnatura di un documento protocollato in uscita da una Amministrazione possono essere
specificate opzionalmente una o più delle seguenti informazioni:
a) indicazione della persona o dell'ufficio all'interno della struttura destinataria a cui si presume verrà
affidato il trattamento del documento;
b) indice di classificazione;
c) identificazione degli allegati;
d) informazioni sul procedimento e sul trattamento.
3. Qualora due o più amministrazioni stabiliscano di scambiarsi informazioni non previste tra quelle
definite al comma precedente, le stesse possono estendere il file di cui al comma 1 dell'art. 18, nel
rispetto delle indicazioni tecniche stabilite dall'Autorità per l'informatica, includendo le informazioni
specifiche stabilite di comune accordo.
Articolo 20.
Realizzazione dell'indice delle amministrazioni
1. La realizzazione ed il funzionamento dell'indice di cui all'art. 12 del presente decreto sono affidati al
Centro tecnico di cui all'art. 17, comma 19, della legge n. 127/1997.
Articolo 21.
Adeguamento delle regole tecniche
1. Le regole tecniche sono adeguate con cadenza almeno biennale a decorrere dalla data di entrata in
vigore del presente decreto per assicurarne la corrispondenza con le esigenze dettate dall'evoluzione
delle conoscenze scientifiche e tecnologiche.
Il presente decreto entra in vigore il giorno successivo a quello della sua pubblicazione nella Gazzetta
Ufficiale della Repubblica Italiana.
Roma, 31 ottobre 2000
p. Il Presidente: Bassanini
Decreto Legislativo 23 gennaio 2002, n. 10
"Attuazione della direttiva 1999/93/CE relativa ad un quadro comunitario per le firme
elettroniche" (Gazz. Uff. n. 39 del 15 febbraio 2002)
IL PRESIDENTE DELLA REPUBBLICA
Visti gli articoli 76 e 87 della Costituzione;
Vista la direttiva 1999/93/CE del Parlamento europeo e del Consiglio, del 13 dicembre 1999, relativa
ad un quadro comunitario per le firme elettroniche;
Vista la legge 29 dicembre 2000, n. 422, recante disposizioni per l'adempimento di obblighi derivanti
dall'appartenenza dell'Italia alla Comunita' europea - legge comunitaria 2000, che ha delegato il
Governo a recepire la citata direttiva 1999/93/CE, ricompresa nell'elenco di cui all'allegato A della
legge stessa;
Visto l'articolo 15, comma 2, della legge 15 marzo 1997, n. 59, recante delega al Governo per il
conferimento di funzioni e compiti alle regioni ed enti locali, per la riforma della pubblica
amministrazione e per la semplificazione amministrativa;
Visto il decreto del Presidente della Repubblica 28 dicembre 2000, n. 445, recante testo unico delle
disposizioni legislative e regolamentari in materia di documentazione amministrativa;
Visto l'articolo 7, comma 6, della legge 8 marzo 1999, n. 50, recante delegificazione e testi unici
concernenti procedimenti amministrativi - legge di semplificazione 1998;
Visto il decreto legislativo 12 febbraio 1993, n. 39, recante norme in materia di sistemi informativi
automatizzati delle amministrazioni pubbliche, a norma dell'articolo 2, comma 1, lettera mm), della
legge 23 ottobre 1992, n. 421;
Vista la legge 31 dicembre 1996, n. 675, recante tutela delle persone e di altri soggetti rispetto al
trattamento dei dati personali;
Visto l'articolo 146 del decreto legislativo 1° settembre 1993, n. 385, recante testo unico delle leggi in
materia bancaria e creditizia;
Vista la legge 23 agosto 1988, n. 400, recante disciplina dell'attivita' di Governo e ordinamento della
Presidenza del Consiglio dei Ministri;
Visto il decreto del Presidente del Consiglio dei Ministri in data 9 agosto 2001, pubblicato nella
Gazzetta Ufficiale n. 198 del 27 agosto 2001 recante delega di funzioni del Presidente del Consiglio dei
Ministri in materia di innovazione e tecnologie al Ministro senza portafoglio dott. Lucio Stanca;
Visto il decreto del Presidente del Consiglio dei Ministri del 27 settembre 2001, pubblicato nella
Gazzetta Ufficiale n. 242 del 17 ottobre 2001 recante istituzione del Dipartimento per l'innovazione e le
tecnologie;
Vista la deliberazione del Consiglio dei Ministri, adottata nella riunione del 21 dicembre 2001;
Sulla proposta del Ministro per le politiche comunitarie e del Ministro per l'innovazione e le tecnologie,
di concerto con i Ministri per la funzione pubblica, della giustizia, dell'economia e delle finanze,
dell'interno, delle attivita' produttive e delle comunicazioni;
Emana
il seguente decreto legislativo:
Articolo 1
1. Il presente decreto reca le disposizioni legislative per il recepimento della direttiva 1999/93/CE del
Parlamento europeo e del Consiglio, del 13 dicembre 1999, relativa ad un quadro comunitario per le
firme elettroniche.
Articolo 2
1. Ai fini del presente decreto si intende per:
a) "firma elettronica" l'insieme dei dati in forma elettronica, allegati oppure connessi tra mite
associazione logica ad altri dati elettronici, utilizzati come metodo di autenticazione informatica;
b) "certificatori" coloro che prestano servizi di certificazione delle firme elettroniche o che forniscono
altri servizi connessi alle firme elettroniche;
c) "certificatori accreditati" i certificatori accreditati in Italia ovvero in altri Stati membri dell'Unione
europea, ai sensi dell'articolo 3, paragrafo 2, della direttiva 1999/93/CE;
d) "certificati elettronici" gli attestati elettronici che collegano i dati utilizzati per verificare le firme
elettroniche ai titolari e confermano l'identita' dei titolari stessi;
e) "certificati qualificati" i certificati elettronici conformi ai requisiti di cui all'allegato I della direttiva
1999/93/CE, rilasciati da certificatori che rispondono ai requisiti fissati dall'allegato II della medesima
direttiva;
f) "dispositivo per la creazione di una firma sicura" l'apparato strumentale, usato per la creazione di una
firma elettronica, rispondente ai requisiti di cui all'articolo 10;
g) "firma elettronica avanzata" la firma elettronica ottenuta attraverso una procedura informatica che
garantisce la connessione univoca al firmatario e la sua univoca identificazione, creata con mezzi sui
quali il firmatario puo' conservare un controllo esclusivo e collegata ai dati ai quali si riferisce in modo
da consentire di rilevare se i dati stessi siano stati successivamente modificati;
h) "accreditamento facoltativo" il riconoscimento del possesso, da parte del certificatore che lo
richieda, dei requisiti del livello piu' elevato, in termini di qualita' e di sicurezza.
Articolo 3
1. L'attivita' dei certificatori stabiliti in Italia o in un altro Stato membro dell'Unione europea e' libera e
non necessita di autorizzazione preventiva.
2. La Presidenza del Consiglio dei Ministri - Dipartimento per l'innovazione e le tecnologie, di seguito
denominato: "Dipartimento", svolge funzioni di vigilanza e controllo nel settore, anche avvalendosi
dell'Autorita' per l'informatica nella pubblica amministrazione e di altre strutture pubbliche individuate
con decreto del Presidente del Consiglio dei Ministri, o, per sua delega, del Ministro per l'innovazione
e le tecnologie, di concerto con i Ministri interessati.
Articolo 4
1. I certificatori stabiliti in Italia che intendono rilasciare al pubblico certificati qualificati devono darne
avviso, anche in via telematica, prima dell'inizio dell'attivita', al Dipartimento.
2. I controlli volti ad accertare se il certificatore che emette al pubblico certificati qualificati soddisfa i
requisiti tecnici ed organizzativi previsti dal regolamento di cui all'articolo 13 sono demandati al
Dipartimento, che all'uopo puo' avvalersi degli organismi indicati nell'articolo 3, comma 2.
3. I controlli di cui al comma 2 sono effettuati d'ufficio ovvero su segnalazione motivata di soggetti
pubblici o privati.
Articolo 5
1. I certificatori che intendono conseguire dal Dipartimento il riconoscimento del possesso dei requisiti
del livello piu' elevato, in termini di qualita' e di sicurezza, possono chiedere di essere accreditati.
2. Il richiedente deve essere dotato di ulteriori requisiti, sul piano tecnico, nonche' in ordine alla
solidita' finanziaria ed alla onorabilita', rispetto a quelli richiesti per gli altri certificatori ai sensi del
regolamento di cui all'articolo 13.
3. Il Dipartimento, per il vaglio delle domande presentate ai sensi del comma 1, puo' avvalersi degli
organismi indicati nell'articolo 3, comma 2.
4. Quando accoglie la domanda, il Dipartimento dispone l'iscrizione del richiedente in un apposito
elenco pubblico, consultabile anche in via telematica, tenuto dal Dipartimento stesso.
Articolo 6
1. L'articolo 10 del testo unico delle disposizioni legislative e regolamentari in materia di
documentazione amministrativa, approvato con decreto del Presidente della Repubblica 28 dicembre
2000, n. 445, e' sostituito dal seguente:
"Art. 10 (L). (Forma ed efficacia del documento informatico). - 1. Il documento informatico ha
l'efficacia probatoria prevista dall'articolo 2712 del codice civile, riguardo ai fatti ed alle cose
rappresentate.
2. Il documento informatico, sottoscritto con firma elettronica, soddisfa il requisito legale della forma
scritta. Sul piano probatorio il documento stesso e' liberamente valutabile, tenuto conto delle sue
caratteristiche oggettive di qualita' e sicurezza. Esso inoltre soddisfa l'obbligo previsto dagli articoli
2214 e seguenti del codice civile e da ogni altra analoga disposizione legislativa o regolamentare.
3. Il documento informatico, quando e' sottoscritto con firma digitale o con un altro tipo di firma
elettronica avanzata, e la firma e' basata su di un certificato qualificato ed e' generata mediante un
dispositivo per la creazione di una firma sicura, fa inoltre piena prova, fino a querela di falso, della
provenienza delle dichiarazioni da chi l'ha sottoscritto.
4. Al documento informatico, sottoscritto con firma elettronica, in ogni caso non puo' essere negata
rilevanza giuridica ne' ammissibilita' come mezzo di prova unicamente a causa del fatto che e'
sottoscritto in forma elettronica ovvero in quanto la firma non e' basata su di un certificato qualificato
oppure non e' basata su di un certificato qualificato rilasciato da un certificatore accreditato o, infine,
perche' la firma non e' stata apposta avvalendosi di un dispositivo per la creazione di una firma sicura.
5. Le disposizioni del presente articolo si applicano anche se la firma elettronica e' basata su di un
certificato qualificato rilasciato da un certificatore stabilito in uno Stato non facente parte dell'Unione
europea, quando ricorre una delle seguenti condizioni:
a) il certificatore possiede i requisiti di cui alla direttiva 1999/93/CE del Parlamento europeo e del
Consiglio, del 13 dicembre 1999, ed e' accreditato in uno Stato membro;
b) il certificato qualificato e' garantito da un certificatore stabilito nella Comunita' europea, in possesso
dei requisiti di cui alla medesima direttiva;
c) il certificato qualificato, o il certificatore, e' riconosciuto in forza di un accordo bilaterale o
multilaterale tra la Comunita' e Paesi terzi o organizzazioni internazionali.
6. Gli obblighi fiscali relativi ai documenti informatici ed alla loro riproduzione su diversi tipi di
supporto sono assolti secondo le modalita' definite con decreto del Ministro dell'economia e delle
finanze.".
Articolo 7
1. Dopo l'articolo 28 del testo unico emanato con il decreto del Presidente della Repubblica n. 445 del
2000 e' aggiunto il seguente:
"Art. 28-bis (L). (Responsabilita' del certificatore). - 1. Il certificatore che rilascia al pubblico un
certificato qualificato o che garantisce al pubblico l'affidabilita' del certificato e' responsabile, se non
prova d'aver agito senza colpa, del danno cagionato a chi abbia fatto ragionevole affidamento:
a) sull'esattezza delle informazioni in esso contenute alla data del rilascio e sulla loro completezza
rispetto ai requisiti fissati per i certificati qualificati;
b) sulla garanzia che al momento del rilascio del certificato il firmatario detenesse i dati per la
creazione della firma corrispondenti ai dati per la verifica della firma riportati o identificati nel
certificato;
c) sulla garanzia che i dati per la creazione e per la verifica della firma possano essere usati in modo
complementare, nei casi in cui il certificatore generi entrambi.
2. Il certificatore che rilascia al pubblico un certificato qualificato e' responsabile, nei confronti dei terzi
che facciano ragionevole affidamento sul certificato stesso, dei danni provocati per effetto della
mancata registrazione della revoca o sospensione del certificato, salvo che provi d'aver agito senza
colpa.
3. Il certificatore puo' indicare, in un certificato qualificato, i limiti d'uso di detto certificato ovvero un
valore limite per i negozi per i quali puo' essere usato il certificato stesso, purche' i limiti d'uso o il
valore limite siano riconoscibili da parte dei terzi. Il certificatore non e' responsabile dei danni derivanti
dall'uso di un certificato qualificato che ecceda i limiti posti dallo stesso o derivanti dal superamento
del valore limite.".
Articolo 8
1. All'articolo 36 del testo unico emanato con il decreto del Presidente della Repubblica n. 445 del 2000
il comma 1 e' sostituito dal seguente:
"1. Le caratteristiche e le modalita' per il rilascio della carta d'identita' elettronica, del documento
d'identita' elettronico e della carta nazionale dei servizi sono definite con decreto del Presidente del
Consiglio dei Ministri, adottato su proposta del Ministro dell'interno, di concerto con il Ministro per la
funzione pubblica, con il Ministro per l'innovazione e le tecnologie e con il Ministro dell'economia e
delle finanze, sentito il Garante per la protezione dei dati personali.".
2. All'articolo 36 del testo unico emanato con il decreto del Presidente della Repubblica n. 445 del
2000, al comma 3 la lettera e) e' sostituita dalla seguente:
"e) le procedure informatiche e le informazioni che possono o debbono essere conosciute dalla
pubblica amministrazione e da altri soggetti, occorrenti per la firma elettronica.".
3. All'articolo 36 del testo unico emanato con il decreto del Presidente della Repubblica n. 445 del 2000
i commi 4 e 5 sono sostituiti dai seguenti:
"4. La carta d'identita' elettronica e la carta nazionale dei servizi possono essere utilizzate ai fini dei
pagamenti tra soggetti privati e pubbliche amministrazioni, secondo le modalita' stabilite con decreto
del Presidente del Consiglio dei Ministri o, per sua delega, del Ministro per l'innovazione e le
tecnologie, di concerto con il Ministro dell'economia e delle finanze, sentita la Banca d'Italia.
5. Con decreto del Ministro dell'interno, del Ministro per l'innovazione e le tecnologie e del Ministro
dell'economia e delle finanze, sentiti il Garante per la protezione dei dati personali e la Conferenza
Stato-citta' ed autonomie locali, sono dettate le regole tecniche e di sicurezza relative alle tecnologie e
ai materiali utilizzati per la produzione della carta di identita' elettronica, del documento di identita'
elettronico e della carta nazionale dei servizi.".
Articolo 9
1. All'articolo 38 del testo unico emanato con il decreto del Presidente della Repubblica n. 445 del
2000, il comma 2 e' sostituito dal seguente:
"2. Le istanze e le dichiarazioni inviate per via telematica sono valide:
a) se sottoscritte mediante la firma digitale, basata su di un certificato qualificato, rilasciato da un
certificatore accreditato, e generata mediante un dispositivo per la creazione di una firma sicura;
b) ovvero quando l'autore e' identificato dal sistema informatico con l'uso della carta d'identita'
elettronica o della carta nazionale dei servizi (L).".
Articolo 10
1. La conformita' dei dispositivi per la creazione di una firma sicura ai requisiti prescritti dall'allegato
III della direttiva 1999/93/CE e' accertata, in Italia, in base allo schema nazionale per la valutazione e
certificazione di sicurezza nel settore della tecnologia dell'informazione, fissato con decreto del
Presidente del Consiglio dei Ministri, o, per sua delega, del Ministro per l'innovazione e le tecnologie,
di concerto con i Ministri delle comunicazioni, delle attivita' produttive e dell'economia e delle finanze.
Lo schema nazionale non reca oneri aggiuntivi per il bilancio dello Stato ed individua l'organismo
pubblico incaricato di accreditare i centri di valutazione e di certificare le valutazioni di sicurezza. Lo
schema nazionale puo' prevedere altresi' la valutazione e la certificazione relativamente ad ulteriori
criteri europei ed internazionali, anche riguardanti altri sistemi e prodotti afferenti al settore suddetto.
2. Il decreto di cui al comma 1 fissa la data sino alla quale per l'accertamento di cui al comma stesso si
procede in base al regime transitorio previsto dall'articolo 63 delle regole tecniche per la formazione, la
trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei
documenti informatici stabilite, ai sensi dell'articolo 3, comma 1, del decreto del Presidente della
Repubblica 10 novembre 1997, n. 513, dal decreto del Presidente del Consiglio dei Ministri 8 febbraio
1999, pubblicato nella Gazzetta Ufficiale n. 87 del 15 aprile 1999, e prorogato, da ultimo, con il
decreto del Presidente del Consiglio dei Ministri 3 ottobre 2001, pubblicato nella Gazzetta Ufficiale n.
233 del 6 ottobre 2001.
3. La conformita' dei dispositivi per la creazione di una firma sicura ai requisiti prescritti dall'allegato
III della direttiva 1999/93/CE e' inoltre riconosciuta se certificata da un organismo all'uopo designato
da un altro Stato membro e notificato ai sensi dell'articolo 11, paragrafo 1, lettera b), della direttiva
stessa.
Articolo 11
1. I documenti sottoscritti con firma digitale basata su certificati rilasciati da certificatori iscritti
nell'elenco pubblico tenuto dall'Autorita' per l'informatica nella pubblica amministrazione ai sensi
dell'articolo 27, comma 3, del testo unico approvato con il decreto del Presidente della Repubblica n.
445 del 2000, producono gli effetti previsti dagli articoli 6, capoversi 1o, 2o e 3o, e 9 del presente
decreto.
2. I certificatori che, alla data di entrata in vigore del regolamento di cui all'articolo 13, risultano iscritti
nell'elenco pubblico previsto dall'articolo 27, comma 3, del testo unico approvato con il decreto del
Presidente della Repubblica n. 445 del 2000, sono iscritti d'ufficio nell'elenco pubblico previsto
dall'articolo 5 del presente decreto, ed hanno facolta' di proseguire l'attivita' gia' svolta o di iniziarne
l'esercizio, se non precedentemente avviato, con gli effetti di cui al comma 1 del presente articolo.
3. Sino alla data di entrata in vigore del regolamento di cui all'articolo 13, i certificatori di cui
all'articolo 4 sono tenuti all'osservanza delle disposizioni dell'articolo 28, comma 2, lettere a), c), e), f),
g), h) ed i), del testo unico approvato con il decreto del Presidente della Repubblica n. 445 del 2000. In
caso di cessazione dell'attivita', devono darne preventivo avviso al Dipartimento, comunicando
contestualmente la conseguente rilevazione della documentazione da parte di altro certificatore o
l'annullamento della stessa.
Articolo 12
1. Le disposizioni vigenti alla data di entrata in vigore del presente decreto che consentono di
presentare per via telematica istanze o dichiarazioni alla pubblica amministrazione o ai gestori o
esercenti di pubblici servizi secondo procedure diverse da quelle indicate nell'articolo 9 continuano ad
avere applicazione fino alla data fissata, con riferimento ai singoli settori, con decreto del Presidente
del Consiglio dei Ministri, da adottarsi, di concerto con i Ministri interessati, entro il 30 novembre
2002. La suddetta data non puo' comunque essere posteriore al 31 dicembre 2005.
Articolo 13
1. Entro trenta giorni dalla data di entrata in vigore del presente decreto e' emanato un regolamento ai
sensi dell'articolo 17, comma 2, della legge 23 agosto 1988, n. 400, anche ai fini del coordinamento
delle disposizioni del testo unico emanato con il decreto del Presidente della Repubblica 28 dicembre
2000, n. 445, con quelle recate dal presente decreto e dalla direttiva 1999/93/CE, nonche' della
fissazione dei requisiti necessari per lo svolgimento dell'attivita' dei certificatori.
2. Il regolamento e' emanato su proposta e con il concerto dei Ministri indicati nell'articolo 1, comma 2,
della legge 29 dicembre 2000, n. 422.
LEGGE 31 dicembre 1996 N. 675
Tutela delle persone e di altri soggetti rispetto al trattamento dei dati personali
Testo coordinato con le modifiche introdotte dai D.Lvi 9/5/1997 n.123, 28/7/1997 n.255, 8/5/1998
n.135, 13/5/1998 n.171, 6/11/1998 n.389, 26/2/1999 n.51, 11/5/1999 n.135, 30/7/1999 n.281,
30/7/1999 n.282 e 28/12/2001 n.467.
Le modifiche sono in corsivo.
CAPO I
PRINCIPI GENERALI
Articolo 1
Finalità e definizioni
1. La presente legge garantisce che il trattamento dei dati personali si svolga nel rispetto dei diritti,
delle libertà fondamentali, nonché della dignità delle persone fisiche, con particolare riferimento alla
riservatezza e all'identità personale; garantisce altresì i diritti delle persone giuridiche e di ogni altro
ente o associazione.
2. Ai fini della presente legge si intende:
a) per -banca di dati- qualsiasi complesso di dati personali, ripartito in una o più unità dislocate in uno
o più siti, organizzato secondo una pluralità di criteri determinati tali da facilitarne il trattamento;
b) per -trattamento- qualunque operazione o complesso di operazioni, svolti con o senza l'ausilio di
mezzi elettronici o comunque automatizzati, concernenti la raccolta, la registrazione, l'organizzazione,
la conservazione, l'elaborazione, la modificazione, la selezione, l'estrazione, il raffronto, l'utilizzo,
l'interconnessione, il blocco, la comunicazione, la diffusione, la cancellazione e la distruzione di dati;
c) per -dato personale- qualunque informazione relativa a persona fisica, persona giuridica, ente od
associazione, identificati o identificabili, anche indirettamente, mediante riferimento a qualsiasi altra
informazione, ivi compreso un numero di identificazione personale;
d) per -titolare- la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi altro
ente, associazione od organismo cui competono le decisioni in ordine alle finalità ed alle modalità del
trattamento di dati personali, ivi compreso il profilo della sicurezza;
e) per -responsabile- la persona fisica, la persona giuridica, la pubblica amministrazione e qualsiasi
altro ente, associazione od organismo preposti dal titolare al trattamento di dati personali;
f) per -interessato- la persona fisica, la persona giuridica, l'ente o l'associazione cui si riferis cono i dati
personali;
g) per -comunicazione- il dare conoscenza dei dati personali a uno o più soggetti determinati diversi
dall'interessato, in qualunque forma, anche mediante la loro messa a disposizione o consultazione;
h) per -diffusione- il dare conoscenza dei dati personali a soggetti indeterminati, in qualunque forma,
anche mediante la loro messa a disposizione o consultazione;
i) per -dato anonimo - il dato che in origine, o a seguito di trattamento, non può essere associato ad un
interessato identificato o identificabile;
l) per -blocco- la conservazione di dati personali con sospensione temporanea di ogni altra operazione
del trattamento;
m) per -Garante- l'autorità istituita ai sensi dell'articolo 30.
Articolo 2
Ambito di applicazione
1. La presente legge si applica al trattamento di dati personali da chiunque effettuato nel territorio dello
Stato.
1-bis. La presente legge si applica anche al trattamento di dati personali effettuato da chiunque è
stabilito nel territorio di un Paese non appartenente all'Unione europea e impiega, per il trattamento,
mezzi situati nel territorio dello Stato anche diversi da quelli elettronici o comunque automatizzati,
salvo che essi siano utilizzati solo ai fini di transito nel territorio dell'Unione europea. (*)
1-ter. Nei casi di cui al comma 1-bis il titolare stabilito nel territorio di un Paese non appartenente
all'Unione europea deve designare ai fini dell'applicazione della presente legge un proprio
rappresentante stabilito nel territorio dello Stato. (*)
Articolo 3
Trattamento di dati per fini esclusivamente personali
1. Il trattamento di dati personali effettuato da persone fisiche per fini esclusivamente personali non è
soggetto all'applicazione della presente legge, sempreché i dati non siano destinati ad una
comunicazione sistematica o alla diffusione.
2. Al trattamento di cui al comma 1 si applicano in ogni caso le disposizioni in tema di sicurezza dei
dati di cui all'articolo 15, nonché l'articolo 18 (*).
Articolo 4
Particolari trattamenti in ambito pubblico
1. La presente legge non si applica al trattamento di dati personali effettuato:
a) dal Centro elaborazione dati di cui all'articolo 8 della legge 1. aprile 1981, n. 121, come modificato
dall'articolo 43, comma 1, della presente legge, ovvero sui dati destinati a confluirvi in base alla legge,
nonché in virtù dell'accordo di adesione alla Convenzione di applicazione dell'Accordo di Schengen,
reso esecutivo con legge 30 settembre 1993, n. 388;
b) dagli organismi di cui agli articoli 3, 4 e 6 della legge 24 ottobre 1977, n. 801, ovvero sui dati coperti
da segreto di Stato ai sensi dell'articolo 12 della medesima legge;
c) nell'ambito del servizio del casellario giudiziale di cui al titolo IV del libro decimo del codice di
procedura penale e al regio decreto 18 giugno 1931, n. 778, e successive modificazioni, o, in base alla
legge, nell'ambito del servizio dei carichi pendenti nella materia penale;
d) in attuazione dell'articolo 371-bis, comma 3, del codice di procedura penale o, per ragioni di
giustizia, nell'ambito di uffici giudiziari, del Consiglio superiore della magistratura e del Ministero di
grazia e giustizia;
e) da altri soggetti pubblici per finalità di difesa o di sicurezza dello Stato o di prevenzione,
accertamento o repressione dei reati, in base ad espresse disposizioni di legge che prevedano
specificamente il trattamento.
2. Ai trattamenti di cui al comma 1 si applicano in ogni caso le disposizioni di cui agli articoli 9, 15, 17,
18, 31, 32, commi 6 e 7, e 36, nonché, fatta eccezione per i trattamenti di cui alla lettera b) del comma
1, le disposizioni di cui agli articoli 7 e 34.
Articolo 5
Trattamento di dati svolto senza l'ausilio di mezzi elettronici
1. Il trattamento di dati personali svolto senza l'ausilio di mezzi elettronici o comunque automatizzati è
soggetto alla medesima disciplina prevista per il trattamento effettuato con l'ausilio di tali mezzi.
Articolo 6
Trattamento di dati detenuti all'estero
1. Il trattamento nel territorio dello Stato di dati personali detenuti all'estero è soggetto alle disposizioni
della presente legge.
2. Se il trattamento di cui al comma 1 consiste in un trasferimento di dati personali fuori dal territorio
nazionale si applicano in ogni caso le disposizioni dell'articolo 28.
CAPO II
OBBLIGHI PER IL TITOLARE DEL TRATTAMENTO
Articolo 7
Notificazione
1. Il titolare che intenda procedere ad un trattamento di dati personali soggetto al campo di applicazione
della presente legge è tenuto a darne notificazione al Garante se il trattamento, in ragione delle relative
modalità o della natura dei dati personali, sia suscettibile di recare pregiudizio ai diritti e alle libertà
dell'interessato, e nei soli casi e con le modalità individuati con il regolamento di cui all'articolo 33,
comma 3(*).
2. La notificazione è effettuata preventivamente ed una sola volta, a mezzo di lettera raccomandata
ovvero con altro mezzo idoneo a certificarne la ricezione, a prescindere dal numero delle operazioni da
svolgere, nonché dalla durata del trattamento e può riguardare uno o più trattamenti con finalità
correlate. Una nuova notificazione è richiesta solo se muta taluno degli elementi che devono essere
indicati (*) e deve precedere l'effettuazione della variazione.
Le disposizioni di cui ai successivi commi 3, 4, 5, 5-bis, 5-ter, 5-quater e 5-quinquies, sono
abrogate a decorrere dalla data di entrata in vigore delle modifiche apportate al regolamento di
cui all'articolo 33, comma 3, in applicazione del comma 1 del presente articolo.
3. La notificazione è sottoscritta dal notificante e dal responsabile del trattamento.
4. La notificazione contiene:
a) il nome, la denominazione o la ragione sociale e il domicilio, la residenza o la sede del titolare;
b) le finalità e modalità del trattamento;
c) la natura dei dati, il luogo ove sono custoditi e le categorie di interessati cui i dati si riferiscono;
d) l'ambito di comunicazione e di diffusione dei dati;
e) i trasferimenti di dati previsti verso Paesi non appartenenti all'Unione europea o, qualora, riguardino
taluno dei dati di cui agli articoli 22 e 24, fuori del territorio nazionale;
f) una descrizione generale che permetta di valutare l'adeguatezza delle misure tecniche ed
organizzative adottate per la sicurezza dei dati;
g) l'indicazione della banca di dati o delle banche di dati cui si riferisce il trattamento, nonché
l'eventuale connessione con altri trattamenti o banche di dati, anche fuori del territorio nazionale;
h) il nome, la denominazione o la ragione sociale e il domicilio, la residenza o la sede del
rappresentante del titolare nel territorio dello Stato e di almeno un responsabile, da indicare nel
soggetto eventualmente designato ai fini di cui all'articolo 13 (**); in mancanza di tale indicazione si
considera responsabile il notificante;
i) la qualità e la legittimazione del notificante.
5. I soggetti tenuti ad iscriversi o che devono essere annotati nel registro delle imprese di cui all'articolo
2188 del codice civile, nonché coloro che devono fornire le informazioni di cui all'articolo 8, comma 8,
lettera d), della legge 29 dicembre 1993, n. 580, alle camere di commercio, industria, artigianato e
agricoltura, possono effettuare la notificazione per il tramite di queste ultime, secondo le modalità
stabilite con il regolamento di cui all'articolo 33, comma 3. I piccoli imprenditori e gli artigiani possono
effettuare la notificazione anche per il tramite delle rispettive rappresentanze di categoria; gli iscritti
agli albi professionali anche per il tramite dei rispettivi ordini professionali. Resta in ogni caso ferma la
disposizione di cui al comma 3.
5-bis. La notificazione in forma semplificata può non contenere taluno degli elementi di cui al comma
4, lettere b), c), e) e g), individuati dal Garante ai sensi del regolamento di cui all'articolo33, comma
3, quando il trattamento è effettuato:
a) da soggetti pubblici, esclusi gli enti pubblici economici, sulla base di espressa disposizione di legge
ai sensi degli articoli 22, comma 3 e 24, ovvero del provvedimento di cui al medesimo articolo 24;
b) nell'esercizio della professione di giornalista e per l'esclusivo perseguimento delle relative finalità,
ovvero dai soggetti indicati nel comma 4-bis dell'articolo 25, nel rispetto del codice di deontologia di
cui al medesimo articolo;
c) temporaneamente senza l'ausilio di mezzi elettronici o comunque automatizzati, ai soli fini e con le
modalità strettamente collegate all'organizzazione interna dell'attività esercitata dal titolare,
relativamente a dati non registrati in una banca di dati e diversi da quelli di cui agli articoli 22 e 24.
c-bis) per scopi storici, di ricerca scientifica e di statistica in conformità alle leggi, ai regolamenti, alla
normativa comunitaria e ai codici di deontologia e di buona condotta sottoscritti ai sensi dell'articolo
31.
5-ter. Fuori dei casi di cui all'articolo 4, il trattamento non è soggetto a notificazione quando:
a) è necessario per l'assolvimento di un compito previsto dalla legge, da un regolamento o dalla
normativa comunitaria, relativamente a dati diversi da quelli indicati negli articoli 22 e 24;
b) riguarda dati contenuti o provenienti da pubblici registri, elenchi, atti o documenti conoscibili da
chiunque, fermi restando i limiti e le modalità di cui all'articolo 20, comma 1, lettera b);
c) è effettuato per esclusive finalità di gestione del protocollo, relativamente ai dati necessari per la
classificazione della corrispondenza inviata per fini diversi da quelli di cui all'articolo 13, comma 1,
lettera e), con particolare riferimento alle generalità e ai recapiti degli interessati, alla loro qualifica e
all'organizzazione di appartenenza;
d) riguarda rubriche telefoniche o analoghe non destinate alla diffusione, utilizzate unicamente per
ragioni d'ufficio e di lavoro e comunque per fini diversi da quelli di cui all'articolo 13, comma 1,
lettera e);
e) è finalizzato unicamente all'adempimento di specifici obblighi contabili, retributivi, previdenziali,
assistenziali e fiscali, ed è effettuato con riferimento alle sole categorie di dati, di interessati e di
destinatari della comunicazione e diffusione strettamente collegate a tale adempimento, conservando i
dati non oltre il periodo necessario all'adempimento medesimo;
f) è effettuato, salvo quanto previsto dal comma 5-bis, lettera b) da liberi professionisti iscritti in albi o
elenchi professionali, per le sole finalità strettamente collegate all'adempimento di specifiche
prestazioni e fermo restando il segreto professionale;
g) è effettuato dai piccoli imprenditori di cui all'articolo 2083 del Codice civile per le sole finalità
strettamente collegate allo svolgimento dell'attività professionale esercitata, e limitatamente alle
categorie di dati di interessati, di destinatari della comunicazione e diffusione e al periodo di
conservazione dei dati necessari per il perseguimento delle finalità medesime;
h) è finalizzato alla tenuta di albi o elenchi professionali in conformità alle leggi a ai regolamenti;
i) è effettuato per esclusive finalità dell'ordinaria gestione di biblioteche, musei e mostre, in conformità
alle leggi e ai regolamenti, ovvero per la organizzazione di iniziative culturali o sportive o per la
formazione di cataloghi e bibliografie;
l) è effettuato da associazioni, fondazioni, comitati anche a carattere politico, filosofico, religioso o
sindacale, ovvero da loro organismi rappresentativi, istituiti per scopi non di lucro e per il
perseguimento di finalità lecite, relativamente a dati inerenti agli associati e ai soggetti che in
relazione a tali finalità hanno contatti regolari con l'associazione, la fondazione, il comitato o
l'organismo, fermi restando gli obblighi di informativa degli interessati e di acquisizione del consenso,
ove necessario;
m) è effettuato dalle organizzazioni di volontariato di cui alla legge 11 agosto 1991, n. 266, nei limiti
di cui alla lettera l) e nel rispetto delle autorizzazioni e delle prescrizioni di legge di cui agli articoli 22
e 23;
n) è effettuato temporaneamente ed è finalizzato esclusivamente alla pubblicazione o diffusione
occasionale di articoli, saggi e altre manifestazioni del pensiero, nel rispetto del Codice di cui
all'articolo 25;
o) è effettuato, anche con mezzi elettronici o comunque automatizzati, per la redazione di periodici o
pubblicazioni aventi finalità di informazione giuridica, relativamente a dati desunti da provvedimenti
dell'autorità giudiziaria o di altre autorità;
p) è effettuato temporaneamente per esclusive finalità di raccolta di adesioni a proposte di legge
d'iniziativa popolare, a richieste di referendum, a petizioni o ad appelli;
q) è finalizzato unicamente all'amministrazione dei condomini di cui all'articolo 1117 e seguenti del
Codice civile, limitatamente alle categorie di dati, di interessati e di destinatari della comunicazione
necessarie per l'amministrazione dei beni comuni, conservando i dati non oltre il periodo necessario
per la tutela dei corrispondenti diritti.
q-bis) è compreso nel programma statistico nazionale o in atti di programmazione statistica previsti
dalla legge ed è effettuato in conformità alle leggi, ai regolamenti, alla normativa comunitaria e ai
codici di deontologia e di buona condotta sottoscritti ai sensi dell'articolo 31.>/P>
5-quater. Il titolare si può avvalere della notificazione semplificata o dell'esonero di cui ai commi 5bis e 5-ter, sempre che il trattamento riguardi unicamente le finalità, le categorie di dati, di interessati
e di destinatari della comunicazione e diffusione individuate, unitamente al periodo di conservazione
dei dati, dai medesimi commi 5-bis e 5-ter, nonchè:
a) nei casi di cui ai commi 5-bis, lettera a) e 5-ter, lettere a) e m), dalle disposizioni di legge o di
regolamento o dalla normativa comunitaria ivi indicate;
b) nel caso di cui al comma 5-bis, lettera b), dal codice di deontologia ivi indicato;
c) nei casi residui, dal Garante, con le autorizzazioni rilasciate con le modalità previste dall'articolo
41, comma 7, ovvero, per i dati diversi da quelli di cui agli articoli 22 e 24, con provvedimenti
analoghi.
5-quinquies. Il titolare che si avvale dell'esonero di cui al comma 5-ter deve fornire gli elementi di cui
al comma 4 a chiunque ne faccia richiesta.
Articolo 8
Responsabile
1. Il responsabile, se designato, deve essere nominato tra soggetti che per esperienza, capacità ed
affidabilità forniscano idonea garanzia del pieno rispetto delle vigenti disposizioni in materia di
trattamento, ivi compreso il profilo relativo alla sicurezza.
2. Il responsabile procede al trattamento attenendosi alle istruzioni impartite dal titolare il quale, anche
tramite verifiche periodiche, vigila sulla puntuale osservanza delle disposizioni di cui al comma 1 e
delle proprie istruzioni.
3. Ove necessario per esigenze organizzative, possono essere designati responsabili più soggetti, anche
mediante suddivisione di compiti.
4. I compiti affidati al responsabile devono essere analiticamente specificati per iscritto.
5. Gli incaricati del trattamento devono elaborare i dati personali ai quali hanno accesso attenendosi
alle istruzioni del titolare o del responsabile.
CAPO III
TRATTAMENTO DEI DATI PERSONALI
SEZIONE I
Raccolta e requisiti dei dati
Articolo 9
Modalità di raccolta e requisiti dei dati personali
1. I dati personali oggetto di trattamento devono essere:
a) trattati in modo lecito e secondo correttezza;
b) raccolti e registrati per scopi determinati, espliciti e legittimi, ed utilizzati in altre operazioni del
trattamento in termini non incompatibili con tali scopi;
c) esatti e, se necessario, aggiornati;
d) pertinenti, completi e non eccedenti rispetto alle finalità per le quali sono raccolti o successivamente
trattati;
e) conservati in una forma che consenta l'identificazione dell'interessato per un periodo di tempo non
superiore a quello necessario agli scopi per i quali essi sono stati raccolti o successivamente trattati.
1-bis. Il trattamento di dati personali per scopi storici, di ricerca scientifica o di statistica è
compatibile con gli scopi per i quali i dati sono raccolti o successivamente trattati e può essere
effettuato anche oltre il periodo necessario a questi ultimi scopi.
Articolo 10
Informazioni rese al momento della raccolta
1. L'interessato o la persona presso la quale sono raccolti i dati personali devono essere previamente
informati oralmente o per iscritto circa:
a) le finalità e le modalità del trattamento cui sono destinati i dati;
b) la natura obbligatoria o facoltativa del conferimento dei dati;
c) le conseguenze di un eventuale rifiuto di rispondere;
d) i soggetti o le categorie di soggetti ai quali i dati possono essere comunicati e l'ambito di diffusione
dei dati medesimi;
e) i diritti di cui all'articolo 13;
f) il nome, la denominazione o la ragione sociale e il domicilio, la residenza o la sede del titolare, del
suo rappresentante nel territorio dello Stato e di almeno un responsabile, da indicare nel soggetto
eventualmente designato ai fini di cui all'articolo 13, indicando il sito della rete di comunicazione o le
modalità attraverso le quali è altrimenti conoscibile in modo agevole l'elenco aggiornato dei
responsabili (**).
2. L'informativa di cui al comma 1 può non comprendere gli elementi già noti alla persona che fornisce
i dati o la cui conoscenza può ostacolare l'espletamento di funzioni pubbliche ispettive o di controllo,
svolte per il perseguimento delle finalità di cui agli articoli 4, comma 1, lettera e), e 14, comma 1,
lettera d).
3. Quando i dati personali non sono raccolti presso l'interessato, l'informativa di cui al comma 1 è data
al medesimo interessato all'atto della registrazione dei dati o, qualora sia prevista la loro
comunicazione, non oltre la prima comunicazione.
4. La disposizione di cui al comma 3 non si applica quando l'informativa all'interessato comporta un
impiego di mezzi che il Garante dichiari manifestamente sproporzionati rispetto al diritto tutelato,
ovvero si rivela, a giudizio del Garante, impossibile, ovvero nel caso in cui i dati sono trattati in base ad
un obbligo previsto dalla legge, da un regolamento o dalla normativa comunitaria. La medesima
disposizione non si applica, altresì, quando i dati sono trattati ai fini dello svolgimento delle
investigazioni difensive di cui alla legge 7 dicembre 2000, n. 397 (*), o, comunque, per far valere o
difendere un diritto in sede giudiziaria, sempre che i dati siano trattati esclusivamente per tali finalità e
per il periodo strettamente necessario al loro perseguimento.
Sezione II
Diritti dell'interessato nel trattamento dei dati
Articolo 11
Consenso
1. Il trattamento di dati personali da parte di privati o di enti pubblici economici è ammesso solo con il
consenso espresso dell'interessato.
2. Il consenso può riguardare l'intero trattamento ovvero una o più operazioni dello stesso.
3. Il consenso è validamente prestato solo se è espresso liberamente, e in forma specifica e
documentata per iscritto, e se sono state rese all'interessato le informazioni di cui all'articolo 10.
Articolo 12
Casi di esclusione del consenso
1. Il consenso non è richiesto quando il trattamento:
a) riguarda dati raccolti e detenuti in base ad un obbligo previsto dalla legge, da un regolamento o dalla
normativa comunitaria;
b) è necessario per l'esecuzione di obblighi derivanti da un contratto del quale è parte l'interessato o per
l'esecuzione di misure precontrattuali adottate (*) su richiesta di quest'ultimo, ovvero per
l'adempimento di un obbligo legale;
c) riguarda dati provenienti da pubblici registri, elenchi, atti o documenti conoscibili da chiunque;
d) è finalizzato unicamente a scopi di ricerca scientifica o di statistica ed è effettuato nel rispetto dei
codici di deontologia e di buona condotta sottoscritti ai sensi dell'articolo 31;
e) è effettuato nell'esercizio della professione di giornalista e per l'esclusivo perseguimento delle
relative finalità. In tale caso, si applica il codice di deontologia di cui all'articolo 25;
f) riguarda dati relativi allo svolgimento di attività economiche raccolti anche ai fini indicati
nell'articolo 13, comma 1, lettera e), nel rispetto della vigente normativa in materia di segreto aziendale
e industriale;
g) è necessario per la salvaguardia della vita o dell'incolumità fisica dell'interessato o di un terzo, nel
caso in cui l'interessato non può prestare il proprio consenso per impossibilità fisica, per incapacità di
agire o per incapacità di intendere o di volere;
h) è necessario ai fini dello svolgimento delle investigazioni difensive di cui alla legge 7 dicembre
2000, n. 397 (*), o, comunque, per far valere o difendere un diritto in sede giudiziaria, sempre che i dati
siano trattati esclusivamente per tali finalità e per il periodo strettamente necessario al loro
perseguimento.
h-bis) è necessario, nei casi individuati dal Garante sulla base dei principi sanciti dalla legge, per
perseguire un legittimo interesse del titolare o di un terzo destinatario dei dati, qualora non
prevalgano i diritti e le libertà fondamentali, la dignità o un legittimo interesse dell'interessato (***).
Articolo 13
Diritti dell'interessato
1. In relazione al trattamento di dati personali l'interessato ha diritto:
a) di conoscere, mediante accesso gratuito al registro di cui all'articolo 31, comma 1, lettera a),
l'esistenza di trattamenti di dati che possono riguardarlo;
Le disposizioni di cui alla successiva lettera b), sono abrogate a decorrere dalla data di entrata in
vigore delle modifiche apportate al regolamento di cui all'articolo 33, comma 3, in applicazione
del comma 1 dell'articolo 7.
b) di essere informato su quanto indicato all'articolo 7, comma 4, lettere a), b) e h);
c) di ottenere, a cura del titolare o del responsabile, senza ritardo:
1) la conferma dell'esistenza o meno di dati personali che lo riguardano, anche se non ancora
registrati, e la comunicazione in forma intellegibile dei medesimi dati e della loro origine, nonché
della logica e delle finalità su cui si basa il trattamento;la richiesta può essere rinnovata, salva
l'esistenza di giustificati motivi, con intervallo non minore di novanta giorni;
2) la cancellazione, la trasformazione in forma anonima o il blocco dei dati trattati in violazione di
legge, compresi quelli di cui non è necessaria la conservazione in relazione agli scopi per i quali i dati
sono stati raccolti o successivamente trattati;
3) l'aggiornamento, la rettificazione ovvero, qualora vi abbia interesse, l'integrazione dei dati;
4) l'attestazione che le operazioni di cui ai numeri 2) e 3) sono state portate a conoscenza, anche per
quanto riguarda il loro contenuto, di coloro ai quali i dati sono stati comunicati o diffusi, eccettuato il
caso in cui tale adempimento si riveli impossibile o comporti un impiego di mezzi manifestamente
sproporzionato rispetto al diritto tutelato;
d) di opporsi, in tutto o in parte, per motivi legittimi, al trattamento dei dati personali che lo riguardano,
ancorché pertinenti allo scopo della raccolta;
e) di opporsi, in tutto o in parte, al trattamento di dati personali che lo riguardano, previsto a fini di
informazioni commerciali o di invio di materiale pubblicitario o di vendita diretta ovvero per il
compimento di ricerche di mercato o di comunicazione commerciale interattiva e di essere informato
dal titolare, non oltre il momento in cui i dati sono comunicati o diffusi, della possibilità di esercitare
gratuitamente tale diritto.
2. Per ciascuna richiesta di cui al comma 1, lettera c), numero 1), può essere chiesto all'interessato, ove
non risulti confermata l'esistenza di dati che lo riguardano, un contributo spese, non superiore ai costi
effettivamente sopportati, secondo le modalità ed entro i limiti stabiliti dal regolamento di cui
all'articolo 33, comma 3.
3. I diritti di cui al comma 1 riferiti ai dati personali concernenti persone decedute possono essere
esercitati da chiunque vi abbia interesse.
4. Nell'esercizio dei diritti di cui al comma 1 l'interessato può conferire, per iscritto, delega o procura a
persone fisiche o ad associazioni.
5. Restano ferme le norme sul segreto professionale degli esercenti la professione di giornalista,
limitatamente alla fonte della notizia.
Articolo 14
Limiti all'esercizio dei diritti
1. I diritti di cui all'articolo 13, comma 1, lettere c) e d), non possono essere esercitati nei confronti dei
trattamenti di dati personali raccolti:
a) in base alle disposizioni del decreto-legge 3 maggio 1991, n. 143, convertito, con modificazioni,
dalla legge 5 luglio 1991, n. 197, e successive modificazioni;
b) in base alle disposizioni del decreto-legge 31 dicemb re 1991, n. 419, convertito, con modificazioni,
dalla legge 18 febbraio 1992, n. 172, e successive modificazioni;
c) da Commissioni parlamentari di inchiesta istituite ai sensi dell'articolo 82 della Costituzione;
d) da un soggetto pubblico, diverso dagli enti pubblici economici, in base ad espressa disposizione di
legge, per esclusive finalità inerenti la politica monetaria e valutaria, il sistema dei pagamenti, il
controllo degli intermediari e dei mercati creditizi e finanziari nonché la tutela della loro stabilità;
e) ai sensi dell'articolo 12, comma 1, lettera h), limitatamente al periodo durante il quale potrebbe
derivarne pregiudizio per lo svolgimento delle investigazioni o per l'esercizio del diritto di cui alla
medesima lettera h).
e-bis) da fornitori di servizi di telecomunicazioni accessibili al pubblico, limitatamente ai dati
personali identificativi di chiamate telefoniche entranti, salvo che possa derivarne pregiudizio per lo
svolgimento delle investigazioni difensive di cui alla legge 7 dicembre 2000, n. 397. (*)
2. Nei casi di cui al comma 1 il Garante, anche su segnalazione dell'interessato ai sensi dell'articolo 31,
comma 1, lettera d), esegue i necessari accertamenti nei modi di cui all'articolo 32, commi 6 e 7, e
indica le necessarie modificazioni ed integrazioni, verificandone l'attuazione.
Sezione III
Sicurezza nel trattamento dei dati, limiti alla utilizzabilità dei dati e risarcimento del danno
Articolo 15
Sicurezza dei dati
1.I dati personali oggetto di trattamento devono essere custoditi e controllati, anche in relazione alle
conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche
del trattamento, in modo da ridurre al minimo, mediante l'adozione di idonee e preventive misure di
sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato
o di trattamento non consentito o non conforme alle finalità della raccolta.
2. Le misure minime di sicurezza da adottare in via preventiva sono individuate con regolamento
emanato con decreto del Presidente della Repubblica, ai sensi dell'articolo 17, comma 1, lettera a), della
legge 23 agosto 1988, n. 400, entro centottanta giorni dalla data di entrata in vigore della presente
legge, su proposta del Ministro di grazia e giustizia, sentiti l'Autorità per l'informatica nella pubblica
amministrazione e il Garante.
3. Le misure di sicurezza di cui al comma 2 sono adeguate, entro due anni dalla data di entrata in
vigore della presente legge e successivamente con cadenza almeno biennale, con successivi
regolamenti emanati con le modalità di cui al medesimo comma 2, in relazione all'evoluzione tecnica
del settore e all'esperienza maturata.
4. Le misure di sicurezza relative ai dati trattati dagli organismi di cui all'articolo 4, comma 1, lettera
b), sono stabilite con decreto del Presidente del Consiglio dei ministri con l'osservanza delle norme che
regolano la materia.
Articolo 16
Cessazione del trattamento dei dati
1. In caso di cessazione, per qualsiasi causa, del trattamento dei dati, il titolare deve notificare
preventivamente al Garante la loro destinazione.
2. I dati possono essere:
a) distrutti;
b) ceduti ad altro titolare, purché destinati ad un trattamento per finalità analoghe agli scopi per i
quali i dati sono raccolti;
c) conservati per fini esclusivamente personali e non destinati ad una comunicazione sistematica o
alla diffusione.
c-bis) conservati o ceduti ad altro titolare, per scopi storici, di ricerca scientifica e di statistica, in
conformità alla legge, ai regolamenti, alla normativa comunitaria e ai codici di deontologia e di
buona condotta sottoscritti ai sensi dell'articolo 31.
3. La cessione dei dati in violazione di quanto previsto dalla lettera b) del comma 2 o di altre
disposizioni di legge in materia di trattamento dei dati personali è nulla ed è punita ai sensi dell'articolo
39, comma 1.
Articolo 17
Limiti all'utilizzabilità di dati personali
1. Nessun atto o provvedimento giudiziario o amministrativo che implichi una valutazione del
comportamento umano può essere fondato unicamente su un trattamento automatizzato di dati
personali volto a definire il profilo o la personalità dell'interessato.
2. L'interessato può opporsi ad ogni altro tipo di decisione adottata sulla base del trattamento di cui al
comma 1 del presente articolo, ai sensi dell'articolo 13, comma 1, lettera d), salvo che la decisione sia
stata adottata in occasione della conclusione o dell'esecuzione di un contratto, in accoglimento di una
proposta dell'interessato o sulla base di adeguate garanzie individuate dalla legge.
Articolo 18
Danni cagionati per effetto del trattamento di dati personali
1. Chiunque cagiona danno ad altri per effetto del trattamento di dati personali è tenuto al risarcimento
ai sensi dell'articolo 2050 del codice civile.
Sezione IV
Comunicazione e diffusione dei dati
Articolo 19
Incaricati del trattamento
1. Non si considera comunicazione la conoscenza dei dati personali da parte delle persone incaricate
per iscritto di compiere le operazioni del trattamento dal titolare o dal responsabile, e che operano sotto
la loro diretta autorità.
Articolo 20
Requisiti per la comunicazione e la diffusione dei dati
1. La comunicazione e la diffusione dei dati personali da parte di privati e di enti pubblici economici
sono ammesse:
a) con il consenso espresso dell'interessato;
a-bis) qualora siano necessarie per l'esecuzione di obblighi derivanti da un contratto del quale è parte
l'interessato o per l'esecuzione di misure precontrattuali adottate su richiesta di quest'ultimo; (*)
b) se i dati provengono da pubblici registri, elenchi, atti o documenti conoscibili da chiunque, fermi
restando i limiti e le modalità che le leggi e i regolamenti stabiliscono per la loro conoscibilità e
pubblicità;
c) in adempimento di un obbligo previsto dalla legge, da un regolamento o dalla normativa
comunitaria;
d) nell'esercizio della professione di giornalista e per l'esclusivo perseguimento delle relative finalità.
Restano fermi i limiti del diritto di cronaca posti a tutela della riservatezza ed in particolare
dell'essenzialità dell'informazione riguardo a fatti di interesse pubblico. Si applica inoltre il codice di
deontologia di cui all'articolo 25;
e) se i dati sono relativi allo svolgimento di attività economiche, nel rispetto della vigente normativa in
materia di segreto aziendale e industriale;
f) qualora siano necessarie per la salvaguardia della vita o dell'incolumità fisica dell'interessato o di un
terzo, nel caso in cui l'interessato non può prestare il proprio consenso per impossibilità fisica, per
incapacità di agire o per incapacità di intendere o di volere;
g) limitatamente alla comunicazione, qualora questa sia necessaria ai fini dello svolgimento delle
investigazioni difensive di cui alla legge 7 dicembre 2000, n. 397 (*), o, comunque, per far valere o
difendere un diritto in sede giudiziaria, nel rispetto della normativa di cui alla lettera e) del presente
comma, sempre che i dati siano trattati esclusivamente per tali finalità e per il periodo strettamente
necessario al loro perseguimento;
h) limitatamente alla comunicazione, quando questa sia effettuata nell'ambito dei gruppi bancari di cui
all'articolo 60 del testo unico delle leggi in materia bancaria e creditizia approvato con decreto
legislativo 1. settembre 1993, n. 385, nonché tra società controllate e società collegate ai sensi
dell'articolo 2359 del codice civile, i cui trattamenti con finalità correlate sono stati notificati ai sensi
dell'articolo 7, comma 2, per il perseguimento delle medesime finalità per le quali i dati sono stati
raccolti;
h-bis) limitatamente alla comunicazione, quando questa sia necessaria, nei casi individuati dal
Garante sulla base dei principi sanciti dalla legge, per perseguire un legittimo interesse del titolare o
di un terzo destinatario dei dati, qualora non prevalgano i diritti e le libertà fondamentali, la dignità o
un legittimo interesse dell'interessato. (*)
2. Alla comunicazione e alla diffusione dei dati personali da parte di soggetti pubblici, esclusi gli enti
pubblici economici, si applicano le disposizioni dell'articolo 27.
Articolo 21
Divieto di comunicazione e diffusione
1. Sono vietate la comunicazione e la diffusione di dati personali per finalità diverse da quelle indicate
nella notificazione di cui all'articolo 7.
2. Sono altresì vietate la comunicazione e la diffusione di dati personali dei quali sia stata ordinata la
cancellazione, ovvero quando sia decorso il periodo di tempo indicato nell'articolo 9, comma 1, lettera
e).
3. Il Garante può vietare la diffusione di taluno dei dati relativi a singoli soggetti, od a categorie di
soggetti, quando la diffusione si pone in contrasto con rilevanti interessi della collettività. Contro il
divieto può essere proposta opposizione ai sensi dell'articolo 29, commi 6 e 7.
4. La comunicazione e la diffusione dei dati sono comunque permesse:
a) qualora siano necessarie per finalità di ricerca scientifica o di statistica e siano effettuate nel
rispetto dei codici di deontologia e di buona condotta sottoscritti ai sensi dell'articolo 31;
b) quando siano richieste dai soggetti di cui all'articolo 4, comma 1, lettere b), d) ed e), per finalità di
difesa o di sicurezza dello Stato o di prevenzione, accertamento o repressione di reati, con
l'osservanza delle norme che regolano la materia.
CAPO IV
TRATTAMENTO DI DATI PARTICOLARI
Articolo 22
Dati sensibili
1. I dati personali idonei a rivelare l'origine razziale ed etnica, le convinzioni religiose, filosofiche o di
altro genere, le opinioni politiche, l'adesione a partiti, sindacati, associazioni od organizzazioni a
carattere religioso, filosofico, politico o sindacale, nonché i dati personali idonei a rivelare lo stato di
salute e la vita sessuale, possono essere oggetto di trattamento solo con il consenso scritto
dell'interessato e previa autorizzazione del Garante.
1-bis. Il comma 1 non si applica ai dati relativi agli aderenti alle confessioni religiose i cui i rapporti
con lo Stato siano regolati da accordi o intese ai sensi degli articoli 7 e 8 della Costituzione, nonchè
relativi ai soggetti che con riferimento a finalità di natura esclusivamente religiosa hanno contatti
regolari con le medesine confessioni, che siano trattati dai relativi organi o enti civilmente
riconosciuti, semprechè i dati non siano comunicati o diffusi fuori delle medesime confessioni. Queste
ultime determinano idonee garanzie relativamente ai trattamenti effettuati.
1-ter. Il comma 1 non si applica, altresì, ai dati riguardanti l'adesione di associazioni od
organizzazioni a carattere sindacale o di categoria ad altre associazioni, organizzazioni o
confederazioni a carattere sindacale o di categoria. (*)
2. Il Garante comunica la decisione adottata sulla richiesta di autorizzazione entro trenta giorni, decorsi
i quali la mancata pronuncia equivale a rigetto. Con il provvedimento di autorizzazione, ovvero
successivamente, anche sulla base di eventuali verifiche, il Garante può prescrivere misure e
accorgimenti a garanzia dell'interessato, che il titolare del trattamento è tenuto ad adottare.
3. Il trattamento dei dati indicati al comma 1 da parte di soggetti pubblici, esclusi gli enti pubblici
economici, è consentito solo se autorizzato da espressa disposizione di legge, nella quale siano
specificati i tipi di dati che possono essere trattati, le operazioni eseguibili e le rilevanti finalità di
interesse pubblico perseguite. In mancanza di espressa disposizione di legge, e fuori dai casi previsti
dai decreti legislativi di modificazione ed integrazione della presente legge, emanati in attuazione
della legge 31 dicembre 1996, n. 676, i soggetti pubblici possono richiedere al Garante, nelle more
della specificazione legislativa, l'individuazione delle attività, tra quelle demandate ai medesimi
soggetti dalla legge, che perseguono rilevanti finalità di interesse pubblico e per le quali è
conseguentemente autorizzato, ai sensi del comma 2, il trattamento dei dati indicati al comma 1.
3-bis. Nei casi in cui è specificata, a norma del comma 3, la finalità di rilevante interesse pubblico, ma
non sono specificati i tipi di dati e le operazioni eseguibili, i soggetti pubblici, in applicazione di
quanto previsto dalla presente legge e dai decreti legislativi di attuazione della legge 31 dicembre
1996, n. 676, in materia di dati sensibili, identificano e rendono pubblici, secondo i rispettivi
ordinamenti, i tipi di dati e di operazioni strettamente pertinenti e necessari in relazione alle finalità
perseguite nei singoli casi, aggiornando tale identificazione periodicamente.
4. I dati personali indicati al comma 1 possono essere oggetto di trattamento previa autorizzazione del
Garante:(*)
a) qualora il trattamento sia effettuato da associazioni, enti od organismi senza scopo di lucro, anche
non riconosciuti, a carattere politico, filosofico, religioso o sindacale, ivi compresi partiti e
movimenti politici, confessioni e comunità religiose, per il perseguimento di finalità lecite,
relativamente ai dati personali degli aderenti o dei soggetti che in relazione a tali finalità hanno
contatti regolari con l'associazione, ente od organismo, sempre che i dati non siano comunicati o
diffusi fuori del relativo ambito e l'ente, l'associazione o l'organismo determinino idonee garanzie
relativamente ai trattamenti effettuati; (****)
b) qualora il trattamento sia necessario per la salvaguardia della vita o dell'incolumità fisica
dell'interessato o di un terzo, nel caso in cui l'interessato non può prestare il proprio consenso per
impossibilità fisica, per incapacità di agire o per incapacità d'intendere o di volere; (*)
c) qualora il trattamento sia necessario ai fini dello svolgimento delle investigazioni difensive di cui
alla legge 7 dicembre 2000, n. 397 o, comunque, per far valere o difendere in sede giudiziaria un
diritto, di rango pari a quello dell'interessato quando i dati siano idonei a rivelare lo stato di salute e
la vita sessuale, sempre che i dati siano trattati esclusivamente per tali finalità e per il periodo
strettamente necessario al loro perseguimento. Il Garante prescrive le misure e gli accorgimenti di
cui al comma 2 e promuove la sottoscrizione di un apposito codice di deontologia e di buona
condotta secondo le modalità di cui all'articolo 31, comma 1, lettera h). Resta fermo quanto previsto
dall'articolo 43, comma 2. (*)
Articolo 23
Dati inerenti alla salute
1. Gli esercenti le professioni sanitarie e gli organismi sanitari pubblici possono, anche senza
l'autorizzazione del Garante, trattare i dati personali idonei a rivelare lo stato di salute, limitatamente ai
dati e alle operazioni indispensabili per il perseguimento di finalità di tutela dell'incolumità fisica e
della salute dell'interessato. Se le medesime finalità riguardano un terzo o la collettività, in mancanza
del consenso dell'interessato, il trattamento può avvenire previa autorizzazione del Garante.
1-bis. Con decreto del ministro della Sanità adottato ai sensi dell'articolo 17, comma 3, della legge 23
agosto 1988, n. 400, sentiti la Conferenza permanente per i rapporti tra lo Stato, le regioni, e le
province autonome di Trento e Bolzano e il Garante, sono individuate modalità semplificate per le
informative di cui all'articolo 10 e per la prestazione del consenso nei confronti di organismi sanitari
pubblici, di organismi sanitari e di esercenti le professioni sanitarie convenzionati o accreditati dal
Servizio sanitario nazionale, nonché per il trattamento dei dati da parte dei medesimi soggetti, sulla
base dei seguenti criteri:
a) previsione di informative effettuate da un unico soggetto, in particolare da parte del medico di
medicina generale scelto dall'interessato, per conto di più titolari di trattamento;
b) validità nei confronti di più titolari di trattamento, del consenso prestato ai sensi dell'articolo 11,
comma 3, per conto di più titolari di trattamento, anche con riguardo alla richiesta di prestazioni
specialistiche, alla prescrizione di farmaci, alla raccolta di dati da parte del medico di medicina
generale, detenuti da altri titolari, e alla pluralità di prestazioni mediche effettuate da un medesimo
titolare di trattamento;
c) identificazione dei casi di urgenza nei quali anche per effetto delle situazioni indicate nel comma
1-ter, l'informativa e il consenso possono intervenire successivamente alla richiesta della
prestazione;
d) previsione di modalità di applicazione del comma 2 del presente articolo ai professionisti sanitari,
diversi dai medici, che intrattengono rapporti diretti con i pazienti;
e) previsione di misure volte ad assicurare che nell'organizzazione dei servizi e delle prestazioni sia
garantito il rispetto dei diritti di cui all'articolo 1.
1-ter. Il decreto di cui al comma 1 disciplina anche quanto previsto dall'articolo 22, comma 3-bis,
della legge.
1-quater. In caso di incapacità di agire, ovvero di impossibilità fisica o di incapacità di intendere o di
volere, il consenso al trattamento dei dati idonei a rivelare lo stato di salute è validamente manifestato
nei confronti di esercenti le professioni sanitarie e di organismi sanitari, rispettivamente, da chi
esercita legalmente la podestà ovvero da un familiare, da un prossimo congiunto, da un convivente, o,
in loro assenza, dal responsabile della struttura presso cui dimori.
2. I dati personali idonei a rivelare lo stato di salute possono essere resi noti all'interessato o ai soggetti
di cui al comma 1-ter solo per il tramite di un medico designato dall'interessato o dal titolare.
3. L'autorizzazione di cui al comma 1 è rilasciata, salvi i casi di particolare urgenza, sentito il Consiglio
superiore di sanità. è vietata la comunicazione dei dati ottenuti oltre i limiti fissati con l'autorizzazione.
4. La diffusione dei dati idonei a rivelare lo stato di salute è vietata, salvo nel caso in cui sia necessaria
per finalità di prevenzione, accertamento o repressione dei reati, con l'osservanza delle norme che
regolano la materia.
Articolo 24
Dati relativi ai provvedimenti di cui all'articolo 686 del codice di procedura penale
1. Il trattamento di dati personali idonei a rivelare provvedimenti di cui all'articolo 686, commi 1,
lettere a) e d), 2 e 3, del codice di procedura penale, è ammesso soltanto se autorizzato da espressa
disposizione di legge o provvedimento del Garante che specifichino le rilevanti finalità di interesse
pubblico del trattamento, i tipi di dati trattati e le precise operazioni autorizzate.
Articolo 24-bis(***)
Altri dati particolari
1. Il trattamento dei dati diversi da quelli di cui agli articoli 22 e 24 che presenta rischi specifici per i
diritti e le libertà fondamentali, nonché per la dignità dell'interessato, in relazione alla natura dei dati
o alle modalità del trattamento o agli effetti che può determinare, è ammesso nel rispetto di misure ed
accorgimenti a garanzia dell'interessato, ove prescritti.
2. Le misure e gli accorgimenti di cui al comma 1 sono prescritti dal Garante sulla base dei principi
sanciti dalla legge nell'ambito di una verifica preliminare all'inizio del trattamento, effettuata anche in
relazione a determinate categorie di titolari o di trattamenti, sulla base di un eventuale interpello del
titolare.
Articolo 25
Trattamento di dati particolari nell'esercizio della professione di giornalista
1. Le disposizioni relative al consenso dell'interessato e all'autorizzazione del Garante,nonché il limite
previsto dall'articolo 24, non si applicano quando il trattamento dei dati di cui agli articoli 22 e 24 è
effettuato nell'esercizio della professione di giornalista e per l'esclusivo perseguimento delle relative
finalità. Il giornalista rispetta i limiti del diritto di cronaca, in particolare quello dell'essenzialità
dell'informazione riguardo a fatti di interesse pubblico,ferma restando la possibiltà di trattare i dati
relativi a circostanze o fatti resi noti direttamente dall'interessato o attraverso i suoi comportamenti in
pubblico.
2. Il Garante promuove, nei modi di cui all'articolo 31, comma 1, lettera h), l'adozione, da parte del
Consiglio nazionale dell'ordine dei giornalisti, di un apposito codice di deontologia relativo al
trattamento dei dati di cui al comma 1 del presente articolo, effettuato nell'esercizio della professione di
giornalis ta, che preveda misure ed accorgimenti a garanzia degli interessati rapportate alla natura dei
dati, in particolare per quanto riguarda quelli idonei a rivelare lo stato di salute e la vita sessuale.
Nella fase di formazione del codice, ovvero successivamente, il Garante, in cooperazione con il
Consiglio, prescrive eventuali misure e accorgimenti a garanzia degli interessati, che il Consiglio è
tenuto a recepire.
Il codice è pubblicato sulla Gazzetta Ufficiale a cura del Garante, e diviene efficace quindici giorni
dopo la sua pubblicazione.
3. Ove entro sei mesi dalla proposta del Garante il codice di deontologia di cui al comma 2 non sia
stato adottato dal Consiglio nazionale dell'ordine dei giornalisti, esso è adottato in via sostitutiva dal
Garante ed è efficace sino alla adozione di un diverso codice secondo la procedura di cui al comma 2.
In caso di violazione delle prescrizioni contenute nel codice di deontologia, il Garante può vietare il
trattamento ai sensi dell'articolo 31, comma 1, lettera l).
4. Nel codice di cui ai commi 2 e 3 sono inserite, altresì, prescrizioni concernenti i dati personali
diversi da quelli indicati negli articoli 22 e 24.
Il codice può prevedere forme semplificate per le informative di cui all'articolo 10.
4-bis. Le disposizioni della presente legge che attengono all'esercizio della professione di giornalista si
applicano anche ai trattamenti effettuati dai soggetti iscritti nell'elenco dei pubblicisti o nel registro
dei praticanti di cui agli articoli 26 e 33 della legge 3 febbraio 1963, n. 69, nonché ai trattamenti
temporanei finalizzati esclusivamente alla pubblicazione o diffusione occasionale di articoli, saggi e
altre manifestazioni del pensiero.
Articolo 26
Dati concernenti persone giuridiche
1. Il trattamento nonché la cessazione del trattamento di dati concernenti persone giuridiche, enti o
associazioni non sono soggetti a notificazione.
2. Ai dati riguardanti persone giuridiche, enti o associazioni non si applicano le disposizioni
dell'articolo 28.
CAPO V
TRATTAMENTI SOGGETTI A REGIME SPECIALE
Articolo 27
Trattamento da parte di soggetti pubblici
1. Salvo quanto previsto al comma 2, il trattamento di dati personali da parte di soggetti pubblici,
esclusi gli enti pubblici economici, è consentito soltanto per lo svolgimento delle funzioni istituzionali,
nei limiti stabiliti dalla legge e dai regolamenti.
2. La comunicazione e la diffusione a soggetti pubblici, esclusi gli enti pubblici economici, dei dati
trattati sono ammesse quando siano previste da norme di legge o di regolamento, o risultino comunque
necessarie per lo svolgimento delle funzioni istituzionali. In tale ultimo caso deve esserne data previa
comunicazione nei modi di cui all'articolo 7, commi 2 e 3 al Garante che vieta, con provvedimento
motivato, la comunicazione o la diffusione se risultano violate le disposizioni della presente legge.
3. La comunicazione e la diffusione dei dati personali da parte di soggetti pubblici a privati o a enti
pubblici economici sono ammesse solo se previste da norme di legge o di regolamento.
4. I criteri di organizzazione delle amministrazioni pubbliche di cui all'articolo 5 del decreto legislativo
3 febbraio 1993, n. 29, sono attuati nel pieno rispetto delle disposizioni della presente legge.
Articolo 28
Trasferimento di dati personali all'estero
1. Il trasferimento anche temporaneo fuori del territorio nazionale, con qualsiasi forma o mezzo, di dati
personali oggetto di trattamento deve essere previamente notificato al Garante, qualora sia diretto verso
un Paese non appartenente all'Unione europea e ricorra uno dei casi individuati ai sensi dell'articolo 7,
comma 1 (*).
2. Il trasferimento può avvenire soltanto dopo quindici giorni dalla data della notificazione; il termine è
di venti giorni qualora il trasferimento riguardi taluno dei dati di cui agli articoli 22 e 24.
3. Il trasferimento è vietato qualora l'ordinamento dello Stato di destinazione o di transito dei dati non
assicuri un livello di tutela delle persone adeguato. Sono valutate anche le modalità del trasferimento e
dei trattamenti previsti, le relative finalità, la natura dei dati e le misure di sicurezza.
4. Il trasferimento è comunque consentito qualora:
a) l'interessato abbia manifestato il proprio consenso espresso ovvero, se il trasferimento riguarda
taluno dei dati di cui agli articoli 22 e 24, in forma scritta;
b) sia necessario per l'esecuzione di obblighi derivanti da un contratto del quale è parte l'interessato o
per l'esecuzione di misure precontrattuali adottate (*) su richiesta di quest'ultimo, ovvero per la
conclusione o per l'esecuzione di un contratto stipulato a favore dell'interessato;
c) sia necessario per la salvaguardia di un interesse pubblico rilevante individuato con legge o con
regolamento, ovvero specificato ai sensi degli articoli 22, comma 3, e 24, se il trasferimento riguarda
taluno dei dati ivi previsti;
d) sia necessario ai fini dello svolgimento delle investigazioni difensive di cui alla legge 7 dicembre
2000, n. 397 (*), o, comunque, per far valere o difendere un diritto in sede giudiziaria, sempre che i
dati siano trasferiti esclusivamente per tali finalità e per il periodo strettamente necessario al loro
perseguimento;
e) sia necessario per la salvaguardia della vita o dell'incolumità fisica dell'interessato o di un terzo,
nel caso in cui l'interessato non può prestare il proprio consenso per impossibilità fisica, per
incapacità di agire o per incapacità di intendere o di volere;
f) sia effettuato in accoglimento di una richiesta di accesso ai documenti amministrativi, ovvero di
una richiesta di informazioni estraibili da un pubblico registro, elenco, atto o documento conoscibile
da chiunque, con l'osservanza delle norme che regolano la materia;
g) sia autorizzato dal Garante sulla base di adeguate garanzie per i diritti dell'interessato, prestate
anche con un contratto, ovvero individuate dalla Commissione europea con le decisioni previste dagli
articoli 25, paragrafo 6, e 26, paragrafo 4, della direttiva n. 95/46/CE del Parlamento europeo e del
Consiglio del 24 ottobre 1995 (*);
g-bis) il trattamento sia finalizzato unicamente a scopi di ricerca scientifica o di statistica e sia
effettuato nel rispetto dei codici di deontologia e di buona condotta sottoscritti ai sensi dell'articolo
31.
5. Contro il divieto di cui al comma 3 del presente articolo può essere proposta opposizione ai sensi
dell'articolo 29, commi 6 e 7.
6. Le disposizioni del presente articolo non si applicano al trasferimento di dati personali effettuato
nell'esercizio della professione di giornalista e per l'esclusivo perseguimento delle relative finalità.
Le disposizioni di cui al successivo comma 7, sono abrogate a decorrere dalla data di entrata in
vigore delle modifiche apportate al regolamento di cui all'articolo 33, comma 3, in applicazione
del comma 1 dell'articolo 7.
7. La notificazione di cui al comma 1 del presente articolo è effettuata ai sensi dell'articolo 7 ed è
annotata in apposita sezione del registro previsto dall'articolo 31, comma 1, lettera a). La notificazione
può essere effettuata con un unico atto unitamente a quella prevista dall'articolo 7.
CAPO VI
TUTELA AMMINISTRATIVA E GIURISDIZIONALE
Articolo 29
Tutela
1. I diritti di cui all'articolo 13, comma 1, possono essere fatti valere dinanzi all'autorità giudiziaria o
con ricorso al Garante. Il ricorso al Garante non può essere proposto qualora, per il medesimo oggetto e
tra le stesse parti, sia stata già adita l'autorità giudiziaria.
2. Salvi i casi in cui il decorso del termine esporrebbe taluno a pregiudizio imminente ed irreparabile, il
ricorso al Garante può essere proposto solo dopo che siano decorsi cinque giorni dalla richiesta
avanzata sul medesimo oggetto al responsabile. La presentazione del ricorso rende improponibile
un'ulteriore domanda dinanzi all'autorità giudiziaria tra le stesse parti e per il medesimo oggetto.
3. Nel procedimento dinanzi al Garante il titolare, il responsabile e l'interessato hanno diritto di essere
sentiti, personalmente o a mezzo di procuratore speciale, e hanno facoltà di presentare memorie o
documenti. Il Garante può disporre, anche d'ufficio, l'espletamento di perizie.
4. Assunte le necessarie informazioni il Garante, se ritiene fondato il ricorso, ordina al titolare e al
responsabile, con decisione motivata, la cessazione del comportamento illegittimo, indicando le misure
necessarie a tutela dei diritti dell'interessato e assegnando un termine per la loro adozione. Il
provvedimento è comunicato senza ritardo alle parti interessate, a cura dell'ufficio del Garante. La
mancata pronuncia sul ricorso, decorsi trenta giorni dalla data di presentazione, equivale a rigetto.
5. Se la particolarità del caso lo richiede, il Garante può disporre in via provvisoria il blocco in tutto o
in parte di taluno dei dati ovvero l'immediata sospensione di una o più operazioni del trattamento. Il
provvedimento cessa di avere ogni effetto se, entro i successivi venti giorni, non è adottata la decisione
di cui al comma 4 ed è impugnabile unitamente a tale decisione.
6. Avverso il provvedimento espresso o il rigetto tacito di cui al comma 4, il titolare o l'interessato
possono proporre opposizione al tribunale del luogo ove risiede il titolare, entro il termine di trenta
giorni dalla data di comunicazione del provvedimento o dalla data del rigetto tacito. L'opposizione non
sospende l'esecuzione del provvedimento.
6-bis. Il decorso dei termini previsti dai commi 4, 5 e 6 è sospeso di diritto dal 1 al 30 agosto di
ciascun anno e riprende a decorrere dalla fine del periodo di sospensione. Ove il decorso abbia inizio
durante tale periodo, l'inizio stesso è differito alla fine del periodo medesimo. La sospensione non
opera nei casi in cui sussista il pregiudizio di cui al comma 2 e non preclude l'adozione dei
provvedimenti di cui al comma 5.
7. Il tribunale provvede nei modi di cui agli articoli 737 e seguenti del codice di procedura civile, anche
in deroga al divieto di cui all'articolo 4 della legge 20 marzo 1865, n. 2248, allegato e), e può
sospendere, a richiesta, l'esecuzione del provvedimento. Avverso il decreto del tribunale è ammesso
unicamente il ricorso per cassazione.
8. Tutte le controversie, ivi comprese quelle inerenti al rilascio dell'autorizzazione di cui all'articolo 22,
comma 1, o che riguardano, comunque, l'applicazione della presente legge, sono di competenza
dell'autorità giudiziaria ordinaria.
9. Il danno non patrimoniale è risarcibile anche nei casi di violazione dell'articolo 9.
CAPO VII
GARANTE PER LA PROTEZIONE DEI DATI
Articolo 30
Istituzione del Garante
1. È istituito il Garante per la protezione dei dati personali.
2. Il Garante opera in piena autonomia e con indipendenza di giudizio e di valutazione.
3. Il Garante è organo collegiale costituito da quattro membri, eletti due dalla Camera dei deputati e
due dal Senato della Repubblica con voto limitato. Essi eleggono nel loro ambito un presidente, il cui
voto prevale in caso di parità. I membri sono scelti tra persone che assicurino indipendenza e che siano
esperti di riconosciuta competenza nelle materie del diritto o dell'informatica, garantendo la presenza di
entrambe le qualificazioni.
4. Il presidente e i membri durano in carica quattro anni e non possono essere confermati per più di una
volta; per tutta la durata dell'incarico il presidente e i membri non possono esercitare, a pena di
decadenza, alcuna attività professionale o di consulenza, né essere amministratori o dipendenti di enti
pubblici o privati, né ricoprire cariche elettive.
5. All'atto dell'accettazione della nomina il presidente e i membri sono collocati fuori ruolo se
dipendenti di pubbliche amministrazioni o magistrati in attività di servizio; se professori universitari di
ruolo, sono collocati in aspettativa senza assegni ai sensi dell'articolo 13 del decreto del Presidente
della Repubblica 11 luglio 1980, n. 382, e successive modificazioni. Il personale collocato fuori ruolo o
in aspettativa non può essere sostituito.
6. Al presidente compete una indennità di funzione non eccedente, nel massimo, la retribuzione
spettante al primo presidente della Corte di cassazione. Ai membri compete un'indennità di funzione
non eccedente, nel massimo, i due terzi di quella spettante al presidente. Le predette indennità di
funzione sono determinate, con il regolamento di cui all'articolo 33, comma 3, in misura tale da poter
essere corrisposte a carico degli ordinari stanziamenti.
Articolo 31
Compiti del garante
1. Il Garante ha il compito di:
a) istituire e tenere un registro generale dei trattamenti sulla base delle notificazioni ricevute;
b) controllare se i trattamenti sono effettuati nel rispetto delle norme di legge e di regolamento e in
conformità alla notificazione;
c) segnalare ai relativi titolari o responsabili le modificazioni necessarie o opportune (*) al fine di
rendere il trattamento conforme alle disposizioni vigenti;
d) ricevere le segnalazioni ed i reclami degli interessati o delle associazioni che li rappresentano,
relativi ad inosservanze di legge o di regolamento, e provvedere sui ricorsi presentati ai sensi
dell'articolo 29;
e) adottare i provvedimenti previsti dalla legge o dai regolamenti;
f) vigilare sui casi di cessazione, per qualsiasi causa, di un trattamento;
g) denunciare i fatti configurabili come reati perseguibili d'ufficio, dei quali viene a conoscenza
nell'esercizio o a causa delle sue funzioni;
h) promuovere nell'ambito delle categorie interessate, nell'osservanza del principio di
rappresentatività, la sottoscrizione di codici di deontologia e di buona condotta per determinati
settori, verificarne la conformità alle leggi e ai regolamenti anche attraverso l'esame di osservazioni
di soggetti interessati e contribuire a garantirne la diffusione e il rispetto;
i) curare la conoscenza tra il pubblico delle norme che regolano la materia e delle relative finalità,
nonché delle misure di sicurezza dei dati di cui all'articolo 15;
l) vietare, in tutto o in parte, il trattamento dei dati o disporne il blocco se il trattamento risulta
illecito o non corretto anche per effetto della mancata adozione delle misure necessarie di cui alla
lettera c), oppure (*) quando, in considerazione della natura dei dati o, comunque, delle modalità del
trattamento o degli effetti che esso può determinare, vi è il concreto rischio del verificarsi di un
pregiudizio rilevante per uno o più interessati;
m) segnalare al Governo l'opportunità di provvedimenti normativi richiesti dall'evoluzione del
settore;
n) predisporre annualmente una relazione sull'attività svolta e sullo stato di attuazione della presente
legge, che è trasmessa al Parlamento e al Governo entro il 30 aprile dell'anno successivo a quello cui
si riferisce;
o) curare l'attività di assistenza indicata nel capitolo IV della Convenzione n. 108 sulla protezione
delle persone rispetto al trattamento automatizzato di dati di carattere personale, adottata a Strasburgo
il 28 gennaio 1981 e resa esecutiva con legge 21 febbraio 1989, n. 98, quale autorità designata ai fini
della cooperazione tra Stati ai sensi dell'articolo 13 della Convenzione medesima;
p) esercitare il controllo sui trattamenti di cui all'articolo 4 e verificare, anche su richiesta
dell'interessato, se rispondono ai requisiti stabiliti dalla legge o dai regolamenti.
2. Il Presidente del Consiglio dei ministri e ciascun ministro consultano il Garante all'atto della
predisposizione delle norme regolamentari e degli atti amministrativi suscettibili di incidere sulle
materie disciplinate dalla presente legge.
3. Il registro di cui al comma 1, lettera a), del presente articolo, è tenuto nei modi di cui all'articolo 33,
comma 5. Entro il termine di un anno dalla data della sua istituzione, il Garante promuove opportune
intese con le province ed eventualmente con altre pubbliche amministrazioni al fine di assicurare la
consultazione del registro mediante almeno un terminale dislocato su base provinciale, preferibilmente
nell'ambito dell'ufficio per le relazioni con il pubblico di cui all'articolo 12 del decreto legislativo 3
febbraio 1993, n. 29, e successive modificazioni.
4. Contro il divieto di cui al comma 1, lettera l), del presente articolo, può essere proposta opposizione
ai sensi dell'a rticolo 29, commi 6 e 7.
5. Il Garante e l'Autorità per l'informatica nella pubblica amministrazione cooperano tra loro nello
svolgimento dei rispettivi compiti; a tal fine, invitano il presidente o un suo delegato membro dell'altro
organo a partecipare alle riunioni prendendo parte alla discussione di argomenti di comune interesse
iscritti all'ordine del giorno; possono richiedere, altresì, la collaborazione di personale specializzato
addetto all'altro organo.
6. Le disposizioni del comma 5 si applicano anche nei rapporti tra il Garante e le autorità di vigilanza
competenti per il settore creditizio, per le attività assicurative e per la radiodiffusione e l'editoria.
Articolo 32
Accertamenti e controlli
1. Per l'espletamento dei propri compiti il Garante può richiedere al responsabile, al titolare,
all'interessato o anche a terzi di fornire informazioni e di esibire documenti.
2. Il Garante, qualora ne ricorra la necessità ai fini del controllo del rispetto delle disposizioni in
materia di trattamento dei dati personali, può disporre accessi alle banche di dati o altre ispezioni e
verifiche nei luoghi ove si svolge il trattamento o nei quali occorre effettuare rilevazioni comunque utili
al medesimo controllo, avvalendosi, ove necessario, della collaborazione di altri organi dello Stato.
3. Gli accertamenti di cui al comma 2 sono disposti previa autorizzazione del presidente del tribunale
competente per territorio in relazione al luogo dell'accertamento, il quale provvede senza ritardo sulla
richiesta del Garante, con decreto motivato; le relative modalità di svolgimento sono individuate con il
regolamento di cui all'articolo 33, comma 3.
4. I soggetti interessati agli accertamenti sono tenuti a farli eseguire.
5. Resta fermo quanto previsto dall'articolo 220 delle norme di attuazione, di coordinamento e
transitorie del codice di procedura penale, approvate con decreto legislativo 28 luglio 1989, n. 271.
6. Per i trattamenti di cui agli articoli 4 e 14, comma 1, gli accertamenti sono effettuati per il tramite di
un membro designato dal Garante. Se il trattamento non risulta conforme alle disposizioni di legge o di
regolamento, il Garante indica al titolare o al responsabile le necessarie modificazioni ed integrazioni e
ne verifica l'attuazione. Se l'accertamento è stato richiesto dall'interessato, a quest'ultimo è fornito in
ogni caso un riscontro circa il relativo esito, salvo che ricorrano i motivi di cui all'articolo 10, comma 4,
della legge 1. aprile 1981, n. 121, come sostituito dall'articolo 42, comma 1, della presente legge, o
motivi di difesa o di sicurezza dello Stato.
7. Gli accertamenti di cui al comma 6 non sono delegabili. Qualora risulti necessario in ragione della
specificità della verifica, il membro designato può farsi assistere da personale specializzato che è tenuto
al segreto ai sensi dell'articolo 33, comma 6. Gli atti e i documenti acquisiti sono custoditi secondo
modalità tali da assicurarne la segretezza e sono conoscibili dal presidente e dai membri del Garante e,
se necessario per lo svolgimento delle funzioni dell'organo, da un numero delimitato di addetti al
relativo ufficio, individuati dal Garante sulla base di criteri definiti dal regolamento di cui all'articolo
33, comma 3. Per gli accertamenti relativi agli organismi e ai dati di cui all'articolo 4, comma 1, lettera
b), il membro designato prende visione degli atti e dei documenti rilevanti e riferisce oralmente nelle
riunioni del Garante.
Articolo 33
Ufficio del Garante
1.
Alle dipendenze del Garante è posto un ufficio composto, in sede di prima applicazione della
presente legge, da dipendenti dello Stato e di altre amministrazioni pubbliche, collocati fuori ruolo
nelle forme previste dai rispettivi ordinamenti, il cui servizio presso il medesimo ufficio è equiparato
ad ogni effetto di legge a quello prestato nelle rispettive amministrazioni di provenienza. Il relativo
contingente è determinato, in misura non superiore a quarantacinque unità, su proposta del Garante
medesimo, con decreto del Presidente del Consiglio dei ministri, di concerto con i Ministri del tesoro e
per la funzione pubblica, entro novanta giorni dalla data di elezione del Garante.
Il segretario generale può essere scelto anche tra magistrati ordinari o amministrativi.
1-bis. E' istituito il ruolo organico del personale dipendente del Garante. Con proprio regolamento il
Garante definisce:
a) l'ordinamento delle carriere e le modalità del reclutamento secondo le procedure previste
dall'articolo 36 del decreto legislativo 3 febbraio 1993, n. 29, e successive modificazioni;
b)
le modalità dell'inquadramento in ruolo del personale in servizio alla data di entrata in
vigore del regolamento;
c)
il trattamento giuridico ed economico del personale, secondo i criteri previsti dalla legge 31
luglio 1997, n. 249, e, per gli incarichi di funzioni dirigenziali, dall'articolo 19, comma 6, del citato
decreto legislativo n. 29, come sostituito dall'articolo 13 del decreto legislativo 31 marzo 1998, n.
80, tenuto conto delle specifiche esigenze funzionali e organizzative. Il regolamento è pubblicato
nella Gazzetta Ufficiale Nelle more della più generale razionalizzazione del trattamento economico
delle autorità amministrative indipendenti, al personale è attribuito l'ottanta per cento del
trattamento economico del personale dell'Autorità per le garanzie nelle comunicazioni.
Per il periodo intercorrente tra l'8 maggio 1997 e la data di entrata in vigore del regolamento, resta
ferma l'indennità di cui all'articolo 41 del decreto del Presidente della Repubblica 10 luglio 1991, n.
231, corrisposta al personale in servizio. Dal 1 gennaio 1998 e fino alla data di entrata in vigore del
medesimo regolamento, è inoltre corrisposta la differenza tra il nuovo trattamento e la retribuzione già
in godimento maggiorata della predetta indennità di funzione.
1-ter. L'ufficio può avvalersi, per motivate esigenze, di dipendenti dello Stato o di altre
amministrazioni pubbliche o di enti pubblici collocati in posizione di fuori ruolo nelle forme previste
dai rispettivi ordinamenti, ovvero in aspettativa ai sensi dell'articolo 13 del decreto del Presidente
della Repubblica 11 luglio 1980, n. 382, e successive modificazioni, in numero non superiore,
complessivamente, a venti unità e per non oltre il venti per cento delle qualifiche dirigenziali,
lasciando non coperto un corrispondente numero di posti di ruolo. Al personale di cui al presente
comma è corrisposta una indennità pari alla eventuale differenza tra il trattamento erogato
dall'amministrazione o dall'ente di provenienza e quello spettante al corrispondente personale di
ruolo, e comunque non inferiore alla indennità di cui all'articolo 41 del citato decreto del Presidente
della Repubblica n. 231 del 1991.
1-quater. Con proprio regolamento il Garante ripartisce l'organico, fissato nel limite di cento unità,
tra il personale dei diversi livelli e quello delle qualifiche dirigenziali e disciplina l'organizzazione, il
funzionamento dell'ufficio, la riscossione e la utilizzazione dei diritti di segreteria, ivi compresi quelli
corrisposti dall'8 maggio 1997, e la gestione delle spese, anche in deroga alle norme sulla contabilità
generale dello Stato.
l regolamento è pubblicato nella Gazzetta Ufficiale.
1-quinquies. In aggiunta al personale di ruolo, l'ufficio può assumere direttamente dipendenti con
contratto a tempo determinato disciplinato dalle norme di diritto privato, in numero non superiore a
venti unità, ivi compresi i consulenti assunti con contratto a tempo determinato ai sensi del comma 4.
1-sexies. All'ufficio del Garante, al fine di garantire la responsabilità e l'autonomia ai sensi della legge
7 agosto 1990, n. 241, e successive modificazioni, e del decreto legislativo 3 febbraio 1993, n. 29, e
successive modificazioni, si applicano i principi riguardanti l'individuazione e le funzioni del
responsabile del procedimento, nonchè quelli relativi alla distinzione fra le funzioni di indirizzo e di
controllo, attribuite agli organi di vertice, e quelli concernenti le funzioni di gestione attribuite ai
dirigenti.
2. Le spese di funzionamento dell'ufficio del Garante sono poste a carico di un fondo stanziato a tale
scopo nel bilancio dello Stato e iscritto in apposito capitolo dello stato di previsione del Ministero del
tesoro. Il rendiconto della gestione finanziaria è soggetto al controllo della Corte dei conti.
3. In sede di prima applicazione della presente legge, le norme concernenti l'organizzazione ed il
funzionamento dell'ufficio del Garante, nonché quelle dirette a disciplinare la riscossione dei diritti di
segreteria e la gestione delle spese, anche in deroga alle disposizioni sulla contabilità generale dello
Stato, sono adottate con regolamento emanato con decreto del Presidente della Repubblica, entro tre
mesi dalla data di entrata in vigore della presente legge, previa deliberazione del Consiglio dei ministri,
sentito il Consiglio di Stato, su proposta del Presidente del Consiglio dei ministri, di concerto con i
Ministri del tesoro, di grazia e giustizia e dell'interno, e su parere conforme del Garante stesso. Nel
medesimo regolamento sono determinate le indennità di cui all'articolo 30, comma 6, e altresì previste
le norme concernenti il procedimento dinanzi al Garante di cui all'articolo 29, commi da 1 a 5, secondo
modalità tali da assicurare, nella speditezza del procedimento medesimo, il pieno rispetto del
contraddittorio tra le parti interessate, nonché le norme volte a precisare le modalità per l'esercizio dei
diritti di cui all'articolo 13, nonché della notificazione di cui all'articolo 7, per via telematica o mediante
supporto magnetico o lettera raccomandata con avviso di ricevimento o altro idoneo sistema. Il parere
del Consiglio di Stato sullo schema di regolamento è reso entro trenta giorni dalla ricezione della
richiesta; decorso tale termine il regolamento può comunque essere emanato.
3-bis. Con effetto dalla data di entrata in vigore del regolamento di cui al comma 1-quater, cessano di
avere vigore le norme adottate ai sensi del comma 3, primo periodo.
4. Nei casi in cui la natura tecnica o la delicatezza dei problemi lo richiedano, il Garante può avvalersi
dell'opera di consulenti, i quali sono remunerati in base alle vigenti tariffe professionali ovvero sono
assunti con contratti a tempo determinato di durata non superiore a due anni, che possono essere
rinnovati per non più di due volte.
5. Per l'espletamento dei propri compiti, l'ufficio del Garante può avvalersi di sistemi automatizzati ad
elaborazione informatica e di strumenti telematici propri ovvero, salvaguardando le garanzie previste
dalla presente legge, appartenenti all'Autorità per l'informatica nella pubblica amministrazione o, in
caso di indisponibilità, ad enti pubblici convenzionati.
6. Il personale addetto all'ufficio del Garante ed i consulenti sono tenuti al segreto su tutto ciò di cui
siano venuti a conoscenza, nell'esercizio delle proprie funzioni, in ordine a banche di dati e ad
operazioni di trattamento.
6-bis. Il personale dell'ufficio del Garante addetto agli accertamenti di cui all'articolo 32 riveste, in
numero non superiore a cinque unità, nei limiti del servizio cui è destinato e secondo le rispettive
attribuzioni, la qualifica di ufficiale o agente di polizia giudiziaria.
CAPO VIII
SANZIONI
Articolo 34 (*)
Omessa o incompleta notificazione
1. Chiunque, essendovi tenuto, non provvede tempestivamente alle notificazioni in conformità a quanto
previsto dagli articoli 7, 16, comma 1, e 28, ovvero indica in esse notizie incomplete, è punito con la
sanzione amministrativa del pagamento di una somma da lire dieci milioni (Ndr: euro 5.164,6) a a lire
sessantamilioni (Ndr: euro 30.987,4) e con la sanzione amministrativa accessoria della pubblicazione
dell'ordinanza-ingiunzione;
2. Alle violazioni dell'articolo 34, comma 1, commesse prima dell'entrata in vigore del dlgs.
21/12/2001 n. , si applicano, in quanto compatibili, le disposizioni di cui agli articoli 100, 101 e 102
del decreto legislativo 30 dicembre 1999, n. 507.
Articolo 35
Trattamento illecito di dati personali
1. Salvo che il fatto costituisca più grave reato, chiunque, al fine di trarne per sé o per altri profitto o
di recare ad altri un danno, procede al trattamento di dati personali in violazione di quanto disposto
dagli articoli 11, 20 e 27, è punito con la reclusione sino a due anni o, se il fatto consiste nella
comunicazione o diffusione, con la reclusione da tre mesi a due anni.
2. Salvo che il fatto costituisca più grave reato, chiunque, al fine di trarne per sé o per altri profitto o
di recare ad altri un danno, procede al trattamento di (*) dati personali in violazione di quanto
disposto dagli articoli 21, 22, 23, 24 e 24-bis (*), ovvero del divieto di cui all'articolo 28, comma 3, è
punito con la reclusione da tre mesi a due anni.
3. Se dai fatti di cui ai commi 1 e 2 deriva nocumento, la reclusione è da uno a tre anni.
Articolo 36 (*)
Omessa adozione di misure necessarie alla sicurezza dei dati
1. Chiunque, essendovi tenuto, omette di adottare le misure necessarie a garantire la sicurezza dei dati
personali, in violazione delle disposizioni dei regolamenti di cui ai commi 2 e 3 dell'articolo 15, è
punito con l'arresto sino a due anni o con l'ammenda da lire dieci milioni (Ndr: euro 5.164,6) a lire
ottanta milioni (Ndr: euro 41.316,6).
2. All'autore del reato, all'atto dell'accertamento o, nei casi complessi, anche con successivo atto del
Garante, è impartita una prescrizione fissando un termine per la regolarizzazione non eccedente il
periodo di tempo tecnicamente necessario, prorogabile in caso di particolare complessità o per
l'oggettiva difficoltà dell'adempimento e comunque non superiore a sei mesi. Nei sessanta giorni
successivi allo scadere del termine, se risulta l'adempimento alla prescrizione, l'autore del reato è
ammesso dal Garante a pagare una somma pari al quarto del massimo dell'ammenda stabilita per la
contravvenzione. L'adempimento e il pagamento estinguono il reato. L'organo che impartisce la
prescrizione e il pubblico ministero provvedono nei modi di cui agli articoli 21, 22, 23 e 24 del decreto
legislativo 19 dicembre 1994, n. 758, in quanto applicabili.
Per i procedimenti penali in corso per il reato di cui all'articolo 36, entro quaranta giorni dall'entrata
in vigore del dlgs. 28/12/2001 n. 467, l'autore del reato può fare richiesta all'autorità giudiziaria di
essere ammesso alla procedura indicata all'articolo 36, comma 2. L'Autorità giudiziaria dispone la
sospensione del procedimento e trasmette gli atti al Garante per la protezione dei dati personali che
provvede ai sensi del medesimo articolo 36, comma 2.
Articolo 37
Inosservanza dei provvedimenti del garante
1. Chiunque, essendovi tenuto, non osserva il provvedimento adottato dal Garante ai sensi dell'articolo
22, comma 2, o degli articoli 29, commi 4 e 5, e 31, comma 1, lettera l (*), è punito con la reclusione
da tre mesi a due anni.
Articolo 37-bis (*)
Falsità nelle dichiarazioni e nelle notificazioni al Garante
1. Chiunque, nelle notificazioni di cui agli articoli 7, 16, comma 1, e 28 o in atti, documenti o
dichiarazioni resi o esibiti in un procedimento dinanzi al Garante o nel corso di accertamenti, dichiara
o attesta falsamente notizie o circostanze o produce atti o documenti falsi, è punito, salvo che il fatto
costituisca più grave reato, con la reclusione da sei mesi a tre anni.
Articolo 38
Pena accessoria
1. La condanna per uno dei delitti previsti dalla presente legge importa la pubblicazione della
sentenza.
Articolo 39
Sanzioni amministrative
1. Chiunque omette di fornire le informazioni o di esibire i documenti richiesti dal Garante ai sensi
degli articoli 29, comma 4, e 32, comma 1, è punito con la sanzione amministrativa del pagamento di
una somma da lire cinquemilioni (Ndr: euro 2.582,3) a lire trentamilioni (Ndr: euro 15.493,7) (*).
2. La violazione delle disposizioni di cui all'articolo 10 è punita con la sanzione amministrativa del
pagamento di una somma da lire tremilioni (Ndr: euro 1.549,4) a lire diciottomilioni (Ndr: euro
9.296,2) o, nei casi di cui agli articoli 22, 24 e 24-bis o, comunque, di maggiore rilevanza del
pregiudizio per uno o più interessati, da lire cinquemilioni (Ndr: euro 2.582,3) a lire trentamilioni
(Ndr: euro 15.493,7). La somma può essere aumentata sino al triplo quando essa risulti inefficace in
ragione delle condizioni economiche del contravventore. La violazione della disposizione di cui
all'articolo 23, comma 2, è punita con la sanzione amministrativa del pagamento di una somma da lire
cinquecentomila (Ndr: euro 258,2) a lire tremilioni (Ndr: euro 1549,4) (*).
3. L'organo competente a ricevere il rapporto e ad irrogare le sanzioni di cui al presente capo (*) è il
Garante. Si osservano, in quanto applicabili, le disposizioni della legge 24 novembre 1981, n. 689, e
successive modificazioni. I proventi, nella misura del cinquanta per cento del totale annuo, sono
riassegnati al fondo di cui all'articolo 33, comma 2, e sono utilizzati unicamente per l'esercizio dei
compiti di cui agli articoli 31, comma 1, lettera i) e 32.
CAPO IX
DISPOSIZIONI TRANSITORIE E FINALI ED ABROGAZIONI
Articolo 40
Comunicazioni al garante
1. Copia dei provvedimenti emessi dall'autorità giudiziaria in relazione a quanto previsto dalla
presente legge e dalla legge 23 dicembre 1993, n. 547, è trasmessa, a cura della cancelleria, al
Garante.
Articolo 41
Disposizioni transitorie
1. Fermo restando l'esercizio dei diritti di cui agli articoli 13 e 29, le disposizioni della presente legge
che prescrivono il consenso dell'interessato non si applicano in riferimento ai dati personali raccolti
precedentemente alla data di entrata in vigore della legge stessa, o il cui trattamento sia iniziato prima
di tale data. Resta salva l'applicazione delle disposizioni relative alla comunicazione e alla diffusione
dei dati previste dalla presente legge.
Le disposizioni del presente comma restano in vigore sino alla data del 30 giugno 2003. (*)
2. Per i trattamenti di dati personali iniziati prima del 1 gennaio 1998 le notificazioni prescritte dagli
articoli 7 e 28 sono effettuate dal 1 gennaio 1998 al 31 marzo 1998 ovvero, per i trattamenti di cui
all'articolo 5 riguardanti dati diversi da quelli di cui agli articoli 22 e 24, nonchè per quelli di cui
all'articolo 4, comma 1, lettere c), d) ed e), dal 1 aprile 1998 al 30 giugno 1998.
3. Le misure minime di sicurezza di cui all'articolo 15, comma 2, devono essere adottate entro il
termine di sei mesi dalla data di entrata in vigore del regolamento ivi previsto. Fino al decorso di tale
termine, i dati personali devono essere custoditi in maniera tale da evitare un incremento dei rischi di
cui all'articolo 15, comma 1.
4. Le misure di cui all'articolo 15, comma 3, devono essere adottate entro il termine di sei mesi dalla
data di entrata in vigore dei regolamenti ivi previsti.
5. Nei ventiquattro mesi successivi alla data di entrata in vigore della presente legge, i trattamenti dei
dati di cui all'articolo 22, comma 3, ad opera di soggetti pubblici, esclusi gli enti pubblici economici, e
all'articolo 24, possono essere proseguiti anche in assenza delle disposizioni di legge ivi indicate,
previa comunicazione al Garante.
6. In sede di prima applicazione della presente legge, fino alla elezione del Garante ai sensi
dell'articolo 30, le funzioni del Garante sono svolte dal presidente dell'Autorità per l'informatica nella
pubblica amministrazione, fatta eccezione per l'esame dei ricorsi di cui all'articolo 29.
7. Le disposizioni della presente legge che prevedono un'autorizzazione del Garante si applicano,
limitatamente alla medesima autorizzazione e fatta eccezione per la disposizione di cui all'articolo 28,
comma 4, lettera g), a decorrere dal 30 novembre 1997. Le medesime disposizioni possono essere
applicate dal Garante anche mediante il rilascio di autorizzazioni relative a determinate categorie di
titolari o di trattamenti.
7-bis. In sede di prima applicazione della presente legge, le informative e le comunicazioni di cui agli
articoli 10, comma 3, e 27, comma 2, possono essere date entro il 30 novembre 1997.
Articolo 42
Modifiche a disposizioni vigenti
1. L'articolo 10 della legge 1. aprile 1981, n. 121, è sostituito dal seguente:
"Articolo
10
-Controlli
1. Il controllo sul Centro elaborazione dati è esercitato dal Garante per la protezione dei dati
personali, nei modi previsti dalla legge e dai regolamenti.
2. I dati e le informazioni conservati negli archivi del Centro possono essere utilizzati in
procedimenti giudiziari o amministrativi soltanto attraverso l'acquisizione delle fonti
originarie indicate nel primo comma dell'articolo 7, fermo restando quanto stabilito
dall'articolo 240 del codice di procedura penale. Quando nel corso di un procedimento
giurisdizionale o amministrativo viene rilevata l'erroneità o l'incompletezza dei dati e delle
informazioni, o l'illegittimità del loro trattamento, l'autorità procedente ne dà notizia al
Garante per la tutela delle persone e di altri soggetti rispetto al trattamento dei dati
personali.
3. La persona alla quale si riferiscono i dati può chiedere all'ufficio di cui alla lettera a) del
primo comma dell'articolo 5 la conferma dell'esistenza di dati personali che lo riguardano, la
loro comunicazione in forma intellegibile e, se i dati risultano trattati in violazione di vigenti
disposizioni di legge o di regolamento, la loro cancellazione o trasformazione in forma
anonima.
4. Esperiti i necessari accertamenti, l'ufficio comunica al richiedente, non oltre venti giorni
dalla richiesta, le determinazioni adottate. L'ufficio può omettere di provvedere sulla richiesta
se ciò può pregiudicare azioni od operazioni a tutela dell'ordine e della sicurezza pubblica o
di prevenzione e repressione della criminalità, dandone informazione al Garante per la
protezione dei dati personali.
5. Chiunque viene a conoscenza dell'esistenza di dati personali che lo riguardano, trattati
anche in forma non automatizzata in violazione di disposizioni di legge o di regolamento, può
chiedere al tribunale del luogo ove risiede il titolare del trattamento di compiere gli
accertamenti necessari e di ordinare la rettifica, l'integrazione, la cancellazione o la
trasformazione in forma anonima dei dati medesimi. Il tribunale provvede nei modi di cui agli
articoli 737 e seguenti del codice di procedura civile".
2. Il comma 1 dell'articolo 4 del decreto legislativo 12 febbraio 1993, n. 39, è sostituito dal seguente:
"1. è istituita l'Autorità per l'informatica nella pubblica amministrazione, denominata
"Autorità" ai fini del presente decreto; tale Autorità opera in piena autonomia e con
indipendenza di giudizio e di valutazione".
3. Il comma 1 dell'articolo 5 del decreto legislativo 12 febbraio 1993, n. 39, è sostituito dal seguente:
"1. Le norme concernenti l'organizzazione ed il funzionamento dell'Autorità, l'istituzione del
ruolo del personale, il relativo trattamento giuridico ed economico e l'ordinamento delle
carriere, nonché la gestione delle spese nei limiti previsti dal presente decreto, anche in
deroga alle disposizioni sulla contabilità generale dello Stato, sono adottate con regolamento
emanato con decreto del Presidente della Repubblica, previa deliberazione del Consiglio dei
ministri, sentito il Consiglio di Stato, su proposta del Presidente del Consiglio dei ministri, di
concerto con il Ministro del tesoro e su parere conforme dell'Autorità medesima. Il parere del
Consiglio di Stato sullo schema di regolamento è reso entro trenta giorni dalla ricezione della
richiesta, decorsi i quali il regolamento può comunque essere emanato. Si applica il
trattamento economico previsto per il personale del Garante per l'editoria e la
radiodiffusione ovvero dell'organismo che dovesse subentrare nelle relative funzioni, fermo
restando il limite massimo complessivo di centocinquanta unità. Restano altresì fermi gli
stanziamenti dei capitoli di cui al comma 2, così come determinati per il 1995 e tenendo conto
dei limiti di incremento previsti per la categoria IV per il triennio 1996-1998".
4. Negli articoli 9, comma 2, e 10, comma 2, della legge 30 settembre 1993, n. 388, le parole:
"Garante per la protezione dei dati" sono sostituite dalle seguenti: "Garante per la tutela delle persone
e di altri soggetti rispetto al trattamento dei dati personali".
Articolo 43
Abrogazioni
1. Sono abrogate le disposizioni di legge o di regolamento incompatibili con la presente legge e, in
particolare, il quarto comma dell'articolo 8 ed il quarto comma dell'articolo 9 della legge 1. aprile
1981, n. 121. Entro sei mesi dalla data di emanazione del decreto di cui all'articolo 33, comma 1, della
presente legge, il Ministro dell'interno trasferisce all'ufficio del Garante il materiale informativo
raccolto a tale data in attuazione del citato articolo 8 della legge n. 121 del 1981.
2. Restano ferme le disposizioni della legge 20 maggio 1970, n. 300, e successive modificazioni,
nonché, in quanto compatibili, le disposizioni della legge 5 giugno 1990, n. 135, e successive
modificazioni, del decreto legislativo 6 settembre 1989, n. 322, nonché le vigenti norme in materia di
accesso ai documenti amministrativi ed agli archivi di Stato. Restano altresì ferme le disposizioni di
legge che stabiliscono divieti o limiti più restrittivi in materia di trattamento di taluni dati personali.
3. Per i trattamenti di cui all'articolo 4, comma 1, lettera e), della presente legge, resta fermo l'obbligo
di conferimento di dati ed informazioni di cui all'articolo 6, primo comma, lettera a), della legge 1.
aprile 1981, n. 121.
CAPO X
COPERTURA FINANZIARIA ED ENTRATA IN VIGORE
Articolo 44
Copertura finanziaria
1. All'onere derivante dall'attuazione della presente legge, valutato in lire 8.029 milioni per il 1997 ed
in lire 12.045 milioni a decorrere dal 1998, si provvede mediante corrispondente riduzione dello
stanziamento iscritto, ai fini del bilancio triennale 1997-1999, al capitolo 6856 dello stato di
previsione del Ministero del tesoro per l'anno 1997, all'uopo utilizzando, per il 1997, quanto a lire
4.553 milioni, l'accantonamento riguardante il Ministero degli affari esteri e, quanto a lire 3.476
milioni, l'accantonamento riguardante la Presidenza del Consiglio dei ministri e, per gli anni 1998 e
1999, quanto a lire 6.830 milioni, le proiezioni per gli stessi anni dell'accantonamento riguardante il
Ministero degli affari esteri e, quanto a lire 5.215 milioni, le proiezioni per gli stessi anni
dell'accantonamento riguardante la Presidenza del Consiglio dei ministri.
2. Il Ministro del tesoro è autorizzato ad apportare, con propri decreti, le occorrenti variazioni di
bilancio.
Articolo 45
Entrata in vigore
1. La presente legge entra in vigore centoventi giorni dopo la sua pubblicazione nella Gazzetta
Ufficiale. Per i trattamenti svolti senza l'ausilio di mezzi elettronici o comunque automatizzati che non
riguardano taluno dei dati di cui agli articoli 22 e 24, le disposizioni della presente legge si applicano
a decorrere dal 1 gennaio 1998. Fermo restando quanto previsto dall'articolo 9, comma 2, della legge
30 settembre 1993, n. 388, la presente legge entra in vigore il giorno successivo a quello della sua
pubblicazione nella Gazzetta Ufficiale, limitatamente ai trattamenti di dati effettuati in esecuzione
dell'accordo di cui all'articolo 4, comma 1, lettera a) e alla nomina del Garante.
Legge n. 241 del 7 agosto 1990
Nuove norme in materia di procedimento amministrativo e di diritto di accesso ai documenti
amministrativi
INDICE
CAPO I - Principi
Art. 1
Art. 2
Art. 3
CAPO II - Responsabile del procedimento
Art. 4
Art. 5
Art. 6
CAPO III - Partecipazione al procedimento amministrativo
Art. 7
Art. 8
Art. 9
Art. 10
Art. 11
Art. 12
Art. 13
CAPO IV - Semplificazione dell'azione amministrativa
Art. 14
Art. 14 bis
Art. 14 ter
Art. 14 quater
Art. 15
Art. 16
Art. 17
Art. 18
Art. 19
Art. 20
Art. 21
CAPO V - Accesso ai documenti amministrativi
Art. 22
Art. 23
Art. 24
Art. 25
Art. 26
Art. 27
Art. 28
CAPO VI - Disposizioni finali
Art. 29
Art. 30
Art. 31
-------------------------------------------------------------------------------CAPO I - Principi
Articolo 1
1. L’attività amministrativa persegue i fini determinati dalla legge ed è retta da criteri di economicità,
di efficacia e di pubblicità secondo le modalità previste dalla presente legge e dalle altre disposizioni
che disciplinano i singoli procedimenti.
2. La pubblica amministrazione non può aggravare il procedimento se non per straordinarie e motivate
esigenze imposte dallo svolgimento dell’istruttoria.
Articolo 2
1. Ove il procedimento consegua obbligatoriamente ad una istanza, ovvero debba essere iniziato
d’ufficio, la pubblica amministrazione ha il dovere di concluderlo mediante l’adozione di un
provvedimento espresso.
2. Le pubbliche amministrazioni determinano per ciascun tipo di procedimento, in quanto non sia già
direttamente disposto per legge o per regolamento, il termine entro cui esso deve concludersi. Tale
termine decorre dall’inizio di ufficio del procedimento o dal ricevimento della domanda se il
procedimento è ad iniziativa di parte.
3. Qualora le pubbliche amministrazioni non provvedano ai sensi del comma 2, il termine è di trenta
giorni.
4. Le determinazioni adottate ai sensi del comma 2 sono rese pubbliche secondo quanto previsto dai
singoli ordinamenti.
Articolo 3
1. Ogni provvedimento amministrativo, compresi quelli concernenti l’organizzazione amministrativa,
lo svolgimento dei pubblici concorsi ed il personale, deve essere motivato, salvo che nelle ipotesi
previste dal comma 2. La motivazione deve indicare i presupposti di fatto e le ragioni giuridiche che
hanno determinato la decisione dell’amministrazione, in relazione alle risultanze dell’istruttoria.
2. La motivazione non è richiesta per gli atti normativi e per quelli a contenuto generale.
3. Se le ragioni della decisione risultano da altro atto dell’amministrazione richiamato dalla decisione
stessa, insieme alla comunicazione di quest’ultima deve essere indicato e reso disponibile, a norma
della presente legge, anche l’atto cui essa si richiama.
4. In ogni atto notificato al destinatario devono essere indicati il termine e l’autorità cui è possibile
ricorrere.
CAPO II - Responsabile del procedimento
Articolo 4
1. Ove non sia già direttamente stabilito per legge o per regolamento, le pubbliche amministrazioni
sono tenute a determinare per ciascun tipo di procedimento relativo ad atti di loro competenza l’unità
organizzativa responsabile della istruttoria e di ogni altro adempimento procedimentale, nonché
dell’adozione del provvedimento finale.
2. Le disposizioni adottate ai sensi del comma 1 sono rese pubbliche secondo quanto previsto dai
singoli ordinamenti.
Articolo 5
1. Il dirigente di ciascuna unità organizzativa provvede ad assegnare a sé o ad altro dipendente addetto
all’unità la responsabilità dell’ istruttoria e di ogni altro adempimento inerente il singolo procedimento
nonché, eventualmente, dell’adozione del provvedimento finale.
2. Fino a quando non sia effettuata l’assegnazione di cui al comma 1, è considerato responsabile del
singolo procedimento il funzionario preposto alla unità organizzativa determinata a norma del comma 1
dell’articolo 4.
3. L’unità organizzativa competente e il nominativo del responsabile del procedimento sono comunicati
ai soggetti di cui all’articolo 7 e, a richiesta, a chiunque vi abbia interesse.
Articolo 6
1. Il responsabile del procedimento:
a) valuta, ai fini istruttori, le condizioni di ammissibilità, i requisiti di legittimazione ed i presupposti
che siano rilevanti per l’emanazione di provvedimento;
b) accerta di ufficio i fatti, disponendo il compimento degli atti all’uopo necessari, e adotta ogni misura
per l’adeguato e sollecito svolgimento dell’istruttoria. In particolare, può chiedere il rilascio di
dichiarazioni e la rettifica di dichiarazioni o istanze erronee o incomplete e può esperire accertamenti
tecnici ed ispezioni ed ordinare esibizioni documentali;
c) propone l’indizione o, avendone la competenza, indice le conferenze di servizi cui all’articolo 14;
d) cura le comunicazioni, le pubblicazioni e le modificazioni previste dalle leggi e dai regolamenti;
e) adotta, ove ne abbia la competenza, il provvedimento finale, ovvero trasmette gli atti all’organo
competente per l’adozione.
CAPO III - Partecipazione al procedimento amministrativo
Articolo 7
1. Ove non sussistano ragioni di impedimento derivanti da particolari esigenze di celerità del
procedimento, l’avvio del procedimento stesso è comunicato, con le modalità previste dall’articolo 8, ai
soggetti nei confronti dei quali il provvedimento finale è destinato a produrre effetti diretti ed a quelli
che per legge debbono intervenirvi. Ove parimenti non sussistano le ragioni di impedimento predette,
qualora da un provvedimento possa derivare un pregiudizio a soggetti individuati o facilmente
individuabili, diversi dai suoi diretti destinatari, l’amministrazione è tenuta a fornire loro, con le stesse
modalità, notizie dell’inizio del procedimento.
2. Nelle ipotesi di cui al comma 1 resta salva la facoltà dell’amministrazione di adottare, anche prima
della effettuazione delle comunicazioni di cui al medesimo comma 1, provvedimenti cautelari.
Articolo 8
1. L’amministrazione provvede a dare notizia dell’avvio del procedimento mediante comunicazione
personale.
2 Nella comunicazione debbono essere indicati:
a) l’amministrazione competente;
b) l’oggetto del procedimento promosso;
c) l’ufficio e la persona responsabile del procedimento;
d) l’ufficio in cui si può prendere visione degli atti.
3. Qualora per il numero dei destinatari la comunicazione personale non sia possibile o risulti
particolarmente gravosa, l’amministrazione provvede a rendere noti gli elementi di cui al comma 2
mediante forme di pubblicità idonee di volta in volta stabilite dall’amministrazione medesima.
4 L’omissione di taluna delle comunicazioni prescritte può essere fatta valere solo dal soggetto nel cui
interesse la comunicazione è prevista.
Articolo 9
1. Qualunque soggetto, portatore di interessi pubblici o privati, nonché i portatori di interessi diffusi
costituiti in associazioni o comitati, cui possa derivare un pregiudizio dal provvedimento, hanno facoltà
di intervenire nel procedimento.
Articolo 10
1. I soggetti di cui all’articolo 7 e quelli intervenuti ai sensi dell’articolo 9 hanno diritto :
a) di prendere visione degli atti del procedimento, salvo quanto previsto dall’articolo 24;
b) di presentare memorie scritte e documenti, che l’amministrazione ha l’obbligo di valutare ove siano
pertinenti all’oggetto del procedimento.
Articolo 11
1. In accoglimento di osservazioni e proposte presentate a norma dell’articolo 10, l’amministrazione
procedente può concludere, senza pregiudizio dei diritti dei terzi, e in ogni caso nel perseguimento del
pubblico interesse, accordi con gli interessati al fine di determinare il contenuto discrezionale del
provvedimento finale ovvero, nei casi previsti dalla legge, in sostituzione di questo.
1-bis. Al fine di favorire la conclusione degli accordi di cui al comma 1, il responsabile del
procedimento può predisporre un calendario di incontri cui invita, separatamente o contestualmente, il
destinatario del provvedimento ed eventuali controinteressati.
2. Gli accordi di cui al presente articolo debbono essere stipulati, a pena di nullità, per atto scritto, salvo
che la legge disponga altrimenti.
Ad essi si applicano, ove non diversamente previsto, i principi del codice civile in materia di
obbligazioni e contratti in quanto compatibili.
3. Gli accordi sostitutivi di provvedimenti sono soggetti ai medesimi controlli previsti per questi ultimi.
4. Per sopravvenuti motivi di pubblico interesse l’amministrazione recede unilateralmente dall’accordo,
salvo l’obbligo di provvedere alla liquidazione di un indennizzo in relazione agli eventuali pregiudizi
verificatisi in danno del privato.
5. Le controversie in materia di formazione, conclusione ed esecuzione degli accordi di cui al presente
articolo sono riservate alla giurisdizione esclusiva del giudice amministrativo.
Articolo 12
1. La concessione di sovvenzioni, contributi, sussidi ed ausili finanziari e l’attribuzione di vantaggi
economici di qualunque genere a persone ed enti pubblici e privati sono subordinate alla
predeterminazione ed alla pubblicazione da parte delle amministrazioni procedenti, nelle forme
previste dai rispettivi ordinamenti, dei criteri e delle modalità cui le amministrazioni stesse devono
attenersi.
2. L’effettiva osservanza dei criteri e delle modalità di cui al comma 1 deve risultare dai singoli
provvedimenti relativi agli interventi di cui al medesimo comma 1.
Articolo 13
1. Le disposizioni contenute nel presente capo non si applicano nei confronti dell’attività della pubblica
amministrazione diretta alla emanazione di atti normativi, amministrativi generali, di pianificazione e
di programmazione, per i quali restano ferme le particolari norme che ne regolano la formazione.
2. Dette disposizioni non si applicano altresì ai procedimenti tributari per i quali restano parimenti
ferme le particolari norme che li regolano.
CAPO IV - Semplificazione dell'azione amministrativa
Articolo 14
1. Qualora sia opportuno effettuare un esame contestuale di vari interessi pubblici coinvolti in un
procedimento amministrativo, l’amministrazione procedente indice di regola una conferenza di servizi.
2. La conferenza stessa può essere indetta anche quando l’amministrazione procedente debba acquisire
intese, concerti, nullaosta o assensi comunque denominati di altre amministrazioni pubbliche. In tal
caso, le determinazioni concordate nella conferenza sostituiscono a tutti gli effetti i concerti, le intese, i
nullaosta e gli assensi richiesti.
2- bis Nella prima riunione della conferenza di servizi le amministrazioni che vi partecipano
stabiliscono il termine entro cui è possibile pervenire ad una decisione. In caso di inutile decorso del
termine l’amministrazione indicente procede ai sensi dei commi 3- bis e 4.
2- ter Le disposizioni cui ai commi 2 e 2- bis si applicano anche quando l’attività del privato sia
subordinata ad atti di consenso, comunque denominati, di competenza di amministrazioni pubbliche
diverse. In questo caso, la conferenza è convocata, anche su richiesta dell’interessato,
dall’amministrazione preposta a tutela dell’interesse pubblico prevalente.
3 Si considera acquisito l’assenso dell’amministrazione la quale, regolarmente convocata, non abbia
partecipato alla conferenza o vi abbia partecipato tramite rappresentanti privi della competenza ad
esprimere definitivamente la volontà, salvo che essa non comunichi all’amministrazione procedente il
proprio motivato dissenso entro venti giorni dalla conferenza stessa ovvero dalla data di ricevimento
della comunicazione delle determinazioni adottate, qualora queste ultime abbiano contenuto
sostanzialmente diverso da quelle originariamente previste.
3- bis Nel caso in cui una amministrazione abbia espresso, anche nel corso della conferenza, il proprio
motivato dissenso, l’amministrazione procedente può assumere la determinazione di conclusione
positiva del procedimento dandone comunicazione al Presidente del Consiglio dei ministri, ove
l’amministrazione procedente o quella dissenziente sia una amministrazione statale; negli altri casi la
comunicazione è data al presidente della regione ed ai sindaci. Il presidente del Consiglio dei ministri,
previa delibera del Consiglio medesimo, o il presidente della regione o i sindaci, previa delibera del
consiglio regionale o dei consigli comunali, entro trenta giorni dalla ricezione della comunicazione,
possono disporre la sospensione della determinazione inviata; trascorso tale termine, in assenza di
sospensione, la determinazione è esecutiva.
4 Qualora il motivato dissenso alla conclusione del procedimento sia espresso da una amministrazione
preposta alla tutela ambientale, paesaggistico-territoriale, del patrimonio storico-artistico o alla tutela
della salute dei cittadini, l’amministrazione procedente può richiedere, purché non vi sia stata una
precedente valutazione di impatto ambientale negativa in base alle norme tecniche di cui al decreto del
Presidente del Consiglio dei ministri 27 dicembre 1988, pubblicato nella Gazzetta Ufficiale n. 4 del 5
gennaio 1989, una determinazione di conclusione del procedimento al Presidente del Consiglio dei
ministri, previa deliberazione del Consiglio dei ministri (5/a).
4- bis La conferenza di servizi può essere convocata anche per l’esame contestuale di interessi coinvolti
in più procedimenti amministrativi connessi, riguardanti medesimi attività o risultati. In tal caso, la
conferenza è indetta dalla amministrazione o, previa informale intesa, da una delle amministrazioni che
curano l’interesse pubblico prevalente ovvero dall’amministrazione competente a concludere il
procedimento che cronologicamente deve precedere gli altri connessi. L’indizione della conferenza può
essere richiesta da qualsiasi altra amministrazione coinvolta (5/b).
Articolo 14 bis
1. Il ricorso alla conferenza di servizi è obbligatorio nei casi in cui l’attività di programmazione,
progettazione, localizzazione, decisione o realizzazione di opere pubbliche o programmi operativi di
importo iniziale complessivo superiore a lire 30 miliardi richieda l’intervento di più amministrazioni o
enti, anche attraverso intese, concerti, nullaosta o assensi comunque denominati, ovvero qualora si tratti
di opere di interesse statale o che interessino più regioni. La conferenza può essere indetta anche dalla
amministrazione preposta al coordinamento in base alla disciplina vigente e può essere richiesta da
qualsiasi altra amministrazione coinvolta in tale attività.
2. Nelle conferenze di servizi di cui al comma 1, la decisione si considera adottata se, acquisita anche
in sede diversa ed anteriore alla conferenza di servizi una intesa tra lo Stato e la regione o le regioni
territorialmente interessate, si esprimano a favore della determinazione i rappresentanti di comuni o
comunità montane i cui abitanti, secondo i dati dell’ultimo censimento ufficiale, costituiscono la
maggioranza di quelli delle collettività locali complessivamente interessate dalla decisione stessa e
comunque i rappresentanti della maggioranza dei comuni o delle comunità mo ntane interessate.
Analoga regola vale per i rappresentanti delle province.
Articolo 14 ter
1. La conferenza di servizi di cui all’articolo 3 del decreto del Presidente della Repubblica 18 aprile
1994, n.383, può essere convocata prima o nel corso dell’accertamento di conformità di cui all’ articolo
2 del predetto decreto. Quando l’accertamento abbia dato esito positivo, la conferenza approva i
progetti entro trenta giorni dalla convocazione.
2. La conferenza di cui al comma 1 è indetta, per le opere di interesse statale, dal provveditore alle
opere pubbliche competente per territorio. Allo stesso organo compete l’accertamento di cui all’articolo
2 del decreto del Presidente della Repubblica 18 aprile 1994, n. 383, salvo il caso di opere che
interessano il territorio di più regioni per il quale l’intesa viene accertata dai competenti organi del
Ministero dei lavori pubblici.
Articolo 14 quater
1. Nei procedimenti relativi ad opere per le quali sia intervenuta la valutazione di impatto ambientale di
cui all’articolo 6 della legge 8 luglio 1986, n.349, le disposizioni di cui agli articoli 14, comma 4,16,
comma 3, e 17, comma 2, si applicano alle sole amministrazioni preposte alla tutela della salute dei
cittadini, fermo restando quanto disposto dall’articolo 3, comma 5, del decreto del Presidente della
Repubblica 18 aprile 1994, n. 383. Su proposta del Ministro competente, del Ministro dell’ambiente o
del Ministro per i beni culturali e ambientali, la valutazione di impatto ambientale può essere estesa,
con decreto del Presidente del Consiglio dei ministri, previa delibera del Consiglio dei ministri, anche
ad opere non appartenenti alle categorie individuate ai sensi dell’articolo 6 della legge 8 luglio 1986,
n.349.
2. Per l’opera sottoposta a valutazione di impatto ambientale, il provvedimento finale, adottato a
conclusione del relativo procedimento, è pubblicato, a cura del proponente, unitamente all’estratto della
predetta valutazione di impatto ambientale, nella Gazzetta Ufficiale e su un quotidiano a diffusione
nazionale. Dalla data della pubblicazione nella Gazzetta Ufficiale decorrono i termini per eventuali
impugnazioni in sede giurisdizionale da parte dei soggetti interessati.
Articolo 15
1. Anche al di fuori delle ipotesi previste dall’articolo 14, el amministrazioni pubbliche possono
sempre concludere tra loro accordi per disciplinare lo svolgimento in collaborazione di attività di
interesse comune .
2. Per detti accordi si osservano, in quanto applicabili, le disposizioni previste dall’articolo 11, commi
2, 3 e 5.
Articolo 16
1. Gli organi consultivi delle pubbliche amministrazioni di cui all’articolo 1, comma 2, del decreto
legislativo 3 febbraio 1993, n. 29, sono tenuti a rendere i pareri ad essi obbligatoriamente richiesti entro
quarantacinque giorni dal ricevimento della richiesta. Qualora siano richiesti di pareri facoltativi, sono
tenuti a dare immediata comunicazione alle amministrazioni richiedenti del termine entro il quale il
parere sarà reso.
2. In caso di decorrenza del termine senza che sia stato comunicato il parere o senza che l’organo adito
abbia rappresentato esigenze istruttorie, è in facoltà dell’amministrazione richiedente di procedere
indipendentemente dall’acquisizione del parere.
3. Le disposizioni di cui ai commi 1 e 2 non si applicano in caso di pareri che debbano essere rilasciati
da amministrazioni preposte alla tutela ambientale, paesaggistica, territoriale e della salute dei cittadini.
4. Nel caso in cui l’organo adito abbia rappresentato esigenze istruttorie il termine di cui al comma 1
può essere interrotto per una sola volta e il parere deve essere reso definitivamente entro quindici giorni
dalla ricezione degli elementi istruttori da parte delle amministrazioni interessate.
5. Qualora il parere sia favorevole, senza osservazioni, il dispositivo è comunicato telegraficamente o
con mezzi telematici.
6. Gli organi consultivi dello Stato predispongono procedure di particolare urgenza per l’adozione dei
pareri loro richiesti.
Articolo 17
1. Ove per disposizione espressa di legge o di regolamento sia previsto che per l’adozione di un
provvedimento debbano essere preventivamente acquisite le valutazioni tecniche di organi od enti
appositi e tali organi ed enti non provvedano o non rappresentino esigenze istruttorie di competenza
dell’amministrazione procedente nei termini prefissati dalla disposizione stessa o , in mancanza, entro
novanta giorni dal ricevimento della richiesta, il responsabile del procedimento deve chiedere le
suddette valutazioni tecniche ad altri organi dell’amministrazione pubblica o ad enti pubblici che siano
dotati di qualificazione e capacità tecnica equipollenti, ovvero ad istituti universitari.
2. La disposizione di cui al comma 1 non si applica in caso di valutazioni che debbano essere prodotte
da ammin istrazioni preposte alla tutela ambientale, paesaggistico-territoriale e della salute dei cittadini.
3. Nel caso in cui l’ente od organo adito abbia rappresentato esigenze istruttorie all’amministrazione
procedente, si applica quanto previsto dal comma 4 dell’articolo 16.
Articolo 18
1. Entro sei mesi dalla data di entrata in vigore della presente legge le amministrazioni interessate
adottano le misure organizzative idonee a garantire l’applicazione delle disposizioni in materia di
autocertificazione e di presentazione di atti e documenti da parte di cittadini a pubbliche
amministrazioni di cui alla legge 4 gennaio 1968, n.15, e successive modificazioni e integrazioni.
Delle misure adottate le amministrazioni danno comunicazione alla commissione di cui all’articolo 27.
2. Qualora l’interessato dichiari che fatti, stati e qualità sono attestati in documenti già in possesso della
stessa amministrazione procedente o di altra pubblica amministrazione, il responsabile del
procedimento provvede d’ufficio all’acquisizione dei documenti stessi o di copie di essi.
3. Parimenti sono accertati d’ufficio dal responsabile del procedimento i fatti, gli stati e le qualità che la
stessa amministrazione procedente o altra pubblica amministrazione è tenuta a certificare.
Articolo 19
1. In tutti i casi in cui l’esercizio di una attività privata sia subordinato ad autorizzazione, licenza,
abilitazione, nulla osta, permesso o altro atto di consenso comunque denominato, ad esclusione delle
concessioni edilizie e delle autorizza zioni rilasciate ai sensi delle leggi 1° giugno 1939, n.1089, 29
giugno 1939, n.1497, e del D.L. 27 giugno 1985, n. 312, convertito, con modificazioni, dalla L. 8
agosto 1985, n. 431, il cui rilascio dipenda esclusivamente dall’accertamento dei presupposti e dei
requisiti di legge, senza l’esperimento di prove a ciò destinate che comportino valutazioni tecniche
discrezionali, e non sia previsto alcun limite o contingente complessivo per il rilascio degli atti stessi,
l’atto di consenso si intende sostituito da una denuncia di inizio di attività da parte dell’interessato alla
pubblica amministrazione competente, attestante l’esigenza dei presupposti e dei requisiti di legge,
eventualmente accompagnata dall’autocertificazione dell’esperimento di prove a ciò destinate, ove
previste. In tali casi, spetta all’amministrazione competente, entro e non oltre sessanta giorni dalla
denuncia, verificare d’ufficio la sussistenza dei presupposti e dei requisiti di legge richiesti e disporre,
se del caso, con provvedimento motivato da notificare all’interessato entro il medesimo termine, il
divieto di prosecuzione dell’attività e la rimozione dei suoi effetti, salvo che, ove ciò sia possibile,
l’interessato provveda a conformare alla normativa vigente detta attività ed i suoi effetti entro il termine
prefissatogli dall’amministrazione stessa.
Articolo 20
1. Con regolamento adottato ai sensi del comma 2 dell’articolo 17 della legge 23 agosto 1988, n. 400,
da emanarsi entro novanta giorni dalla data di entrata in vigore della presente legge e previo parere
delle competenti Commissioni parlamentari, sono determinati i casi in cui la domanda di rilascio di una
autorizzazione, licenza, abilitazione, nulla-osta, permesso od altro atto di consenso comunque
denominato, cui sia subordinato lo svolgimento di un’attività privata, si considera accolta qualora non
venga comunicato all’interessato il provvedimento di diniego entro il termine fissato per categorie di
atti, in relazione alla complessità del rispettivo procedimento, dal medesimo predetto regolamento . In
tali casi, sussistendone le ragioni di pubblico interesse, l’amministrazione competente può annullare
l’atto di assenso illegittimamente formato, salvo che, ove ciò sia possibile, l’interessato provveda a
sanare i vizi entro il termine prefissatogli dall’amministrazione stessa.
2. Ai fini dell’adozione del regolamento di cui al comma 1, il parere delle Commissioni parlamentari e
del Consiglio di Stato deve essere reso entro sessanta giorni dalla richiesta. Decorso tale termine, il
Governo procede comunque all’adozione dell’atto.
3. Restano ferme le disposizioni attualmente vigenti che stabiliscono regole analoghe o equipollenti a
quelle previste dal presente articolo.
Articolo 21
1. Con la denuncia o con la domanda di cui agli articoli 19 e 20 l’interessato deve dichiarare la
sussistenza dei presupposti e dei requisiti di legge richiesti. In caso di dichiarazioni mendaci o di false
attestazioni non è ammessa la conformazione dell’attività e dei suoi effetti a legge o la sanatoria
prevista dagli articoli medesimi ed il dichiarante è punito con la sanzione prevista dall’articolo 483 del
codice penale, salvo che il fatto costituisca più grave reato.
2. Le sanzioni attualmente previste in caso di svolgimento dell’attività in carenza dell’atto di assenso
dell’amministrazione o in difformità di esso si applicano anche nei riguardi di coloro i quali diano
inizio all’attività ai sensi degli articoli 19 e 20 in mancanza dei requisiti richiesti o, comunque, in
contrasto con la normativa vigente.
CAPO V - Accesso ai documenti amministrativi
Articolo 22
1. Al fine di assicurare la trasparenza dell’attività amministrativa e di favorirne lo svolgimento
imparziale è riconosciuto a chiunque vi abbia interesse per la tutela di situazioni giurid icamente
rilevanti il diritto di accesso ai documenti amministrativi, secondo le modalità stabilite dalla presente
legge.
2.E’ considerato documento amministrativo ogni rappresentazione grafica, fotocinematografica,
elettromagnetica o di qualunque altra specie del contenuto di atti, anche interni, formati dalle pubbliche
amministrazioni o, comunque, utilizzati ai fini dell’attività amministrativa.
3. Entro sei mesi della data di entrata in vigore della presente legge le amministrazioni interessate
adottano le misure organizzative idonee a garantire l’applicazione della disposizione di cui al comma 1,
dandone comunicazione alla Commissione di cui all’articolo 27.
Articolo 23
1. Il diritto di accesso di cui all’articolo 22 si esercita nei confronti delle amministrazioni dello Stato,
ivi compresi le aziende autonome, gli enti pubblici ed i concessionari di pubblici servizi.
Articolo 24
1. Il diritto di accesso è escluso per i documenti coperti da segreto di Stato ai sensi dell’articolo 12
della legge 24 ottobre 1977,
n. 801, nonché nei casi di segreto o di divieto di divulgazione altrimenti previsti dall’ordinamento.
2. Il Governo è autorizzato ad emanare, ai sensi del comma 2 dell’articolo 17 della legge 23 agosto
1988, n. 400, entro sei mesi dalla data di entrata in vigore della presente legge, uno o più decreti intesi
a disciplinare le modalità di esercizio del diritto di accesso e gli altri casi di esclusione del diritto di
accesso in relazione alla esigenza di salvaguardare:
a) la sicurezza, la difesa nazionale e le relazioni internazionali;
b) la politica monetaria e valutaria;
c) l’ordine pubblico e la prevenzione e repressione della criminalità;
d) la riservatezza di terzi, persone, gruppi ed imprese, garantendo peraltro agli interessati la visione
degli atti relativi ai procedimenti amministrativi, la cui conoscenza sia necessaria per curare o per
difendere i loro interessi giuridici.
3. Con i decreti di cui al comma 2 sono altresì stabilite norme particolari per assicurare che l’accesso ai
dati raccolti mediante strumenti informatici avvenga nel rispetto delle esigenze di cui al medesimo
comma 2.
4. Le singole amministrazioni hanno l’obbligo di individuare, con uno o più regolamenti da emanarsi
entro i sei mesi successivi, le categorie di documenti da esse formati o comunque rientranti nella loro
disponibilità sottratti all’accesso per le esigenze di cui al comma 2.
5. Restano ferme le disposizioni previste dall’articolo 9, L. 1 aprile 1981, n. 121, come modificato
dall’articolo 26, L. 10 ottobre 1986, n. 668, e dalle relative norme di attuazione, nonché ogni altra
disposizione attualmente vigente che limiti l’accesso ai documenti amministrativi.
6. I soggetti indicati nell’articolo 23 hanno facoltà di differire l’accesso ai documenti richiesti sino a
quando la conoscenza di essi possa impedire o gravemente ostacolare lo svolgimento dell’azione
amministrativa. Non è comunque ammesso l’accesso agli atti preparatori nel corso della formazione dei
provvedimenti di cui all’articolo 13, salvo diverse disposizioni di legge.
Articolo 25
1. Il diritto di accesso si esercita mediante esame ed estrazione di copia dei documenti amministrativi,
nei modi e con i limiti indicati dalla presente legge. L’esame dei documenti è gratuito. Il rilascio di
copia è subordinato soltanto al rimborso del costo di riproduzione, salve le disposizioni vigenti in
materia di bollo, nonché i diritti di ricerca e di visura.
2. La richiesta di accesso ai documenti deve essere motivata. Essa deve essere rivolta
all’amministrazione che ha formato il documento o che lo detiene stabilmente.
3. Il rifiuto, il differimento e la limitazione dell’accesso sono ammessi nei casi e nei limiti stabiliti
dall’articolo 24 e debbono essere motivati.
4. Trascorsi inutilmente trenta giorni dalla richiesta, questa si intende rifiutata.
5. Contro le determinazioni amministrative concernenti il diritto di accesso e nei casi previsti dal
comma 4 è dato ricorso, nel termine di trenta giorni, al tribunale amministrativo regionale, il quale
decide in camera di consiglio entro trenta giorni dalla scadenza del termine per il deposito del ricorso,
uditi i difensori delle parti che ne abbiano fatto richiesta. La decisione del tribunale è appellabile, entro
trenta giorni dalla notifica della stessa, al Consiglio di Stato, il quale decide con le medesime modalità
e negli stessi termini.
6. In caso di totale o parziale accoglimento del ricorso il giudice amministrativo, sussistendone i
presupposti, ordina l’esibizione dei documenti richiesti.
Articolo 26
1. Fermo restando quanto previsto per le pubblicazioni nella Gazzetta Ufficiale della Repubblica
italiana dalla legge 11 dicembre 1984, n. 839, e dalle relative norme di attuazione, sono pubblicati,
secondo le modalità previste dai singoli ordinamenti, le direttive, i programmi, le istruzioni, le circolari
e ogni atto che dispone in generale sulla organizzazione, sulle funzioni, sugli obiettivi, sui procedimenti
di una pubblica amministrazione ovvero nel quale si determina l’interpretazione di norme giuridiche o
si dettano disposizioni per l’applicazione di esse.
2. Sono altresì pubblicate, nelle forme predette, le relazioni annuali della Commissione di cui
all’articolo 27 e, in generale, è data la massima pubblicità a tutte le disposizioni attuative della presente
legge e a tutte le iniziative dirette a precisare ed a rendere effettivo il diritto di accesso.
3. Con la pubblicazione di cui al comma 1, ove essa sia integrale, la libertà di accesso ai documenti
indicati nel predetto comma 1 s’intende realizzata.
Articolo 27
1. E’ istituita presso la Presidenza del Consiglio dei ministri la Commissione per l’accesso ai
documenti amministrativi.
2. La Commissione è nominata con decreto del Presidente della Repubblica, su proposta del Presidente
del Consiglio dei ministri, sentito il Consiglio dei ministri. Essa è presieduta dal sottosegretario di Stato
alla Presidenza del Consiglio dei ministri ed è composta da sedici membri , dei quali due senatori e due
deputati designati dai Presidenti delle rispettive Camere, quattro scelti fra il personale di cui alla legge
2 aprile 1979, n. 97, su designazione dei rispettivi organi di autogoverno, quattro fra i professori di
ruolo in materia giuridico-amministrative e quattro fra i dirigenti dello Stato e degli altri enti pubblici.
3. La Co mmissione è rinnovata ogni tre anni. Per i membri parlamentari si procede a nuova nomina in
caso di scadenza o scioglimento anticipato delle Camere nel corso del triennio.
4. Gli oneri per il funzionamento della Commissione sono a carico dello stato di previsione della
Presidenza del Consiglio dei ministri.
5. La Commissione vigila affinché venga attuato il principio di piena conoscibilità dell’attività della
pubblica amministrazione con il rispetto dei limiti fissati dalla presente legge; redige una relazione
annuale sulla trasparenza dell’attività della pubblica amministrazione, che comunica alle Camere e al
Presidente del Consiglio dei ministri; propone al Governo modifiche dei testi legislativi e regolamentari
che siano utili a realizzare la più ampia garanzia del diritto di accesso di cui all’articolo 22.
6. Tutte le amministrazioni sono tenute a comunicare alla Commissione, nel termine assegnato dalla
medesima, le informazioni ed i documenti da essa richiesti, ad eccezione di quelli coperti da segreto di
Stato.
7. In caso di prolungato inadempimento all’obbligo di cui al comma 1 dell’articolo 18, le misure ivi
previste sono adottate dalla Commissione di cui al presente articolo.
Articolo 28
1. (Sostituisce l’art. 15, D.P.R. 10 gennaio 1957, n. 3)
CAPO VI - Disposizioni finali
Articolo 29
1. Le regioni a statuto ordinario regolano le materie disciplinate dalla presente legge nel rispetto dei
principi desumibili dalle disposizioni in essa contenute, che costituiscono principi generali
dell’ordinamento giuridico. Tali disposizioni operano direttamente nei riguardi delle regioni fino a
quando esse non avranno legiferato in materia.
2. Entro un anno dalla data di entrata in vigore della presente legge, le regioni a statuto speciale e le
province autonome di Trento e di Bolzano provvedono ad adeguare i rispettivi ordinamenti alle norme
fondamentali contenute nella legge medesima.
Articolo 30
1. In tutti i casi in cui le leggi e i regolamenti prevedono atti di notorietà o attestazioni asseverate da
testimoni altrimenti denominate, il numero dei testimoni è ridotto a due.
2. E’ fatto divieto alle pubbliche amministrazioni e alle imprese esercenti servizi di pubblica necessità e
di pubblica utilità di esigere atti di notorietà in luogo della dichiarazione sostitutiva dell’atto di
notorietà prevista dall’articolo 4 della legge 4 gennaio 1968, n. 15, quando si tratti di provare qualità
personali, stati o fatti che siano a diretta conoscenza dell’interessato.
Articolo 31
1 Le norme sul diritto di accesso ai documenti amministrativi di cui al capo V hanno effetto dalla data
di entrata in vigore dei decreti di cui all’art. 24.
F
3897
ÅÖÇÌÅÑÉÓ ÔÇÓ ÊÕÂÅÑÍÇÓÅÙÓ
ÔÇÓ ÅËËÇÍÉÊÇÓ ÄÇÌÏÊÑÁÔÉÁÓ
Áñ. Öýëëïõ 273
ÔÅÕ×ÏÓ ÐÑÙÔÏ
19 Äåêåìâñßïõ 2000
ÍÏÌÏÓ ÕÐ ÁÑÉÈ. 2867
ÏñãÜíùóç êáé ëåéôïõñãßá ôùí ôçëåðéêïéíùíéþí êáé Üëëåò
äéáôÜîåéò
Ï ÐÑÏÅÄÑÏÓ
Åêäßäïìå ôïí áêüëïõèï íüìï ðïõ øÞöéóå ç ÂïõëÞ:
ÊÅÖÁËÁÉÏ Á´
ÃÅÍÉÊÅÓ ÄÉÁÔÁÎÅÉÓ
¢ñèñï 1
ÃåíéêÝò áñ÷Ýò
1. Ïé äéáôÜîåéò ôïõ ðáñüíôïò íüìïõ äéÝðïõí ôéò êÜèå åßäïõò ôçëåðéêïéíùíéáêÝò äñáóôçñéüôçôåò, ïé ïðïßåò áíáðôýóóïíôáé åíôüò ôçò ÅëëçíéêÞò ÅðéêñÜôåéáò áðü ïðïéïäÞðïôå öõóéêü Þ íïìéêü ðñüóùðï.
2. Ç Üóêçóç ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí åßíáé
åëåýèåñç êáôÜ ôéò äéáôÜîåéò ôçò êåßìåíçò íïìïèåóßáò. Ùò
ôçëåðéêïéíùíéáêÝò äñáóôçñéüôçôåò íïïýíôáé :
á) ç åãêáôÜóôáóç, ëåéôïõñãßá, äéá÷åßñéóç êáé åêìåôÜëëåõóç ôùí Ôçëåðéêïéíùíéáêþí Äéêôýùí,
â) ç ðáñï÷Þ ðÜóçò öýóåùò Ôçëåðéêïéíùíéáêþí Yðçñåóéþí,
ã) ç åéóáãùãÞ, åìðïñßá, êáôáóêåõÞ, åãêáôÜóôáóç êáé
óõíôÞñçóç ôçëåðéêïéíùíéáêïý åîïðëéóìïý.
3. Õðü ôçí åðéöýëáîç ôùí äéáôÜîåùí ôçò ðáñ. 5 ôïõ Üñèñïõ áõôïý, ïé êÜôùèé äñáóôçñéüôçôåò åîáéñïýíôáé áðü
ôéò äéáôÜîåéò ôïõ ðáñüíôïò íüìïõ:
á) ç åêðïìðÞ êáé ôï ðåñéå÷üìåíï ñáäéïöùíéêþí êáé ôçëåïðôéêþí ðñïãñáììÜôùí. Óôçí åîáßñåóç áõôÞ äåí ðåñéëáìâÜíåôáé ç ôçëåðéêïéíùíéáêÞ õðïäïìÞ ìåôÜäïóçò ñáäéïöùíéêþí êáé ôçëåïðôéêþí ðñïãñáììÜôùí óôï ìÝôñï ðïõ
÷ñçóéìïðïéåßôáé ãéá ôçëåðéêïéíùíéáêÝò äñáóôçñéüôçôåò,
â) ôá ÉäéùôéêÜ Äßêôõá,
ã) ôá ðÜóçò öýóåùò áõôïôåëÞ áóõñìáôéêÜ äßêôõá ôçò
Õðçñåóßáò ÐïëéôéêÞò Áåñïðïñßáò, ðïõ ëåéôïõñãïýí óå
óõ÷íüôçôåò Þ æþíåò óõ÷íïôÞôùí áðïêëåéóôéêÞò ÷ñÞóçò
ôçò áåñïíáõôéëßáò.
4. Ïé âáóéêÝò áñ÷Ýò ðïõ äéÝðïõí ôçí ïñãÜíùóç êáé ëåéôïõñãßá ôïõ ôïìÝá ôùí ôçëåðéêïéíùíéþí åßíáé ïé åîÞò:
á) ç ðñïóôáóßá ôïõ êáôáíáëùôÞ,
â) ç ðñïóôáóßá ôïõ åëåýèåñïõ êáé õãéïýò áíôáãùíéóìïý,
ã) ç ðñïóôáóßá ôùí ðñïóùðéêþí äåäïìÝíùí êáé ôïõ áðïññÞôïõ ôùí ôçëåðéêïéíùíéþí,
ä) ç ðáñï÷Þ ÊáèïëéêÞò Õðçñåóßáò ãéá üëåò ôéò ðåñéï÷Ýò
êáé üëïõò ôïõò êáôïßêïõò ôçò ÷þñáò, êáôÜ ôïõò ïñéóìïýò
ôïõ ðáñüíôïò,
å) ç áíÜðôõîç ôùí ôçëåðéêïéíùíéþí.
5. Ôï Õðïõñãåßï Ìåôáöïñþí êáé Åðéêïéíùíéþí ÷áñÜæåé
ôéò êáôåõèõíôÞñéåò ãñáììÝò ôçò ðïëéôéêÞò ôùí ôçëåðéêïéíùíéþí êáé ëáìâÜíåé ôéò áðáéôïýìåíåò íïìïèåôéêÝò ðñùôïâïõëßåò óôïí ôïìÝá ôùí ôçëåðéêïéíùíéþí. ×áñÜæåé áðü
êïéíïý ìå ôï Õðïõñãåßï ÅèíéêÞò ¢ìõíáò ôçí ôçëåðéêïéíùíéáêÞ ðïëéôéêÞ ãéá ôçí åèíéêÞ Üìõíá. Ôï Õðïõñãåßï Ìåôáöïñþí êáé Åðéêïéíùíéþí äéá÷åéñßæåôáé ôá èÝìáôá ôùí äïñõöïñéêþí ôñï÷éþí, ðñïâáßíåé óôçí êáôáíïìÞ ôùí ñáäéïóõ÷íïôÞôùí êáé åêäßäåé ôïí Åèíéêü Êáíïíéóìü ÊáôáíïìÞò
Æùíþí Óõ÷íïôÞôùí (Å.Ê.Ê.Æ.Ó.) óå óõíåñãáóßá ìå ôï Õðïõñãåßï ÅèíéêÞò ¢ìõíáò. ÊÜèå èÝìá ðïõ áöïñÜ ôïí
Å.Ê.Ê.Æ.Ó. ó÷åôéêÜ ìå ôçí Ýêäïóç, óýíôáîç, ôÞñçóç, ëåéôïõñãßá áõôïý èá êáèïñéóôåß ìå áðüöáóç ôùí Õðïõñãþí
ÅèíéêÞò ¢ìõíáò êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí. Ç äéáõëïðïßçóç ôùí ñáäéïóõ÷íïôÞôùí åíôüò ôçò æþíçò óõ÷íïôÞôùí ðïõ äéáôßèåôáé ãéá ôçí åêðïìðÞ êáé ìåôÜäïóç
ñáäéïöùíéêþí êáé ôçëåïðôéêþí ðñïãñáììÜôùí ãßíåôáé ìå
êïéíÞ áðüöáóç ôùí Õðïõñãþí Ìåôáöïñþí êáé Åðéêïéíùíéþí êáé Ôýðïõ êáé Ì.Ì.Å., óýìöùíá ìå ôçí åêÜóôïôå éó÷ýïõóá ñáäéïôçëåïðôéêÞ íïìïèåóßá.
6. Ôï ÊñÜôïò, äéá ôùí íïìßìùí ïñãÜíùí ôïõ, êáé ç ÅèíéêÞ ÅðéôñïðÞ Ôçëåðéêïéíùíéþí êáé Ôá÷õäñïìåßùí
(Å.Å.Ô.Ô.) öñïíôßæïõí þóôå ç Üóêçóç ôùí ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí íá ãßíåôáé ìå âÜóç ôéò áñ÷Ýò ôçò áíôéêåéìåíéêüôçôáò, ôçò äéáöÜíåéáò, ôçò ßóçò ìåôá÷åßñéóçò
êáé ôçò áðïöõãÞò äéáêñßóåùí ìåôáîý ôçëåðéêïéíùíéáêþí
åðé÷åéñÞóåùí, êáèþò êáé ãéá ôçí ðëÞñùóç ôùí Ïõóéùäþí
ÁðáéôÞóåùí ôïõ Üñèñïõ 2 ôïõ ðáñüíôïò.
¢ñèñï 2
Ïñéóìïß
Ãéá ôçí åöáñìïãÞ ôïõ íüìïõ áõôïý ïé áêüëïõèïé üñïé Ý÷ïõí ôçí Ýííïéá ðïõ ôïõò áðïäßäåôáé ðáñáêÜôù:
«¢äåéá», ç Üäåéá ìå ôçí ïðïßá ïé åðé÷åéñÞóåéò åðéôñÝðåôáé íá ðáñÝ÷ïõí ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò Þ/êáé íá åãêáèéóôïýí Þ/êáé íá ëåéôïõñãïýí Þ/êáé íá åêìåôáëëåýïíôáé Äßêôõá ðáñï÷Þò Ôçëåðéêïéíùíéáêþí Õðçñåóéþí.
3898
ÅÖÇÌÅÑÉÓ ÔÇÓ ÊÕÂÅÑÍÇÓÅÙÓ (ÔÅÕ×ÏÓ ÐÑÙÔÏ)
«ÁðëÞ Ìåôáðþëçóç Ôçëåðéêïéíùíéáêþí Õðçñåóéþí», ç
áðëÞ ðñïþèçóç ãéá åìðïñéêïýò ëüãïõò êáé ç ìåôáðþëçóç óå ôåëéêïýò ÷ñÞóôåò Ôçëåðéêïéíùíéáêþí Õðçñåóéþí,
ïé ïðïßåò ðáñÝ÷ïíôáé áðü íïìßìùò ëåéôïõñãïýíôåò Ôçëåðéêïéíùíéáêïýò Ïñãáíéóìïýò.
«ÁðïäåóìåõìÝíç Ðñüóâáóç óôïí Ôïðéêü Âñü÷ï», ç
öõóéêÞ êáé ëïãéêÞ óýíäåóç óôïí Ôïðéêü Âñü÷ï åíüò Ôçëåðéêïéíùíéáêïý Ïñãáíéóìïý ðïõ åðéôñÝðåé ôç ìåñéêÞ Þ
ðëÞñç ÷ñÞóç ôïõ äéáèåóßìïõ ìÝóù ôïõ ÷áëêïý öÜóìáôïò áõôïý áðü Üëëï Ôçëåðéêïéíùíéáêü Ïñãáíéóìü.
«ÃåíéêÞ ¢äåéá», êÜèå ¢äåéá ðïõ äåí åßíáé åéäéêÞ.
«Äçìüóéåò ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò», ïé ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò ðïõ äéáôßèåíôáé óôï êïéíü.
«Äçìüóéï Ôçëåðéêïéíùíéáêü Äßêôõï», ôï Ôçëåðéêïéíùíéáêü Äßêôõï ðïõ ÷ñçóéìïðïéåßôáé, åí üëù Þ åí ìÝñåé, ãéá
ôçí ðáñï÷Þ Ôçëåðéêïéíùíéáêþí Õðçñåóéþí óôï êïéíü.
«Äéáóýíäåóç», ç öõóéêÞ êáé ëïãéêÞ óýíäåóç Ôçëåðéêïéíùíéáêþí Äéêôýùí ðïõ ÷ñçóéìïðïéïýíôáé áðü ôïí ßäéï Þ
äéáöïñåôéêü Ôçëåðéêïéíùíéáêü Ïñãáíéóìü ðñïêåéìÝíïõ
íá ðáñÝ÷åôáé óôïõò ×ñÞóôåò åíüò Ôçëåðéêïéíùíéáêïý
Ïñãáíéóìïý ç äõíáôüôçôá íá åðéêïéíùíïýí ìå ×ñÞóôåò
ôïõ éäßïõ Þ Üëëïõ Ôçëåðéêïéíùíéáêïý Ïñãáíéóìïý Þ íá Ý÷ïõí ðñüóâáóç óå õðçñåóßåò ðïõ ðáñÝ÷ïíôáé áðü Üëëï
Ôçëåðéêïéíùíéáêü Ïñãáíéóìü. Ïé õðçñåóßåò ìðïñïýí íá
ðáñÝ÷ïíôáé áðü ôá åíå÷üìåíá ìÝñç Þ áðü ôñßôïõò ðïõ Ý÷ïõí ðñüóâáóç óôï äßêôõï.
«Äßêôõï ÊáëùäéáêÞò Ôçëåüñáóçò», êÜèå åðßãåéá õðïäïìÞ ìå ôçí ïðïßá åßíáé äõíáôÞ ç äéáâßâáóç Þ äéáíïìÞ ñáäéïôçëåïðôéêþí óçìÜôùí óôï êïéíü, õðü ôçí åðéöýëáîç
ôùí åéäéêþí êáíüíùí ðïõ åêÜóôïôå éó÷ýïõí ãéá ôç äéáíïìÞ ïðôéêïáêïõóôéêþí ðñïãñáììÜôùí ðïõ ðñïïñßæïíôáé
ãéá ôï êïéíü, êáèþò êáé ãéá ôï ðåñéå÷üìåíï ôùí ðñïãñáììÜôùí áõôþí.
«ÅèíéêÞ ÑõèìéóôéêÞ Áñ÷Þ», ç ÅèíéêÞ ÅðéôñïðÞ Ôçëåðéêïéíùíéþí êáé Ôá÷õäñïìåßùí (Å.Å.Ô.Ô.).
«ÅéäéêÞ ¢äåéá», ç ¢äåéá ðïõ ðñïâëÝðåôáé áðü ôï Üñèñï
6 ôïõ ðáñüíôïò.
«ÅðéëïãÞ ÖïñÝá», ç äõíáôüôçôá ðïõ ðáñÝ÷åôáé óôïõò
óõíäñïìçôÝò åíüò Ôçëåðéêïéíùíéáêïý Ïñãáíéóìïý íá åðéëÝãïõí, êáôÜ ðåñßðôùóç êáé ìå ôçí ðëçêôñïëüãçóç åéäéêïý ÷áñáêôçñéóôéêïý ðñïèÝìáôïò, äéáöïñåôéêü öïñÝá
ãéá ôç äéåêðåñáßùóç ôçëåöùíéêþí êëÞóåùí.
«Éäéùôéêü Äßêôõï», êÜèå êáëùäéáêü äßêôõï ðïõ Ý÷åé åî ïëïêëÞñïõ åãêáôáóôáèåß êáé ëåéôïõñãåß áðïêëåéóôéêÜ åíôüò ôçò áõôÞò éäéïêôçóßáò Þ óõíéäéïêôçóßáò êáé ìÝóù
ôïõ ïðïßïõ ðáñÝ÷ïíôáé ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò ãéá
éäéùôéêÞ ÷ñÞóç. Ïé õðçñåóßåò áõôÝò äåí äéáôßèåíôáé ãéá åìðïñéêÞ åêìåôÜëëåõóç êáé åîõðçñåôïýí áðïêëåéóôéêÜ ôéò
ßäéåò áíÜãêåò ôùí öõóéêþí Þ íïìéêþí ðñïóþðùí ôá ïðïßá
åãêáèéóôïýí, ëåéôïõñãïýí, äéá÷åéñßæïíôáé êáé ÷ñçóéìïðïéïýí ôï åí ëüãù äßêôõï.
«ÊáèïëéêÞ Õðçñåóßá», ðñïêáèïñéóìÝíï åëÜ÷éóôï óýíïëï Ôçëåðéêïéíùíéáêþí Õðçñåóéþí óõãêåêñéìÝíçò ðïéüôçôáò, ðïõ ðñïóöÝñåôáé óå üëïõò ôïõò ×ñÞóôåò áíåîáñôÞôùò ãåùãñáöéêÞò èÝóçò óå ðñïóéôÞ ôéìÞ, êáôÜ ôéò äéáôÜîåéò ôïõ Üñèñïõ 8 ðáñ. 5 ôïõ ðáñüíôïò.
«ÊéíçôÞ êáé ÐñïóùðéêÞ Åðéêïéíùíßá», ç äõíáôüôçôá ñáäéïåðéêïéíùíßáò ìå êéíçôü ×ñÞóôç ìÝóù ôçò ÷ñçóéìïðïßçóçò óõóôçìÜôùí õðïäïìÞò êéíçôïý äéêôýïõ, áíåîáñôÞôùò óýíäåóÞò ôçò ìå ôï Äçìüóéï Ôåñìáôéêü Äßêôõï, ÷ùñßò ôç ÷ñÞóç äïñõöüñïõ.
«Êïéíü÷ñçóôï ÔçëÝöùíï», ôçëÝöùíï êïéíÞò ÷ñÞóçò,
ìå ôï ïðïßï ðáñÝ÷ïíôáé ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò Ý-
íáíôé áìïéâÞò ðïõ êáôáâÜëëåôáé Üìåóá (ð.÷. ìå ôç ñßøç
êåñìÜôùí, ôç ÷ñÞóç ðéóôùôéêþí Þ ÷ñåùóôéêþí êáñôþí,
ðñïðëçñùìÝíùí ôçëåöùíéêþí êáñôþí ê.ëð.).
«ÌéóèùìÝíåò ÃñáììÝò», ôá ôçëåðéêïéíùíéáêÜ ìÝóá - äéåõêïëýíóåéò ðïõ ðáñÝ÷ïíôáé óôï ðëáßóéï ôçò äçìéïõñãßáò, áíÜðôõîçò êáé åêìåôÜëëåõóçò ôïõ Äçìüóéïõ Ôçëåðéêïéíùíéáêïý Äéêôýïõ, ôá ïðïßá ðáñÝ÷ïõí ÷ùñçôéêüôçôá
äéáöáíïýò ìåôÜäïóçò ìåôáîý ôåñìáôéêþí óçìåßùí ôïõ
äéêôýïõ êáé äåí ðáñÝ÷ïõí äõíáôüôçôá ìåôáãùãÞò êáô åðéëïãÞ (ëåéôïõñãßåò ìåôáãùãÞò ðïõ ìðïñåß íá åëÝã÷åé ï
×ñÞóôçò ùò ìÝñïò ôçò ðáñï÷Þò ÌéóèùìÝíçò ÃñáììÞò).
«Ïñãáíéóìüò ìå ÓçìáíôéêÞ ÈÝóç óôçí ÁãïñÜ», ïé ïñãáíéóìïß ðïõ ðëçñïýí ôéò ðñïûðïèÝóåéò ôïõ Üñèñïõ 8
ðáñ. 7 ôïõ ðáñüíôïò.
«Ïõóéþäåéò ÁðáéôÞóåéò», ïé ëüãïé äçìïóßïõ óõìöÝñïíôïò ìç ïéêïíïìéêïý ÷áñáêôÞñá, âÜóåé ôùí ïðïßùí ç åãêáôÜóôáóç Þ/êáé ç ëåéôïõñãßá ôùí Ôçëåðéêïéíùíéáêþí
Äéêôýùí Þ/êáé ç ðáñï÷Þ Ôçëåðéêïéíùíéáêþí Õðçñåóéþí
ìðïñïýí íá åðéôñáðïýí õðü ðñïûðïèÝóåéò. Ïé ëüãïé áõôïß ìðïñåß íá åßíáé ìüíï:
á) ç áóöÜëåéá ôçò ëåéôïõñãßáò ôïõ äéêôýïõ,
â) ç äéáôÞñçóç ôçò áêåñáéüôçôÜò ôïõ, êáô åîáßñåóç äå,
êáé åöüóïí áðáéôåßôáé, ç äéáëåéôïõñãéêüôçôá ôùí õðçñåóéþí,
ã) ç ðñïóôáóßá äåäïìÝíùí, óõìðåñéëáìâáíïìÝíùí ôùí
äåäïìÝíùí ðñïóùðéêïý ÷áñáêôÞñá, ôïõ áðüññçôïõ ôùí
ðëçñïöïñéþí êáé ôçò ðñïóôáóßáò ôçò éäéùôéêÞò æùÞò,
ä) ç ðñïóôáóßá ôïõ ðåñéâÜëëïíôïò, ðïëåïäïìéêïß êáé
÷ùñïôáîéêïß ëüãïé êáé
å) ç áðïôåëåóìáôéêÞ ÷ñÞóç ôïõ öÜóìáôïò ôùí óõ÷íïôÞôùí êáé ç áðïöõãÞ âëáðôéêÞò ðáñåìâïëÞò ìåôáîý ñáäéïôçëåðéêïéíùíéáêþí óõóôçìÜôùí êáé Üëëùí äéáóôçìéêþí Þ åðßãåéùí ôå÷íéêþí óõóôçìÜôùí.
«Ðáñï÷Þ Áíïéêôïý Äéêôýïõ», ç åëåýèåñç êáé áðïôåëåóìáôéêÞ ðñüóâáóç óôá Äçìüóéá ÔçëåðéêïéíùíéáêÜ Äßêôõá
êáé ôéò Äçìüóéåò ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò, êáôÜ ôéò
äéáôÜîåéò ôçò åêÜóôïôå éó÷ýïõóáò íïìïèåóßáò êáé ç áðïôåëåóìáôéêÞ ÷ñÞóç ôùí åí ëüãù äéêôýùí êáé õðçñåóéþí.
«ÐÜñï÷ïò Ôçëåðéêïéíùíéáêþí Õðçñåóéþí», ç ôçëåðéêïéíùíéáêÞ åðé÷åßñçóç ðïõ ðáñÝ÷åé ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò äéáèÝóéìåò óôï êïéíü.
«ÐåñéáãùãÞ», õðçñåóßá ðïõ ðáñÝ÷åé ôç äõíáôüôçôá óå
óõíäñïìçôÝò íá ÷ñçóéìïðïéïýí äßêôõï Üëëï áðü áõôü
ôïõ ïðïßïõ åßíáé óõíäñïìçôÝò.
«ÐñïåðéëïãÞ ÖïñÝá», ç äõíáôüôçôá ðïõ ðáñÝ÷åôáé
óôïõò óõíäñïìçôÝò åíüò Ôçëåðéêïéíùíéáêïý Ïñãáíéóìïý íá åðéëÝãïõí óå ðÜãéá âÜóç üôé ìßá Þ ðåñéóóüôåñåò
êáôçãïñßåò ôçëåöùíéêþí êëÞóåùí èá äéåêðåñáéþíïíôáé
áðü Üëëï ðñïåðéëåãìÝíï öïñÝá óôç âÜóç åéäéêÞò ðñïò
ôïýôï óõìöùíßáò ìå ôï öïñÝá áõôüí, ÷ùñßò íá áðáéôåßôáé
ãéá ôï óêïðü áõôüí ç ðëçêôñïëüãçóç åéäéêïý ÷áñáêôçñéóôéêïý ðñïèÝìáôïò Þ êùäéêïý.
«Ðñüôõðï», ç ôå÷íéêÞ ðñïäéáãñáöÞ ðïõ Ý÷åé èåóðéóôåß
áðü áíáãíùñéóìÝíï ïñãáíéóìü ôõðïðïßçóçò, ðÝñáí åêåßíùí ðïõ ðñÝðåé õðï÷ñåùôéêÜ äéá íüìïõ íá ôçñïýíôáé.
«Ñáäéïåîïðëéóìüò», ðñïúüí, Þ ó÷åôéêü óôïé÷åßï ôïõ, ôï
ïðïßï äýíáôáé íá áðïêáôáóôÞóåé åðéêïéíùíßá ìÝóù åêðïìðÞò Þ/êáé ëÞøçò ñáäéïêõìÜôùí, ÷ñçóéìïðïéþíôáò öÜóìá ðïõ Ý÷åé ðáñá÷ùñçèåß óå åðßãåéåò Þ/êáé äïñõöïñéêÝò ñáäéïåðéêïéíùíßåò.
«ÓðÜíéïé Ðüñïé», ôï öÜóìá ñáäéïóõ÷íïôÞôùí, ïé èÝóåéò
óôç ãåùóôáôéêÞ ôñï÷éÜ êáé ïé áñéèìïß áðü ôï Åèíéêü Ó÷Ýäéï Áñéèìïäüôçóçò.
«Ôåñìáôéêüò Åîïðëéóìüò», êÜèå åîïðëéóìüò ðïõ ðñïïñßæåôáé íá óõíäåèåß Üìåóá Þ Ýììåóá ìå Ôåñìáôéêü Óçìåßï
ôïõ Äçìüóéïõ Ôçëåðéêïéíùíéáêïý Äéêôýïõ ìå óêïðü ôç
ìåôÜäïóç, åðåîåñãáóßá Þ ôç ëÞøç äåäïìÝíùí.
«Ôåñìáôéêü Óçìåßï», ôï öõóéêü óçìåßï ðñüóâáóçò ôïõ
×ñÞóôç óôï Äçìüóéï Ôçëåðéêïéíùíéáêü Äßêôõï ðïõ áðïôåëåß êáé ôï üñéï ôïõ äéêôýïõ.
«Ôçëåðéêïéíùíéáêü Äßêôõï», óýóôçìá ìåôÜäïóçò êáé,
êáôÜ ðåñßðôùóç, åîïðëéóìïß ìåôáãùãÞò êáé Üëëá ìÝóá
ìåôáöïñÜò óçìÜôùí ìåôáîý êáèïñéóìÝíùí Ôåñìáôéêþí
Óçìåßùí ìå ôç ÷ñÞóç êáëùäßïõ, ñáäéïóõ÷íïôÞôùí, ïðôéêïý Þ Üëëïõ çëåêôñïìáãíçôéêïý ìÝóïõ.
«ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò», ïé õðçñåóßåò ðïõ óõíßóôáíôáé, åí üëù Þ åí ìÝñåé, óôç äñïìïëüãçóç, åðåîåñãáóßá Þ/êáé ìåôÜäïóç óçìÜôùí óå ÔçëåðéêïéíùíéáêÜ Äßêôõá.
«Ôçëåðéêïéíùíéáêüò Ïñãáíéóìüò», ç ôçëåðéêïéíùíéáêÞ
åðé÷åßñçóç ðïõ åãêáèéóôÜ, ëåéôïõñãåß, äéá÷åéñßæåôáé Þ/êáé
åêìåôáëëåýåôáé Äçìüóéá ÔçëåðéêïéíùíéáêÜ Äßêôõá êáé åíäå÷ïìÝíùò ðáñÝ÷åé êáé ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò.
«Ôïðéêüò Âñü÷ïò», ç åíóýñìáôç óýíäåóç áðü ÷áëêü
ìåôáîý ôïõ Ôåñìáôéêïý Óçìåßïõ êáé ôïõ ôïðéêïý êÝíôñïõ
ìåôáãùãÞò ôïõ Ôçëåðéêïéíùíéáêïý Ïñãáíéóìïý.
«Öïñçôüôçôá Áñéèìïý ÊëÞóçò», ç äõíáôüôçôá ôùí ôåëéêþí ×ñçóôþí íá äéáôçñïýí ôïí Þ ôïõò ãåùãñáöéêïýò Þ
ìç áñéèìïýò êëÞóçò ôïõò üôáí áëëÜæïõí öïñÝá ðáñï÷Þò
õðçñåóßáò, ôïðïèåóßá Þ ôýðï õðçñåóßáò.
«ÖùíçôéêÞ Ôçëåöùíßá», ç ìåôÜäïóç ïìéëßáò óå ðñáãìáôéêü ÷ñüíï ìÝóù Äçìüóéùí Ôçëåðéêïéíùíéáêþí Äéêôýùí. Õðçñåóßåò ÖùíçôéêÞò Ôçëåöùíßáò ðáñÝ÷ïíôáé üôáí êÜèå ×ñÞóôçò Ôåñìáôéêïý Åîïðëéóìïý óõíäåäåìÝíïõ óå óôáèåñü Ôåñìáôéêü Óçìåßï ôïõ Äéêôýïõ ìðïñåß íá
åðéêïéíùíåß ìå Üëëï ×ñÞóôç ôåñìáôéêïý åîïðëéóìïý óõíäåäåìÝíïõ óå Üëëï Ôåñìáôéêü Óçìåßï ôïõ ßäéïõ Þ Üëëïõ
Äéêôýïõ.
«×ñÞóôçò», êÜèå öõóéêü Þ íïìéêü ðñüóùðï ðïõ ÷ñçóéìïðïéåß Þ æçôÜ íá ÷ñçóéìïðïéÞóåé Äçìüóéåò ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò.
ÊÅÖÁËÁÉÏ Â´
ÄÉÏÉÊÇÓÇ ÔÏÕ ÔÏÌÅÁ ÔÙÍ ÔÇËÅÐÉÊÏÉÍÙÍÉÙÍ
¢ñèñï 3
Óõãêñüôçóç, áñìïäéüôçôåò, ëåéôïõñãßá êáé äéïßêçóç ôçò
ÅèíéêÞò ÅðéôñïðÞò Ôçëåðéêïéíùíéþí êáé Ôá÷õäñïìåßùí
1. Ï Ýëåã÷ïò êáé ç ñýèìéóç ôïõ ôïìÝá ôùí ôçëåðéêïéíùíéþí êáé ç åðïðôåßá ôçò ôçëåðéêïéíùíéáêÞò áãïñÜò áóêïýíôáé áðü ôçí ÅèíéêÞ ÅðéôñïðÞ Ôçëåðéêïéíùíéþí êáé
Ôá÷õäñïìåßùí (Å.Å.Ô.Ô.), ç ïðïßá áðïôåëåß ôçí ÅèíéêÞ
ÑõèìéóôéêÞ Áñ÷Þ (NRA) óå èÝìáôá ôçëåðéêïéíùíéþí êáé ç
ïðïßá óõóôÜèçêå ìå ôï Í. 2246/1994 (ÖÅÊ 172 Á´).
2. Ç Å.Å.Ô.Ô. åßíáé áíåîÜñôçôç äéïéêçôéêÞ áñ÷Þ ìå Ýäñá
ôçí ÁèÞíá, ðïõ áðïëáìâÜíåé äéïéêçôéêÞò êáé ïéêïíïìéêÞò
áõôïôÝëåéáò. Ç Å.Å.Ô.Ô. ìðïñåß ìå áðüöáóÞ ôçò íá åãêáèéóôÜ êáé ëåéôïõñãåß ãñáöåßá êáé óå Üëëåò ðüëåéò ôçò ÅëëÜäáò. Ïé áðïöÜóåéò ôçò Å.Å.Ô.Ô. êïéíïðïéïýíôáé ìå ìÝñéìíÜ ôçò óôïí Õðïõñãü Ìåôáöïñþí êáé Åðéêïéíùíéþí.
¸êèåóç ðåðñáãìÝíùí ôçò Å.Å.Ô.Ô. õðïâÜëëåôáé êáô Ýôïò
óôïí Õðïõñãü Ìåôáöïñþí êáé Åðéêïéíùíéþí êáé óôïí
Ðñüåäñï ôçò ÂïõëÞò.
3. Ç Å.Å.Ô.Ô. óõãêñïôåßôáé áðü åííÝá (9) ìÝëç, åê ôùí ïðïßùí Ýíáò åßíáé ï Ðñüåäñïò êáé äýï Áíôéðñüåäñïé, ï Ýíáò åê ôùí ïðïßùí åßíáé áñìüäéïò ãéá ôïí ôïìÝá ôùí ôçëå-
3899
ðéêïéíùíéþí êáé ï Üëëïò ãéá ôïí ôïìÝá ðáñï÷Þò ôá÷õäñïìéêþí õðçñåóéþí. Ôá ìÝëç ôçò Å.Å.Ô.Ô. êáôÜ ôçí Üóêçóç
ôùí êáèçêüíôùí ôïõò áðïëáýïõí ðëÞñïõò ðñïóùðéêÞò
êáé ëåéôïõñãéêÞò áíåîáñôçóßáò. Ï Ðñüåäñïò, ïé Áíôéðñüåäñïé êáé ôá õðüëïéðá ìÝëç ôçò Å.Å.Ô.Ô. äéïñßæïíôáé ìå áðüöáóç ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí ìåôÜ áðü ðñïçãïýìåíç åðéëïãÞ ôïõò áðü ôç ÄéÜóêåøç ôùí
ÐñïÝäñùí ôçò ÂïõëÞò ìå ôçí áõîçìÝíç ðëåéïøçößá ôùí
ôåóóÜñùí ðÝìðôùí ôùí ìåëþí ôçò. Ùò ìÝëç ôçò Å.Å.Ô.Ô.
åðéëÝãïíôáé ðñüóùðá åãíùóìÝíïõ êýñïõò, ðïõ áðïëáýïõí åõñåßáò êïéíùíéêÞò áðïäï÷Þò êáé äéáêñßíïíôáé ãéá
ôçí åðéóôçìïíéêÞ ôïõò êáôÜñôéóç êáé ôçí åðáããåëìáôéêÞ
ôïõò éêáíüôçôá óôïí ôå÷íéêü, ïéêïíïìéêü Þ íïìéêü ôïìÝá.
4. Ç èçôåßá ôïõ ÐñïÝäñïõ êáé ôùí ìåëþí ôçò Å.Å.Ô.Ô. åßíáé ðåíôáåôÞò. Äåí åðéôñÝðåôáé ï äéïñéóìüò ôùí ìåëþí
ôçò Å.Å.Ô.Ô. ãéá ðåñéóóüôåñï áðü äýï (2) èçôåßåò.
5. Áíáêáëåßôáé áõôïäéêáßùò ï äéïñéóìüò ìÝëïõò, ôï ïðïßï áðïõóßáóå áäéêáéïëüãçôá áðü ôñåéò äéáäï÷éêÝò óõíåäñéÜóåéò ôçò ÅðéôñïðÞò. Ãéá ôï õðüëïéðï ôçò èçôåßáò
ôïõ áðï÷ùñïýíôïò äéïñßæåôáé íÝï ìÝëïò, óýìöùíá ìå ôéò
äéáôÜîåéò ôïõ ðáñüíôïò Üñèñïõ.
6. Ôá ìÝëç ôçò Å.Å.Ô.Ô. åêðßðôïõí áõôïäéêáßùò óôçí ðåñßðôùóç ðïõ Ý÷åé åêäïèåß åéò âÜñïò ôïõò ôåëåóßäéêç êáôáäéêáóôéêÞ áðüöáóç ãéá áäßêçìá ðïõ óõíåðÜãåôáé êþëõìá äéïñéóìïý Þ Ýêðôùóç äçìïóßïõ õðáëëÞëïõ óýìöùíá ìå ôéò äéáôÜîåéò ôïõ Õðáëëçëéêïý Êþäéêá.
7. Ï Ðñüåäñïò êáé ïé Áíôéðñüåäñïé ôçò Å.Å.Ô.Ô. åßíáé äçìüóéïé ëåéôïõñãïß ðëÞñïõò áðáó÷üëçóçò. ÊáôÜ ôç äéÜñêåéá ôçò èçôåßáò ôïõò áíáóôÝëëåôáé ç Üóêçóç ïðïéïõäÞðïôå Üëëïõ äçìüóéïõ ëåéôïõñãÞìáôïò. Ï Ðñüåäñïò êáé
ïé Áíôéðñüåäñïé ôçò Å.Å.Ô.Ô. äåí åðéôñÝðåôáé íá áóêïýí
êáìßá åðáããåëìáôéêÞ äñáóôçñéüôçôá Þ íá áíáëáìâÜíïõí
Üëëá êáèÞêïíôá, áìåéâüìåíá Þ ìç óôï äçìüóéï Þ éäéùôéêü
ôïìÝá, ìå åîáßñåóç äéäáêôéêÜ êáèÞêïíôá ìåëþí Ä.Å.Ð.
Á.Å.É. õðü êáèåóôþò ìåñéêÞò áðáó÷üëçóçò. ÊáôÜ ôçí åêôÝëåóç ôùí êáèçêüíôùí ôïõò, ôá ìÝëç ôçò Å.Å.Ô.Ô. äåóìåýïíôáé áðü ôï íüìï, Ý÷ïõí äå õðï÷ñÝùóç ôçñÞóåùò
ôùí áñ÷þí ôçò áíôéêåéìåíéêüôçôáò êáé áìåñïëçøßáò. Ï
Ðñüåäñïò, ïé Áíôéðñüåäñïé êáé ôá ìÝëç ôçò Å.Å.Ô.Ô. õðï÷ñåïýíôáé óôçí ôÞñçóç åìðéóôåõôéêüôçôáò åìðïñéêþí
ðëçñïöïñéþí ãéá ôÝóóåñá (4) Ýôç ìåôÜ ôçí åêïýóéá Þ áêïýóéá áðï÷þñçóÞ ôïõò áðü ôçí Å.Å.Ô.Ô..
8. Óôïí Ðñüåäñï, ôïõò ÁíôéðñïÝäñïõò êáé óôá ìÝëç ôçò
Å.Å.Ô.Ô., óôï ðñïóùðéêü ôçò, êáèþò êáé óôï ðñïóùðéêü
ôçò ÃåíéêÞò Ãñáììáôåßáò Åðéêïéíùíéþí ôïõ Õðïõñãåßïõ
Ìåôáöïñþí êáé Åðéêïéíùíéþí áðáãïñåýåôáé ï Üìåóïò Þ
Ýììåóïò ðñïóðïñéóìüò ïðïéïõäÞðïôå ïöÝëïõò áðü ôçëåðéêïéíùíéáêÝò, ôá÷õäñïìéêÝò åðé÷åéñÞóåéò Þ áðü ôñßôïõò ðïõ åðçñåÜæïíôáé Üìåóá áðü ôç äñáóôçñéüôçôÜ
ôïõò. Åéäéêüôåñá, êáôÜ ôç äéÜñêåéá ôçò èçôåßáò ôïõò, ï
Ðñüåäñïò, ïé Áíôéðñüåäñïé êáé ôá õðüëïéðá ìÝëç áðáãïñåýåôáé íá êáôáóôïýí åôáßñïé, ìÝôï÷ïé êáé íá åßíáé ìÝëç
äéïéêçôéêïý óõìâïõëßïõ, äéá÷åéñéóôÝò, õðÜëëçëïé, ôå÷íéêïß óýìâïõëïé Þ ìåëåôçôÝò áôïìéêÞò Þ Üëëçò åðé÷åßñçóçò, ç ïðïßá áíáðôýóóåé äñáóôçñéüôçôá óôïõò ôïìåßò
ôùí ôçëåðéêïéíùíéþí Þ ðáñï÷Þò ôá÷õäñïìéêþí õðçñåóéþí. Åöüóïí ï Ðñüåäñïò, ïé Áíôéðñüåäñïé êáé ôá ìÝëç
ôçò Å.Å.Ô.Ô. êáôÝ÷ïõí åôáéñéêÜ ìåñßäéá Þ ìåôï÷Ýò ôùí
ðñïáíáöåñüìåíùí åðé÷åéñÞóåùí, ôéò ïðïßåò áðÝêôçóáí
åßôå ðñï ôïõ äéïñéóìïý ôïõò ìå ïðïéáäÞðïôå áéôßá åßôå êáôÜ ôç äéÜñêåéá ôçò èçôåßáò ôïõò áðü êëçñïíïìéêÞ äéáäï÷Þ, õðï÷ñåïýíôáé íá áðÝ÷ïõí êáôÜ ôç äéÜñêåéá ôçò èçôåßáò ôïõò áðü ôçí åíÜóêçóç ôùí äéêáéùìÜôùí óõììåôï÷Þò
3900
êáé øÞöïõ óôá üñãáíá äéïßêçóçò, äéá÷åßñéóçò êáé åëÝã÷ïõ ôùí åí ëüãù åðé÷åéñÞóåùí. Ç ßäéá õðï÷ñÝùóç éó÷ýåé
êáé ãéá ôïõò óõæýãïõò êáé ôá ôÝêíá ôïõò.
9. Ïé áðïäï÷Ýò ôïõ ÐñïÝäñïõ êáé ôùí ÁíôéðñïÝäñùí
êáé ç áðïæçìßùóç ôùí õðüëïéðùí ìåëþí ôçò Å.Å.Ô.Ô. êáèïñßæïíôáé ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí Ïéêïíïìéêþí êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí, êáôÜ ðáñÝêêëéóç
ôùí äéáôÜîåùí ðïõ éó÷ýïõí.
10. Ôá ìÝëç ôçò Å.Å.Ô.Ô. õðïâÜëëïõí êáô Ýôïò óôçí Åéóáããåëßá ôïõ Áñåßïõ ÐÜãïõ, ôçí ðñïâëåðüìåíç áðü ôï Í.
2429/1996 (ÖÅÊ 155 Á´), üðùò åêÜóôïôå éó÷ýåé, äÞëùóç
ðåñéïõóéáêÞò êáôÜóôáóçò.
11. Ç Å.Å.Ô.Ô. óõíÝñ÷åôáé óôçí Ýäñá ôçò Þ åíäå÷ïìÝíùò
êáé åêôüò áõôÞò, áí ôïýôï Ý÷åé ïñéóôåß ðñïçãïõìÝíùò, ôáêôéêþò ìåí ôïõëÜ÷éóôïí ìßá öïñÜ ôï ìÞíá êáé åêôÜêôùò üôáí æçôçèåß áðü ôïí Ðñüåäñï áõôÞò Þ áðü ôÝóóåñá (4)
ôïõëÜ÷éóôïí ìÝëç áõôÞò. Ç Å.Å.Ô.Ô. óõíåäñéÜæåé íïìßìùò,
åöüóïí ìåôÝ÷ïõí óôç óõíåäñßáóç ï Ðñüåäñïò Þ ï áñìüäéïò ãéá ôá èÝìáôá ôçò çìåñÞóéáò äéÜôáîçò (ôçëåðéêïéíùíéþí Þ ôá÷õäñïìéêþí õðçñåóéþí) Áíôéðñüåäñïò êáé
ôÝóóåñá (4) ôïõëÜ÷éóôïí ìÝëç, áðïöáóßæåé äå ìå áðüëõôç ðëåéïøçößá ôùí ðáñüíôùí ìåëþí. Óå ðåñßðôùóç éóïøçößáò õðåñéó÷ýåé ç ãíþìç ôïõ ÐñïÝäñïõ Þ, áðïõóéÜæïíôïò, ôïõ ÁíôéðñïÝäñïõ.
12. Ôá ìÝëç ôçò Å.Å.Ô.Ô. êáôÜ ôçí åêôÝëåóç ôùí êáèçêüíôùí ôïõò åíåñãïýí óõëëïãéêÜ. Ìå áðüöáóç ôçò Å.Å.Ô.Ô.
áíáôßèåíôáé óôïí Ðñüåäñï Þ óôá ìÝëç Þ óôá ìÝëç ôïõ
ðñïóùðéêïý ôçò, óõãêåêñéìÝíá êáèÞêïíôá äéïßêçóçò Þ
êáé äéá÷åßñéóçò. Ç Å.Å.Ô.Ô. åêðñïóùðåßôáé Ýíáíôé ôñßôùí
äéêáóôéêþò êáé åîùäßêùò áðü ôïí Ðñüåäñü ôçò êáé üôáí
áõôüò êùëýåôáé áðü ôïí áñìüäéï Áíôéðñüåäñï. Óå ðåñßðôùóç êùëýìáôïò ôïõ ôåëåõôáßïõ, ç Å.Å.Ô.Ô. ïñßæåé ìå áðüöáóÞ ôçò ôï ìÝëïò ðïõ èá ôçí åêðñïóùðåß ãéá óõãêåêñéìÝíç ðñÜîç Þ åíÝñãåéá Þ êáôçãïñßá ðñÜîåùí Þ åíåñãåéþí.
13. Ôá èÝìáôá ôçò çìåñÞóéáò äéÜôáîçò ôá êáèïñßæåé ï
Ðñüåäñïò, ç åéóÞãçóç äå åð áõôþí ãßíåôáé áðü ôïí Ðñüåäñï Þ áðü Üëëï ìÝëïò ðïõ ôï ïñßæåé ï Ðñüåäñïò. Ïé áðïöÜóåéò ôçò Å.Å.Ô.Ô. ðïõ ðñÝðåé íá åßíáé åéäéêþò áéôéïëïãçìÝíåò, êáôá÷ùñïýíôáé óå åðßóçìï éäéáßôåñï âéâëßï
êáé ìðïñïýí íá áíáêïéíþíïíôáé äçìïóßùò, åêôüò áí áöïñïýí ôçí åèíéêÞ Üìõíá êáé ôçí áóöÜëåéá ôçò ÷þñáò. Ç
Å.Å.Ô.Ô. äåí áðïêáëýðôåé ïðïéáäÞðïôå ðëçñïöïñßá ðïõ
êáëýðôåôáé áðü ôï åðáããåëìáôéêü áðüññçôï êáé éäéáßôåñá ôéò ðëçñïöïñßåò ó÷åôéêÜ ìå ôéò åðé÷åéñÞóåéò, ôéò åðé÷åéñçìáôéêÝò ôïõò ó÷Ýóåéò Þ ôá óôïé÷åßá êüóôïõò ôïõò. Ç
õðï÷ñÝùóç áõôÞ ôçò Å.Å.Ô.Ô. äåí èßãåé ôï äéêáßùìÜ ôçò íá
ðñïâáßíåé óå áðïêÜëõøç ðëçñïöïñéþí ðïõ åßíáé áíáãêáßåò ãéá ôçí åêðëÞñùóç ôùí êáèçêüíôùí ôçò. Óôçí ðåñßðôùóç áõôÞ ç áðïêÜëõøç ðñÝðåé íá âáóßæåôáé óôçí áñ÷Þ ôçò áíáëïãéêüôçôáò êáé íá óõíåêôéìÜ ôá íüìéìá óõìöÝñïíôá ôùí åðé÷åéñÞóåùí ãéá ôçí ðñïóôáóßá ôïõ
åðáããåëìáôéêïý áðïññÞôïõ ôïõò. Ç Å.Å.Ô.Ô. äýíáôáé åðßóçò íá äçìïóéåýåé ðëçñïöïñßåò ó÷åôéêÜ ìå ôïõò üñïõò
÷ïñçãçèåéóþí áäåéþí, ïé ïðïßåò äåí Ý÷ïõí åìðéóôåõôéêü
÷áñáêôÞñá. Ôá ôçñïýìåíá êáôÜ ôéò óõíåäñéÜóåéò ðñáêôéêÜ, êáèþò êáé ïé öÜêåëïé ôùí õðïèÝóåùí ðïõ äéåêðåñáéþèçêáí áðü ôçí Å.Å.Ô.Ô. åßíáé ðñïóéôÜ óôïõò Üìåóá åíäéáöåñïìÝíïõò õðü ôïí ðåñéïñéóìü ôïõ ðñïçãïýìåíïõ
åäáößïõ.
14. Ç Å.Å.Ô.Ô. Ý÷åé ôéò áêüëïõèåò áñìïäéüôçôåò :
á. Êáôáñôßæåé êáé ôñïðïðïéåß ôï Åèíéêü Ó÷Ýäéï Áñéèìïäüôçóçò (Å.Ó.Á.) êáé åê÷ùñåß áñéèìïýò Þ ïìÜäåò áñéèìþí
óôïõò Ôçëåðéêïéíùíéáêïýò Ïñãáíéóìïýò êáé óôïõò Ðáñü÷ïõò Ôçëåðéêïéíùíéáêþí Õðçñåóéþí êáé êáèïñßæåé ôá
ôÝëç åê÷þñçóçò êáé ÷ñÞóçò ôùí áñéèìþí. Êáíïíßæåé ôá
ôçò Öïñçôüôçôáò ôùí Áñéèìþí ÊëÞóçò êáé ôçò ÐñïåðéëïãÞò ÖïñÝá. Åðßóçò, ñõèìßæåé ôá èÝìáôá ôïõ äéáäéêôýïõ
êáé åê÷ùñåß ïíüìáôá ÷þñïõ (domain name) ìå êáôÜëçîç
«.gr».
â. Áó÷ïëåßôáé ìå ôá èÝìáôá ôïõ Ôåñìáôéêïý Åîïðëéóìïý
êáôÜ ôéò äéáôÜîåéò ôçò êåßìåíçò íïìïèåóßáò.
ã. ×ïñçãåß, áíáíåþíåé, ôñïðïðïéåß, áíáóôÝëëåé, ðáñáôåßíåé êáé áíáêáëåß ôéò ÅéäéêÝò ¢äåéåò, åãêñßíåé äå ôçí åêìßóèùóç, ðáñá÷þñçóç ÷ñÞóçò, ìåôáâßâáóç Þ óõíåêìåôÜëëåõóç áõôþí.
ä. Äéåíåñãåß ôïõò äéáãùíéóìïýò ãéá ôç ÷ïñÞãçóç Åéäéêþí Áäåéþí Ôçëåðéêïéíùíéáêþí Õðçñåóéþí, êáèïñßæïíôáò ôïõò ó÷åôéêïýò üñïõò.
å. ÄéáâéâÜæåé, åöüóïí ôçò æçôçèåß áðü ôïõò åíäéáöåñüìåíïõò êáôü÷ïõò Åéäéêþí Áäåéþí, óôéò áñìüäéåò õðçñåóßåò ôïõ åõñýôåñïõ äçìüóéïõ ôïìÝá - ôï ôá÷ýôåñï äõíáôüí - ôéò áéôÞóåéò ôùí ôçëåðéêïéíùíéáêþí åðé÷åéñÞóåùí
ãéá ôç ëÞøç ôùí áðáñáßôçôùí (ãéá ôçí Üóêçóç ôçò óõãêåêñéìÝíçò äñáóôçñéüôçôÜò ôïõò) áäåéþí êáé åãêñßóåùí áðü Üëëïõò öïñåßò, ðñïò äéåõêüëõíóç ôçò ìïíïáðåõèõíôéêÞò äéáäéêáóßáò Ýêäïóçò Áäåéþí êáé ðñïâáßíåé óå êÜèå áðáéôïýìåíç ó÷åôéêÞ åíÝñãåéá ãéá äéåõêüëõíóç ôùí
äéáäéêáóéþí êáé ôùí áäåéïäïôÞóåùí.
óô. Ñõèìßæåé ôá èÝìáôá ôùí Ãåíéêþí Áäåéþí êáé åëÝã÷åé
ôçí ôÞñçóç ôùí üñùí ôïõò.
æ. Êáôáñôßæåé ôïí åôÞóéï êáôÜëïãï ôùí Ïñãáíéóìþí ìå
ÓçìáíôéêÞ ÈÝóç óôçí ÁãïñÜ êáé êáèïñßæåé ôéò åéäéêüôåñåò
õðï÷ñåþóåéò ôùí ïñãáíéóìþí áõôþí, óýìöùíá ìå ôï åèíéêü êáé êïéíïôéêü äßêáéï.
ç. Ïñßæåé ìå áðüöáóÞ ôçò ôéò ðñïûðïèÝóåéò Ðáñï÷Þò Áíïéêôïý Äéêôýïõ êáé ôïõò ðåñéïñéóìïýò ðñüóâáóçò óôá
Äçìüóéá ÔçëåðéêïéíùíéáêÜ Äßêôõá ëüãù Ïõóéùäþí ÁðáéôÞóåùí.
è. Ïñßæåé ìå áðüöáóÞ ôçò, ôï áñãüôåñï åíôüò ôñéþí (3)
ìçíþí áðü ôç èÝóç óå éó÷ý ôïõ ðáñüíôïò íüìïõ, ôéò áñ÷Ýò êïóôïëüãçóçò ãéá ôçí ðñüóâáóç êáé ÷ñÞóç ôïõ Ôïðéêïý Âñü÷ïõ, ãéá ôéò ÌéóèùìÝíåò ÃñáììÝò êáé ãéá ôç Äéáóýíäåóç.
é. Êáôáñôßæåé ôïí êáôÜëïãï ôùí ïñãáíéóìþí ðïõ õðï÷ñåïýíôáé íá ðáñÝ÷ïõí ÌéóèùìÝíåò ÃñáììÝò, ïñßæåé ôéò
êáôçãïñßåò ÌéóèùìÝíùí Ãñáììþí, êáôÜ ôéò äéáôÜîåéò ôçò
êåßìåíçò íïìïèåóßáò êáé áóêåß ôçí åðïðôåßá ó÷åôéêÜ ìå
ôéò ÌéóèùìÝíåò ÃñáììÝò.
éá. Áóêåß êÜèå áñìïäéüôçôá óå ó÷Ýóç ìå ôçí åöáñìïãÞ
ôçò ÊáèïëéêÞò Õðçñåóßáò, óõìðåñéëáìâáíïìÝíïõ êáé
ôïõ êáèïñéóìïý ôïõ ìç÷áíéóìïý ÷ñçìáôïäüôçóÞò ôçò.
éâ. Åêäßäåé êáíïíéóìïýò ãéá ôéò áñ÷Ýò ôéìïëüãçóçò ðïõ
ïöåßëïõí íá áêïëïõèïýí ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß êáé äçìïóéåýåé åêèÝóåéò ãéá ôçí åîÝëéîç ôùí ôéìïëïãßùí ôùí Ôçëåðéêïéíùíéáêþí Ïñãáíéóìþí êáé, êáôÜ ôï ìÝôñï ðïõ áõôü åðéôñÝðåôáé áðü ôçí êåßìåíç íïìïèåóßá, åëÝã÷åé ôá óõóôÞìáôá êïóôïëüãçóçò ôùí Ôçëåðéêïéíùíéáêþí Ïñãáíéóìþí.
éã. Åêäßäåé ôïõò Êþäéêåò Äåïíôïëïãßáò ðïõ äéÝðïõí ôçí
Üóêçóç ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí.
éä. ÌåñéìíÜ ãéá ôçí ôÞñçóç ôçò íïìïèåóßáò ðåñß ôçëåðéêïéíùíéþí, ðåñéëáìâáíïìÝíùí êáé èåìÜôùí áíôáãùíéóìïý ðïõ áíáêýðôïõí êáôÜ ôçí Üóêçóç ôùí äñáóôçñéïôÞôùí ôùí ôçëåðéêïéíùíéáêþí åðé÷åéñÞóåùí. Óôçí ôåëåõôáßá ðåñßðôùóç ç Å.Å.Ô.Ô. ìðïñåß íá æçôÜ ôç óõíäñïìÞ
ôçò ÅðéôñïðÞò Áíôáãùíéóìïý Þ íá ðáñáðÝìðåé óå áõôÞí
ôï èÝìá.
éå. Ãíùìïäïôåß ãéá ôç ëÞøç íïìïèåôéêþí ìÝôñùí ìå óêïðü ôçí áðñüóêïðôç êáé áðïäïôéêÞ áíÜðôõîç ôïõ ôïìÝá
ôùí ôçëåðéêïéíùíéþí.
éóô. Ðñïâáßíåé óôçí áðïíïìÞ êáé åê÷þñçóç ìåìïíùìÝíùí ñáäéïóõ÷íïôÞôùí Þ æùíþí ñáäéïóõ÷íïôÞôùí, ìå ôçí
åðéöýëáîç ôùí èåìÜôùí ôçò ôçëåðéêïéíùíéáêÞò ðïëéôéêÞò
ðïõ áöïñïýí ôçí åèíéêÞ Üìõíá, ãéá ôá ïðïßá áñìüäéá åßíáé áðü êïéíïý ôï Õðïõñãåßï Ìåôáöïñþí êáé Åðéêïéíùíéþí êáé ôï Õðïõñãåßï ÅèíéêÞò ¢ìõíáò.
éæ. Äéá÷åéñßæåôáé ôï öÜóìá ôùí ñáäéïóõ÷íïôÞôùí.
éç. Åêäßäåé ôïí Åèíéêü Êáíïíéóìü Ñáäéïåðéêïéíùíéþí êáé
ôçñåß ìçôñþï åê÷ùñïõìÝíùí ñáäéïóõ÷íïôÞôùí (Åèíéêü
Ìçôñþï Ñáäéïóõ÷íïôÞôùí).
éè. Åðïðôåýåé êáé åëÝã÷åé ôç ÷ñÞóç ôïõ öÜóìáôïò ñáäéïóõ÷íïôÞôùí êáé åðéâÜëëåé ôéò ó÷åôéêÝò êõñþóåéò, ìå
ôçí åðéöýëáîç ôùí äéáôÜîåùí ôçò éó÷ýïõóáò ñáäéïôçëåïðôéêÞò íïìïèåóßáò ðïõ ðñïâëÝðïõí ôçí åðéâïëÞ äéïéêçôéêþí êõñþóåùí ãéá êÜèå åßäïõò ðáñåìâïëÝò êáôÜ ôçí
åêðïìðÞ ñáäéïöùíéêþí êáé ôçëåïðôéêþí ðñïãñáììÜôùí.
ê. ×ïñçãåß ôéò Üäåéåò êáôáóêåõÞò êåñáéþí óôáèìþí
óôçí îçñÜ, áóêþíôáò üëåò ôéò áñìïäéüôçôåò ðïõ áíáöÝñïíôáé óôï Üñèñï 1 ôïõ Í. 2801/2000, ðëçí áõôþí ðïõ áöïñïýí ôá ðÜñêá êåñáéþí êáé áõôþí ôçò ðåñßðôùóçò ÉÁ´
ôçò ðáñ. 2 ôïõ Üñèñïõ 1 ôïõ Í. 2801/2000.
êá. ÅëÝã÷åé ôçí ôÞñçóç åê ìÝñïõò ôùí ôçëåðéêïéíùíéáêþí åðé÷åéñÞóåùí ôùí äéáôÜîåùí ôçò êåßìåíçò íïìïèåóßáò êáé ôùí üñùí ôùí áäåéþí.
êâ. ÅëÝã÷åé ôéò óõìâÜóåéò ðáñï÷Þò õðçñåóéþí ÖùíçôéêÞò Ôçëåöùíßáò êáé ÊéíçôÞò Åðéêïéíùíßáò ðïõ õðïâÜëëïõí åíþðéüí ôçò ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß êáé ïé
ÐÜñï÷ïé Ôçëåðéêïéíùíéáêþí Õðçñåóéþí. ÅëÝã÷åé êáé äéáóöáëßæåé ôçí ðñïóôáóßá ôùí äéêáéùìÜôùí ôùí ×ñçóôþí.
êã. ÅëÝã÷åé ôéò óõìâÜóåéò Äéáóýíäåóçò ìåôáîý Ôçëåðéêïéíùíéáêþí Ïñãáíéóìþí.
êä. ÄéáâéâÜæåé (óôï ðëáßóéï ôùí áñìïäéïôÞôùí ôçò) óôçí
ÅðéôñïðÞ Åõñùðáúêþí ÊïéíïôÞôùí êÜèå ðëçñïöïñßá
ðïõ áðáéôåßôáé, óýìöùíá ìå ôçí êïéíïôéêÞ íïìïèåóßá ðåñß ôçëåðéêïéíùíéþí, Þ êÜèå Üëëç ðëçñïöïñßá ðïõ ç
Å.Å.Ô.Ô. Þ ç ÅðéôñïðÞ Åõñùðáúêþí ÊïéíïôÞôùí èåùñåß
÷ñÞóéìç ãéá ôç äéáðßóôùóç ôçò ôÞñçóçò ôçò êïéíïôéêÞò
íïìïèåóßáò ðåñß ôçëåðéêïéíùíéþí åíôüò ôçò ÅëëçíéêÞò ÅðéêñÜôåéáò.
êå. ÓõíåñãÜæåôáé ìå äéåèíåßò öïñåßò êáé åêðñïóùðåß
ôçí ÅëëÜäá óå äéåèíåßò ïñãáíéóìïýò êáé óõíáíôÞóåéò ãéá
èÝìáôá ôçò áñìïäéüôçôÜò ôçò, åêôüò åÜí Üëëùò ïñßæåôáé
áðü äéåèíåßò óõìâÜóåéò.
êóô. Ðñïâáßíåé óôç äéáðßóôåõóç ôùí öïñÝùí ðïõ ðáñÝ÷ïõí ðéóôïðïßçóç çëåêôñïíéêÞò õðïãñáöÞò.
êæ. Åêäßäåé ôïí Êáíïíéóìü ëåéôïõñãßáò ôçò, ðïõ ñõèìßæåé
ôá èÝìáôá óýãêëçóçò, áðáñôßáò êáé ëÞøçò áðïöÜóåùí.
êç. Åêäßäåé êáíïíéóôéêÝò Þ áôïìéêÝò ðñÜîåéò, äçìïóéåõüìåíåò óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò, äéá ôùí ïðïßùí ñõèìßæåôáé êÜèå äéáäéêáóßá êáé ëåðôïìÝñåéá óå ó÷Ýóç
ìå ôéò áíùôÝñù áñìïäéüôçôÝò ôçò.
15. Óôá ðëáßóéá ôçò Üóêçóçò ôùí áñìïäéïôÞôùí ôçò, ç
Å.Å.Ô.Ô. ôçñåß áñ÷åßï ðïõ ðåñéÝ÷åé üëá ôá áðáñáßôçôá
óôïé÷åßá ðïõ áðïôõðþíïõí ôçí ôñÝ÷ïõóá åéêüíá ôçò ôçëåðéêïéíùíéáêÞò áãïñÜò óôçí ÅëëÜäá, ôçñåß Ìçôñþï Ôçëåðéêïéíùíéáêþí Åðé÷åéñÞóåùí êáôü÷ùí Áäåéþí, áðåõèýíåé ïäçãßåò êáé óõóôÜóåéò ðñïò ôïõò åíäéáöåñüìåíïõò,
êáëåß ôïõò ðáñáâÜôåò íá ðáýóïõí ôéò ðáñáâÜóåéò, åðé-
3901
âÜëëåé ðñüóôéìá êáé ëïéðÝò äéïéêçôéêÝò êõñþóåéò ðïõ
ðñïâëÝðïíôáé óôçí êåßìåíç íïìïèåóßá, óõìðåñéëáìâáíïìÝíùí ôùí ðïéíþí êáé êõñþóåùí ðïõ ðñïâëÝðïíôáé óôï
Í. 703/1977 êáé ðáñáðÝìðåé ôïõò ðáñáâÜôåò óôéò áñìüäéåò äéêáóôéêÝò áñ÷Ýò.
Ôï ðñïóùðéêü ôçò Å.Å.Ô.Ô., ðëçí ôïõ âïçèçôéêïý ðñïóùðéêïý, Ý÷åé, ðñïò äéáðßóôùóç ôùí ðáñáâÜóåùí ôçò ôçëåðéêïéíùíéáêÞò íïìïèåóßáò êáé ôùí êáíüíùí ôïõ áíôáãùíéóìïý, ôéò åîïõóßåò êáé ôá äéêáéþìáôá ðïõ ðñïâëÝðïíôáé óôï Í. 703/1977 êáé äýíáôáé íá åëÝã÷åé ôá ðÜóçò
öýóåùò âéâëßá, óôïé÷åßá êáé ëïéðÜ Ýããñáöá ôùí ôçëåðéêïéíùíéáêþí åðé÷åéñÞóåùí, íá åíåñãåß Ýñåõíåò óôá ãñáöåßá êáé ëïéðÝò åãêáôáóôÜóåéò ôùí ôåëåõôáßùí, íá ëáìâÜíåé Ýíïñêåò Þ áíùìïôß êáôÜ ôçí êñßóç ôïõ êáôáèÝóåéò,
ìå ôçí åðéöýëáîç ôïõ Üñèñïõ 212 ôïõ Êþäéêá ÐïéíéêÞò
Äéêïíïìßáò. Ïé ó÷åôéêÝò äéáôÜîåéò, áðáãïñåýóåéò, ðïéíÝò
êáé êõñþóåéò ôïõ Í. 703/1977 åöáñìüæïíôáé áíáëüãùò
óå ðåñßðôùóç áñíÞóåùò ðáñï÷Þò óôïé÷åßùí, ðáñåìðüäéóçò Þ äõó÷Ýñáíóçò ôïõ Ýñãïõ ôçò Å.Å.Ô.Ô., åðéöõëáóóïìÝíçò ôçò åöáñìïãÞò ôùí ðñïâëåðüìåíùí áðü ôïí ðáñüíôá íüìï êõñþóåùí.
16. Ç Å.Å.Ô.Ô. ðñïóöÝñåé ôéò õðçñåóßåò ôçò ðñïò åðßëõóç äéáöïñþí ðïõ áíáöýïíôáé ìåôáîý ôçëåðéêïéíùíéáêþí
åðé÷åéñÞóåùí Þ ìåôáîý ôçëåðéêïéíùíéáêþí åðé÷åéñÞóåùí
êáé ôïõ Äçìïóßïõ Þ ×ñçóôþí Þ éäéùôþí êáé Üðôïíôáé ôçò åöáñìïãÞò ôçò íïìïèåóßáò ðåñß ôçëåðéêïéíùíéþí Þ ôùí
êáíüíùí ôïõ áíôáãùíéóìïý. Ãéá ôï óêïðü áõôüí ïñãáíþíåôáé ìüíéìç äéáéôçóßá ôçò Å.Å.Ô.Ô., ìå âÜóç ðñïåäñéêü
äéÜôáãìá ðïõ èá åêäïèåß ýóôåñá áðü ðñüôáóç ôùí Õðïõñãþí Äéêáéïóýíçò êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí.
Óôï ßäéï ðñïåäñéêü äéÜôáãìá èá ïñßæïíôáé ëåðôïìåñþò ïé
äéáöïñÝò ðïõ ìðïñïýí íá õðá÷èïýí óôç äéáéôçóßá ôçò
Å.Å.Ô.Ô. êáé êÜèå áðáñáßôçôç ëåðôïìÝñåéá ãéá ôçí ïñãÜíùóç ôçò äéáéôçóßáò êáôÜ ôïõò ïñéóìïýò ôïõ Üñèñïõ 902
ôïõ Êþäéêá ÐïëéôéêÞò Äéêïíïìßáò.
17. Ç Å.Å.Ô.Ô. ìðïñåß ìå áðüöáóÞ ôçò íá óõãêñïôåß ìüíéìåò êáé Ýêôáêôåò åðéôñïðÝò êáé ïìÜäåò åñãáóßáò ãéá ôçí
åîÝôáóç êáé Ýñåõíá åðß èåìÜôùí åéäéêïý åíäéáöÝñïíôïò
ðïõ ó÷åôßæåôáé ìå ôá èÝìáôá ôùí áñìïäéïôÞôùí ôçò. Óôéò
åðéôñïðÝò êáé ïìÜäåò åñãáóßáò ìðïñïýí íá óõììåôÝ÷ïõí êáé ðñüóùðá ðïõ äåí áðïôåëïýí ìÝëç Þ óôåëÝ÷ç ôçò
Å.Å.Ô.Ô.. Ôï Ýñãï ôùí Ýêôáêôùí åðéôñïðþí Þ ïìÜäùí åñãáóßáò êáôåõèýíåôáé áðü ìÝëç ôçò Å.Å.Ô.Ô.. Ïé åéóçãÞóåéò êáé ïé ãíùìïäïôÞóåéò ôùí åðéôñïðþí êáé ïìÜäùí åñãáóßáò õðïâÜëëïíôáé óôá áñìüäéá üñãáíá ôçò Å.Å.Ô.Ô.
ðïõ áðïöáóßæïõí ãéá ôçí ôõ÷üí äçìüóéá áíáêïßíùóç ôùí
óõìðåñáóìÜôùí.
18. Ç Å.Å.Ô.Ô. ìðïñåß íá óõíÜðôåé óõìâÜóåéò ðáñï÷Þò
õðçñåóéþí, ìåëåôþí êáé ðñïìçèåéþí ãéá èÝìáôá ðïõ Üðôïíôáé ôùí óêïðþí ôçò êáé ôçò ëåéôïõñãßáò ôçò.
Ç óýíáøç êáé ç õëïðïßçóç ôùí óõìâÜóåùí áõôþí äéÝðïíôáé áðïêëåéóôéêÜ áðü ôéò åêÜóôïôå éó÷ýïõóåò äéáôÜîåéò ôïõ Äéêáßïõ ôçò ÅõñùðáúêÞò ¸íùóçò êáé áðü ôïõò
ó÷åôéêïýò Êáíïíéóìïýò ôçò Å.Å.Ô.Ô., ïé ïðïßïé åãêñßíïíôáé êáé ôñïðïðïéïýíôáé ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí Ìåôáöïñþí êáé Åðéêïéíùíéþí êáé Ïéêïíïìéêþí.
ÓõìâÜóåéò, üðùò ïé áíùôÝñù, ïé ïðïßåò Ý÷ïõí Þäç óõíáöèåß áðü ôï Õðïõñãåßï Ìåôáöïñþí êáé Åðéêïéíùíéþí,
ìðïñïýí íá ìåôáöåñèïýí óôçí Å.Å.Ô.Ô. ìå áðüöáóç ôïõ
Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí.
19. ¼ëïé ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß êáé åðé÷åéñÞóåéò ðïõ äñáóôçñéïðïéïýíôáé óôï ÷þñï ôùí Ôçëåðéêïéíùíéþí õðï÷ñåïýíôáé íá ðáñÝ÷ïõí óôçí Å.Å.Ô.Ô. êÜèå
3902
ðëçñïöïñßá ðïõ áðáéôåßôáé ãéá ôçí åöáñìïãÞ ôçò êåßìåíçò íïìïèåóßáò.
¢ñèñï 4
Ôï ðñïóùðéêü ôçò Å.Å.Ô.Ô.
1. Ãéá ôç óôåëÝ÷ùóç ôçò Å.Å.Ô.Ô. óõíéóôþíôáé óõíïëéêÜ
180 èÝóåéò óõìðåñéëáìâáíïìÝíùí ôùí Þäç õðçñåôïýíôùí, áðü ôéò ïðïßåò ïé 80 åßíáé èÝóåéò ôáêôéêïý ðñïóùðéêïý, ïé 99 åßíáé èÝóåéò åéäéêïý åðéóôçìïíéêïý ðñïóùðéêïý
êáé 1 èÝóç Íïìéêïý Óõìâïýëïõ. Ãéá ôçí êÜëõøç ôùí èÝóåùí ôïõ ôáêôéêïý ðñïóùðéêïý ãßíåôáé êáô´ áñ÷Þí ðñüóëçøç áõôïý ìå óýìâáóç åñãáóßáò ïñéóìÝíïõ ÷ñüíïõ
äéÜñêåéáò åíüò Ýôïõò (äüêéìç õðçñåóßá). Ç óýìâáóç áõôÞ ìåôáôñÝðåôáé óå áïñßóôïõ ÷ñüíïõ êáé ôï ðñïóùðéêü
ìïíéìïðïéåßôáé ìåôÜ áðü áðüöáóç ôçò Å.Å.Ô.Ô., ç ïðïßá
ëáìâÜíåé õðüøç ôçí åõäüêéìç åôÞóéá õðçñåóßá ôïõ ðñïóùðéêïý. Ùò ðñïóüíôá ðñüóëçøçò, ãéá ôï åéäéêü åðéóôçìïíéêü ðñïóùðéêü ïñßæïíôáé ôá ðñïâëåðüìåíá óôï Üñèñï 25 ðáñ. 2 ôïõ Í. 1943/1991 ìå åðéóôçìïíéêÞ åîåéäßêåõóç óôï áíôéêåßìåíï êáé ôéò áñìïäéüôçôåò ôçò Å.Å.Ô.Ô..
Ôï Åéäéêü Åðéóôçìïíéêü Ðñïóùðéêü ôçò Å.Å.Ô.Ô. ðñïóëáìâÜíåôáé ìå ôçí áêüëïõèç äéáäéêáóßá, ÷ùñßò íá åöáñìüæåôáé ç ðáñ. 2 ôïõ Üñèñïõ 2 ôçò ÐÕÓ 236/1994, üðùò éó÷ýåé êÜèå öïñÜ:
á. Ç Å.Å.Ô.Ô. ðñïêçñýóóåé ôéò èÝóåéò ôïõ Åéäéêïý Åðéóôçìïíéêïý Ðñïóùðéêïý ìå ôçí áðáéôïýìåíç åîåéäßêåõóç
êáé åìðåéñßá. Ìå ôçí ßäéá ðñïêÞñõîç êáèïñßæïíôáé êáé ôá
êñéôÞñéá åðéëïãÞò áõôïý, êáèþò êáé ç äéáäéêáóßá áóêÞóåùò åíóôÜóåùí.
â. ÅéäéêÞ ÅðéôñïðÞ Åìðåéñïãíùìüíùí ðïõ óõãêñïôåßôáé áðü ôçí Å.Å.Ô.Ô., êáôüðéí óõíÝíôåõîçò ôùí õðïøçößùí åéóçãåßôáé óôçí Å.Å.Ô.Ô. ãéá ôçí åðéëïãÞ ôïõò. Óôç
óýíèåóç ôçò ÅðéôñïðÞò óõììåôÝ÷ïõí õðï÷ñåùôéêÜ Ýíá
ìÝëïò ôïõ Á.Ó.Å.Ð., ùò Ðñüåäñïò, ðïõ ïñßæåôáé áðü ôïí
Ðñüåäñï ôïõ Á.Ó.Å.Ð., êáé Ýíáò ôïõëÜ÷éóôïí êáèçãçôÞò
Á.Å.É. Á´ âáèìßäáò. Ôá ìÝëç ôçò ÅðéôñïðÞò áìåßâïíôáé ãéá
ôï Ýñãï ôïõò.
ã. Ç Å.Å.Ô.Ô. ìå áéôéïëïãçìÝíç áðüöáóÞ ôçò åðéëÝãåé
ôïõò õðïøçößïõò, ïé ïðïßïé äéáèÝôïõí êáôÜ ôçí êñßóç ôçò
åõñýôåñç äõíáôÞ åìðåéñßá êáé ãíþóç ðïõ áðáéôåßôáé ãéá
ôç èÝóç ãéá ôçí ïðïßá ðñïïñßæïíôáé.
ä. Ïé ðßíáêåò ôùí åðéëåãïìÝíùí ìå ôá áðáñáßôçôá óôïé÷åßá áðïóôÝëëïíôáé óôï Á.Ó.Å.Ð. ãéá åðéêýñùóç.
å. Óå ðåñßðôùóç ìç åðéêýñùóçò (ìåñéêÞò Þ ïëéêÞò) ôùí
ðéíÜêùí åíôüò åßêïóé (20) çìåñþí áðü ôçí çìÝñá ðáñáëáâÞò ç Å.Å.Ô.Ô. ðñïâáßíåé óôçí ðñüóëçøç ôùí åðéëåãÝíôùí.
2. Ìå áðüöáóç ôïõ áñìüäéïõ Õðïõñãïý ìåôÜ áðü åéóÞãçóç ôçò Å.Å.Ô.Ô. êáé ýóôåñá áðü áßôçóç ôùí åíäéáöåñïìÝíùí, åßíáé äõíáôü íá áðïóðþíôáé ãéá óõãêåêñéìÝíï êáé
áðü ôçí áíùôÝñù áðüöáóç ðñïóäéïñéæüìåíï ÷ñïíéêü äéÜóôçìá, ôï ïðïßï äåí õðåñâáßíåé ôç äéåôßá, ìå äõíáôüôçôá
áíáíÝùóçò, óôçí Å.Å.Ô.Ô., õðÜëëçëïé áðü Üëëåò õðçñåóßåò, Í.Ð.Ä.Ä. Þ Í.Ð.É.Ä. Þ Ï.Ô.Á. êáé ïñãáíéóìïýò ôïõ äçìüóéïõ ôïìÝá, ðñïò êÜëõøç ôùí Üìåóùí áíáãêþí ôçò
Å.Å.Ô.Ô., êáôÜ ðáñÝêêëéóç ôùí äéáôÜîåùí ðïõ éó÷ýïõí êáé
õðü ôçí ðñïûðüèåóç üôé ï öïñÝáò áðü ôïí ïðïßï ðñïÝñ÷åôáé ï õðÜëëçëïò äåí áóêåß ôçëåðéêïéíùíéáêÝò äñáóôçñéüôçôåò. Ãéá ôçí áðüóðáóç ôùí áíùôÝñù õðáëëÞëùí, áíáãêáßá åßíáé ç åìðåéñßá ôïõò óå áíôéêåßìåíï óõíáöÝò
ðñïò áõôü ôçò áðáó÷üëçóÞò ôïõò óôçí Å.Å.Ô.Ô. Ç áðüóðáóç ôùí áíùôÝñù õðáëëÞëùí äýíáôáé íá äéáêüðôåôáé
ìå áðüöáóç ôïõ áñìüäéïõ Õðïõñãïý ìåôÜ áðü åéóÞãçóç
ôçò Å.Å.Ô.Ô. óå ðåñßðôùóç ðïõ ïé óõãêåêñéìÝíåò áíÜãêåò
ôçò Å.Å.Ô.Ô., ãéá ôéò ïðïßåò Ýãéíå ç áðüóðáóç ôïõ óõãêåêñéìÝíïõ õðáëëÞëïõ, äýíáíôáé íá êáëõöèïýí áðü ôï ðñïóùðéêü ôçò Å.Å.Ô.Ô. Ç éó÷ýò ôçò ðáñïýóáò ðáñáãñÜöïõ
ðáýåé ìåôÜ ðÜñïäï ôåôñáåôßáò áðü ôç äçìïóßåõóç ôïõ ðáñüíôïò íüìïõ óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò.
Ìå áðüöáóç ôïõ áñìüäéïõ Õðïõñãïý êáé óýìöùíç
ãíþìç ôçò Å.Å.Ô.Ô., ìåôÜ áðü áßôçóç ôùí åíäéáöåñïìÝíùí, åßíáé äõíáôüí íá ìåôáôÜóóïíôáé õðÜëëçëïé óôçí
Å.Å.Ô.Ô. áðü Üëëåò õðçñåóßåò, Í.Ð.Ä.Ä. Þ Í.Ð.É.Ä. Þ
Ï.Ô.Á. êáé ïñãáíéóìïýò ôïõ äçìüóéïõ ôïìÝá. ÊáôÜ ðáñÝêêëéóç ôùí êåéìÝíùí äéáôÜîåùí ïé ìåôáôáóóüìåíïé êáëýðôïõí ìÝ÷ñé ôï 1/2 ôùí èÝóåùí ôáêôéêïý ðñïóùðéêïý
ôçò Å.Å.Ô.Ô. ãéá ôçí êÜëõøç áíáãêþí ôçò Å.Å.Ô.Ô.. Ðñïûðüèåóç ãéá ôç ìåôÜôáîç ôùí áíùôÝñù õðáëëÞëùí åßíáé ç
ðñïûðçñåóßá ôïõò óå áíôéêåßìåíï óõíáöÝò ìå áõôü ôçò áðáó÷üëçóÞò ôïõò óôçí Å.Å.Ô.Ô.. Ãéá ôç ìåôÜôáîç ôùí áíùôÝñù, áðáéôåßôáé êáé ãíþìç ôïõ ïéêåßïõ Õðçñåóéáêïý
Óõìâïõëßïõ. ¼óïé åê ôùí ìåôáôáóóïìÝíùí õðáëëÞëùí Ý÷ïõí ðñïûðçñåóßá óõíáöÞ ìå ôï áíôéêåßìåíï ôçò Å.Å.Ô.Ô.
ãéá ôïõëÜ÷éóôïí äÝêá (10) Ýôç ìðïñïýí íá êáôáëáìâÜíïõí èÝóåéò ðñïúóôáìÝíùí ðïõ ðñïâëÝðïíôáé ãéá ôï åéäéêü åðéóôçìïíéêü ðñïóùðéêü ôçò Å.Å.Ô.Ô.
3. Ïé èÝóåéò ôïõ ôáêôéêïý ðñïóùðéêïý êáôáíÝìïíôáé êáôÜ êáôçãïñßåò êáé êëÜäïõò ùò åîÞò:
ÐáíåðéóôçìéáêÞò åêðáßäåõóçò (ÐÅ): ÊëÜäïò ÐÅ Äéïéêçôéêïý Ïéêïíïìéêïý, èÝóåéò ðÝíôå (5).
ÐáíåðéóôçìéáêÞò åêðáßäåõóçò (ÐÅ): ÊëÜäïò ÐÅ Ìç÷áíéêïý, èÝóåéò ïêôþ (8).
ÐáíåðéóôçìéáêÞò åêðáßäåõóçò (ÐÅ): ÊëÜäïò ÐÅ ÐëçñïöïñéêÞò, èÝóåéò ôñåéò (3).
Ôå÷íïëïãéêÞò åêðáßäåõóçò (ÔÅ): ÊëÜäïò ÔÅ Äéïéêçôéêüò Ëïãéóôéêüò, èÝóåéò äþäåêá (12), ÊëÜäïò ÔÅ2 Ôå÷íïëïãéêþí åöáñìïãþí, èÝóåéò ôñéÜíôá (30).
ÄåõôåñïâÜèìéáò åêðáßäåõóçò (ÄÅ): ÊëÜäïò ÄÅ, èÝóåéò
äýï (2).
ÐñùôïâÜèìéáò åêðáßäåõóçò (ÕÅ): ÊëÜäïò ÕÅ Âïçèçôéêïý Ðñïóùðéêïý, èÝóåéò åßêïóé (20).
Ïé èÝóåéò ôïõ åéäéêïý åðéóôçìïíéêïý ðñïóùðéêïý êáôáíÝìïíôáé ùò åîÞò:
ÅîÞíôá (60) èÝóåéò äéðëùìáôïý÷ùí çëåêôñïëüãùí ìç÷áíéêþí Þ çëåêôñïëüãùí ìç÷áíéêþí êáé ìç÷áíéêþí Ç/Õ Þ
çëåêôñïíéêþí ìç÷áíéêþí Þ ôçëåðéêïéíùíéáêþí ìç÷áíéêþí
Þ ìç÷áíéêþí ðëçñïöïñéêÞò Þ ðëçñïöïñéêÞò Þ öõóéêþí.
ÅðôÜ (7) èÝóåéò ðôõ÷éïý÷ùí íïìéêÞò, ïé ïðïßåò äåí åßíáé
áóõìâßâáóôåò ìå ôç äéêçãïñßá.
ÔñéÜíôá äýï (32) èÝóåéò ðôõ÷éïý÷ùí ïéêïíïìéêþí Þ ðïëéôéêþí åðéóôçìþí Þ äéïßêçóçò Þ äçìïóßùí ó÷Ýóåùí.
Ï Íïìéêüò Óýìâïõëïò ðñÝðåé íá åßíáé Äéêçãüñïò ðáñ
Áñåßù ÐÜãù, êÜôï÷ïò ôïõëÜ÷éóôïí ìåôáðôõ÷éáêïý ôßôëïõ
óðïõäþí óå óõíáöÝò ìå ôïõò óêïðïýò ôçò Å.Å.Ô.Ô. áíôéêåßìåíï êáé äåêáåôïýò ôïõëÜ÷éóôïí åìðåéñßáò.
4. ÌÝ÷ñé ôçí Ýêäïóç ôïõ ðñïåäñéêïý äéáôÜãìáôïò ôçò
ðáñ. 9 ôïõ ðáñüíôïò ìå áðüöáóç ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, ìåôÜ áðü ó÷åôéêÞ åéóÞãçóç ôçò
Å.Å.Ô.Ô., åðéôñÝðåôáé ç ìåôáâïëÞ, ìåôïíïìáóßá Þ óõã÷þíåõóç ôùí êëÜäùí ôïõ ðáñüíôïò êáé ç ìåôáâïëÞ êáôÜ
êëÜäï Þ åéäéêüôçôá èÝóåùí ðñïóùðéêïý.
5. Ïé äçìüóéïé õðÜëëçëïé ðïõ ìåôáôÜóóïíôáé óôçí
Å.Å.Ô.Ô. äéáôçñïýí (åöüóïí ôï åðéèõìïýí) ôá äéêáéþìáôá
ðïõ ôïõò ðáñÝ÷ïíôáé áðü ôïí öïñÝá êýñéáò êáé åðéêïõñéêÞò áóöÜëéóçò. Ç ìéóèïäïóßá ôùí áðïóðáóìÝíùí õðáë-
ëÞëùí ãßíåôáé áðü ôïí öïñÝá áðü ôïí ïðïßï ðñïÝñ÷ïíôáé,
åíþ ç Å.Å.Ô.Ô. êáôáâÜëëåé ôõ÷üí ðñüóèåôá åðéäüìáôá Þ
êáé áðïæçìéþóåéò ðïõ áíáëïãïýí óôïõò áðïóðþìåíïõò
ðïõ áðáó÷ïëåß, êáèþò êáé ïðïéáäÞðïôå ðñüóèåôç äáðÜíç óôçí ïðïßá ïé áðïóðþìåíïé ðñïâáßíïõí ãéá ôçí ðáñï÷Þ ôùí õðçñåóéþí ôïõò. ÌåôÜ ôç ìåôÜôáîç ïé óõíïëéêÝò
áðïäï÷Ýò êáôáâÜëëïíôáé áðü ôçí Å.Å.Ô.Ô., ç ïðïßá ðáñáêñáôåß êáé áðïäßäåé óôá áóöáëéóôéêÜ ôáìåßá ôïõ õðáëëÞëïõ ôéò áíáëïãïýóåò êñáôÞóåéò.
6. Óôïõò ìåôáôáóóüìåíïõò óôçí Å.Å.Ô.Ô. õðáëëÞëïõò
÷ïñçãåßôáé åéäéêÞ ìçíéáßá áðïæçìßùóç ðñïóÝëêõóçò êáé
ðáñáìïíÞò, ôçò ïðïßáò ôï ìÝãéóôï ýøïò ðñïóäéïñßæåôáé
ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí Ìåôáöïñþí êáé Åðéêïéíùíéþí êáé Ïéêïíïìéêþí êáé óõãêáôáëÝãåôáé ìåôáîý ôùí
ôáêôéêþí áðïäï÷þí. Ç åéäéêÞ áõôÞ áðïæçìßùóç äýíáôáé
íá áíáðñïóáñìüæåôáé ìÝ÷ñé ôïõ ðïóïóôïý áýîçóçò ôïõ
äåßêôç ôéìþí êáôáíáëùôÞ ôïõ ðñïçãïýìåíïõ Ýôïõò ìå áðüöáóç ôçò Å.Å.Ô.Ô..
7. Ôá õðçñåóéáêÜ êùëýìáôá, áóõìâßâáóôá êáé ïé õðï÷ñåþóåéò ôçò ðáñ. 8 ôïõ Üñèñïõ 3 ôïõ ðáñüíôïò, ðïõ
ðñïâëÝðïíôáé ãéá ôá ìÝëç ôçò Å.Å.Ô.Ô., éó÷ýïõí êáé ãéá ôï
ðñïóùðéêü ôçò. Ôï ðñïóùðéêü ôçò Å.Å.Ô.Ô. õðï÷ñåïýôáé
óôçí ôÞñçóç åìðéóôåõôéêüôçôáò åìðïñéêþí ðëçñïöïñéþí ãéá ôÝóóåñá (4) Ýôç ìåôÜ ôçí åêïýóéá Þ áêïýóéá áðï÷þñçóÞ ôïõ áðü ôçí Å.Å.Ô.Ô..
8. Ïé áðïäï÷Ýò êáé ïé ðñüóèåôåò áðïëáâÝò ôïõ ðñïóùðéêïý ôçò Å.Å.Ô.Ô. (ðåñéëáìâáíïìÝíùí ôùí áðïóðáóìÝíùí) êáèïñßæïíôáé ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí Ïéêïíïìéêþí êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí êáé êáôÜ ðáñÝêêëéóç ôùí êåéìÝíùí äéáôÜîåùí.
9. Ìå ðñïåäñéêü äéÜôáãìá, ðïõ åêäßäåôáé ìå ðñüôáóç
ôùí Õðïõñãþí Åóùôåñéêþí, Äçìüóéáò Äéïßêçóçò êáé ÁðïêÝíôñùóçò êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí, êáèïñßæåôáé ç åóùôåñéêÞ äéÜñèñùóç ôçò Å.Å.Ô.Ô., ïé åðß ìÝñïõò
õðçñåóéáêÝò ìïíÜäåò áõôÞò, ôá ðñïóüíôá êáé ï ôñüðïò
åðéëïãÞò ôùí ðñïúóôáìÝíùí ôïõ ðñïóùðéêïý êáé êÜèå
Üëëç áíáãêáßá ëåðôïìÝñåéá.
ÊÅÖÁËÁÉÏ Ã´
ÁÄÅÉÅÓ
¢ñèñï 5
ÃåíéêÝò ¢äåéåò
1. Õðü ôçí åðéöýëáîç ôùí ðåñéðôþóåùí ãéá ôéò ïðïßåò áðáéôåßôáé ç Ýêäïóç ÅéäéêÞò ¢äåéáò êáôÜ ôéò äéáôÜîåéò ôïõ
Üñèñïõ 6 ôïõ ðáñüíôïò, ç Üóêçóç ïðïéáóäÞðïôå ôçëåðéêïéíùíéáêÞò äñáóôçñéüôçôáò ôåëåß õðü êáèåóôþò ÃåíéêÞò ¢äåéáò. Ãéá ôçí õðáãùãÞ óôï êáèåóôþò ÃåíéêÞò ¢äåéáò äåí áðáéôåßôáé ç Ýêäïóç áðüöáóçò ôçò Å.Å.Ô.Ô..
2. Äåí áðáéôåßôáé ¢äåéá ãéá ôçí Üóêçóç ôùí êÜôùèé äñáóôçñéïôÞôùí:
á. ãéá ôçí åéóáãùãÞ, åìðïñßá, êáôáóêåõÞ, åãêáôÜóôáóç
êáé óõíôÞñçóç ôçëåðéêïéíùíéáêïý Ôåñìáôéêïý Åîïðëéóìïý,
â. ãéá ôçí åãêáôÜóôáóç Þ/êáé ëåéôïõñãßá óôáèìþí ñáäéïåðéêïéíùíéþí ôùí îÝíùí ðñåóâåéþí êáé äéðëùìáôéêþí
áðïóôïëþí Þ/êáé óôáèìþí ñáäéïåðéêïéíùíéþí ðïõ åãêáèßóôáíôáé âÜóåé äéìåñïýò äéáêñáôéêÞò óõìöùíßáò,
ã. ãéá ôçí ÁðëÞ Ìåôáðþëçóç Ôçëåðéêïéíùíéáêþí Õðçñåóéþí, ãéá ôçí ïðïßá áðáéôåßôáé áðëÞ ãíùóôïðïßçóç
óôçí Å.Å.Ô.Ô..
3. Ç ÃåíéêÞ ¢äåéá áðïêôÜôáé ìå ôçí ðáñÝëåõóç äåêáðÝíôå (15) çìåñþí áðü ôçí êáôÜèåóç áðü ôïí åíäéáöåñüìå-
3903
íï óôçí Å.Å.Ô.Ô. ÄÞëùóçò Êáôá÷þñéóçò, ìå ôçí ïðïßá äçëþíåôáé ç Ýíáñîç ôçò Üóêçóçò ìéáò Þ ðåñéóóüôåñùí ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí, ïé ïðïßåò ðñÝðåé íá
ðåñéãñÜöïíôáé ëåðôïìåñþò. Ç ÄÞëùóç Êáôá÷þñéóçò êáôá÷ùñåßôáé óå åéäéêü ìçôñþï ðïõ ôçñåßôáé ãéá ôï óêïðü
áõôüí áðü ôçí Å.Å.Ô.Ô. êáé åðÝ÷åé èÝóç ÃåíéêÞò ¢äåéáò õðü ôéò ðñïûðïèÝóåéò ôïõ ðáñüíôïò Üñèñïõ. Ç Å.Å.Ô.Ô.
äýíáôáé, ìå áéôéïëïãçìÝíç áðüöáóÞ ôçò, ðïõ åêäßäåôáé
ìÝóá óôçí ùò Üíù ðñïèåóìßá ôùí äåêáðÝíôå (15) çìåñþí, íá æçôÞóåé áðü ôéò ôçëåðéêïéíùíéáêÝò åðé÷åéñÞóåéò
íá áíáìåßíïõí ìÝ÷ñé ôÝóóåñéò (4) åâäïìÜäåò áðü ôçí õðïâïëÞ ôçò ÄÞëùóçò Êáôá÷þñéóçò, ðñïêåéìÝíïõ íá êÜíïõí Ýíáñîç Üóêçóçò ôùí ðñïâëåðüìåíùí óôç ÄÞëùóç
Êáôá÷þñéóçò ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí.
4. Óå ðåñßðôùóç Üóêçóçò íÝïõ åßäïõò ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí ãéá ôéò ïðïßåò ðñïêýðôåé áìöéóâÞôçóç ãéá ôçí õðáãùãÞ ôïõò óôï êáèåóôþò Ãåíéêþí Þ Åéäéêþí Áäåéþí, ìå áðüöáóç ôçò Å.Å.Ô.Ô. ðïõ åêäßäåôáé åíôüò
Ýîé (6) åâäïìÜäùí áðü ôçí ðáñáëáâÞ ôçò ó÷åôéêÞò ÄÞëùóçò Êáôá÷þñéóçò, åßôå ôßèåíôáé ðñïóùñéíïß üñïé ðáñï÷Þò êáé åðéôñÝðåôáé óôçí åðé÷åßñçóç íá áñ÷ßóåé íá ðáñÝ÷åé ôçí áéôçèåßóá ôçëåðéêïéíùíéáêÞ äñáóôçñéüôçôá, åßôå
áðïññßðôåôáé ðñïóùñéíÜ ç ÄÞëùóÞ ôçò êáé åíçìåñþíåôáé ç åíäéáöåñüìåíç åðé÷åßñçóç ãéá ôïõò ëüãïõò ôçò áðüññéøçò. Óôç óõíÝ÷åéá, ôï ôá÷ýôåñï äõíáôü êáé ôï áñãüôåñï åíôüò ìçíüò áðü ôçí Ýêäïóç ôçò ðéï ðÜíù áðüöáóçò ìå íÝá áðüöáóç ôçò Å.Å.Ô.Ô. åßôå êáèïñßæïíôáé ïé
ïñéóôéêïß üñïé åßôå áéôéïëïãåßôáé ç åíäå÷üìåíç ïñéóôéêÞ
Üñíçóç óå ôÝôïéá óõíáßíåóç.
5. Óå ðåñßðôùóç ðáñáâßáóçò Þ õðÝñâáóçò ôïõ ðåñéå÷ïìÝíïõ ôçò ÄÞëùóçò Êáôá÷þñéóçò, ç Å.Å.Ô.Ô. ìðïñåß íá
áðáãïñåýóåé ôçí Üóêçóç óõãêåêñéìÝíçò äñáóôçñéüôçôáò Þ/êáé ìå áéôéïëïãçìÝíç áðüöáóÞ ôçò íá åðéâÜëåé ôéò
ðñïâëåðüìåíåò óôï ÊåöÜëáéï Å´ ôïõ ðáñüíôïò äéïéêçôéêÝò êõñþóåéò. Ç Å.Å.Ô.Ô. äýíáôáé íá ôñïðïðïéåß ôï ðåñéå÷üìåíï ôçò ÄÞëùóçò Êáôá÷þñéóçò óå áéôéïëïãçìÝíåò
ðåñéðôþóåéò êáé óýìöùíá ìå ôçí áñ÷Þ ôçò áíáëïãéêüôçôáò, áöïý ðñïçãïõìÝíùò åíçìåñþóåé ó÷åôéêÜ ôïí åíäéáöåñüìåíï êáé ôïí êáëÝóåé íá åêöñÜóåé ôéò áðüøåéò ôïõ åðß ôùí ðñïôåéíüìåíùí ôñïðïðïéÞóåùí.
6. Ç Å.Å.Ô.Ô. åêäßäåé Êáíïíéóìü, ðïõ äçìïóéåýåôáé óôçí
Åöçìåñßäá ôçò ÊõâåñíÞóåùò, åíôüò ìçíüò áðü ôç èÝóç
óå éó÷ý ôïõ ðáñüíôïò íüìïõ, óôïí ïðïßï ñõèìßæïíôáé ïé
ëåðôïìÝñåéåò áðüêôçóçò ôùí Ãåíéêþí Áäåéþí, ïé êáôçãïñßåò ôùí Ãåíéêþí Áäåéþí, ôá åëÜ÷éóôá óôïé÷åßá êáé ðëçñïöïñßåò, êáèþò êáé ïé üñïé ðïõ ðñÝðåé íá ðåñéÝ÷ïíôáé óôç
ÄÞëùóç Êáôá÷þñéóçò, ôá ôÝëç ãéá ôçí Ýêäïóç ôçò ¢äåéáò ðïõ èá ðñÝðåé íá êáëýðôïõí áðïêëåéóôéêÜ ôéò äéïéêçôéêÝò äáðÜíåò ôïõ óõóôÞìáôïò áäåéïäüôçóçò, ç äéáäéêáóßá åðéâïëÞò êõñþóåùí êáé êÜèå Üëëç ëåðôïìÝñåéá ðïõ
áöïñÜ ôéò ÃåíéêÝò ¢äåéåò.
¢ñèñï 6
ÅéäéêÝò ¢äåéåò
1. ÅéäéêÝò ¢äåéåò åêäßäïíôáé áðü ôçí Å.Å.Ô.Ô. ãéá ôéò áêüëïõèåò äñáóôçñéüôçôåò:
á. Ãéá ôçí åãêáôÜóôáóç Ôçëåðéêïéíùíéáêþí Äéêôýùí,
ãéá ôá ïðïßá áðáéôåßôáé ç ðñüóâáóç Þ/êáé äéÝëåõóç óå
Þ/êáé ìÝóù äçìïóßùí ðñáãìÜôùí Þ/êáé êïéíï÷ñÞóôùí ÷þñùí Þ/êáé éäéïêôçóéþí ôñßôùí.
â. Ãéá ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò ãéá ôçí ðáñï÷Þ ôùí
ïðïßùí áðáéôåßôáé ç ÷ñÞóç ÓðÜíéùí Ðüñùí.
3904
2. Ï áñéèìüò ôùí Åéäéêþí Áäåéþí ìðïñåß íá ðåñéïñéóôåß
ìüíï óôï âáèìü ðïõ áðáéôåßôáé ãéá ôç äéáóöÜëéóç ôçò áðïäïôéêÞò ÷ñÞóçò ôùí ñáäéïóõ÷íïôÞôùí Þ ãéá üóï ÷ñïíéêü äéÜóôçìá áðáéôåßôáé ãéá íá åîáóöáëéóôåß ç ðáñï÷Þ åðáñêþí áñéèìþí, ëáìâáíïìÝíçò õðüøç ôçò ìåãéóôïðïßçóçò ôïõ ïöÝëïõò ôùí ×ñçóôþí êáé ôçò äéåõêüëõíóçò ôçò
áíÜðôõîçò ôïõ áíôáãùíéóìïý, ýóôåñá áðü áðüöáóç ôïõ
Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, ðïõ äçìïóéåýåôáé óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò. Ìå ôçí ßäéá áðüöáóç êáèïñßæåôáé ôï åßäïò ôïõ äéáãùíéóìïý. ¼ôáí äéáðéóôùèåß üôé åßíáé äõíáôÞ ç áýîçóç ôïõ áñéèìïý ôùí ó÷åôéêþí Åéäéêþí Áäåéþí, ï Õðïõñãüò Ìåôáöïñþí êáé
Åðéêïéíùíéþí, ìå ôçí ßäéá äéáäéêáóßá, ôñïðïðïéåß áíÜëïãá
ôçí áðüöáóÞ ôïõ ðåñß ðåñéïñéóìïý ôïõ áñéèìïý ôùí Åéäéêþí Áäåéþí êáé ïñßæåé ôï åßäïò ôïõ ôõ÷üí íÝïõ äéáãùíéóìïý. Ìå áðüöáóç ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, êáé ìåôÜ áðü åéóÞãçóç ôçò Å.Å.Ô.Ô., êáèïñßæåôáé äéáäéêáóßá äçìüóéáò äéáâïýëåõóçò ðïõ äéåíåñãåßôáé
áðü ôçí Å.Å.Ô.Ô. êáé ç ïðïßá ðñïçãåßôáé ôçò äéáäéêáóßáò
÷ïñÞãçóçò Åéäéêþí Áäåéþí óå óõíèÞêåò ðåñéïñéóìïý ôïõ
áñéèìïý ôïõò. Ç ôåëåõôáßá áõôÞ áðüöáóç èá äçìïóéåõèåß óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò åíôüò ìçíüò áðü
ôç èÝóç óå éó÷ý ôïõ ðáñüíôïò íüìïõ.
3. Ïé ÅéäéêÝò ¢äåéåò åêäßäïíôáé áðü ôçí Å.Å.Ô.Ô. åíôüò Ýîé (6) åâäïìÜäùí áðü ôçí õðïâïëÞ ó÷åôéêÞò áßôçóçò áðü
ôçí åíäéáöåñüìåíç ôçëåðéêïéíùíéáêÞ åðé÷åßñçóç, åöüóïí ç áßôçóç óõíïäåýåôáé áðü ðëÞñç öÜêåëï êáôÜ ôéò êåßìåíåò äéáôÜîåéò. Ç ðñïèåóìßá áõôÞ åðéìçêýíåôáé óå ôÝóóåñéò (4) ìÞíåò üôáí áðáéôåßôáé ç ÷ñÞóç ôïõ öÜóìáôïò
ñáäéïóõ÷íïôÞôùí. Ìå áðüöáóç ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí êáèïñßæïíôáé ïé óõíÝðåéåò ôçò Üðñáêôçò ðáñÝëåõóçò ôùí ùò Üíù ðñïèåóìéþí. Óå ðåñßðôùóç ðïõ ôçò ÷ïñÞãçóçò ôçò ÅéäéêÞò ¢äåéáò ðñïçãçèåß
äéáäéêáóßá ðñüóêëçóçò õðïâïëÞò ðñïóöïñþí, ç áíùôÝñù ðñïèåóìßá ìðïñåß íá åðéìçêõíèåß óôïõò ïêôþ (8) óõíïëéêÜ ìÞíåò áðü ôç äçìïóßåõóç ôçò ðñüóêëçóçò. Ïé áíùôÝñù ðñïèåóìßåò éó÷ýïõí ìå ôçí åðéöýëáîç ôùí äéáôÜîåùí äéåèíþí óõìöùíéþí Þ êáíïíéóìþí ðïõ
ðñïâëÝðïõí äéåèíÞ óõíôïíéóìü óõ÷íïôÞôùí ãéá åðßãåéá Þ
äïñõöïñéêÜ äßêôõá. Ç áäéêáéïëüãçôç ðáñáâßáóç ôùí ùò
Üíù ðñïèåóìéþí èåìåëéþíåé ðåéèáñ÷éêÝò êáé ðïéíéêÝò åõèýíåò ôùí õðåõèýíùí ãéá ôçí êáèõóôÝñçóç ðñïóþðùí.
4. Ç Å.Å.Ô.Ô. äéêáéïýôáé íá áñíçèåß ôçí Ýêäïóç ÅéäéêÞò
¢äåéáò óôéò áêüëïõèåò ðåñéðôþóåéò:
á. üôáí âÜóåé ôïõ Å.Ê.Ê.Æ.Ó. êáé ôïõ Åèíéêïý Ìçôñþïõ
Ñáäéïóõ÷íïôÞôùí äåí õðÜñ÷åé Üëëç äéáèÝóéìç ñáäéïóõ÷íüôçôá,
â. üôáí ç åíäéáöåñüìåíç ôçëåðéêïéíùíéáêÞ åðé÷åßñçóç
äåí ðáñÝ÷åé ôéò áðáéôïýìåíåò ðëçñïöïñßåò óôçí Å.Å.Ô.Ô.
áðü ôéò ïðïßåò íá áðïäåéêíýåôáé üôé ðëçñïýíôáé ïé üñïé
÷ïñÞãçóçò ôçò ÅéäéêÞò ¢äåéáò,
ã. üôáí õðÜñ÷ïõí âÜóéìåò åíäåßîåéò üôé ç åíäéáöåñüìåíç
ôçëåðéêïéíùíéáêÞ åðé÷åßñçóç äåí äéáèÝôåé, êáôÜ ôïõò ó÷åôéêïýò êáíïíéóìïýò ôçò Å.Å.Ô.Ô. êáé ôçí êåßìåíç íïìïèåóßá,
ôçí áðáéôïýìåíç áîéïðéóôßá êáé öåñåããõüôçôá Þ ôï åëÜ÷éóôï áðáéôïýìåíï êåöÜëáéï Þ ôçí ïéêïíïìéêÞ äõíáôüôçôá ãéá
ôï ýøïò ôçò áðáéôïýìåíçò åðÝíäõóçò Þ ôçí áðáéôïýìåíç
óôåëÝ÷ùóç, åìðåéñßá êáé ôå÷íïãíùóßá ðïõ íá åããõÜôáé ôçí
ïñèÞ åöáñìïãÞ ôùí üñùí ÷ïñÞãçóçò ôçò ÅéäéêÞò ¢äåéáò,
ä. üôáí õðÜñ÷ïõí âÜóéìåò åíäåßîåéò üôé áðü ôç ÷ïñÞãçóç ôçò ÅéäéêÞò ¢äåéáò ôßèåôáé óå êßíäõíï ç äçìüóéá ôÜîç,
áóöÜëåéá êáé õãåßá,
å. üôáí èßãåôáé ç áíÜðôõîç ôïõ õãéïýò áíôáãùíéóìïý.
5. Ç ÅéäéêÞ ¢äåéá äåí ìðïñåß íá åêäßäåôáé ãéá äéÜñêåéá
ìéêñüôåñç áðü äåêáðÝíôå (15) êáé ìåãáëýôåñç áðü åßêïóé
(20) Ýôç êáé ðåñéëáìâÜíåé üñïõò õðü ôïõò ïðïßïõò áóêïýíôáé ïé ôçëåðéêïéíùíéáêÝò äñáóôçñéüôçôåò ãéá ôéò ïðïßåò åêäßäåôáé ç ÅéäéêÞ ¢äåéá. Ç äéÜôáîç áõôÞ äåí èßãåé
ÅéäéêÝò ¢äåéåò ðïõ Ý÷ïõí Þäç ÷ïñçãçèåß ãéá ìéêñüôåñç Þ
ìåãáëýôåñç äéÜñêåéá. Åöüóïí ôçëåðéêïéíùíéáêÞ åðé÷åßñçóç ðïõ áóêåß ôçëåðéêïéíùíéáêÝò äñáóôçñéüôçôåò õðü
êáèåóôþò ÅéäéêÞò ¢äåéáò, äåí ðëçñïß üñï ðïõ ðåñéëáìâÜíåôáé óå áõôÞí Þ ðáñáâáßíåé äéáôÜîåéò ôçò êåßìåíçò íïìïèåóßáò, óõìðåñéëáìâáíïìÝíùí ôùí ðñÜîåùí ôçò
Å.Å.Ô.Ô. êáé ôùí êáíüíùí ôïõ áíôáãùíéóìïý, ç Å.Å.Ô.Ô.
ìðïñåß íá áíáêáëÝóåé, ôñïðïðïéÞóåé Þ áíáóôåßëåé ôçí éó÷ý ôçò ÅéäéêÞò ¢äåéáò ìå áéôéïëïãçìÝíç áðüöáóÞ ôçò
Þ/êáé ìå áéôéïëïãçìÝíç áðüöáóÞ ôçò íá ôçò åðéâÜëëåé ôéò
ðñïâëåðüìåíåò óôïí ðáñüíôá íüìï äéïéêçôéêÝò êõñþóåéò. Ç Å.Å.Ô.Ô. äýíáôáé íá ôñïðïðïéåß ôïõò üñïõò ôçò ÅéäéêÞò ¢äåéáò óå áéôéïëïãçìÝíåò ðåñéðôþóåéò êáé óýìöùíá ìå ôçí áñ÷Þ ôçò áíáëïãéêüôçôáò. Óôéò ùò Üíù ðåñéðôþóåéò, ç Å.Å.Ô.Ô. ïöåßëåé ðñïçãïõìÝíùò íá
åíçìåñþóåé ó÷åôéêÜ ôïí åíäéáöåñüìåíï êáé íá ôïí êáëÝóåé íá åêöñÜóåé ôéò áðüøåéò ôïõ.
6. Ç ÅéäéêÞ ¢äåéá åßíáé áõóôçñÜ ðñïóùðéêÞ. Ç ÅéäéêÞ ¢äåéá ìðïñåß íá ìåôáâéâáóôåß ìüíï ìå Ýãêñéóç ôçò
Å.Å.Ô.Ô., ýóôåñá áðü ôçí õðïâïëÞ ó÷åôéêÞò áßôçóçò áðü
ôçí áäåéïäïôçìÝíç åðé÷åßñçóç êáé åöüóïí, áö åíüò ìåí,
ðáñáó÷åèïýí ôá å÷Ýããõá óôçí Å.Å.Ô.Ô. üôé ïé üñïé ôçò ÅéäéêÞò ¢äåéáò èá ðëçñïýíôáé êáé áðü ôï íÝï äéêáé-ïý÷ï, ï
ïðïßïò ðñÝðåé íá Ý÷åé ôïõëÜ÷éóôïí ôá ßäéá ðñïóüíôá ìå
áõôÜ ðïõ åß÷å ï êÜôï÷ïò ôçò ¢äåéáò êáôÜ ôï ÷ñüíï ÷ïñÞãçóÞò ôçò êáé, áö åôÝñïõ äå, äåí ðáñáâéÜæïíôáé ïé äéáôÜîåéò ãéá ôçí ðñïóôáóßá ôïõ áíôáãùíéóìïý. Óå ðåñßðôùóç ðïõ ç ÅéäéêÞ ¢äåéá ÷ïñçãÞèçêå õðü óõíèÞêåò ðåñéïñéóìïý ôùí Áäåéþí, äåí ìðïñåß íá ìåôáâéâáóôåß ðñéí áðü
ôçí ðáñÝëåõóç åííÝá (9) ìçíþí áðü ôç ÷ïñÞãçóÞ ôçò. Ç
éó÷ýò ôïõ ðñïçãïýìåíïõ åäáößïõ áñ÷ßæåé áðü ôç äçìïóßåõóç ôïõ ðáñüíôïò íüìïõ óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò, êáôáëáìâÜíåé äå êáé åéäéêÝò Üäåéåò ðïõ èá ÷ïñçãçèïýí ìåôÜ áðü äéáãùíéóôéêÝò äéáäéêáóßåò ðïõ åßíáé óå
åîÝëéîç.
Áðáãïñåýåôáé ç ìå ïðïéïíäÞðïôå ôñüðï åêìßóèùóç Þ
óõíåêìåôÜëëåõóç ôçò ÷ïñçãïýìåíçò ÅéäéêÞò ¢äåéáò ìå
ôñßôïõò Þ ç ìåôáâïëÞ ôçò óýíèåóçò ôïõ åôáéñéêïý êåöáëáßïõ ôçò ôçëåðéêïéíùíéáêÞò åðé÷åßñçóçò ðïõ ïäçãåß óå
Üìåóç Þ Ýììåóç áëëáãÞ åëÝã÷ïõ ôçò äéïßêçóÞò ôçò ÷ùñßò
ðñïçãïýìåíç Ýãêñéóç ôçò Å.Å.Ô.Ô.. Ç Ýãêñéóç áõôÞ ðáñÝ÷åôáé õðü ôïõò üñïõò ôçò ðñïçãïýìåíçò ðáñáãñÜöïõ.
ÊÜèå ìåôáâßâáóç ìåôï÷þí ìå ìßá Þ ðåñéóóüôåñåò ðñÜîåéò, ðñïò Þ áðü ôï ßäéï íïìéêü ðñüóùðï, ßóç Þ ìåãáëýôåñç áðü ôï äýï ôïéò åêáôü (2%) ôïõ åôáéñéêïý êåöáëáßïõ
ôçëåðéêïéíùíéáêÞò åðé÷åßñçóçò ðïõ åßíáé êÜôï÷ïò ÅéäéêÞò ¢äåéáò ãíùóôïðïéåßôáé óôçí Å.Å.Ô.Ô. åíôüò äåêáðÝíôå
(15) çìåñþí áðü ôçí ùò Üíù ìåôáâßâáóç. Ìå ðñïåäñéêü
äéÜôáãìá, ðïõ åêäßäåôáé ýóôåñá áðü ðñüôáóç ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, ïñßæïíôáé áíþôáôá ðïóïóôÜ óõììåôï÷Þò ôïõ éäßïõ ðñïóþðïõ óå ðåñéóóüôåñåò ïìïåéäåßò ôçëåðéêïéíùíéáêÝò åðé÷åéñÞóåéò ðïõ
ëåéôïõñãïýí óôçí ßäéá ãåùãñáöéêÞ áãïñÜ.
7. Ç Å.Å.Ô.Ô. åêäßäåé Êáíïíéóìü, ðïõ äçìïóéåýåôáé óôçí
Åöçìåñßäá ôçò ÊõâåñíÞóåùò, åíôüò ìçíüò áðü ôç èÝóç óå
éó÷ý ôïõ ðáñüíôïò íüìïõ, ìå ôïí ïðïßï ñõèìßæïíôáé ç äéáäéêáóßá êáé ïé ðñïûðïèÝóåéò Ýêäïóçò, áíáíÝùóçò, ìåôáâßâáóçò, åêìßóèùóçò, óõíåêìåôÜëëåõóçò, ôñïðïðïßçóçò,
ÖÅÊ 273
áíáóôïëÞò, ðáñÜôáóçò êáé áíÜêëçóçò ôùí Åéäéêþí Áäåéþí, ïé üñïé ðïõ ðñÝðåé íá ðåñéÝ÷ïíôáé óå áõôÝò, ôï ðåñéå÷üìåíï ôçò áßôçóçò Ýêäïóçò ôçò ÅéäéêÞò ¢äåéáò, ôá ôçò åêäüóåùò ðñïóùñéíþí áäåéþí ãéá äïêéìÝò, ôá ôÝëç ãéá ôçí
êÜëõøç áðïêëåéóôéêÜ ôùí äéïéêçôéêþí äáðáíþí ôïõ óõóôÞìáôïò áäåéïäüôçóçò, ôá ôÝëç ãéá ôç ÷ñÞóç ÓðÜíéùí
Ðüñùí, ç äéáäéêáóßá åðéâïëÞò êõñþóåùí êáé êÜèå Üëëç ëåðôïìÝñåéá ðïõ áöïñÜ ôçí Ýêäïóç ôùí Åéäéêþí Áäåéþí êáé
ôéò õðï÷ñåþóåéò ôùí ìåôü÷ùí êáé åôáßñùí ôçëåðéêïéíùíéáêþí åðé÷åéñÞóåùí ðïõ åßíáé êÜôï÷ïé EéäéêÞò ¢äåéáò.
8. ÐáñÜôáóç ÅéäéêÞò ¢äåéáò íïåßôáé ìüíï óå ó÷Ýóç ìå
¢äåéåò ãéá ôéò ïðïßåò äåí õðÜñ÷åé ðåñéïñéóìüò ôïõ áñéèìïý ôïõò. Óå êÜèå ðåñßðôùóç, ç äõíáôüôçôá ðáñÜôáóçò
ìðïñåß íá óõíåðÜãåôáé êáé ôñïðïðïßçóÞ ôçò, óýìöùíá
ìå ôçí êåßìåíç íïìïèåóßá, êáé ðñïûðïèÝôåé üôé äåí óõíåðÜãåôáé ðåñéïñéóìü ôïõ áíôáãùíéóìïý.
9. ÅéäéêÝò ¢äåéåò ðïõ åßíáé óå éó÷ý êáé ôùí ïðïßùí üñïé
áíôßêåéíôáé óôéò äéáôÜîåéò ôçò êåßìåíçò íïìïèåóßáò, ôñïðïðïéïýíôáé ìå áðüöáóç ôçò Å.Å.Ô.Ô., ðïõ äçìïóéåýåôáé
óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò, áíåîáñôÞôùò ôïõ åßäïõò ôçò áñ÷éêÞò ðñÜîçò ÷ïñÞãçóçò ôçò áñ÷éêÞò ¢äåéáò.
10. ÓðÜíéïé Ðüñïé ðïõ äåí ÷ñçóéìïðïéïýíôáé åíôüò äýï
(2) åôþí áðü ôçí çìåñïìçíßá ðïõ ðñüâëåðåôáé áðü ôç
ó÷åôéêÞ ÅéäéêÞ ¢äåéá, ìðïñïýí íá åê÷ùñçèïýí åê íÝïõ áðü ôçí Å.Å.Ô.Ô. óýìöùíá ìå ôçí êåßìåíç íïìïèåóßá.
¢ñèñï 7
Áñéèìïäüôçóç êáé ñáäéïóõ÷íüôçôåò ñáäéïåðéêïéíùíéþí
1. Ôï Åèíéêü Ó÷Ýäéï Áñéèìïäüôçóçò (Å.Ó.Á.) ñõèìßæåé ôá
èÝìáôá ôçò äïìÞò êáé óýíèåóçò ôùí áñéèìþí êáé ïíïìÜôùí ÷þñïõ (domain names) ðïõ ÷ñçóéìïðïéïýíôáé ãéá ôçëåðéêïéíùíéáêÝò äñáóôçñéüôçôåò, ôá ôùí êùäéêþí ðñüóâáóçò, óýíôïìùí êùäéêþí ãéá õðçñåóßåò ðñïò ôï êïéíü,
ôïí ôñüðï áëëáãÞò ôïõ Å.Ó.Á. êáé êÜèå Üëëï ó÷åôéêü æÞôçìá. Ç Å.Å.Ô.Ô. åêäßäåé ôï Å.Ó.Á., ðïõ äçìïóéåýåôáé óôçí
Åöçìåñßäá ôçò ÊõâåñíÞóåùò, åíôüò ìçíüò áðü ôç èÝóç
óå éó÷ý ôïõ ðáñüíôïò íüìïõ êáé ôï ïðïßï ðñÝðåé:
á. Íá äéáóöáëßæåé ôçí éêáíïðïßçóç ôçò ìáêñïðñüèåóìçò æÞôçóçò áñéèìþí ãéá ôéò ôçëåðéêïéíùíéáêÝò õðçñåóßåò, óýìöùíá ìå ôéò áíÜãêåò ôçò áãïñÜò êáé ôùí äéáöïñåôéêþí êáôçãïñéþí ×ñçóôþí.
â. Íá ðñïÜãåé ôçí ðëÝïí áðïôåëåóìáôéêÞ ÷ñÞóç ôùí áñéèìïäïôéêþí ðüñùí ëáìâÜíïíôáò õðüøç åãêáßñùò ôéò
áðáéôÞóåéò ðïõ Ý÷ïõí ïé ÷ñÞóôåò ó÷åôéêÜ ìå ôéò õðçñåóßåò, óå óõíÜñôçóç ìå ôç äéáóöÜëéóç óõíèçêþí áðïôåëåóìáôéêïý áíôáãùíéóìïý.
ã. Íá ðñïâëÝðåé ôç äõíáôüôçôá äéÜèåóçò áñéèìþí ãéá
íÝåò ôçëåðéêïéíùíéáêÝò õðçñåóßåò, ôç äõíáôüôçôá ÅðéëïãÞò ÖïñÝá êáé, ôï áñãüôåñï Ýùò 1.1.2003, ôçí åéóáãùãÞ
ôçò äéåõêüëõíóçò Öïñçôüôçôáò ôùí Áñéèìþí êáé ÐñïåðéëïãÞò ÖïñÝá.
ä. Íá ðåñéëáìâÜíåé ñõèìßóåéò ãéá ôá ïíüìáôá ÷þñïõ
(domain names) óôï äéáäßêôõï, ìå ôçí êáôÜëçîç «.gr».
2. Ç Å.Å.Ô.Ô. öñïíôßæåé ãéá ôçí ïñèÞ êáé áðïôåëåóìáôéêÞ
÷ñÞóç ôùí åê÷ùñïýìåíùí ðñïèåìÜôùí êáé áñéèìþí êáé
åê÷ùñåß áñéèìïýò Þ ïìÜäåò áñéèìþí óôéò åíäéáöåñüìåíåò ôçëåðéêïéíùíéáêÝò åðé÷åéñÞóåéò, ýóôåñá áðü ó÷åôéêÞ
áßôçóÞ ôïõò, óýìöùíá ìå ôéò ðñïûðïèÝóåéò ðïõ ðåñéëáìâÜíïíôáé óôéò ¢äåéåò.
3. Ç äéá÷åßñéóç ôïõ öÜóìáôïò ñáäéïóõ÷íïôÞôùí êáé ï Ýëåã÷ïò ôùí ñáäéïåêðïìðþí ðñáãìáôïðïéåßôáé óýìöùíá
ìå ôéò åèíéêÝò áíÜãêåò, ôéò Ïäçãßåò ôçò ÅõñùðáúêÞò ¸-
3905
íùóçò, ôéò äéåèíåßò óõìöùíßåò êáé ôéò äéáôÜîåéò ôïõ Êáôáóôáôéêïý ×Üñôç, ôçò Óýìâáóçò êáé ôïõ Êáíïíéóìïý Ñáäéïåðéêïéíùíéþí ôçò Äéåèíïýò ¸íùóçò Ôçëåðéêïéíùíéþí,
ëáìâáíïìÝíùí õðüøç êáé ôùí áðïöÜóåùí ôçò ÅõñùðáúêÞò ÅðéôñïðÞò Ñáäéïåðéêïéíùíéþí (ERC) ôçò ÅõñùðáúêÞò ÓõíäéÜóêåøçò Ôá÷õäñïìåßùí êáé Ôçëåðéêïéíùíéþí
(CEPT).
4. Ìå êïéíÝò áðïöÜóåéò ôïõ Õðïõñãïý Ìåôáöïñþí êáé
Åðéêïéíùíéþí êáé ôùí êáôÜ ðåñßðôùóç óõíáñìüäéùí Õðïõñãþí êáèïñßæïíôáé ôá ìÝôñá ðïõ ëáìâÜíïíôáé ãéá ôçí
ðñïóôáóßá ôùí äçìüóéùí ôçëåðéêïéíùíéáêþí äéêôýùí,
ôùí åéäéêþí åãêáôáóôÜóåùí, ôçò äçìüóéáò õãåßáò, ôïõ
ðåñéâÜëëïíôïò êáé ôçò äçìüóéáò áóöÜëåéáò áðü ôçí Ýëëåéøç çëåêôñïìáãíçôéêÞò óõìâáôüôçôáò êáé áðü ôç ëåéôïõñãßá åîïðëéóìïý êáé åãêáôáóôÜóåùí ñáäéïåðéêïéíùíéþí êáé çëåêôñéêþí êáé çëåêôñïíéêþí óõóêåõþí.
5. Ìå Êáíïíéóìü Þ ÐñÜîåéò ðïõ èá åêäïèïýí áðü ôçí
Å.Å.Ô.Ô. ñõèìßæåôáé ç äéáäéêáóßá, ïé üñïé, ïé ðñïûðïèÝóåéò êáé êÜèå èÝìá ó÷åôéêü ðñïò ôçí åê÷þñçóç ìåìïíùìÝíùí ñáäéïóõ÷íïôÞôùí Þ æùíþí ñáäéïóõ÷íïôÞôùí ãéá
ñáäéïåðéêïéíùíßá, ìåôÜäïóç Þ åêðïìðÞ åíÝñãåéáò, ðñïò
ôéò ôå÷íéêÝò ðñïäéáãñáöÝò ôùí åãêáôáóôÜóåùí, ðñïò
ôçí êáôï÷Þ êáé ÷ñÞóç ñáäéïåîïðëéóìïý, ðñïò ôçí ðñïóôáóßá ôùí ñáäéïåðéêïéíùíéþí áðü ðáñåìâïëÝò, ðñïò ôç
äéáäéêáóßá êáé ôá êñéôÞñéá Ýêäïóçò, ôñïðïðïßçóçò, áíáóôïëÞò êáé áíÜêëçóçò ôçò Üäåéáò ëåéôïõñãßáò ðåéñáìáôéêþí óôáèìþí ñáäéïåðéêïéíùíéþí, ðñïò ôá ôÝëç áäåéïäüôçóçò êáé ëåéôïõñãßáò ôùí ñáäéïóôáèìþí êáé ñáäéïäéêôýùí.
6. Óå ðåñßðôùóç ñáäéïóõ÷íïôÞôùí ç ÷ñÞóç ôùí ïðïßùí
äåí áðïôåëåß áíôéêåßìåíï ôïõ ðáñüíôïò íüìïõ, ôá áñìüäéá ãéá ôç ÷ñÞóç ôùí óõãêåêñéìÝíùí óõ÷íïôÞôùí êñáôéêÜ
üñãáíá, óõìðåñéëáìâáíïìÝíùí ôõ÷üí áíåîÜñôçôùí äéïéêçôéêþí áñ÷þí, èá ðáñÝ÷ïõí óôçí Å.Å.Ô.Ô. êÜèå ðëçñïöïñßá ç ïðïßá åßíáé áíáãêáßá ãéá ôçí Üóêçóç ôùí áñìïäéïôÞôùí ôéò ïðïßåò ç Å.Å.Ô.Ô. Ý÷åé óýìöùíá ìå ôïí ðáñüíôá íüìï êáé üðïõ åßíáé äõíáôüí èá óõíäñÜìïõí ôï Ýñãï
ôçò Å.Å.Ô.Ô. óôï ðñïóÞêïí ìÝôñï.
7. Óôçí Ýêôáóç ðïõ áõôü åßíáé åýëïãï êáé áíáãêáßï ãéá
ôçí åîõðçñÝôçóç ôùí áñ÷þí ôïõ Üñèñïõ 1 ôïõ ðáñüíôïò,
ç Å.Å.Ô.Ô. äýíáôáé íá ðñïâáßíåé óå áíáäáóìü ôùí óõ÷íïôÞôùí ïé ïðïßåò Ý÷ïõí åê÷ùñçèåß. Ãéá ôï óêïðü áõôüí ç
Å.Å.Ô.Ô. ìðïñåß íá ôñïðïðïéåß ôéò ó÷åôéêÝò ¢äåéåò ðáñÝ÷ïíôáò Üëëåò óõ÷íüôçôåò óôï öÜóìá êáé áðïæçìéþíïíôáò ôïí êÜôï÷ï ôçò ¢äåéáò ãéá ôõ÷üí æçìßá ðïõ èá õðïóôåß áðü ôçí ôñïðïðïßçóç áõôÞí. Åê ôïõ áíáäáóìïý áõôïý äåí ìðïñåß íá ðñïêýðôåé óáí áðïôÝëåóìá ç
áíÜêëçóç ôçò ¢äåéáò Þ ï ðåñéïñéóìüò ôïõ áíôáãùíéóìïý.
ÊÅÖÁËÁÉÏ Ä´
ÄÉÊÁÉÙÌÁÔÁ ÊÁÉ ÕÐÏ×ÑÅÙÓÅÉÓ
¢ñèñï 8
Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß
1. Õðü ôçí åðéöýëáîç ýðáñîçò åðáñêïýò áíôáãùíéóìïý óôç ó÷åôéêÞ áãïñÜ, ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß ïöåßëïõí íá äéáóöáëßæïõí Ðáñï÷Þ Áíïéêôïý Äéêôýïõ, áíåîáñôÞôùò ôçò ÷ñçóéìïðïéïýìåíçò õðïäïìÞò, áíôß
åõëüãïõ ôéìÞìáôïò êáé åöáñìüæïíôáò ôéò áñ÷Ýò ôçò áíôéêåéìåíéêüôçôáò, ôçò äéáöÜíåéáò, ôçò áðïöõãÞò äéáêñßóåùí, ôçò éóüôçôáò óôçí ðñüóâáóç êáé ðñïóöÝñïíôáò ôçí
ßäéá ðïéüôçôá õðçñåóßáò ìå áõôÞí ðïõ ðñïóöÝñïõí ïé ßäéïé, ïé èõãáôñéêÝò ôïõò åðé÷åéñÞóåéò Þ ïé åôáßñïé ôïõò
3906
óôçí áãïñÜ. Óå êÜèå ðåñßðôùóç, ðåñéïñéóìïß óôçí Ðáñï÷Þ Áíïéêôïý Äéêôýïõ åðéôñÝðïíôáé ìüíï óôçí ðåñßðôùóç
ðïõ óõíôñÝ÷ïõí Ïõóéþäåéò ÁðáéôÞóåéò êáôÜ ôçí Ýííïéá
ôïõ Üñèñïõ 2. Äåí åðéôñÝðåôáé ç èÝóðéóç ðñïûðïèÝóåùí
ðñüóâáóçò ùò ðñïò ôï ÷ñçóéìïðïéïýìåíï Ôåñìáôéêü Åîïðëéóìü, åöüóïí ï åîïðëéóìüò áõôüò ðëçñïß ôá èåóðéóìÝíá Ðñüôõðá êáé ðñïäéáãñáöÝò óå Êïéíïôéêü åðßðåäï
Þ åëëåßøåé áõôþí, äéáäï÷éêÜ êáôÜ ôçí áêüëïõèç óåéñÜ, ôá
Ðñüôõðá Þ/êáé ôéò ðñïäéáãñáöÝò ðïõ èåóðßæïíôáé áðü
Åõñùðáúêïýò Ïñãáíéóìïýò Ôõðïðïßçóçò [üðùò ôï Åõñùðáúêü Éíóôéôïýôï Ôõðïðïßçóçò óôïí ôïìÝá ôùí ôçëåðéêïéíùíéþí (ETSI), ç ÅõñùðáúêÞ ÅðéôñïðÞ Ôõðïðïßçóçò
(CEN), ç ÅõñùðáúêÞ ÅðéôñïðÞ Çëåêôñïôå÷íéêÞò Ôõðïðïßçóçò (CENELEC)], ôá äéåèíÞ Ðñüôõðá Þ ôéò óõóôÜóåéò
ôçò Äéåèíïýò ¸íùóçò Ôçëåðéêïéíùíéþí Þ ôï ÄéåèíÞ Ïñãáíéóìü Ôõðïðïßçóçò Þ ôá åèíéêÜ Ðñüôõðá Þ/êáé ðñïäéáãñáöÝò.
2. Ìå áðïöÜóåéò ôçò Å.Å.Ô.Ô. ïñßæïíôáé: á) ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß ðïõ õðï÷ñåïýíôáé íá ðáñÝ÷ïõí ôï
åëÜ÷éóôï óýíïëï ôùí ÌéóèùìÝíùí Ãñáììþí ôïõ ÐáñáñôÞìáôïò III ôïõ Üñèñïõ 6 ôïõ ð.ä. 40/1996 (ÖÅÊ 27 Á´), üðùò áíôéêáôáóôÜèçêå ìå ôï Üñèñï 13 ôïõ ð.ä. 156/1999,
(ÖÅÊ 153 Á´), â) ïé äéáäéêáóßåò ðáñáããåëßáò êáé ÷ñÝùóçò
ÌéóèùìÝíùí Ãñáììþí, ã) ïé áñ÷Ýò ôéìïëüãçóçò ôùí ÌéóèùìÝíùí Ãñáììþí ðïõ (ãéá ôïõò Ïñãáíéóìïýò ìå ÓçìáíôéêÞ ÈÝóç óôçí ÁãïñÜ) ðñÝðåé íá åßíáé äéáöáíåßò êáé
ðñïóáíáôïëéóìÝíåò ðñïò ôï êüóôïò, ä) åíäå÷üìåíïé ðåñéïñéóìïß óôçí ðáñï÷Þ êáé ÷ñÞóç ôùí ÌéóèùìÝíùí Ãñáììþí óýìöùíá ìå ôçí áíùôÝñù ðáñÜãñáöï 1, å) êÜèå Üëëï èÝìá ðïõ áöïñÜ ôïõò üñïõò ðáñï÷Þò ÌéóèùìÝíùí
Ãñáììþí.
3. Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß ðïõ ðáñÝ÷ïõí: á)
óôáèåñÜ Þ/êáé êéíçôÜ Äçìüóéá ÔçëåðéêïéíùíéáêÜ Äßêôõá
ìåôáãùãÞò Þ/êáé Äçìüóéåò ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò, â) ÌéóèùìÝíåò ÃñáììÝò óôéò åãêáôáóôÜóåéò ôùí
×ñçóôþí êáé ã) Üëëåò ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò ðïõ
åíäå÷ïìÝíùò ïñßóåé ç Å.Å.Ô.Ô. ìå åéäéêÞ áðüöáóÞ ôçò, ïöåßëïõí íá ðñïóöÝñïõí Äéáóýíäåóç åßôå ìåôáîý ôïõò åßôå ìå áëëïäáðïýò Ôçëåðéêïéíùíéáêïýò Ïñãáíéóìïýò, êáôÜ ôéò äéáôÜîåéò ôçò êåßìåíçò íïìïèåóßáò. ¼ëåò ïé óõìöùíßåò Äéáóýíäåóçò ìåôáîý ôùí Ôçëåðéêïéíùíéáêþí
Ïñãáíéóìþí, êáèþò êáé êÜèå Üñíçóç ðáñï÷Þò Äéáóýíäåóçò áðü Ôçëåðéêïéíùíéáêü Ïñãáíéóìü êïéíïðïéïýíôáé
óôçí Å.Å.Ô.Ô., ç ïðïßá äéáôçñåß ôï äéêáßùìá íá æçôÞóåé ôçí
ôñïðïðïßçóç Þ ôïí ðåñéïñéóìü ôïõò, êáôÜ ôéò éó÷ýïõóåò
íïìïèåôéêÝò äéáôÜîåéò. Ôï åëÜ÷éóôï ðåñéå÷üìåíï ôçò
ðñïóöåñüìåíçò Äéáóýíäåóçò, êáèþò êáé êÜèå Üëëï åéäéêüôåñï èÝìá åöáñìïãÞò ôçò ðáñïýóáò ðáñáãñÜöïõ,
óõìðåñéëáìâáíïìÝíùí êáé ôùí áñ÷þí ôéìïëüãçóçò ôçò
Äéáóýíäåóçò, ðïõ (ãéá ôïõò Ïñãáíéóìïýò ìå ÓçìáíôéêÞ
ÈÝóç óôçí ÁãïñÜ) ðñÝðåé íá åßíáé äéáöáíåßò êáé ðñïóáíáôïëéóìÝíåò ðñïò ôï êüóôïò, ïñßæåôáé ìå áðüöáóç ôçò
Å.Å.Ô.Ô.. Åðßóçò, Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß ðïõ ðáñÝ÷ïõí êéíçôÜ Äçìüóéá ÔçëåðéêïéíùíéáêÜ Äßêôõá ïöåßëïõí, ìåôÜ áðü ó÷åôéêÞ áðüöáóç ôçò Å.Å.Ô.Ô. êáé ôï áñãüôåñï åíôüò åíüò (1) Ýôïõò áðü ôç èÝóç óå éó÷ý ôïõ ðáñüíôïò íüìïõ, íá óõíÜøïõí ìåôáîý ôïõò óõìöùíßåò
åèíéêÞò ÐåñéáãùãÞò.
4. ÊÜèå Ôçëåðéêïéíùíéáêüò Ïñãáíéóìüò ðïõ åðéèõìåß
íá áóêÞóåé äñáóôçñéüôçôåò ãéá ôéò ïðïßåò Ý÷åé åêäïèåß
ÅéäéêÞ ¢äåéá äýíáôáé íá æçôÞóåé ôçí ðñüóâáóç Þ/êáé äéÝëåõóç ôùí äéêôýùí ôïõ êáé ëïéðþí õðïäïìþí óå äçìüóéá
ðñÜãìáôá êáé êïéíü÷ñçóôïõò ÷þñïõò Þ äéáìÝóïõ áõôþí,
åöüóïí äåí êáèßóôáôáé åöéêôÞ ç ðáñï÷Þ ôùí óõãêåêñéìÝíùí ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí ìå Üëëï, ëéãüôåñï åðá÷èÞ, ôñüðï. Óôçí ðåñßðôùóç áõôÞí, ï áñìüäéïò
öïñÝáò õðï÷ñåïýôáé íá áðáíôÞóåé åíôüò äþäåêá (12) åâäïìÜäùí áðü ôçí ðáñáëáâÞ ôçò ó÷åôéêÞò ðëÞñïõò áßôçóçò áðü ôïí åíäéáöåñüìåíï. Áí ðáñÝëèåé Üðñáêôç ç
ðñïèåóìßá áõôÞ, ç Üäåéá ðñüóâáóçò Þ / êáé äéÝëåõóçò èá
ôåêìáßñåôáé üôé ÷ïñçãÞèçêå áõôïäßêáéá. Ïé áñìüäéïé öïñåßò äåí äýíáíôáé íá áñíïýíôáé ôç ÷ïñÞãçóç ôçò ó÷åôéêÞò Üäåéáò ðñüóâáóçò Þ äéÝëåõóçò, äýíáíôáé üìùò íá
èÝóïõí ðñïûðïèÝóåéò, ïé ïðïßåò üìùò äåí èá áíáéñïýí
ïõóéùäþò ôç ÷ñçóéìüôçôá ôçò Üäåéáò, åêôüò åÜí óõíôñÝ÷åé óðïõäáßïò ëüãïò, åíäå÷üìåíç äå Üñíçóç èá ðñÝðåé
íá áéôéïëïãåßôáé åéäéêÜ, êáé ìüíï ãéá ëüãïõò ðñïóôáóßáò
ôïõ ðåñéâÜëëïíôïò, ôçò äçìüóéáò õãåßáò êáé ôùí áñ÷áéïëïãéêþí ôüðùí. Ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß ôçò ðáñïýóáò ðáñáãñÜöïõ äéêáéïýíôáé, êáôÜ ôéò äéáôÜîåéò ôïõ
Áóôéêïý Êþäéêá êáé Ýíáíôé åýëïãçò áðïæçìßùóçò, ôç óýóôáóç ðñïóùðéêÞò äïõëåßáò óå âÜñïò áêéíÞôùí éäéùôþí,
üôáí áõôü åßíáé áðáñáßôçôï ãéá ôçí ôïðïèÝôçóç Þ /êáé äéÝëåõóç Þ/êáé óõíôÞñçóç êáé åðéóêåõÞ ôùí äéêôýùí êáé åãêáôáóôÜóåþí ôïõò, õðü ôçí ðñïûðüèåóç ôçò åöáñìïãÞò ôùí äéáôÜîåùí ôçò êåßìåíçò íïìïèåóßáò ãéá ôçí áóöáëÞ åãêáôÜóôáóç äéêôýùí êáé ëïéðþí õðïäïìþí. Ïé
äéáôÜîåéò ôùí Üñèñùí 1003 åð. ôïõ Áóôéêïý Êþäéêá åöáñìüæïíôáé ãéá ôçí ðåñßðôùóç äéåõêüëõíóçò ôçò êáôáóêåõÞò, åãêáôÜóôáóçò Þ åðéóêåõÞò ôùí äéêôýùí, ôùí Ýñãùí õðïäïìÞò ê.ëð. ôùí Ôçëåðéêïéíùíéáêþí Ïñãáíéóìþí
ôçò ðáñáãñÜöïõ áõôÞò.
5. ÊÜèå Ôçëåðéêïéíùíéáêüò Ïñãáíéóìüò äéêáéïýôáé íá
ðáñÜó÷åé ÊáèïëéêÞ Õðçñåóßá. Ç Å.Å.Ô.Ô. ìå âÜóç ôá êñéôÞñéá ôçò åèíéêÞò êáé êïéíïôéêÞò íïìïèåóßáò êáôáñôßæåé
êáé äçìïóéåýåé óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò ôïí êáôÜëïãï ôùí ïñãáíéóìþí ðïõ õðï÷ñåïýíôáé íá ðáñÜó÷ïõí ÊáèïëéêÞ Õðçñåóßá, ôï åëÜ÷éóôï óýíïëï õðçñåóéþí êáé ôá ôå÷íéêÜ ÷áñáêôçñéóôéêÜ ðïõ ðåñéëáìâÜíåé ç
ÊáèïëéêÞ Õðçñåóßá, ôéò áñ÷Ýò êïóôïëüãçóçò ðïõ ïöåßëïõí íá áêïëïõèïýí ïé ïñãáíéóìïß ãéá ôçí ðáñï÷Þ ÊáèïëéêÞò Õðçñåóßáò, êáèþò êáé êÜèå Üëëï èÝìá ðïõ Üðôåôáé
ôçò åöáñìïãÞò ôçò ÊáèïëéêÞò Õðçñåóßáò. Ç ðáñï÷Þ ôçò
ÊáèïëéêÞò Õðçñåóßáò èá áðïâëÝðåé áö´ åíüò óôçí åí ãÝíåé ôçëåðéêïéíùíéáêÞ åîõðçñÝôçóç üëùí ôùí ðåñéï÷þí
ôçò ÷þñáò óå ðñïóéôÞ ôéìÞ êáé ìå éêáíïðïéçôéêÞ ðïéüôçôá
êáé áö åôÝñïõ óôçí áíÜðôõîç ôçò Êïéíùíßáò ôçò Ðëçñïöïñßáò. Ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß ðïõ õðï÷ñåïýíôáé íá ðáñÝ÷ïõí ÊáèïëéêÞ Õðçñåóßá, åöüóïí áðïäåéêíýïõí üôé ç ðáñï÷Þ áõôÞ áðïôåëåß õðåñâïëéêÞ åðéâÜñõíóÞ ôïõò, äéêáéïýíôáé íá æçôÞóïõí áðü ôçí Å.Å.Ô.Ô. ôïí
åðéìåñéóìü ôïõ êáèáñïý êüóôïõò ôçò ðáñï÷Þò ìå Üëëïõò Ôçëåðéêïéíùíéáêïýò Ïñãáíéóìïýò ðïõ åêìåôáëëåýïíôáé Äçìüóéá ÔçëåðéêïéíùíéáêÜ Äßêôõá Þ/êáé Äçìüóéåò
ÔçëåðéêïéíùíéáêÝò Õðçñåóßåò ðïõ ðñïóöÝñïõí ïìïåéäåßò ðáñï÷Ýò ìå åêåßíåò ðïõ áðïôåëïýí ðåñéå÷üìåíï ôçò
ÊáèïëéêÞò Õðçñåóßáò.
6. Ç Å.Å.Ô.Ô. óõíôÜóóåé ôïí êáôÜëïãï ôùí Ïñãáíéóìþí
ìå ÓçìáíôéêÞ ÈÝóç óôçí ÁãïñÜ, ìå âÜóç ôéò åðéôáãÝò ôïõ
êïéíïôéêïý êáé åèíéêïý äéêáßïõ, êáé ïñßæåé ôéò åéäéêÝò õðï÷ñåþóåéò ôùí Ïñãáíéóìþí áõôþí ó÷åôéêÜ ìå ôéò äéáôÜîåéò
ôïõ ðáñüíôïò Üñèñïõ êáé åíäå÷ïìÝíùò ìå ôçí êïóôïëüãçóç ôçò ÖùíçôéêÞò Ôçëåöùíßáò. Ï ïñéóìüò ôùí åéäéêþí
áõôþí õðï÷ñåþóåùí ìðïñåß íá ãßíåôáé åßôå ìå ôçí Ýêäïóç åéäéêÞò ðñïò ôïýôï áðüöáóçò ôçò Å.Å.Ô.Ô., ðïõ äçìï-
óéåýåôáé óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò, åßôå ìå ôçí
ÅéäéêÞ ¢äåéá ôùí Ïñãáíéóìþí áõôþí, êáôÜ ôéò äéáôÜîåéò
ôïõ Üñèñïõ 6 ôïõ ðáñüíôïò. Óôéò åéäéêÝò õðï÷ñåþóåéò
ôùí Ïñãáíéóìþí ôçò ðáñïýóáò ðáñáãñÜöïõ ðåñéëáìâÜíåôáé êáé ç õðï÷ñÝùóç ðëÞñùò ÁðïäåóìåõìÝíçò Ðñüóâáóçò óôïí Ôïðéêü Âñü÷ï ôïõò óå åðé÷åéñÞóåéò ðïõ
ðñùôïåéóÝñ÷ïíôáé óôï óõãêåêñéìÝíï áíôéêåßìåíï, ìå
ôïõò ßäéïõò üñïõò êáé ðïéüôçôá ÷ùñßò äéáêñßóåéò êáé óôéò
ßäéåò ðñïèåóìßåò ìå ôéò ïðïßåò ðñïóöÝñïõí ôçí ðáñï÷Þ
áõôÞ óôéò óõíäåäåìÝíåò ìå áõôïýò åðé÷åéñÞóåéò ôïõò êáé
ìå ôßìçìá ðïõ áíôáðïêñßíåôáé óôï ðñáãìáôéêü êüóôïò. Ç
ùò Üíù õðï÷ñÝùóç ôùí Ïñãáíéóìþí ôçò ðáñïýóáò ðáñáãñÜöïõ ãéá ôçí ðëÞñùò ÁðïäåóìåõìÝíç Ðñüóâáóç
óôïí Ôïðéêü Âñü÷ï, ëÞãåé ìåôÜ ðáñÝëåõóç ôåôñáåôßáò áðü ôç äéÜèåóç ðñïò ÷ñÞóç áõôïý, åêôüò åÜí áðü ôçí åîÝëéîç ôçò ôå÷íïëïãßáò êáé ôçí áíÜðôõîç ôïõ áíôáãùíéóìïý
äéêáéïëïãåßôáé íùñßôåñá ç ëÞîç ôçò õðï÷ñÝùóçò.
7. ¸íáò Ôçëåðéêïéíùíéáêüò Ïñãáíéóìüò ÷áñáêôçñßæåôáé ùò Ïñãáíéóìüò ìå ÓçìáíôéêÞ ÈÝóç óôçí ÁãïñÜ üôáí
êáôÝ÷åé ìåñßäéï ßóï Þ ìåãáëýôåñï ôïõ 25% óôç ãåùãñáöéêÞ áãïñÜ ðïõ äñáóôçñéïðïéåßôáé êáé óôï ôçëåðéêïéíùíéáêü áíôéêåßìåíï óõãêåêñéìÝíçò õðçñåóßáò. Ç Å.Å.Ô.Ô.
ìðïñåß íá ïñßóåé, ìå åéäéêÜ áéôéïëïãçìÝíç áðüöáóÞ ôçò,
êáé êáôÜ ôïõò ïñéóìïýò ôïõ êïéíïôéêïý êáé åèíéêïý äéêáßïõ, üôé Ýíáò ïñãáíéóìüò ðïõ êáôÝ÷åé ìåñßäéï óå óõãêåêñéìÝíç áãïñÜ ìéêñüôåñï Þ ìåãáëýôåñï ôïõ 25% áðïôåëåß Þ äåí áðïôåëåß áíôßóôïé÷á Ïñãáíéóìü ìå ÓçìáíôéêÞ
ÈÝóç óôçí ÁãïñÜ.
8. Ôçëåðéêïéíùíéáêüò Ïñãáíéóìüò ðïõ êáôÝ÷åé äåóðüæïõóá èÝóç óôçí ðáñï÷Þ Äçìüóéùí Ôçëåðéêïéíùíéáêþí Äéêôýùí êáé õðçñåóéþí ÖùíçôéêÞò Ôçëåöùíßáò åíôüò ôçò ÅëëçíéêÞò åðéêñÜôåéáò, äåí äéêáéïýôáé íá ÷ñçóéìïðïéåß ôï ßäéï
íïìéêü ðñüóùðï ãéá ôçí åêìåôÜëëåõóç äéêôýùí êáëùäéáêÞò ôçëåüñáóçò ìå áõôü ðïõ ÷ñçóéìïðïéåß ãéá ôçí åêìåôÜëëåõóç ôïõ Äçìüóéïõ Ôçëåðéêïéíùíéáêïý Äéêôýïõ ôïõ.
¢ñèñï 9
×ñÞóôåò
1. ÁíåîÜñôçôá áðü ôá äéêáéþìáôá ðïõ áðïêôïýí ïé ÷ñÞóôåò ìÝóù ôùí åéäéêþí óõìâÜóåùí ðáñï÷Þò ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí ìå ôïõò åêÜóôïôå Ôçëåðéêïéíùíéáêïýò Ïñãáíéóìïýò, êÜèå ×ñÞóôçò, áäéáêñßôùò, Ý÷åé ôá åîÞò äéêáéþìáôá:
á. ôï äéêáßùìá óýíäåóçò ìå ôá íïìßìùò ëåéôïõñãïýíôá
Äçìüóéá ÔçëåðéêïéíùíéáêÜ Äßêôõá ìÝóá óå åýëïãï ÷ñïíéêü äéÜóôçìá áðü ôçí õðïâïëÞ ôçò ó÷åôéêÞò áßôçóçò, ðïõ
äåí ìðïñåß íá õðåñâáßíåé ôéò äýï (2) åâäïìÜäåò,
â. ôï äéêáßùìá áêþëõôçò êáé ðïéïôéêÞò ÷ñÞóçò ôùí íïìßìùò ðáñå÷üìåíùí Ôçëåðéêïéíùíéáêþí Õðçñåóéþí,
ã. ôï äéêáßùìá óýíäåóçò óå Ôåñìáôéêü Óçìåßï ôïõ óôáèåñïý Äçìüóéïõ Ôçëåðéêïéíùíéáêïý Äéêôýïõ êáé ÷ñÞóçò
Ôåñìáôéêïý Åîïðëéóìïý åëåýèåñçò åðéëïãÞò ôïõ ×ñÞóôç, åöüóïí åßíáé êáôÜëëçëïò ãéá ôçí ðáñå÷üìåíç óýíäåóç, êáôÜ ôéò äéáôÜîåéò ôïõ Üñèñïõ 10 ôïõ ðáñüíôïò,
ä. ôï äéêáßùìá íá ëáìâÜíïõí áíáëõôéêïýò ëïãáñéáóìïýò ÷ñÝùóçò ìå ôï áíôßôéìï ôùí ðáñå÷üìåíùí Ôçëåðéêïéíùíéáêþí Õðçñåóéþí ìå åðáñêåßò ëåðôïìÝñåéåò, þóôå
íá êáèßóôáôáé äõíáôÞ ç åðáëÞèåõóç êáé ï Ýëåã÷ïò ôùí ôåëþí ôá ïðïßá óõíåðÜãåôáé ç ÷ñÞóç ôïõ Äçìüóéïõ Ôçëåðéêïéíùíéáêïý Äéêôýïõ êáé ôùí Äçìüóéùí Ôçëåðéêïéíùíéáêþí Õðçñåóéþí,
3907
å. ôï äéêáßùìá íá äéáôçñåß åìðéóôåõôéêü êáé áðüññçôï
ôï ÷áñáêôÞñá ôùí åðéêïéíùíéþí ôïõ,
óô. õðü ôçí åðéöýëáîç ïìÜäùí ×ñçóôþí ìå åéäéêÝò êïéíùíéêÝò áíÜãêåò, ôï äéêáßùìá ßóçò ìåôá÷åßñéóçò áðü ôéò
ôçëåðéêïéíùíéáêÝò åðé÷åéñÞóåéò óå èÝìáôá ôéìïëüãçóçò,
æ. íá æçôÜ áðü ôéò ôçëåðéêïéíùíéáêÝò åðé÷åéñÞóåéò ôç
÷ñÞóç ôçò åëëçíéêÞò ãëþóóáò ãéá ïðïéáäÞðïôå ðáñå÷üìåíç õðçñåóßá.
Ïé Ôçëåðéêïéíùíéáêïß Ïñãáíéóìïß ïöåßëïõí íá ëáìâÜíïõí ôá êáôÜëëçëá ìÝôñá ãéá ôç äéáóöÜëéóç ôùí áíùôÝñù äéêáéùìÜôùí, óõìðåñéëáìâáíïìÝíçò êáé ôçò õðï÷ñÝùóÞò ôïõò íá ãíùóôïðïéïýí äçìïóßùò ôá ôå÷íéêÜ ÷áñáêôçñéóôéêÜ ôùí äéêôýùí ôïõò êáé ôá ôéìïëüãéÜ ôïõò, êáèþò
êáé ôéò óõíèÞêåò ðáñï÷Þò êáé ÷ñÞóçò ôùí ðáñå÷üìåíùí
õðçñåóéþí êáé äéêôýùí.
2. Ç åê ìÝñïõò ôçò ôçëåðéêïéíùíéáêÞò åðé÷åßñçóçò ìïíïìåñÞò ðñïóùñéíÞ äéáêïðÞ ôçò ðáñï÷Þò ôçëåðéêïéíùíéáêÞò õðçñåóßáò ðñïò ôï ×ñÞóôç ëüãù ëçîéðñüèåóìçò
êáé áðáéôçôÞò ïöåéëÞò ôïõ ôåëåõôáßïõ ðñïò ôçí ôçëåðéêïéíùíéáêÞ åðé÷åßñçóç åðéôñÝðåôáé ìüíï ìåôÜ ôçí ðÜñïäï äåêáðÝíôå (15) çìåñþí áðü ôçí êïéíïðïßçóç ðñïò áõôüí ó÷åôéêÞò Ýããñáöçò åéäïðïßçóçò. Ç äéáêïðÞ áõôÞ, åöüóïí åßíáé ôå÷íéêþò åöéêôü, ðåñéïñßæåôáé óôç
óõãêåêñéìÝíç õðçñåóßá. ÊáôÜ ôçí ðåñßïäï ðñïóùñéíÞò
äéáêïðÞò èá ðñÝðåé íá åðéôñÝðåôáé ç ðñáãìáôïðïßçóç
êëÞóåùí ðïõ äåí óõíåðÜãïíôáé ÷ñÝùóç ãéá ôïí åí ëüãù
×ñÞóôç.
3. Ç åê ìÝñïõò ôçò ôçëåðéêïéíùíéáêÞò åðé÷åßñçóçò ìïíïìåñÞò ïñéóôéêÞ äéáêïðÞ ôçò ðáñï÷Þò ôçëåðéêïéíùíéáêÞò õðçñåóßáò ðñïò ôï ×ñÞóôç ëüãù ëçîéðñüèåóìçò êáé
áðáéôçôÞò ïöåéëÞò ôïõ ôåëåõôáßïõ ðñïò ôçí ôçëåðéêïéíùíéáêÞ åðé÷åßñçóç åðéôñÝðåôáé ìüíï ìåôÜ ôçí ðÜñïäï åîÞíôá (60) çìåñþí áðü ôçí ðñïóùñéíÞ äéáêïðÞ ôçò ðáñï÷Þò ôçò åí ëüãù ôçëåðéêïéíùíéáêÞò õðçñåóßáò ãéá ôïí
ßäéï ëüãï êáé Ýðåéôá áðü ôçí êïéíïðïßçóç ðñïò áõôüí ó÷åôéêÞò Ýããñáöçò åéäïðïßçóçò. Êáô åîáßñåóç åðéôñÝðåôáé
ç ïñéóôéêÞ äéáêïðÞ êáé áðïóýíäåóç ôïõ ×ñÞóôç áðü ôï
Ôçëåðéêïéíùíéáêü Äßêôõï ÷ùñßò ðñïçãïýìåíç åéäïðïßçóç óôéò ðåñéðôþóåéò áðÜôçò êáé åðáíåéëçììÝíçò åêðñüèåóìçò åîüöëçóçò Þ ìç åîüöëçóçò ëïãáñéáóìþí.
4. ÊÜèå ×ñÞóôçò äéêáéïýôáé íá æçôÞóåé áðü ôéò ôçëåðéêïéíùíéáêÝò åðé÷åéñÞóåéò Üìåóç êáé ðëÞñç áðïêáôÜóôáóç ïðïéáóäÞðïôå èåôéêÞò Þ áðïèåôéêÞò æçìßáò Þ çèéêÞò
âëÜâçò ðïõ õðÝóôç ëüãù åëëéðïýò Þ åëáôôùìáôéêÞò êáôáóêåõÞò, åãêáôÜóôáóçò, óõíôÞñçóçò Þ ëåéôïõñãßáò
ôùí äéêôýùí, õðçñåóéþí Þ ôçëåðéêïéíùíéáêïý Ôåñìáôéêïý
Åîïðëéóìïý. Ç áäéêáéïëüãçôç äéáêïðÞ õðçñåóßáò ðñïò
ôïõò ÷ñÞóôåò ãåííÜ åðßóçò äéêáßùìá áðïæçìßùóÞò ôïõò.
5. Õðü ôçí åðéöýëáîç ôùí äéáôÜîåùí ôçò êåßìåíçò íïìïèåóßáò ãéá ôçí ðñïóôáóßá ôùí ðñïóùðéêþí äåäïìÝíùí, ïé ôçëåðéêïéíùíéáêÝò åðé÷åéñÞóåéò ðïõ ðáñÝ÷ïõí õðçñåóßåò ÖùíçôéêÞò Ôçëåöùíßáò Þ ÊéíçôÞò êáé ÐñïóùðéêÞò Åðéêïéíùíßáò ïöåßëïõí íá åêäßäïõí óå Ýíôõðç Þ/êáé
çëåêôñïíéêÞ ìïñöÞ ïíïìáóôéêïýò ôçëåöùíéêïýò êáôáëüãïõò ôùí óõíäñïìçôþí ðïõ äåí Ý÷ïõí äçëþóåé ñçôÜ áíôßññçóç óôçí êáôá÷þñçóÞ ôïõò óôïõò ùò Üíù êáôáëüãïõò. Óå üëïõò ôïõò ×ñÞóôåò, óõìðåñéëáìâáíïìÝíùí
ôùí ×ñçóôþí êïéíï÷ñÞóôùí ôçëåöþíùí, äéáôßèåôáé ìßá
ôïõëÜ÷éóôïí õðçñåóßá ðëçñïöïñéþí ôçëåöùíéêïý êáôáëüãïõ, ç ïðïßá êáëýðôåé üëïõò ôïõò êáôá÷ùñçìÝíïõò
óõíäñïìçôéêïýò áñéèìïýò ÖùíçôéêÞò Ôçëåöùíßáò Þ ÊéíçôÞò êáé ÐñïóùðéêÞò Åðéêïéíùíßáò.
3908
¢ñèñï 10
Ôåñìáôéêüò Åîïðëéóìüò
1. ÌÝ÷ñé ôç äçìïóßåõóç ðñïåäñéêïý äéáôÜãìáôïò åíáñìüíéóçò ôçò Ïäçãßáò 99/5/ÅÊ, êÜèå óõóêåõÞ ç ïðïßá
åìðßðôåé óôï ðåäßï åöáñìïãÞò ôçò Ïäçãßáò 99/5/ÅÊ ìðïñåß íá ôßèåôáé óå êõêëïöïñßá êáé ÷ñÞóç óýìöùíá ìå ôá
ðñïâëåðüìåíá óôçí ùò Üíù Ïäçãßá.
2. Ç óýíäåóç êáé ÷ñÞóç ñáäéïåîïðëéóìïý Þ/êáé ôçëåðéêïéíùíéáêïý Ôåñìáôéêïý Åîïðëéóìïý óå Äçìüóéï Ôçëåðéêïéíùíéáêü Äßêôõï åßíáé åëåýèåñç õðü ôéò ðñïûðïèÝóåéò
ôçò ðáñáðÜíù ðáñáãñÜöïõ.
2. Óå ðåñßðôùóç ðáñáâßáóçò ôùí êáíüíùí ôïõ áíôáãùíéóìïý, ç Å.Å.Ô.Ô. äéêáéïýôáé, ìå åéäéêÜ áéôéïëïãçìÝíç áðüöáóÞ ôçò êáé ýóôåñá áðü ðñïçãïýìåíç áêñüáóç ôùí
åíäéáöåñïìÝíùí, íá åðéâÜëëåé ôéò ðñïâëåðüìåíåò áðü ôï
Í. 703/1977, üðùò åêÜóôïôå éó÷ýåé, êõñþóåéò.
3. Ç åðéëïãÞ ôïõ åßäïõò êáé ç åðéìÝôñçóç ôùí äéïéêçôéêþí êõñþóåùí ôïõ Üñèñïõ áõôïý ãßíåôáé áíÜëïãá ìå ôç
âáñýôçôá ôçò ðáñÜâáóçò, ôï åßäïò ôçò ¢äåéáò ðïõ êáôÝ÷åé ï ðáñáâÜôçò, ôçí Ýêôáóç ôçò äñáóôçñéüôçôÜò ôïõ êáé
ôçí ôõ÷üí õðïôñïðÞ ôïõ.
ÊÅÖÁËÁÉÏ ÓÔ´
ÊÅÖÁËÁÉÏ Å´
ÔÅËÉÊÅÓ ÊÁÉ ÌÅÔÁÂÁÔÉÊÅÓ ÄÉÁÔÁÎÅÉÓ
ÊÕÑÙÓÅÉÓ
ÑÕÈÌÉÓÅÉÓ ÈÅÌÁÔÙÍ ÅË.ÔÁ.
¢ñèñï 11
¢ñèñï 13
ÐïéíéêÝò Êõñþóåéò
ÔåëéêÝò êáé ìåôáâáôéêÝò äéáôÜîåéò
1. Ç êáôÜ ðáñÜâáóç ôùí Üñèñùí 5 êáé 6 ôïõ ðáñüíôïò
Üóêçóç ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí ôéìùñåßôáé
ìå öõëÜêéóç ôïõëÜ÷éóôïí äþäåêá (12) ìçíþí êáé ìå ÷ñçìáôéêÞ ðïéíÞ ýøïõò áðü ðÝíôå åêáôïììýñéá (5.000.000)
Ýùò ðåíôáêüóéá åêáôïììýñéá (500.000.000) äñá÷ìÝò.
2. ¼ðïéïò ðáñáâáßíåé ìå ïðïéïíäÞðïôå ôñüðï ôéò õðï÷ñåþóåéò å÷åìýèåéáò, óåâáóìïý ôçò éäéùôéêÞò æùÞò êáé
ôÞñçóçò ôïõ áðïññÞôïõ ôùí êÜèå åßäïõò äåäïìÝíùí ðïõ
ìåôáâéâÜæïíôáé Þ ìåôÜãïíôáé ìÝóù ôùí ôçëåðéêïéíùíéáêþí óõóôçìÜôùí ðïõ ÷ñçóéìïðïéåß Þ äéáèÝôåé, ôéìùñåßôáé
ìå ðïéíÞ öõëÜêéóçò ôïõëÜ÷éóôïí äýï (2) åôþí êáé ÷ñçìáôéêÞ ðïéíÞ ðÝíôå åêáôïììõñßùí (5.000.000) Ýùò åßêïóé åêáôïììõñßùí (20.000.000) äñá÷ìþí, åöüóïí äåí ðñïâëÝðïíôáé âáñýôåñåò ðïéíÝò áðü Üëëåò éó÷ýïõóåò äéáôÜîåéò. Óå ðåñßðôùóç ðïõ ï ðáñáâÜôçò ôçò ðáñïýóáò
äéÜôáîçò áíÞêåé óôï ðñïóùðéêü ôçëåðéêïéíùíéáêÞò åðé÷åßñçóçò, ç åðéâáëëüìåíç ðïéíÞ öõëÜêéóçò åßíáé ôïõëÜ÷éóôïí ôñéþí (3) åôþí êáé ç ÷ñçìáôéêÞ ðïéíÞ ôïõëÜ÷éóôïí
äÝêá åêáôïììýñéá (10.000.000) äñá÷ìÝò.
3. Ï ôå÷íéêüò åîïðëéóìüò êáé ôá ìÝóá ðïõ ÷ñçóéìïðïéÞèçêáí ãéá ôçí ôÝëåóç ôùí ðáñáðÜíù áîéüðïéíùí ðñÜîåùí
äçìåýïíôáé.
4. Óå ðåñéðôþóåéò ðïëëáðëþí Þ êáè õðïôñïðÞ ðáñáâÜóåùí ðñïâëåðüìåíùí óôïí ðáñüíôá íüìï, üðùò åêÜóôïôå
éó÷ýåé, Þ óôïí Ðïéíéêü Êþäéêá, óå ó÷Ýóç ìå ôá áíùôÝñù áäéêÞìáôá, åðéâÜëëïíôáé áèñïéóôéêÜ ïé âáñýôåñåò ðïéíÝò.
1. Ç êáô áðïêëåéóôéêüôçôá åãêáôÜóôáóç, ëåéôïõñãßá
êáé åêìåôÜëëåõóç ôïõ óôáèåñïý Äçìüóéïõ Ôçëåðéêïéíùíéáêïý Äéêôýïõ êáé ç ðáñï÷Þ ÖùíçôéêÞò Ôçëåöùíßáò áðü
ôïí Ïñãáíéóìü Ôçëåðéêïéíùíéþí ÅëëÜäïò (ÏÔÅ Á.Å.) ëÞãåé ôçí 31.12.2000.
2. Ï ÏÔÅ Á.Å. åßíáé õðü÷ñåïò ãéá ôçí ðáñï÷Þ ôçò ÊáèïëéêÞò Õðçñåóßáò êáé ôùí åëÜ÷éóôùí ÌéóèùìÝíùí Ãñáììþí, êáôÜ ôéò äéáôÜîåéò ôçò êåßìåíçò íïìïèåóßáò, Ýùò
31.12.2001. ÅéäéêÜ ãéá ôïí ÏÔÅ êáé ãéá ôï ÷ñïíéêü äéÜóôçìá Ýùò 31.12.2001, ùò ÊáèïëéêÞ Õðçñåóßá êáèïñßæåôáé: ç
ðñüóâáóç óôï óôáèåñü äçìüóéï ôçëåöùíéêü äßêôõï (ÖùíçôéêÞ Ôçëåöùíßá ãéá åèíéêÝò êáé äéåèíåßò êëÞóåéò, åðéêïéíùíßåò ôçëåïìïéïôõðßáò ïìÜäáò ÉÉÉ, óýìöùíá ìå ôéò
ÓõóôÜóåéò ôçò Äéåèíïýò ¸íùóçò Ôçëåðéêïéíùíéþí ÔïìÝáò Ñáäéïåðéêïéíùíéþí (ITU-T) óôç «óåéñÜ Ô», ìåôÜäïóç
äåäïìÝíùí öùíçôéêÞò æþíçò ìÝóù äéáðïäéáìïñöùôþí modem ìå ôá÷ýôçôá ôïõëÜ÷éóôïí 9600 äõáäéêþí øçößùí
áíÜ äåõôåñüëåðôï (bits per second-bps), óýìöùíá ìå ôéò
ÓõóôÜóåéò ôçò ITU-T óôç «óåéñÜ V»), õðçñåóßåò ôçëåöùíçôÞ, õðçñåóßá ðëçñïöïñéþí ôçëåöùíéêïý êáôáëüãïõ,
êáôÜëïãïé óõíäñïìçôþí óå Ýíôõðç Þ / êáé çëåêôñïíéêÞ
ìïñöÞ, Êïéíü÷ñçóôá ÔçëÝöùíá, äùñåÜí ðñüóâáóç óå õðçñåóßåò åêôÜêôïõ áíÜãêçò «112».
3. ÐñÜîåéò óõãêñüôçóçò ôçò Å.Å.Ô.Ô., ìå âÜóç ôéò äéáôÜîåéò ôïõ Í. 2246/1994, üðùò éó÷ýåé, ðáñáìÝíïõí éó÷õñÝò ìÝ÷ñé ôç ëÞîç ôçò èçôåßáò ôùí ìåëþí ôçò. Ï Ðñüåäñïò, ïé Áíôéðñüåäñïé êáé ôá ÌÝëç ôçò Å.Å.Ô.Ô. äéáíýïõí
ôç èçôåßá ãéá ôçí ïðïßá äéïñßóôçêáí.
4. Äéáäéêáóßåò ÷ïñÞãçóçò Åéäéêþí Áäåéþí ðïõ åõñßóêïíôáé óå åîÝëéîç, óõíå÷ßæïíôáé áðü ôçí Å.Å.Ô.Ô. áðü ôç èÝóç óå éó÷ý ôïõ ðáñüíôïò íüìïõ.
5. Ìå ðñïåäñéêü äéÜôáãìá, ðïõ èá åêäïèåß ìå ðñüôáóç
ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, ñõèìßæåôáé
êÜèå èÝìá ó÷åôéêü ìå ôç ìïíïáðåõèõíôéêÞ äéáäéêáóßá êáé
éäéáßôåñá ï ôñüðïò Ýêäïóçò ìÝóù ôçò Å.Å.Ô.Ô. üëùí ôùí
áäåéþí Þ åãêñßóåùí Üëëùí öïñÝùí ôïõ åõñýôåñïõ äçìüóéïõ ôïìÝá ðïõ áðáéôïýíôáé ãéá ôçí Üóêçóç ôçò óõãêåêñéìÝíçò äñáóôçñéüôçôáò ôçò åíäéáöåñüìåíçò ôçëåðéêïéíùíéáêÞò åðé÷åßñçóçò, ïé åõèýíåò ôùí áñìüäéùí ïñãÜíùí
óôçí
ðåñßðôùóç
ôçò
áäéêáéïëüãçôçò
êáèõóôÝñçóçò, ç Üóêçóç ôùí áñìïäéïôÞôùí óå ðåñßðôùóç áëëçëïåðéêÜëõøçò êáé êÜèå Üëëç ó÷åôéêÞ ëåðôïìÝñåéá.
6. Ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí Ìåôáöïñþí êáé Åðéêïéíùíéþí êáé ÁíÜðôõîçò ìðïñåß íá êáèïñéóôåß ç íïìéêÞ
¢ñèñï 12
ÄéïéêçôéêÝò Êõñþóåéò
1. Óå ðåñßðôùóç ðáñáâÜóåùò ôçò êåßìåíçò íïìïèåóßáò
óôïí ôïìÝá ôùí ôçëåðéêïéíùíéþí Þ ìç ðëÞñùóçò õðï÷ñÝùóçò Þ ðáñáâÜóåùò üñùí Áäåéþí, ç Å.Å.Ô.Ô. äýíáôáé, ìå
åéäéêÜ áéôéïëïãçìÝíç áðüöáóÞ ôçò êáé ýóôåñá áðü ðñïçãïýìåíç áêñüáóç ôùí åíäéáöåñïìÝíùí, íá åðéâÜëëåé ìßá
Þ ðåñéóóüôåñåò áðü ôéò ðáñáêÜôù êõñþóåéò:
á. óýóôáóç ãéá óõììüñöùóç óå óõãêåêñéìÝíç äéÜôáîç
ôçò íïìïèåóßáò ìå ðñïåéäïðïßçóç åðéâïëÞò ëïéðþí êõñþóåùí,
â. ðñüóôéìï áðü ðÝíôå åêáôïììýñéá (5.000.000) Ýùò ðåíôáêüóéá åêáôïììýñéá (500.000.000) äñá÷ìÝò, ðïõ åéóðñÜôôåôáé êáôÜ ôéò äéáôÜîåéò ôïõ íüìïõ ãéá ôçí åßóðñáîç ôùí äçìïóßùí åóüäùí (Ê.Å.Ä.Å.),
ã. ðñïóùñéíÞ áíáóôïëÞ ìÝ÷ñé ôñåéò (3) ìÞíåò ôçò ëåéôïõñãßáò ôçëåðéêïéíùíéáêÞò åðé÷åßñçóçò,
ä. ôñïðïðïßçóç Þ áíÜêëçóç ôçò ¢äåéáò.
ìïñöÞ, ôï åëÜ÷éóôï êåöÜëáéï êáé ç åëÜ÷éóôç õðï÷ñåùôéêÞ óôåëÝ÷ùóç ôùí ôçëåðéêïéíùíéáêþí åðé÷åéñÞóåùí, áíáëüãùò ôïõ áíôéêåéìÝíïõ êáé ôïõ ýøïõò ôùí äñáóôçñéïôÞôùí ôïõò.
7. Ìå ðñïåäñéêü äéÜôáãìá, ðïõ èá åêäïèåß ìå ðñüôáóç
ôùí Õðïõñãþí Åóùôåñéêþí, Äçìüóéáò Äéïßêçóçò êáé ÁðïêÝíôñùóçò, Ïéêïíïìéêþí êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí, ñõèìßæåôáé ç äéÜñèñùóç ôçò ÃåíéêÞò Ãñáììáôåßáò Åðéêïéíùíéþí êáé êáèïñßæåôáé ç êáôáíïìÞ èÝóåùí êáôÜ êáôçãïñßá êáé êëÜäï.
8. Óôçí Å.Å.Ô.Ô. êáôáâÜëëïíôáé êáé ðåñéÝñ÷ïíôáé áðåõèåßáò ùò Ýóïäï ôá ðÜãéá ôÝëç ÷ïñÞãçóçò Åéäéêþí Þ Ãåíéêþí Áäåéþí, ôá áíôáðïäïôéêÜ ôÝëç, ôá ôÝëç ÷ñÞóçò áñéèìþí êáé öÜóìáôïò. Óôçí Å.Å.Ô.Ô. áðïäßäåôáé êáé ðåñéÝñ÷åôáé åðßóçò êÜèå Üëëï ðïóü ôï ïðïßï åéóðñÜôôåôáé áðü
ïðïéáäÞðïôå äéïéêçôéêÞ Þ äéêáóôéêÞ áñ÷Þ Þ Üëëïí ôñßôï
ùò ÷ñçìáôéêÞ ðïéíÞ, äéêáóôéêü ðñüóôéìï Þ ðñïúüí äÞìåõóçò óå ó÷Ýóç ìå ôçí Üóêçóç ôùí ôçëåðéêïéíùíéáêþí äñáóôçñéïôÞôùí, óýìöùíá ìå ôéò äéáôÜîåéò ôïõ Êåöáëáßïõ Å´
ôïõ ðáñüíôïò íüìïõ. Ôá ùò Üíù ôÝëç åéóðñÜôôïíôáé óôï
üíïìá êáé ãéá ëïãáñéáóìü ôçò Å.Å.Ô.Ô. êáé êáôáôßèåíôáé
óå åéäéêü ëïãáñéáóìü áõôÞò. Ôá ðïóÜ ðïõ êáôáâÜëëïíôáé
ãéá ôç ÷ïñÞãçóç Åéäéêþí Áäåéþí (åßôå âÜóåé ðñïêáèïñéóìÝíïõ ôéìÞìáôïò åßôå âÜóåé äéáãùíéóôéêÞò äéáäéêáóßáò)
ðåñéÝñ÷ïíôáé áðåõèåßáò óôïí Êñáôéêü Ðñïûðïëïãéóìü.
Åîáéñåßôáé áðü ôçí ðáñáðÜíù äéáäéêáóßá êáé êáôáôßèåôáé
áðåõèåßáò óôïí åéäéêü ëïãáñéáóìü ôçò Å.Å.Ô.Ô. ðïóü ßóï
ìå ôï óõíïëéêü êüóôïò ôçò ðñïåôïéìáóßáò êáé äéåíÝñãåéáò ôçò äéáãùíéóôéêÞò äéáäéêáóßáò Þ ôïõ ðëåéóôçñéáóìïý
óôï ïðïßï õðåâëÞèç ç Å.Å.Ô.Ô., óõìðåñéëáìâáíïìÝíïõ
êáé ôïõ óõíïëéêïý êüóôïõò ôçò äéáäéêáóßáò ðïõ ïäÞãçóå
óôïí ðåñéïñéóìü ôïõ áñéèìïý ôùí áäåéþí êáé ôïõ êüóôïõò
ôïõ åíäå÷üìåíïõ áíáäáóìïý ôùí óõ÷íïôÞôùí ôïõ Üñèñïõ 7 ðáñ. 7 ôïõ ðáñüíôïò.
Ï Ýëåã÷ïò ôùí ïéêïíïìéêþí óôïé÷åßùí êáé åôÞóéùí ëïãáñéáóìþí êáé ïéêïíïìéêþí êáôáóôÜóåùí ôçò Å.Å.Ô.Ô. ãßíåôáé áðü ïñêùôïýò åëåãêôÝò. Ôá óôïé÷åßá áõôÜ êáé ïé ïéêïíïìéêÝò êáôáóôÜóåéò äçìïóéåýïíôáé óå äýï (2) ôïõëÜ÷éóôïí çìåñÞóéåò åöçìåñßäåò êáé ôçí Åöçìåñßäá ôçò
ÊõâåñíÞóåùò.
Ï ôñüðïò ïéêïíïìéêÞò äéá÷åßñéóçò ôçò Å.Å.Ô.Ô. êáèïñßæåôáé ìå êáíïíéóìü, ðïõ åêäßäåôáé ìå êïéíÞ áðüöáóç ôùí
Õðïõñãþí Ïéêïíïìéêþí êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí, ðïõ äçìïóéåýåôáé óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò. ÌÝ÷ñé ôç äçìïóßåõóç áõôÞí åîáêïëïõèåß íá åöáñìüæåôáé ÊÕÁ 60266/1996 (ÖÅÊ 259 Â´).
Óôçí ðåñßðôùóç ðïõ áðü ôçí ïéêïíïìéêÞ äéá÷åßñéóç ôçò
Å.Å.Ô.Ô åêÜóôçò äéåôßáò ðñïêýðôåé èåôéêü ïéêïíïìéêü áðïôÝëåóìá (Ýóïäá Ýîïäá), ðïóïóôü ôïõ áðïôåëÝóìáôïò áõôïý áðïäßäåôáé óôïí Êñáôéêü Ðñïûðïëïãéóìü, ùò
äçìüóéï Ýóïäï. Ôï áðïäéäüìåíï ðïóïóôü, ðïõ äåí èá õðåñâáßíåé ôï 80%, êáé ïé ó÷åôéêÝò ëåðôïìÝñåéåò, êáèïñßæïíôáé ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí Ïéêïíïìéêþí êáé
Ìåôáöïñþí êáé Åðéêïéíùíéþí. Ôï õðüëïéðï ðïóïóôü ðáñáìÝíåé óôçí Å.Å.Ô.Ô, ç ïðïßá ìðïñåß íá ôï äéáèÝôåé, ìåôÜ
áðü áðüöáóç ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, ãéá èÝìáôá ëåéôïõñãßáò ôçò ÃåíéêÞò Ãñáììáôåßáò Åðéêïéíùíéþí, ðåñéëáìâáíïìÝíçò ôçò åðéóôçìïíéêÞò, ìåëåôçôéêÞò êáé óõìâïõëåõôéêÞò õðïóôÞñéîçò áõôÞò, ôùí áìïéâþí Åðéôñïðþí åðß èåìÜôùí áñìïäéüôçôÜò ôçò, ôùí
óõììåôï÷þí Þ ïñãáíþóåùí óõíüäùí Þ óõíåäñßùí, êáèþò êáé ôùí åñåõíçôéêþí ðñïãñáììÜôùí áðü åéäéêïýò åðéóôÞìïíåò Þ ïìÜäåò åñãáóßáò. Ç ðñþôç äéåôßá ãéá ôçí å-
3909
öáñìïãÞ ôçò ðáñïýóáò ðáñáãñÜöïõ ëÞãåé ôçí
31.12.2001.
9. Ïé äáðÜíåò ðïõ ðñïêáëïýíôáé áðü ôéò äéáôÜîåéò ôïõ
Üñèñïõ 4 èá êáëõöèïýí áðü ôçí åöáñìïãÞ ôçò ðáñ. 8
ôïõ Üñèñïõ 13 ôïõ ðáñüíôïò íüìïõ.
10. Ìå ðñïåäñéêü äéÜôáãìá, ðïõ åêäßäåôáé ýóôåñá áðü
ðñüôáóç ôùí Õðïõñãþí Ìåôáöïñþí êáé Åðéêïéíùíéþí, ÁíÜðôõîçò, Åóùôåñéêþí, Äçìüóéáò Äéïßêçóçò êáé ÁðïêÝíôñùóçò êáé ÐåñéâÜëëïíôïò, ×ùñïôáîßáò êáé Äçìüóéùí
¸ñãùí êáé äçìïóéåýåôáé óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò åíôüò ïêôþ (8) ìçíþí áðü ôç èÝóç óå éó÷ý ôïõ ðáñüíôïò íüìïõ, ñõèìßæåôáé êÜèå èÝìá ðïõ áöïñÜ ôçí êáôÜñôéóç êáé åêôÝëåóç ôùí óõìâÜóåùí åêôÝëåóçò äçìüóéùí Ýñãùí êáé åêðüíçóçò äçìüóéùí ìåëåôþí êáé
ðáñï÷Þò äçìüóéùí õðçñåóéþí óôïõò ôïìåßò ôùí ôçëåðéêïéíùíéþí êáé ôçò ðëçñïöïñéêÞò, ôï ëåðôïìåñÞ ôñüðï
äéåîáãùãÞò ôùí äéáäéêáóéþí áíÜèåóçò ôùí åí ëüãù Ýñãùí, ìåëåôþí êáé õðçñåóéþí, ôç óýóôáóç ôùí áðáñáßôçôùí åðéôñïðþí ãéá ôçí áîéïëüãçóç ôùí åíäéáöåñüìåíùí
åðé÷åéñÞóåùí, ôç äéáäéêáóßá õðïãñáöÞò ôçò óýìâáóçò
êáé ôçí áíáêÞñõîç ôùí áíáäü÷ùí, ôéò äéÜöïñåò ðñïèåóìßåò ðïõ Üðôïíôáé ôçò åêôÝëåóçò ôïõ Ýñãïõ, ôá äéêáéþìáôá êáé ôéò õðï÷ñåþóåéò ôïõ áíáäü÷ïõ, ôïí ôñüðï ðëçñùìÞò ôïõ áíáäü÷ïõ, ôçí åðéâïëÞ êáé êáôÜðôùóç ðïéíéêþí ñçôñþí, ôéò õðï÷ñåþóåéò ôùí ïñãÜíùí ôïõ êõñßïõ
ôïõ Ýñãïõ Þ ôïõ öïñÝá åðßâëåøçò ôçò åêôÝëåóçò áõôïý,
ôç äéåíÝñãåéá ôçò ðáñáëáâÞò ôïõ Ýñãïõ, ôçí ðáñï÷Þ åããõÞóåùí, ôçí áðüäïóç Þ êáôÜðôùóç åããõÞóåùí êáé åããõçôéêþí åðéóôïëþí, ôç äéáêïðÞ ôùí Ýñãùí êáé ôç äéÜëõóç ôùí óõìâÜóåùí, ôçí åðéâïëÞ äéïéêçôéêþí ðïéíþí êáé
êÜèå Üëëï óõíáöÝò èÝìá ðïõ Üðôåôáé ôùí áíùôÝñù.
11. Ìå ðñïåäñéêü äéÜôáãìá, ðïõ åêäßäåôáé ýóôåñá áðü
ðñüôáóç ôùí Õðïõñãþí Ìåôáöïñþí êáé Åðéêïéíùíéþí, ÁíÜðôõîçò, Åóùôåñéêþí, Äçìüóéáò Äéïßêçóçò êáé ÁðïêÝíôñùóçò êáé ÐåñéâÜëëïíôïò, ×ùñïôáîßáò êáé Äçìüóéùí
¸ñãùí êáé äçìïóéåýåôáé óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò åíôüò ïêôþ (8) ìçíþí áðü ôç èÝóç óå éó÷ý ôïõ ðáñüíôïò íüìïõ, êáèïñßæïíôáé ïé åëÜ÷éóôåò áðáéôÞóåéò
(ðñïäéáãñáöÝò) ðïõ èá ðñÝðåé íá ðëçñïß ç ìåëÝôç, ç êáôáóêåõÞ, ç óõíôÞñçóç êáé ç åðßâëåøç ôçëåðéêïéíùíéáêþí
åãêáôáóôÜóåùí êáé åãêáôáóôÜóåùí ðëçñïöïñéêÞò, ïé
êõñþóåéò êáé ëïéðÝò óõíÝðåéåò ðïõ óõíåðÜãåôáé ç ðáñÜâáóç ôùí åí ëüãù áðáéôÞóåùí, ç ðéóôïðïßçóç ôçò åêðëÞñùóçò ôùí ùò Üíù áðáéôÞóåùí êáé ï Ýëåã÷üò ôïõò, êáèþò êáé êÜèå êÜèå Üëëï óõíáöÝò èÝìá ðïõ Üðôåôáé ôùí áíùôÝñù.
12. Áðü ôçí Ýíáñîç éó÷ýïò ôïõ ðáñüíôïò íüìïõ êáôáñãïýíôáé ôá Üñèñá 1 Ýùò êáé 4 ôïõ Í. 2840/2000, ï Í.
2246/1994, üðùò éó÷ýåé, ðëçí ôùí äéáôÜîåþí ôïõ ðïõ áöïñïýí ôïí ôïìÝá ðáñï÷Þò ôá÷õäñïìéêþí õðçñåóéþí,
êáèþò êáé êÜèå Üëëç ãåíéêÞ Þ åéäéêÞ äéÜôáîç íüìïõ, ðñïåäñéêïý äéáôÜãìáôïò Þ õðïãñáöÞò áðüöáóçò, ç ïðïßá
áíôßêåéôáé óôéò äéáôÜîåéò ôïõ ðáñüíôïò Þ êáôÜ ôï ìÝñïò
ðïõ ñõèìßæåé êáôÜ äéÜöïñï ôñüðï èÝìáôá ðïõ ñõèìßæïíôáé ìå ôïí ðáñüíôá íüìï. Êáô åîáßñåóç ðáñáìÝíïõí óå
éó÷ý ïé åîÞò äéáôÜîåéò:
á. ¸ùò ôç èÝóç óå éó÷ý áðüöáóçò ôçò Å.Å.Ô.Ô. ìå ôçí ïðïßá íá ïñßæïíôáé ëåðôïìåñþò ôá ôçò õðáãùãÞò óå êáèåóôþò Ãåíéêþí Áäåéþí êáé ôá ôçò Ýêäïóçò Åéäéêþí Áäåéþí,
ôï óôïé÷åßï Å´ ôçò ðáñáãñÜöïõ 4 ôïõ Üñèñïõ ðñþôïõ ôïõ
Í. 2246/1994, ôï óôïé÷åßï Â´ ôçò ðáñáãñÜöïõ 8 ôïõ Üñèñïõ äåýôåñïõ ôïõ Í. 2246/1994, ôï óôïé÷åßï Ó´ ôçò ðáñáãñÜöïõ 4 ôïõ Üñèñïõ ôñßôïõ ôïõ Í. 2246/1994, êáé ïé
3910
ðáñÜãñáöïé 10 êáé 11 ôïõ Üñèñïõ ôñßôïõ ôïõ Í.
2246/1994, üðùò ôñïðïðïéÞèçêå áðü ôï ð.ä. 157/1999.
â. ¸ùò ôç èÝóç óå éó÷ý áðüöáóçò ôçò Å.Å.Ô.Ô. ìå ôçí ïðïßá íá ïñßæïíôáé ïé áêñéâåßò ðñïûðïèÝóåéò Ðáñï÷Þò Áíïéêôïý Äéêôýïõ, ôá ÐáñáñôÞìáôá É êáé ÉÉ ôïõ Í.
2246/1994, üðùò ôñïðïðïéÞèçêáí áðü ôï ð.ä. 156/1999.
ã. ¸ùò ôç èÝóç óå éó÷ý áðüöáóçò ôçò Å.Å.Ô.Ô. ìå ôçí ïðïßá íá ïñßæïíôáé ëåðôïìåñþò ïé üñïé Äéáóýíäåóçò ìåôáîý Äçìüóéùí Ôçëåðéêïéíùíéáêþí Äéêôýùí, ç ðáñÜãñáöïò
3á, ç õðïðáñÜãñáöïò â´ ôïõ óôïé÷åßïõ Ó´ ôçò ðáñáãñÜöïõ 9, ç ðáñÜãñáöïò 12, ç ðáñÜãñáöïò 13 õðïðáñÜãñáöïé 1, 2 êáé 3 êáé ç ðáñÜãñáöïò 14 ôïõ Üñèñïõ ôñßôïõ
ôïõ Í. 2246/1994, üðùò ðñïóôÝèçêáí óå áõôüí ìå ôï ð.ä.
165/1999.
ËïéðÜ ðñïåäñéêÜ äéáôÜãìáôá Þ õðïõñãéêÝò áðïöÜóåéò
ðïõ Ý÷ïõí åêäïèåß âÜóåé åîïõóéïäüôçóçò ôïõ Í. 2246/
1994 äéáôçñïýíôáé óå éó÷ý åöüóïí ïé äéáôÜîåéò ôïõò äåí
áíôßêåéíôáé óôéò äéáôÜîåéò ôïõ ðáñüíôïò íüìïõ.
¢ñèñï 14
Ñõèìßóåéò èåìÜôùí ÅË.ÔÁ. êáé Üëëåò äéáôÜîåéò
1. Áðü ôçí Ýíáñîç éó÷ýïò ôïõ ðáñüíôïò, ôá ÅëëçíéêÜ
Ôá÷õäñïìåßá (ÅË.ÔÁ.) êáé ïé èõãáôñéêÝò åôáéñåßåò áõôþí
(ÊÝíôñï ÅðáããåëìáôéêÞò ÊáôÜñôéóçò Áíþíõìïò Åôáéñåßá
êáé Ôá÷õìåôáöïñÝò ÅË.ÔÁ. Á.Å.) ðáýïõí íá õðÜãïíôáé
óôéò äéáôÜîåéò ðïõ éó÷ýïõí ãéá ôéò åðé÷åéñÞóåéò ðïõ áíÞêïõí óôï äçìüóéï ôïìÝá.
2. Óôçí ðáñÜãñáöï 1 Ã ôïõ Üñèñïõ 9 ôïõ Í. 2801/2000
(ÖÅÊ 46 Á´) ðñïóôßèåíôáé ôá åîÞò åäÜöéá:
«Óôïí Ðñüåäñï êáé ôïõò ÁíôéðñïÝäñïõò ôïõ Äéïéêçôéêïý Óõìâïõëßïõ ôïõ Ôá÷õäñïìéêïý Ôáìéåõôçñßïõ ðáñÝ÷åôáé äéêáßùìá ÷ñÞóçò áõôïêéíÞôïõ, ôï êüóôïò ôçò ïðïßáò âáñýíåé ôïí ðñïûðïëïãéóìü ôïõ Ôá÷õäñïìéêïý Ôáìéåõôçñßïõ. Ãéá ôï óêïðü áõôüí ôï Ôá÷õäñïìéêü
ÔáìéåõôÞñéï äýíáôáé íá ðñïâáßíåé óôç ìßóèùóç áõôïêéíÞôùí Þ óôçí êáôÜñôéóç ÷ñçìáôïäïôéêÞò ìßóèùóçò óýìöùíá ìå ôéò éó÷ýïõóåò äéáôÜîåéò.
Åðßóçò, ïé áíùôÝñù äýíáíôáé íá åîõðçñåôïýíôáé ìå õðçñåóéáêÜ áõôïêßíçôá ôïõ Ôá÷õäñïìéêïý Ôáìéåõôçñßïõ,
óýìöùíá ìå ôá ïñéæüìåíá óôéò äéáôÜîåéò ôïõ Í.Ä.
2396/1953 (ÖÅÊ 117 Á´) üðùò Ýêôïôå éó÷ýåé.
Ìåôáîý ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí
êáé ôïõ ÐñïÝäñïõ ôïõ Ôá÷õäñïìéêïý Ôáìéåõôçñßïõ êáé
ìåôáîý ôïõ ÐñïÝäñïõ êáé ôùí ÁíôéðñïÝäñùí ôïõ Ôá÷õäñïìéêïý Ôáìéåõôçñßïõ óõíÜðôïíôáé óõìâÜóåéò, ìå ôéò ïðïßåò åîåéäéêåýïíôáé êáé ðñïóäéïñßæïíôáé ôá äéêáéþìáôá
êáé ïé õðï÷ñåþóåéò ðïõ áðïññÝïõí áðü ôçí éó÷ýïõóá íïìïèåóßá, êáèþò êáé ïé óôü÷ïé ðïõ áíáëáìâÜíïõí íá õëïðïéÞóïõí êáôÜ ôç äéÜñêåéá ôçò èçôåßáò ôïõò.
Ïé óõìâÜóåéò äýíáíôáé íá êáôáããåëèïýí ìå áðïöÜóåéò
ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, áí äéáðéóôùèïýí áðïêëßóåéò áðü ôïõò üñïõò ðïõ Ý÷ïõí ôåèåß Þ áêüìç êáé ãéá ôïõò åéäéêïýò ëüãïõò ðïõ áíáöÝñïíôáé óå
áõôÝò.»
3.á. Ï ðñþôïò óôß÷ïò ôçò ðáñáãñÜöïõ 2 ôïõ Üñèñïõ 7
ôïõ Í. 2669/1998 (ÖÅÊ 283 Á´) «åíôüò ôñéþí (3) ìçíþí áðü ôçí Ýãêñéóç ôïõ ó÷åäßïõ ëåéôïõñãßáò» áíôéêáèßóôáôáé
ùò áêïëïýèùò: «ìÝ÷ñé ôçí 31.12.2000».
â. Óôï Í. 2669/1998 ðñïóôßèåôáé Üñèñï 7Á ùò áêïëïýèùò:
«¢ñèñï 7Á
1. Óå èõãáôñéêÞ åôáéñßá ðïõ èá óõóôáèåß áðü ôçí åôáé-
ñßá ÁÔÔÉÊÏ ÌÅÔÑÏ Á.Å. åíôüò äýï (2) ìçíþí áðü ôç äçìïóßåõóç ôïõ ðáñüíôïò êáé èá äéÝðåôáé áðü ôéò äéáôÜîåéò
ôïõ Üñèñïõ ðñþôïõ ðáñÜãñáöïé 2 êáé 3 ôïõ Í. 1955/1991
(ÖÅÊ 112 Á´), áíáôßèåôáé ç ìåëÝôç, åðßâëåøç, êáôáóêåõÞ,
äçìïðñÜôçóç, ðñïìÞèåéá, ïñãÜíùóç, äéá÷åßñéóç êáé åêìåôÜëëåõóç äéêôýïõ áóôéêþí ôñï÷éïäñüìùí ôñáì, êáèþò êáé ôùí áíáãêáßùí ðñïò ôïýôï åãêáôáóôÜóåùí, ï÷çìÜôùí êáé ôùí åí ãÝíåé õëéêþí êáé ìÝóùí. Ç åôáéñßá áõôÞ
åðïðôåýåôáé áðü ôïí Õðïõñãü Ìåôáöïñþí êáé Åðéêïéíùíéþí.
2. Óôçí åôáéñßá áõôÞí åöáñìüæïíôáé áíáëüãùò êáé ïé
äéáôÜîåéò ôùí Üñèñùí Ýêôïõ ðáñ. 2, Ýâäïìïõ ðáñÜãñáöïé 2, 3, 4, 5 êáé 6, ïãäüïõ, åíÜôïõ ðáñÜãñáöïé 2, 3, êáé 4
êáé äåêÜôïõ ôïõ Í. 1955/1991. ¼ðïõ óôéò åí ëüãù äéáôÜîåéò ðñïâëÝðåôáé áðüöáóç, åðïðôåßá Þ Üëëçò ìïñöÞò åíÝñãåéá ôïõ Õðïõñãïý ÐåñéâÜëëïíôïò, ×ùñïôáîßáò êáé
Äçìüóéùí ¸ñãùí, áõôÞ ëáìâÜíåôáé, áóêåßôáé Þ äéåíåñãåßôáé áðü ôïí Õðïõñãü Ìåôáöïñþí êáé Åðéêïéíùíéþí, åêôüò
ôùí ïéêïäïìéêþí áäåéþí êáé ôùí áðïöÜóåùí åðß ôùí áéôÞóåùí èåñáðåßáò åðß ôùí ïðïßùí ç áñìïäéüôçôá áíÞêåé
óôïí Õðïõñãü ÐåñéâÜëëïíôïò, ×ùñïôáîßáò êáé Äçìüóéùí
¸ñãùí.
3. Ãéá ôç äçìïðñÜôçóç êáé áíÜèåóç ôùí Ýñãùí ôçò åôáéñßáò åðéôñÝðåôáé íá åöáñìüæïíôáé áíáëüãùò êáé ïé
äéáôÜîåéò ôùí Üñèñùí 8 êáé 9 ôïõ Í. 2052/1992 (ÖÅÊ 94
Á´).
4. Ïé äéáôÜîåéò ôùí Üñèñùí 6, 7, 8, 9, 10, 11, 12, 13 êáé
14 ôïõ Í. 2730/1999 «Ó÷åäéáóìüò ãéá ôçí ïëïêëçñùìÝíç
áíÜðôõîç êáé åêôÝëåóç Ïëõìðéáêþí ¸ñãùí êáé Üëëåò
äéáôÜîåéò» (ÖÅÊ 130 Á´), üðùò áõôÝò êÜèå öïñÜ éó÷ýïõí,
Ý÷ïõí åöáñìïãÞ óôçí åôáéñßá ÁÔÔÉÊÏ ÌÅÔÑÏ Á.Å. êáé
óôéò èõãáôñéêÝò áõôÞò».
ã. Óôï Üñèñï äÝêáôï ôïõ Í. 1955/1991 ðñïóôßèåôáé íÝá
ðáñÜãñáöïò 8, ùò åîÞò:
«8. Ç Åôáéñåßá äýíáôáé íá áðáëëïôñéþíåé éäéïêôçóßåò
ðñïêåéìÝíïõ íá êáôáóêåõÜóåé óå áõôÝò ÷þñïõò óôÜèìåõóçò ëåùöïñåßùí (áóôéêþí Þ õðåñáóôéêþí), ïé ïðïßïé
åßíáé óå ëåéôïõñãéêÞ åíüôçôá ìå ôéò åãêáôáóôÜóåéò ôïõ õðüãåéïõ çëåêôñéêïý óéäçñüäñïìïõ ôïõ Íïìïý ÁôôéêÞò.
Ôá Ýñãá áõôÜ ÷áñáêôçñßæïíôáé ùò Ýñãá ðñïöáíïýò äçìüóéáò Þ êïéíÞò ùöÝëåéáò. ÊáôÜ ôá ëïéðÜ éó÷ýïõí êáé óôéò
áðáëëïôñéþóåéò áõôÝò ïé äéáôÜîåéò ôïõ ðáñüíôïò Üñèñïõ».
4. ÅðéöõëáóóïìÝíùí ôùí äéáôÜîåùí ôçò ðáñ. 8 ôïõ Üñèñïõ 34 ôïõ Í.2696/1999 «Êýñùóç ôïõ Êþäéêá ÏäéêÞò
Êõêëïöïñßáò» (ÖÅÊ 57 Á´) åðéôñÝðåôáé ç ìßóèùóç, áðü
ôïí Ïñãáíéóìü Áóôéêþí Óõãêïéíùíéþí Áèçíþí, ï÷çìÜôùí
åðé÷åéñÞóåùí ÏäéêÞò ÂïÞèåéáò, ãéá ôçí áðïìÜêñõíóç
ôùí ðáñáíüìùò óôáèìåõìÝíùí ï÷çìÜôùí, êáô åöáñìïãÞ ôùí äéáôÜîåùí ôçò ðåñßðôùóçò êá´ ôçò ðáñ. 1 ôïõ Üñèñïõ 2 ôïõ Í. 2669/1998 (ÖÅÊ 283 Á´).
¢ñèñï 15
1. ÖïñôçãÜ áõôïêßíçôá éäéùôéêÞò ÷ñÞóçò ìéêôïý âÜñïõò êÜôù ôùí ôåóóÜñùí ÷éëéÜäùí (4.000) ÷éëéïãñÜììùí,
ôùí ïðïßùí ïé éäéïêôÞôåò êáôÝ÷ïõí Üäåéá ðáñáãùãïý Þ
êáé ðùëçôÞ ëáúêþí áãïñþí, åîáéñïýíôáé ôùí ðåñéïñéóìþí
êõêëïöïñßáò óôéò ðåñéï÷Ýò ôùí Íïìáñ÷éáêþí ÁõôïäéïéêÞóåùí ÁèÞíáò êáé Èåóóáëïíßêçò, ðïõ êáèïñßóôçêáí ìå
ôéò äéáôÜîåéò ôçò ðåñßðôùóçò á´ ôçò ðáñ. 1 ôïõ Üñèñïõ 1
ôïõ Í. 1108/1980 (ÖÅÊ 304 Á´), åöüóïí ìåôáöÝñïõí ðñïúüíôá ãéá ðþëçóç óôéò ëáúêÝò áãïñÝò.
Ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí ÐåñéâÜëëïíôïò, ×ù-
3911
ñïôáîßáò êáé Äçìüóéùí ¸ñãùí êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí ðñïóäéïñßæåôáé ç ôå÷íïëïãßá êáé ç çëéêßá ôùí
öïñôçãþí áõôïêéíÞôùí ãéá ôá ïðïßá èá éó÷ýåé ç ðáñáðÜíù ñýèìéóç.
2. Ôï Üñèñï 2 ôïõ Í. 2465/1997 (ÖÅÊ 28 Á´) áíôéêáèßóôáôáé ùò åîÞò:
ÐáñáããÝëëïìå ôç äçìïóßåõóç ôïõ ðáñüíôïò óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò êáé ôçí åêôÝëåóÞ ôïõ ùò Íüìïõ ôïõ ÊñÜôïõò.
«¢ñèñï 2
ÊÙÍÓÔÁÍÔÉÍÏÓ ÓÔÅÖÁÍÏÐÏÕËÏÓ
Ìå êïéíÞ áðüöáóç ôùí Õðïõñãþí ÐåñéâÜëëïíôïò ×ùñïôáîßáò êáé Äçìüóéùí ¸ñãùí êáé Ìåôáöïñþí êáé Åðéêïéíùíéþí êáèïñßæïíôáé ïé ëåðôïìÝñåéåò ôçò äéåíÝñãåéáò
ôïõ ôå÷íéêïý åëÝã÷ïõ ôùí ìåôá÷åéñéóìÝíùí, ìå ðñïçãïýìåíç êõêëïöïñßá óå ÊñÜôïò-ÌÝëïò ôçò ÅõñùðáúêÞò ¸íùóçò êáé ôïõ Åõñùðáúêïý Ïéêïíïìéêïý ×þñïõ (Å.Ï.×.),
öïñôçãþí áõôïêéíÞôùí ìéêôïý âÜñïõò Üíù ôùí 4 ôüííùí
êáé ëåùöïñåßùí ìéêôïý âÜñïõò Üíù ôùí 3,5 ôüííùí, ðñéí
áðü ôç ÷ïñÞãçóç ðñþôçò Üäåéáò êõêëïöïñßáò óôç ×þñá
ìáò. ÌÝ÷ñé ôçí Ýêäïóç ôçò ðáñáðÜíù áðüöáóçò, ï õðüøç ôå÷íéêüò Ýëåã÷ïò ôùí ðáñáðÜíù êáôçãïñéþí áõôïêéíÞôùí èá ãßíåôáé óýìöùíá ìå ôéò éó÷ýïõóåò äéáôÜîåéò».
¢ñèñï 16
¸íáñîç éó÷ýïò
Ç éó÷ýò ôïõ ðáñüíôïò íüìïõ áñ÷ßæåé ôçí 1ç Éáíïõáñßïõ
2001, ðëçí ôùí Üñèñùí 4, 10, 14 êáé 15, ç éó÷ýò ôùí ïðïßùí áñ÷ßæåé áðü ôç äçìïóßåõóç ôïõ ðáñüíôïò óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò.
ÁèÞíá, 15 Äåêåìâñßïõ 2000
Ï ÐÑÏÅÄÑÏÓ ÔÇÓ ÄÇÌÏÊÑÁÔÉÁÓ
ÏÉ ÕÐÏÕÑÃÏÉ
ÅÓÙÔÅÑÉÊÙÍ, ÄÇÌÏÓÉÁÓ
ÄÉÏÉÊÇÓÇÓ ÊÁÉ ÁÐÏÊÅÍÔÑÙÓÇÓ
Â. ÐÁÐÁÍÄÑÅÏÕ
ÅÈÍÉÊÇÓ ÁÌÕÍÁÓ
ÁÐ.-ÁÈ. ÔÓÏ×ÁÔÆÏÐÏÕËÏÓ
ÅÈÍÉÊÇÓ ÏÉÊÏÍÏÌÉÁÓ
ÊÁÉ ÏÉÊÏÍÏÌÉÊÙÍ
ÁÍÁÐÔÕÎÇÓ
ÃÉÁÍ. ÐÁÐÁÍÔÙÍÉÏÕ
ÍÉÊ. ×ÑÉÓÔÏÄÏÕËÁÊÇÓ
ÐÅÑÉÂÁËËÏÍÔÏÓ, ×ÙÑÏÔÁÎÉÁÓ
ÊÁÉ ÄÇÌÏÓÉÙÍ ÅÑÃÙÍ
ÄÉÊÁÉÏÓÕÍÇÓ
ÊÙÍ/ÍÏÓ ËÁËÉÙÔÇÓ ÌÉ×.-ÊÙÍ/ÍÏÓ ÓÔÁÈÏÐÏÕËÏÓ
ÌÅÔÁÖÏÑÙÍ ÊÁÉ
ÅÐÉÊÏÉÍÙÍÉÙÍ
ÔÕÐÏÕ ÊÁÉ ÌÅÓÙÍ
ÌÁÆÉÊÇÓ ÅÍÇÌÅÑÙÓÇÓ
×Ñ. ÂÅÑÅËÇÓ
Ä. ÑÅÐÐÁÓ
ÈåùñÞèçêå êáé ôÝèçêå ç ÌåãÜëç Óöñáãßäá ôïõ ÊñÜôïõò
AèÞíá, 15 Äåêåìâñßïõ 2000
Ï ÅÐÉ ÔÇÓ ÄÉÊÁÉÏÓÕÍÇÓ ÕÐÏÕÑÃÏÓ
ÌÉ×. ÓÔÁÈÏÐÏÕËÏÓ
3912
ÅÈÍÉÊÏ ÔÕÐÏÃÑÁÖÅÉÏ
ÅÖÇÌÅÑÉÄÁ ÔÇÓ ÊÕÂÅÑÍÇÓÅÙÓ
ÊÁÐÏÄÉÓÔÑÉÏÕ 34 * ÁÈÇÍÁ 104 32 * TELEX 223211 YPET GR * FAX 52 34 312
ÇËÅÊÔÑÏÍÉÊÇ ÄÉÅÕÈÕÍÓÇ: http: www.et.gr
e-mail: webmaster @ et.gr
ÕÐÇÑÅÓÉÅÓ ÅÎÕÐÇÑÅÔÇÓÇÓ ÐÏËÉÔÙÍ
ÊÅÍÔÑÉÊÇ ÕÐÇÑÅÓÉÁ
ÐÅÑÉÖÅÑÅÉÁÊÁ ÃÑÁÖÅÉÁ
Óïëùìïý 51
Ðëçñïöïñßåò äçìïóéåõìÜôùí Á.Å. - Å.Ð.Å.
Ðëçñïöïñßåò äçìïóéåõìÜôùí ëïéðþí Ö.Å.Ê.
Ðþëçóç Ö.Å.Ê.
Öùôïáíôßãñáöá ðáëáéþí Ö.Å.Ê.
ÂéâëéïèÞêç ðáëáéþí Ö.Å.Ê.
Ïäçãßåò ãéá äçìïóéåýìáôá Á.Å. - Å.Ð.Å.
ÅããñáöÞ Óõíäñïìçôþí Ö.Å.Ê. êáé
áðïóôïëÞ Ö.Å.Ê.
ÐÙËÇÓÇÓ Ö.Å.Ê.
5225 761 - 5230 841
5225 713 - 5249 547
5239 762
5248 141
5248 188
5248 785
5248 320
ÈÅÓÓÁËÏÍÉÊÇ - Âáó. ¼ëãáò 227 - Ô.Ê. 54100
ÐÅÉÑÁÉÁÓ - ÍéêÞôá 6-8 Ô.Ê. 185 31
ÐÁÔÑÁ - Êïñßíèïõ 327 - Ô.Ê. 262 23
ÉÙÁÍÍÉÍÁ - ÄéïéêçôÞñéï Ô.Ê. 450 44
ÊÏÌÏÔÇÍÇ - Äçìïêñáôßáò 1 Ô.Ê. 691 00
ËÁÑÉÓÁ - ÄéïéêçôÞñéï Ô.Ê. 411 10
ÊÅÑÊÕÑÁ - ÓáìáñÜ 13 Ô.Ê. 491 00
ÇÑÁÊËÅÉÏ - Ðë. Åëåõèåñßáò 1, Ô.Ê. 711 10
ËÅÓÂÏÓ - Ðë. Êùíóôáíôéíïõðüëåùò
Ô.Ê. 811 00 MõôéëÞíç
(031) 423 956
4135 228
(061) 6381 100
(0651) 87215
(0531) 22 858
(041) 597449
(0661) 89 127 / 89 120
(081) 396 223
(0251) 46 888 / 47 533
ÔÉÌÇ ÐÙËÇÓÇÓ ÖÕËËÙÍ ÅÖÇÌÅÑÉÄÏÓ ÔÇÓ ÊÕÂÅÑÍÇÓÅÙÓ
Ãéá ôá ÖÅÊ áðü 1 ìÝ÷ñé 8 óåëßäåò 200 äñ÷.
Ãéá ôá ÖÅÊ áðü 8 óåëßäåò êáé ðÜíù ç ôéìÞ ðþëçóçò êÜèå öýëëïõ (8óÝëéäïõ Þ ìÝñïõò áõôïý) ðñïóáõîÜíåôáé êáôÜ 100 äñ÷. áíÜ 8óÝëéäï Þ ìÝñïò áõôïý.
Ãéá ôá ÖÅÊ ôïõ Ôåý÷ïõò Ðñïêçñýîåùí Á.Ó.Å.Ð. áíåîáñôÞôùò áñéèìïý óåëßäùí äñ÷. 100. (Óå ðåñßðôùóç ÐáíåëëÞíéïõ Äéáãùíéóìïý ç ôéìÞ èá ðñïóáõîÜíåôáé êáôÜ äñ÷. 100 áíÜ 8óÝëéäï Þ ìÝñïò áõôïý).
ÅÔÇÓÉÅÓ ÓÕÍÄÑÏÌÅÓ Ö.Å.Ê.
Ôåý÷ïò
Ê.Á.Å. Ðñïûðïëïãéóìïý
2531
Á~ (Íüìïé, Ð.Ä., ÓõìâÜóåéò ê.ëð.)
Â~ (ÕðïõñãéêÝò áðïöÜóåéò ê.ëð.)
Ã~ (Äéïñéóìïß, áðïëýóåéò ê.ëð. Äçì. ÕðáëëÞëùí)
Ä~ (Áðáëëïôñéþóåéò, ðïëåïäïìßá ê.ëð.)
Áíáðôõîéáêþí ÐñÜîåùí (Ô.Á.Ð.Ó.)
Í.Ð.Ä.Ä. (Äéïñéóìïß ê.ëð. ðñïóùðéêïý Í.Ð.Ä.Ä.)
ÐáñÜñôçìá (Ðñïêçñýîåéò èÝóåùí ÄÅÐ ê.ôë.)
Äåëôßï Âéïìç÷áíéêÞò Éäéïêôçóßáò (Ä.Å.Â.É.)
ÁíùôÜôïõ Åéäéêïý Äéêáóôçñßïõ (Á.Å.Ä.)
Ðñïêçñýîåùí Á.Ó.Å.Ð.
Áíùíýìùí Åôáéñåéþí & Å.Ð.Å.
Äéáêçñýîåùí Äçìïóßùí ÓõìâÜóåùí (Ä.Ä.Ó.)
60.000 äñ÷.
70.000
»
15.000 »
70.000 »
30.000 »
15.000 »
5.000 »
10.000 »
3.000 »
10.000 »
300.000 »
50.000 »
3.000 äñ÷.
3.500
»
750
»
3.500
»
1.500
»
750
»
250
»
500
»
150
»
500
»
15.000
»
2.500
»
ÃÉÁ ÏËÁ ÔÁ ÔÅÕ×Ç ÅÊÔÏÓ Á.Å. & Å.Ð.Å.
300.000
15.000
»
Ê.Á.Å. åóüäïõ õðÝñ
ÔÁÐÅÔ 3512
»
* Ïé óõíäñïìÝò ôïõ åóùôåñéêïý ðñïðëçñþíïíôáé óôá Äçìüóéá Ôáìåßá ðïõ äßíïõí áðïäåéêôéêü åßóðñáîçò (äéðëüôõðï) ôï ïðïßï
ìå ôç öñïíôßäá ôïõ åíäéáöåñïìÝíïõ ðñÝðåé íá óôÝëíåôáé óôçí Õðçñåóßá ôïõ Åèíéêïý Ôõðïãñáöåßïõ.
* Ïé óõíäñïìÝò ôïõ åîùôåñéêïý åðéâáñýíïíôáé ìå ôï äéðëÜóéï ôùí áíùôÝñù ôéìþí.
* Ç ðëçñùìÞ ôïõ õðÝñ ÔÁÐÅÔ ðïóïóôïý ðïõ áíôéóôïé÷åß óå óõíäñïìÝò, åéóðñÜôôåôáé áðü ôá Äçìüóéá Ôáìåßá.
* Ïé óõíäñïìçôÝò ôïõ åîùôåñéêïý ìðïñïýí íá óôÝëíïõí ôï ðïóü ôïõ ÔÁÐÅÔ ìáæß ìå ôï ðïóü ôçò óõíäñïìÞò.
* Ïé Íïìáñ÷éáêÝò ÁõôïäéïéêÞóåéò, ïé ÄÞìïé, ïé Êïéíüôçôåò ùò êáé ïé åðé÷åéñÞóåéò áõôþí ðëçñþíïõí ôï ìéóü ÷ñçìáôéêü ðïóü ôçò
óõíäñïìÞò êáé ïëüêëçñï ôï ðïóü õðÝñ ôïõ ÔÁÐÅÔ.
* Ç óõíäñïìÞ éó÷ýåé ãéá Ýíá ÷ñüíï, ðïõ áñ÷ßæåé ôçí 1ç Éáíïõáñßïõ êáé ëÞãåé ôçí 31ç Äåêåìâñßïõ ôïõ ßäéïõ ÷ñüíïõ.
Äåí åããñÜöïíôáé óõíäñïìçôÝò ãéá ìéêñüôåñï ÷ñïíéêü äéÜóôçìá.
* Ç åããñáöÞ Þ áíáíÝùóç ôçò óõíäñïìÞò ðñáãìáôïðïéåßôáé ôï áñãüôåñï ìÝ÷ñé ôïí ÌÜñôéï êÜèå Ýôïõò.
* Áíôßãñáöá äéðëïôýðùí, ôá÷õäñïìéêÝò åðéôáãÝò êáé ÷ñçìáôéêÜ ãñáììÜôéá äåí ãßíïíôáé äåêôÜ.
Ïé õðçñåóßåò åîõðçñÝôçóçò ôùí ðïëéôþí ëåéôïõñãïýí êáèçìåñéíÜ áðü 08.00~ Ýùò 13.00~
ÁÐÏ ÔÏ ÅÈÍÉÊÏ ÔÕÐÏÃÑÁÖÅÉÏ
F
2061
ÅÖÇÌÅÑÉÓ ÔÇÓ ÊÕÂÅÑÍÇÓÅÙÓ
Áñ. Öýëëïõ 125
ÔÅÕ×ÏÓ ÐÑÙÔÏ
25 Éïõíßïõ 2001
ÐÑÏÅÄÑÉÊÏ ÄÉÁÔÁÃÌÁ ÕÐ ÁÑÉÈ. 150
ÐñïóáñìïãÞ óôçí Ïäçãßá 99/93/ÅÊ ôïõ Åõñùðáúêïý Êïéíïâïõëßïõ êáé ôïõ Óõìâïõëßïõ ó÷åôéêÜ ìå ôï êïéíïôéêü ðëáßóéï ãéá çëåêôñïíéêÝò õðïãñáöÝò.
Ï ÐÑÏÅÄÑÏÓ
´Å÷ïíôáò õðüøç:
1. Ôéò äéáôÜîåéò:
á) Ôïõ Üñèñïõ 3 ôïõ N. 1338/1983 «ÅöáñìïãÞ ôïõ Êïéíïôéêïý Äéêáßïõ» (Á´ 34), üðùò áíôéêáôáóôÜèçêå ìå ôï Üñèñï 65
ôïõ Í. 1892/1990(Á´ 101) «Ãéá ôïí åêóõã÷ñïíéóìü êáé ôçí áíÜðôõîç êáé Üëëåò äéáôÜîåéò» .
â) Ôïõ Üñèñïõ 4 ôïõ áõôïý N. 1338/1983, üðùò áíôéêáôáóôÜèçêå ìå ôçí ðáñÜãñáöï 4 ôïõ Üñèñïõ 6 ôïõ Í.1440/1984
(Á´ 70) «Óõììåôï÷Þ ôçò ÅëëÜäïò óôï êåöÜëáéï, ôá áðïèåìáôéêÜ êáé ôéò ðñïâëÝøåéò ôçò ÅõñùðáúêÞò ÔñÜðåæáò Åðåíäýóåùí, óôï êåöÜëáéï ôçò ÅõñùðáúêÞò Êïéíüôçôáò ¢íèñáêïò
êáé ×Üëõâïò êáé ôïõ Ïñãáíéóìïý ÅÕÑÁÔÏÌ» êáé ôñïðïðïéÞèçêå ìå ôï Üñèñï 22 ôïõ Í. 2789/2000 (Á´ 21).
2. Ôéò äéáôÜîåéò ôïõ äåýôåñïõ Üñèñïõ ôïõ Í. 2077/1992
«Êýñùóç ôçò ÓõíèÞêçò ãéá ôçí ÅõñùðáúêÞ ´Åíùóç êáé ôùí
ó÷åôéêþí ðñùôïêüëëùí êáé äçëþóåùí ðïõ ðåñéëáìâÜíïíôáé
óôçí ÔåëéêÞ ÐñÜîç» (Á´ 136).
3. Ôéò äéáôÜîåéò ôïõ Üñèñïõ 29 Á´ ôïõ Í. 1558/ 1985(Á´ 137)
ôï ïðïßï ðñïóôÝèçêå ìå ôï Üñèñï 27 ôïõ Í. 2081/1992 (Á´
154) êáé áíôéêáôáóôÜèçêå ìå ôçí ðáñ. 2á ôïõ Üñèñïõ 1 ôïõ Í.
2469/1997 (Á´ 38).
4. Ôéò äéáôÜîåéò ôïõ Í. 2867/2000 (Á´ 273) «ÏñãÜíùóç êáé
ëåéôïõñãßá ôùí ôçëåðéêïéíùíéþí êáé Üëëåò äéáôÜîåéò»..
5. Ôéò äéáôÜîåéò ôïõ Í. 2672/98 (Á´ 290) «Ïéêïíïìéêïß ðüñïé
ôçò Íïìáñ÷éáêÞò Áõôïäéïßêçóçò êáé Üëëåò äéáôÜîåéò».
6. ¼ôé áðü ôçí åöáñìïãÞ ôïõ ðáñüíôïò ÄéáôÜãìáôïò äåí
ðñïêáëåßôáé äáðÜíç óå âÜñïò ôïõ Êñáôéêïý Ðñïûðïëïãéóìïý.
7. Ôçí õð' áñéèì. 98/2001 ãíùìïäüôçóç ôïõ Óõìâïõëßïõ
ôçò Åðéêñáôåßáò ìåôÜ áðü ðñüôáóç ôùí Õðïõñãþí Åóùôåñéêþí, Äçìüóéáò Äéïßêçóçò êáé ÁðïêÝíôñùóçò, ÅèíéêÞò Ïéêïíïìßáò, Äéêáéïóýíçò êáé ôïõ Õðïõñãïý Ìåôáöïñþí êáé Åðéêïéíùíéþí, áðïöáóßæïõìå:
¢ñèñï 1
Óêïðüò êáé Ðåäßï ÅöáñìïãÞò
1. Ìå ôï ðáñüí ÄéÜôáãìá ðñïóáñìüæåôáé ç åëëçíéêÞ íïìïèåóßá ðñïò ôéò äéáôÜîåéò ôçò Ïäçãßáò 99/93/ÅÊ ôïõ Åõñùðáúêïý Êïéíïâïõëßïõ êáé ôïõ Óõìâïõëßïõ ôçò 13çò Äåêåì-
âñßïõ 1999 « Ó÷åôéêÜ ìå ôï êïéíïôéêü ðëáßóéï ãéá çëåêôñïíéêÝò õðïãñáöÝò» (EEL 13/19.1.2000) óôï åîÞò: Ïäçãßá.
2. Ïé äéáôÜîåéò ôïõ ðáñüíôïò ÄéáôÜãìáôïò äåí èßãïõí äéáôÜîåéò ðïõ, áíáöïñéêÜ ìå ôç óýíáøç êáé ôçí éó÷ý óõìâÜóåùí
Þ åí ãÝíåé ôç óýóôáóç íïìéêþí õðï÷ñåþóåùí, åðéâÜëëïõí ôç
÷ñÞóç ïñéóìÝíïõ ôýðïõ, ïýôå äéáôÜîåéò ãéá ôçí áðïäåéêôéêÞ
Þ Üëëç ÷ñÞóç åããñÜöùí Þ äéáôÜîåéò ìå ôéò ïðïßåò áðáãïñåýåôáé íá äéáêéíïýíôáé êáé íá êáèßóôáíôáé ãíùóôÜ Ýããñáöá
ïñéóìÝíùí êáôçãïñéþí êáé äåäïìÝíá ðñïóùðéêïý ÷áñáêôÞñá.
¢ñèñï 2
Ïñéóìïß
Ãéá ôçí åöáñìïãÞ ôïõ ðáñüíôïò ÄéáôÜãìáôïò íïïýíôáé ùò:
1. «çëåêôñïíéêÞ õðïãñáöÞ»: äåäïìÝíá óå çëåêôñïíéêÞ
ìïñöÞ, ôá ïðïßá åßíáé óõíçììÝíá óå Üëëá çëåêôñïíéêÜ äåäïìÝíá Þ óõó÷åôßæïíôáé ëïãéêÜ ìå áõôÜ êáé ôá ïðïßá ÷ñçóéìåýïõí ùò ìÝèïäïò áðüäåéîçò ôçò ãíçóéüôçôáò.
2. «ðñïçãìÝíç çëåêôñïíéêÞ õðïãñáöÞ»Þ «øçöéáêÞ õðïãñáöÞ»: çëåêôñïíéêÞ õðïãñáöÞ, ðïõ ðëçñïß ôïõò åîÞò
üñïõò:
á) óõíäÝåôáé ìïíïóÞìáíôá ìå ôïí õðïãñÜöïíôá,
â) åßíáé éêáíÞ íá êáèïñßóåé åéäéêÜ êáé áðïêëåéóôéêÜ ôçí ôáõôüôçôá ôïõ õðïãñÜöïíôïò,
ã) äçìéïõñãåßôáé ìå ìÝóá ôá ïðïßá ï õðïãñÜöùí ìðïñåß íá
äéáôçñÞóåé õðü ôïí áðïêëåéóôéêü ôïõ Ýëåã÷ï êáé
ä) óõíäÝåôáé ìå ôá äåäïìÝíá óôá ïðïßá áíáöÝñåôáé êáôÜ
ôñüðï, þóôå íá ìðïñåß íá åíôïðéóèåß ïðïéáäÞðïôå ìåôáãåíÝóôåñç áëëïßùóç ôùí åí ëüãù äåäïìÝíùí.
3. «õðïãñÜöùí»: öõóéêü Þ íïìéêü ðñüóùðï, ðïõ êáôÝ÷åé
äéÜôáîç äçìéïõñãßáò õðïãñáöÞò êáé åíåñãåß åßôå óôï äéêü
ôïõ üíïìá åßôå óôï üíïìá Üëëïõ öõóéêïý Þ íïìéêïý ðñïóþðïõ Þ öïñÝá.
4. «äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò»: ìïíïóÞìáíôá äåäïìÝíá, üðùò êþäéêåò Þ éäéùôéêÜ êëåéäéÜ êñõðôïãñáößáò,
ðïõ ÷ñçóéìïðïéïýíôáé áðü ôïí õðïãñÜöïíôá ãéá ôç äçìéïõñãßá çëåêôñïíéêÞò õðïãñáöÞò.
5. «äéÜôáîç äçìéïõñãßáò õðïãñáöÞò»: äéáôåôáãìÝíï õëéêü
Þ ëïãéóìéêü ðïõ ÷ñçóéìïðïéåßôáé ãéá ôçí åöáñìïãÞ ôùí äåäïìÝíùí äçìéïõñãßáò ôçò õðïãñáöÞò.
6. «áóöáëÞò äéÜôáîç äçìéïõñãßáò õðïãñáöÞò» äéÜôáîç
äçìéïõñãßáò õðïãñáöÞò, ðïõ ðëçñïß ôïõò üñïõò ôïõ ÐáñáñôÞìáôïò ÉÉÉ.
7. «äåäïìÝíá åðáëÞèåõóçò õðïãñáöÞò»: äåäïìÝíá, üðùò
êþäéêåò, Þ äçìüóéá êëåéäéÜ êñõðôïãñáößáò, ôá ïðïßá ÷ñçóéìïðïéïýíôáé ãéá ôçí åðáëÞèåõóç ôçò çëåêôñïíéêÞò õðïãñáöÞò.
2062
8. «äéÜôáîç åðáëÞèåõóçò õðïãñáöÞò»: äéáôåôáãìÝíï õëéêü Þ ëïãéóìéêü, ðïõ ÷ñçóéìïðïéåßôáé ãéá ôçí åöáñìïãÞ ôùí
äåäïìÝíùí åðáëÞèåõóçò õðïãñáöÞò.
9. «ðéóôïðïéçôéêü»: çëåêôñïíéêÞ âåâáßùóç, ç ïðïßá óõíäÝåé äåäïìÝíá åðáëÞèåõóçò õðïãñáöÞò ìå Ýíá Üôïìï êáé åðéâåâáéþíåé ôçí ôáõôüôçôÜ ôïõ.
10. «áíáãíùñéóìÝíï ðéóôïðïéçôéêü»: ðéóôïðïéçôéêü ðïõ
ðëçñïß ôïõò üñïõò ôïõ ÐáñáñôÞìáôïò É êáé åêäßäåôáé áðü
ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò, ï ïðïßïò ðëçñïß ôïõò ïñéæüìåíïõò óôï ÐáñÜñôçìá ÉÉ üñïõò.
11. «ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò»: öõóéêü Þ íïìéêü
ðñüóùðï Þ Üëëïò öïñÝáò, ðïõ åêäßäåé ðéóôïðïéçôéêÜ Þ ðáñÝ÷åé Üëëåò õðçñåóßåò, óõíáöåßò ìå ôéò çëåêôñïíéêÝò õðïãñáöÝò.
12. «ðñïúüí çëåêôñïíéêÞò õðïãñáöÞò»: õëéêü Þ ëïãéóìéêü
Þ óõíáöÞ óõóôáôéêÜ óôïé÷åßá ôïõò, ðïõ ðñïïñßæïíôáé ðñïò
÷ñÞóç áðü ôïí ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò ãéá ôçí
ðñïóöïñÜ õðçñåóéþí çëåêôñïíéêÞò õðïãñáöÞò Þ ðñïïñßæïíôáé íá ÷ñçóéìïðïéçèïýí ãéá ôç äçìéïõñãßá Þ åðáëÞèåõóç
çëåêôñïíéêþí õðïãñáöþí.
13. «åèåëïíôéêÞ äéáðßóôåõóç»: êÜèå Üäåéá äéáðßóôåõóçò
ôùí çëåêôñïíéêþí äåäïìÝíùí, óôçí ïðïßá ïñßæïíôáé ôá äéêáéþìáôá êáé ïé õðï÷ñåþóåéò, ðïõ äéÝðïõí ôçí ðáñï÷Þ õðçñåóéþí ðéóôïðïßçóçò êáé ç ïðïßá ÷ïñçãåßôáé ýóôåñá áðü áßôçóç ôïõ åíäéáöåñüìåíïõ ðáñü÷ïõ õðçñåóéþí áðü ôïí öïñÝá
ðïõ ðñïâëÝðåôáé óôçí ðáñÜãñáöï 5 ôïõ Üñèñïõ 4 ôïõ ðáñüíôïò.
¢ñèñï 3
¸ííïìåò óõíÝðåéåò ôùí çëåêôñïíéêþí õðïãñáöþí
1. Ç ðñïçãìÝíç çëåêôñïíéêÞ õðïãñáöÞ ðïõ âáóßæåôáé óå
áíáãíùñéóìÝíï ðéóôïðïéçôéêü êáé äçìéïõñãåßôáé áðü áóöáëÞ
äéÜôáîç äçìéïõñãßáò õðïãñáöÞò åðÝ÷åé èÝóç éäéü÷åéñçò õðïãñáöÞò ôüóï óôï ïõóéáóôéêü üóï êáé óôï äéêïíïìéêü äßêáéï.
2. Ç éó÷ýò ôçò çëåêôñïíéêÞò õðïãñáöÞò Þ ôï ðáñáäåêôü
ôçò ùò áðïäåéêôéêïý óôïé÷åßïõ äåí áðïêëåßåôáé áðü ìüíï ôïí
ëüãï üôé äåí óõíôñÝ÷ïõí ïé ðñïûðïèÝóåéò ôçò ðñïçãïýìåíçò ðáñáãñÜöïõ.
¢ñèñï 4
Ðñüóâáóç óôçí áãïñÜ - Áñ÷Ýò ôçò åóùôåñéêÞò áãïñÜò
1. Ôá äéáôéèÝìåíá ðñïúüíôá çëåêôñïíéêÞò õðïãñáöÞò ìðïñåß íá áöïñïýí áóöáëåßò äéáôÜîåéò õðïãñáöÞò Þ êáé ìç
áóöáëåßò äéáôÜîåéò óôïí âáèìü ðïõ áõôü äéáôõðþíåôáé êáôÜ
ôñüðï áðüëõôá óáöÞ ãéá ïðïéïíäÞðïôå ôñßôï ìå ôçí åðéöýëáîç ôïõ Üñèñïõ 3 ôïõ ðáñüíôïò.
2. Ç óõììüñöùóç ôùí áóöáëþí äéáôÜîåùí äçìéïõñãßáò
õðïãñáöÞò ðñïò ôï ÐáñÜñôçìá ÉÉÉ ôïõ ðáñüíôïò ÄéáôÜãìáôïò äéáðéóôþíåôáé áðü ôçí ÅèíéêÞ ÅðéôñïðÞ Ôçëåðéêïéíùíéþí
Ôá÷õäñïìåßùí (Å.Å.Ô.Ô.) (Üñèñï 3 ôïõ í. 2867/2000) Þ áðü
ïñéæüìåíïõò áðü áõôÞí äçìüóéïõò Þ éäéùôéêïýò öïñåßò. Ç
Å.Å.Ô.Ô. êáé ïé ïñéæüìåíïé áðü áõôÞ äçìüóéïé Þ éäéùôéêïß öïñåßò õðï÷ñåïýíôáé óôçí åöáñìïãÞ ôùí åëá÷ßóôùí êñéôçñßùí
ðïõ ðñïâëÝðïíôáé óôçí Áðüöáóç ôçò ÅðéôñïðÞò ôçò
6.11.2000 (Å (2000) 3179 ôåëéêü). Ç óõììüñöùóç ôùí ðñïúüíôùí çëåêôñïíéêÞò õðïãñáöÞò ðñïò áíáãíùñéóìÝíá ðñüôõðá áðïôåëåß ôåêìÞñéï óõììüñöùóçò ìå ôéò áðáéôÞóåéò ðïõ
êáèïñßæïíôáé óôï óçìåßï (óô) ôïõ ÐáñáñôÞìáôïò ÉÉ êáé óôï
ÐáñÜñôçìá ÉÉÉ ôïõ ðáñüíôïò.
3. Ôá ðáñå÷üìåíá ðéóôïðïéçôéêÜ åðáëÞèåõóçò ïñßæïõí ñçôÜ, êáôÜ ôñüðï åýêïëá áíôéëçðôü áðü ìç åéäéêü ôñßôï, áí ðñüêåéôáé ãéá áíáãíùñéóìÝíá Þ ìç áíáãíùñéóìÝíá ðéóôïðïéçôéêÜ.
4. Ìå ôçí åðéöýëáîç ôçò ðáñáãñÜöïõ 5 ôïõ ðáñüíôïò Üñèñïõ, ãéá ôçí ðáñï÷Þ ôùí õðçñåóéþí ðéóôïðïßçóçò ïðïéáóäÞðïôå ìïñöÞò äåí áðáéôåßôáé ç ÷ïñÞãçóç Üäåéáò óôïõò ðáñü÷ïõò ôùí õðçñåóéþí áõôþí.
5. ÐñïêåéìÝíïõ íá åðéôåõ÷èåß âåëôéùìÝíï åðßðåäï ðáñï÷Þò õðçñåóéþí ðéóôïðïßçóçò, ðáñÝ÷åôáé áðü ôçí Å.Å.Ô.Ô. Þ
áðü ïñéæüìåíïõò áðü áõôÞí äçìüóéïõò Þ éäéùôéêïýò öïñåßò,
ýóôåñá áðü Ýããñáöç áßôçóç ôïõ åíäéáöåñüìåíïõ ðáñü÷ïõ
õðçñåóéþí ðéóôïðïßçóçò, åèåëïíôéêÞ äéáðßóôåõóç. Ìå ôçí
åèåëïíôéêÞ äéáðßóôåõóç áðïíÝìïíôáé äéêáéþìáôá êáé åðéâÜëëïíôáé õðï÷ñåþóåéò, óõìðåñéëáìâáíïìÝíùí ôåëþí, óôïí ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò. Ïé ðñïûðïèÝóåéò åèåëïíôéêÞò äéáðßóôåõóçò ðñÝðåé íá åßíáé áíôéêåéìåíéêÝò, äéáöáíåßò,
áíÜëïãåò ìå ôïí åðéäéùêüìåíï óêïðü êáé íá ìçí ïäçãïýí óå
äéáêñßóåéò. Ç Å.Å.Ô.Ô. äåí ìðïñåß íá ðåñéïñßóåé ôïí áñéèìü
ôùí ðáñü÷ùí õðçñåóéþí ðéóôïðïßçóçò, ðïõ åðéèõìïýí ôç
äéáðßóôåõóÞ ôïõò óýìöùíá ìå ôéò äéáôÜîåéò ôïõ ðáñüíôïò.
6. Ïé äéáðéóôåõìÝíïé Þ ìç, ðÜñï÷ïé õðçñåóéþí ðéóôïðïßçóçò, ðïõ ðëçñïýí ôéò ðñïûðïèÝóåéò ôïõ ÐáñáñôÞìáôïò ÉÉ
ôïõ ðáñüíôïò, åêäßäïõí áíáãíùñéóìÝíá ðéóôïðïéçôéêÜ ãéá
ôï êïéíü.
7. Ïé ðÜñï÷ïé õðçñåóéþí ðéóôïðïßçóçò ïöåßëïõí éäéáßôåñá
íá ìåñéìíïýí ãéá ôçí áðü ìÝñïõò ôïõò ôÞñçóç ôùí äéáôÜîåùí ãéá ôçí ðñïóôáóßá ôïõ áíôáãùíéóìïý, ãéá ôïí áèÝìéôï
áíôáãùíéóìü, ãéá ôçí ðíåõìáôéêÞ êáé âéïìç÷áíéêÞ éäéïêôçóßá
êáé ãéá ôçí ðñïóôáóßá ôïõ êáôáíáëùôÞ.
8. Ç Å.Å.Ô.Ô. Ý÷åé ôçí åðïðôåßá êáé ôïí Ýëåã÷ï ôùí åãêáôåóôçìÝíùí óôçí ÅëëÜäá ðáñï÷þí õðçñåóéþí ðéóôïðïßçóçò,
êáèþò êáé ôùí óýìöùíá ìå ôéò ðáñáãñÜöïõò 5 êáé 2 ôïõ ðáñüíôïò öïñÝùí äéáðßóôåõóçò êáé åëÝã÷ïõ ôçò óõììüñöùóçò ôùí õðïãñáöþí ðñïò ôï ðáñÜñôçìá ÉÉÉ.
9. Óå ðåñßðôùóç ðïõ ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò
åíåñãåß ùò äéáðéóôåõìÝíïò ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò, ÷ùñßò íá åßíáé, ç Å.Å.Ô.Ô. åðéâÜëëåé ðñüóôéìï áðü åîÞíôá
÷éëéÜäåò (60.000) Ýùò ôñéáêüóéåò ÷éëéÜäåò (300.000) Åõñþ.
¢ñèñï 5
Äéåèíåßò ðôõ÷Ýò
1. Ç ðñïóöïñÜ õðçñåóéþí ðéóôïðïßçóçò åíôüò ôçò åëëçíéêÞò åðéêñÜôåéáò áðü ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò, ðïõ
åßíáé åãêáôåóôçìÝíïò óôçí ÅëëÜäá äéÝðåôáé áðü ôçí êåßìåíç
åëëçíéêÞ íïìïèåóßá.
2. Õðçñåóßåò ðéóôïðïßçóçò óôïõò êáëõðôüìåíïõò áðü ôç
íïìïèåóßá ôçò ÅõñùðáúêÞò ¸íùóçò ãéá ôçí çëåêôñïíéêÞ
õðïãñáöÞ ôïìåßò, åöüóïí ðñïÝñ÷ïíôáé áðü Üëëç ÷þñá ìÝëïò ôçò ÅõñùðáúêÞò ¸íùóçò, óõíåðÜãïíôáé ôéò ßäéåò Ýííïìåò óõíÝðåéåò ìå ôéò áíôßóôïé÷åò õðçñåóßåò ðéóôïðïßçóçò,
ðïõ ðáñÝ÷ïíôáé áðü ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò, ï
ïðïßïò åßíáé åãêáôåóôçìÝíïò óôçí ÅëëÜäá.
3. Ðñïúüíôá çëåêôñïíéêÞò õðïãñáöÞò, ôá ïðïßá óõíÜäïõí
ìå ôçí êåßìåíç íïìïèåóßá ôçò ÅõñùðáúêÞò ¸íùóçò, óõíåðÜãïíôáé ôéò ßäéåò Ýííïìåò óõíÝðåéåò ìå ôá áíôßóôïé÷á ðñïúüíôá
çëåêôñïíéêÞò õðïãñáöÞò, ôá ïðïßá ðñïÝñ÷ïíôáé áðü ôçí ÅëëÜäá. Éäéáßôåñá, ç äéáðßóôùóç óõììüñöùóçò ðñïò ôçí êåßìåíç íïìïèåóßá ôçò ÅõñùðáúêÞò ¸íùóçò, ðïõ áöïñÜ ðñïûðïèÝóåéò ãéá áóöáëåßò äéáôÜîåéò äçìéïõñãßáò ôçò õðïãñáöÞò áðü öïñÝá óôïí ïðïßï Ý÷åé áíáôåèåß ç äéáðßóôùóç áõôÞ
óýìöùíá ìå ôç íïìïèåóßá êñÜôïõò ìÝëïõò ôçò ÅõñùðáúêÞò
¸íùóçò, Ý÷åé Üìåóç éó÷ý êáé óôçí ÅëëÜäá.
4. Ôá áíáãíùñéóìÝíá ðéóôïðïéçôéêÜ, ðïõ åêäßäïíôáé óôï
êïéíü áðü ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò, ï ïðïßïò åßíáé
åãêáôåóôçìÝíïò óå ÷þñá åêôüò ôçò ÅõñùðáúêÞò ¸íùóçò, åßíáé íïìéêþò éóïäýíáìá ìå ôá åêäéäüìåíá áðü ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò åãêáôåóôçìÝíï óôçí ÅõñùðáúêÞ ¸íùóç, åöüóïí:
á) ï ðÜñï÷ïò áõôüò ðëçñïß ôïõò üñïõò ôïõ ðáñüíôïò ÄéáôÜãìáôïò êáé Ý÷åé äéáðéóôåõèåß åèåëïíôéêþò óå êñÜôïò -ìÝëïò ôçò ÅõñùðáúêÞò ¸íùóçò
â) ãéá ôï óõãêåêñéìÝíï ðéóôïðïéçôéêü Ý÷åé åããõçèåß ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò, ðïõ åßíáé åãêáôåóôçìÝíïò óå
êñÜôïò-ìÝëïò êáé ðëçñïß ôïõò üñïõò ôïõ ðáñüíôïò ÄéáôÜãìáôïò.
ã) ôï áíáãíùñéóìÝíï ðéóôïðïéçôéêü ôïõ ðáñü÷ïõ õðçñåóéþí ðéóôïðïßçóçò áíáãíùñßæåôáé âÜóåé äéìåñïýò Þ ðïëõìåñïýò óõìöùíßáò ìåôáîý ôçò ÅõñùðáúêÞò ¸íùóçò êáé ôñßôùí
÷ùñþí Þ äéåèíþí ïñãáíéóìþí.
¢ñèñï 6
Åõèýíç ôùí ðáñü÷ùí ðéóôïðïßçóçò
1. Ï ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò, äéáðéóôåõìÝíïò Þ
ìç, ðïõ åêäßäåé áíáãíùñéóìÝíï ðéóôïðïéçôéêü óôï êïéíü Þ åããõÜôáé ãéá ôçí áêñßâåéá ôÝôïéïõ ðéóôïðïéçôéêïý, åõèýíåôáé
Ýíáíôé ïðïéïõäÞðïôå öïñÝá Þ öõóéêïý Þ íïìéêïý ðñïóþðïõ
ãéá ôç æçìßá ðïõ ðñïêëÞèçêå óå âÜñïò ôïõ åðåéäÞ ôï ðñüóùðï áõôü åýëïãá âáóßóèçêå óôï ðéóôïðïéçôéêü, üóïí áöïñÜ:
á) ôçí áêñßâåéá, êáôÜ ôç óôéãìÞ ôçò ÝêäïóÞò ôïõ, üëùí ôùí
ðëçñïöïñéþí ðïõ ðåñéÝ÷ïíôáé óôï áíáãíùñéóìÝíï ðéóôïðïéçôéêü, êáèþò êáé ôçí ýðáñîç üëùí ôùí óôïé÷åßùí ðïõ
áðáéôïýíôáé ãéá ôçí ÝêäïóÞ ôïõ.
â) ôç äéáâåâáßùóç üôé ï õðïãñÜöùí, ç ôáõôüôçôá ôïõ ïðïßïõ âåâáéþíåôáé óôï áíáãíùñéóìÝíï ðéóôïðïéçôéêü, êáôÜ ôç
óôéãìÞ ôçò ÝêäïóÞò ôïõ, êáôåß÷å äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò, ðïõ áíôéóôïé÷ïýóáí óôá áíáöåñüìåíá Þ êáèïñéæüìåíá óôï ðéóôïðïéçôéêü äåäïìÝíá åðáëÞèåõóçò ôçò õðïãñáöÞò.
ã) ôç äéáâåâáßùóç üôé áìöüôåñá ôá äåäïìÝíá äçìéïõñãßáò
õðïãñáöÞò êáé åðáëÞèåõóçò õðïãñáöÞò ìðïñïýí íá ÷ñçóéìïðïéçèïýí óõìðëçñùìáôéêÜ, åöüóïí ðñïÝñ÷ïíôáé áðü
ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò.
2. Ï ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò åõèýíåôáé åðßóçò,
áí ðáñáëåßøåé íá êáôáãñÜøåé ôçí áíÜêëçóç ôïõ ðéóôïðïéçôéêïý.
3. Óå üëåò ôéò ðáñáðÜíù ðåñéðôþóåéò ï ðÜñï÷ïò äåí åõèýíåôáé, áí áðïäåßîåé üôé äåí ôïí âáñýíåé ðôáßóìá.
4. Óôï áíáãíùñéóìÝíï ðéóôïðïéçôéêü äýíáíôáé íá áíáãñÜöïíôáé, áðü ôïí ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò, ðåñéïñéóìïß ÷ñÞóçò áõôïý, õðü ôçí ðñïûðüèåóç üôé ïé ðåñéïñéóìïß
ôßèåíôáé êáôÜ ôñüðï, ï ïðïßïò åßíáé áíáãíùñßóéìïò áðü ïðïéïíäÞðïôå ôñßôï. Ó´áõôÞ ôçí ðåñßðôùóç ï ðÜñï÷ïò õðçñåóéþí
ðéóôïðïßçóçò äåí åõèýíåôáé ãéá ôç æçìßá ðïõ ðñïêýðôåé áðü
ôçí õðÝñâáóç ôùí áíáöåñüìåíùí ðåñéïñéóìþí êáôÜ ôç ÷ñÞóç ôïõ áíáãíùñéóìÝíïõ ðéóôïðïéçôéêïý.
5. Óôï áíáãíùñéóìÝíï ðéóôïðïéçôéêü äýíáíôáé íá áíáãñÜöïíôáé, áðü ôïí ðÜñï÷ï õðçñåóéþí ðéóôïðïßçóçò, üñéá ãéá
ôï ýøïò ôùí óõíáëëáãþí, ãéá ôéò ïðïßåò ìðïñåß íá ÷ñçóéìïðïéçèåß ôï ó÷åôéêü ðéóôïðïéçôéêü, ìå ôçí ðñïûðüèåóç üôé ôá
üñéá áõôÜ ôßèåíôáé êáôÜ ôñüðï áíáãíùñßóéìï áðü ïðïéïíäÞðïôå ôñßôï. Óôçí ðåñßðôùóç áõôÞí ï ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò äåí åõèýíåôáé ãéá ôç æçìßá ðïõ ðñïêáëåßôáé áðü
ôçí õðÝñâáóç ôùí ïñßùí áõôþí.
6. Ôá ïñéæüìåíá óôéò äéáôÜîåéò ôùí ðáñáðÜíù ðáñáãñÜöùí éó÷ýïõí ìå ôçí åðéöýëáîç ôùí äéáôÜîåùí ôïõ í.
2251/1994 (Á´191)üðùò éó÷ýåé ãéá ôçí ðñïóôáóßá êáôáíáëùôþí êáé éäéáßôåñá ãéá ôéò êáôá÷ñçóôéêÝò ñÞôñåò ôùí óõìâÜóåùí, ðïõ óõíÜðôïíôáé ìå êáôáíáëùôÝò.
¢ñèñï 7
Ðñïóôáóßá äåäïìÝíùí
1. Ïé ðÜñï÷ïé õðçñåóéþí ðéóôïðïßçóçò, ç Å.Å.Ô.Ô êáé ïé öïñåßò ôïõ Üñèñïõ 4 ôïõ ðáñüíôïò ÄéáôÜãìáôïò õðüêåéíôáé
óôéò äéáôÜîåéò ôïõ í. 2472 /1997 (Á´ 50) êáé ôïõ Í. 2774 /1999
(Á´ 287) ãéá ôçí ðñïóôáóßá ôïõ áôüìïõ áðü ôçí åðåîåñãáóßá
äåäïìÝíùí ðñïóùðéêïý ÷áñáêôÞñá.
2. Åéäéêüôåñá ï ðÜñï÷ïò ôùí õðçñåóéþí ðéóôïðïßçóçò ðïõ
åêäßäåé ðéóôïðïéçôéêü, äýíáôáé íá óõãêåíôñþíåé äåäïìÝíá
ðñïóùðéêïý ÷áñáêôÞñá ãéá ôçí Ýêäïóç ðéóôïðïéçôéêþí ìüíï áðåõèåßáò áðü ôï åíäéáöåñüìåíï ðñüóùðï Þ êáôüðéí ñçôÞò óõãêáôÜèåóÞò ôïõ êáé ìüíï óôï âáèìü ðïõ åßíáé áðáñáßôçôï ãéá ôçí Ýêäïóç êáé äéáôÞñçóç ôïõ ðéóôïðïéçôéêïý. Ç
2063
óõëëïãÞ Þ åðåîåñãáóßá äåäïìÝíùí ðñïóùðéêïý ÷áñáêôÞñá
ãéá Üëëïõò óêïðïýò áðáãïñåýåôáé, ÷ùñßò ôç óõãêáôÜèåóç
ôïõ åíäéáöåñüìåíïõ ðñïóþðïõ.
3. ÅðéôñÝðåôáé óôïõò ðáñü÷ïõò õðçñåóéþí ðéóôïðïßçóçò
íá áíáãñÜöïõí óôï áíáãíùñéóìÝíï ðéóôïðïéçôéêü øåõäþíõìï áíôß ôïõ ïíüìáôïò ôïõ õðïãñÜöïíôïò.
¢ñèñï 8
Êïéíïðïßçóç
1. Ç ÃåíéêÞ Ãñáììáôåßá Åðéêïéíùíéþí ôïõ Õðïõñãåßïõ Ìåôáöïñþí Åðéêïéíùíéþí åíçìåñþíåé ôçí ÅõñùðáúêÞ ÅðéôñïðÞ ôï ôá÷ýôåñï äõíáôüí ãéá ôçí åöáñìïãÞ ôùí äéáôÜîåùí
ôïõ Üñèñïõ 4 ôïõ ðáñüíôïò.
2. Ç Å.Å.Ô.Ô åíçìåñþíåé ôçí ÅõñùðáúêÞ ÅðéôñïðÞ ãéá ôéò
åðùíõìßåò êáé ôéò äéåõèýíóåéò üëùí ôùí äéáðéóôåõìÝíùí
åèíéêþí ðáñü÷ùí õðçñåóéþí ðéóôïðïßçóçò.
3. Ôõ÷üí áëëáãÝò ôùí ðáñáðÜíù ðëçñïöïñéþí áíáêïéíþíïíôáé ôï ôá÷ýôåñï äõíáôüí óôçí ÅðéôñïðÞ áðü ôá áíùôÝñù
üñãáíá.
¢ñèñï 9
ÐáñáñôÞìáôá
Áðïôåëïýí áíáðüóðáóôï ìÝñïò ôïõ ðáñüíôïò ôá ðáñáêÜôù ÐáñáñôÞìáôá É, II, III êáé IV
ÐÁÑÁÑÔÇÌÁ É
¼ñïé éó÷ýïíôåò ãéá áíáãíùñéóìÝíá ðéóôïðïéçôéêÜ
Ôá áíáãíùñéóìÝíá ðéóôïðïéçôéêÜ ðñÝðåé íá ðåñéëáìâÜíïõí:
á) Ýíäåéîç üôé ôï ðéóôïðïéçôéêü åêäßäåôáé ùò áíáãíùñéóìÝíï ðéóôïðïéçôéêü,
â) ôá óôïé÷åßá áíáãíþñéóçò ôïõ ðáñü÷ïõ õðçñåóéþí ðéóôïðïßçóçò êáé ôï êñÜôïò, óôï ïðïßï åßíáé åãêáôåóôçìÝíïò,
ã) ôï üíïìá ôïõ õðïãñÜöïíôïò Þ øåõäþíõìï ðïõ áíáãíùñßæåôáé ùò øåõäþíõìï,
ä) ðñüâëåøç åéäéêïý ÷áñáêôçñéóôéêïý ôïõ õðïãñÜöïíôïò,
ðïõ èá ðåñéëçöèåß åöüóïí åßíáé óçìáíôéêü óå ó÷Ýóç ìå ôïí
óêïðü ãéá ôïí ïðïßï ðñïïñßæåôáé ôï ðéóôïðïéçôéêü,
å) äåäïìÝíá åðáëÞèåõóçò õðïãñáöÞò ðïõ áíôéóôïé÷ïýí
óå äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò õðü ôïí Ýëåã÷ï ôïõ
õðïãñÜöïíôïò,
óô) Ýíäåéîç ôçò Ýíáñîçò êáé ôïõ ôÝëïõò ôçò ðåñéüäïõ
éó÷ýïò ôïõ ðéóôïðïéçôéêïý,
æ) ôïí êùäéêü ôáõôïðïßçóçò ôïõ ðéóôïðïéçôéêïý,
ç) ôçí ðñïçãìÝíç çëåêôñïíéêÞ õðïãñáöÞ ôïõ ðáñü÷ïõ
ôùí õðçñåóéþí ðéóôïðïßçóçò ðïõ ôï åêäßäåé,
è) ôõ÷üí ðåñéïñéóìïýò ôïõ ðåäßïõ ÷ñÞóçò ôïõ ðéóôïðïéçôéêïý, êáé
é) ôõ÷üí üñéá óôï ýøïò ôùí óõíáëëáãþí ãéá ôéò ïðïßåò ôï
ðéóôïðïéçôéêü ìðïñåß íá ÷ñçóéìïðïéçèåß.
ÐÁÑÁÑÔÇÌÁ ÉÉ
¼ñïé éó÷ýïíôåò ãéá ðáñü÷ïõò õðçñåóéþí ðéóôïðïßçóçò
ðïõ åêäßäïõí áíáãíùñéóìÝíá ðéóôïðïéçôéêÜ
Ïé ðáñü÷ïé õðçñåóéþí ðéóôïðïßçóçò ðñÝðåé:
á) íá áðïäåéêíýïõí ôçí áðáñáßôçôç áîéïðéóôßá ãéá ôçí ðáñï÷Þ õðçñåóéþí ðéóôïðïßçóçò, óýìöùíá ìå ôá åêÜóôïôå
éó÷ýïíôá êñéôÞñéá,
â) íá äéáóöáëßæïõí ôçí ðáñï÷Þ áóöáëþí êáé Üìåóùí õðçñåóéþí êáôáëüãïõ êáé áíÜêëçóçò,
ã) íá äéáóöáëßæïõí üôé ç çìåñïìçíßá êáé ï ÷ñüíïò Ýêäïóçò
Þ áíÜêëçóçò ðéóôïðïéçôéêïý ìðïñåß íá ðñïóäéïñéóôåß åðáêñéâþò,
ä) íá ðñïâáßíïõí, ìå êáôÜëëçëá ìÝóá êáé óýìöùíá ìå ôï
åèíéêü äßêáéï, óå åðáëÞèåõóç ôçò ôáõôüôçôáò êáé åíäå÷ïìÝíùò ôõ÷üí åéäéêþí ÷áñáêôçñéóôéêþí ôïõ áôüìïõ óôï üíïìá
ôïõ ïðïßïõ Ý÷åé åêäïèåß áíáãíùñéóìÝíï ðéóôïðïéçôéêü.
å) íá áðáó÷ïëïýí ðñïóùðéêü ðïõ äéáèÝôåé ôçí êáôÜñôéóç,
ôçí åìðåéñßá êáé ôá ðñïóüíôá ðïõ åßíáé áðáñáßôçôá ãéá ôéò
2064
ðáñå÷üìåíåò õðçñåóßåò, éäßùò éêáíüôçôá óå äéá÷åéñéóôéêü
åðßðåäï, ôå÷íïãíùóßá êáé åìðåéñßá óôéò çëåêôñïíéêÝò õðïãñáöÝò êáé åîïéêåßùóç ìå ôéò êáôÜëëçëåò äéáäéêáóßåò áóöÜëåéáò êáé íá ÷ñçóéìïðïéïýí êáôÜëëçëåò äéïéêçôéêÝò êáé äéá÷åéñéóôéêÝò äéáäéêáóßåò, ïé ïðïßåò íá áíôéóôïé÷ïýí ðñïò áíáãíùñéóìÝíá ðñüôõðá.
óô) íá ÷ñçóéìïðïéïýí áîéüðéóôá óõóôÞìáôá êáé ðñïúüíôá ôá
ïðïßá ðñïóôáôåýïíôáé Ýíáíôé ôñïðïðïßçóçò êáé íá äéáóöáëßæïõí ôçí ôå÷íéêÞ êáé êñõðôïãñáöéêÞ áóöÜëåéá ôùí äéåñãáóéþí ðéóôïðïßçóçò ïé ïðïßåò õðïóôçñßæïíôáé áðü áõôÜ.
æ) íá ëáìâÜíïõí ìÝôñá Ýíáíôé ôçò ðëáóôïãñÜöçóçò ðéóôïðïéçôéêþí êáé óå ðåñßðôùóç ðïõ ï ðÜñï÷ïò ðéóôïðïßçóçò
ðáñÜãåé äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò íá åããõþíôáé
ôçí ôÞñçóç ôïõ áðïññÞôïõ êáôÜ ôç äéÜñêåéá ôçò äéåñãáóßáò
ðáñáãùãÞò ôùí åí ëüãù äåäïìÝíùí.
ç) íá äéáèÝôïõí åðáñêåßò ÷ñçìáôéêïýò ðüñïõò þóôå íá ëåéôïõñãïýí óýìöùíá ìå ôéò áðáéôÞóåéò ðïõ êáèïñßæïíôáé óôçí
ïäçãßá, éäßùò ãéá ôçí áíÜëçøç ôçò åõèýíçò æçìéþí,
è) íá êáôáãñÜöïõí ôï óýíïëï ôùí óõíáöþí ðëçñïöïñéþí
ðïõ áöïñïýí Ýíá áíáãíùñéóìÝíï ðéóôïðïéçôéêü ãéá ÷ñïíéêü
äéÜóôçìá ôñéÜíôá (30) åôþí, éäßùò ãéá ôçí ðáñï÷Þ áðïäåéêôéêþí óôïé÷åßùí ðéóôïðïßçóçò óå íïìéêÝò äéáäéêáóßåò. Ç êáôáãñáöÞ áõôÞ äýíáôáé íá ðñáãìáôïðïéåßôáé ìå çëåêôñïíéêÜ ìÝóá.
é) íá ìçí áðïèçêåýïõí Þ áíôéãñÜöïõí äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò ôïõ áôüìïõ ðñïò ôï ïðïßï ï ðÜñï÷ïò õðçñåóéþí ðéóôïðïßçóçò ðáñÝó÷å õðçñåóßåò äéá÷åßñéóçò êëåéäéþí.
éá) ðñéí óõíÜøïõí óõìâáôéêÞ ó÷Ýóç ìå ðñüóùðï ðïõ æçôåß
ðéóôïðïéçôéêü áðü áõôïýò ãéá íá êáôï÷õñþóåé ôçí çëåêôñïíéêÞ ôïõ õðïãñáöÞ, íá ôï åíçìåñþíïõí ìå áíèåêôéêÜ ìÝóá
åðéêïéíùíßáò ó÷åôéêÜ ìå ôïõò áêñéâåßò üñïõò êáé ðñïûðïèÝóåéò ÷ñçóéìïðïßçóçò ôïõ ðéóôïðïéçôéêïý, óõìðåñéëáìâáíïìÝíùí åíäå÷ïìÝíùí ðåñéïñéóìþí ôçò ÷ñÞóçò ôïõ ðéóôïðïéçôéêïý, ôçò ýðáñîçò ìç÷áíéóìïý åèåëïíôéêÞò äéáðßóôåõóçò
êáé ôùí äéáäéêáóéþí õðïâïëÞò ðáñáðüíùí êáé åðßëõóçò äéáöïñþí. Ïé ðëçñïöïñßåò áõôÝò, ïé ïðïßåò äýíáíôáé íá äéáâéâÜæïíôáé çëåêôñïíéêþò, ðñÝðåé íá ðáñÝ÷ïíôáé åããñÜöùò, óå
åýêïëá êáôáëçðôÞ ãëþóóá. Ó÷åôéêÜ áðïóðÜóìáôá ôùí ðëçñïöïñéþí áõôþí êáèßóôáíôáé åðßóçò ðñïóéôÜ êáôüðéí áéôÞìáôïò ôñßôùí, ïé ïðïßïé âáóßæïíôáé óôï ðéóôïðïéçôéêü áõôü.
éâ) íá ÷ñçóéìïðïéïýí áîéüðéóôá óõóôÞìáôá ãéá ôçí áðïèÞêåõóç ðéóôïðïéçôéêþí óå åðáëçèåýóéìç ìïñöÞ, ïýôùò þóôå:
- ìüíï áñìüäéïé íá ìðïñïýí íá äéåíåñãïýí åéóáãùãÝò êáé
ôñïðïðïéÞóåéò
- íá ìðïñåß íá åëÝã÷åôáé ç ãíçóéüôçôá ôùí ðëçñïöïñéþí,
- íá åßíáé äõíáôÞ ç êïéíü÷ñçóôç áíÜêôçóç ðéóôïðïéçôéêþí
ìüíïí óôéò ðåñéðôþóåéò åêåßíåò ãéá ôéò ïðïßåò Ý÷åé äïèåß ç óõãêáôÜèåóç ôïõ êáôü÷ïõ êáé
- ïé ôõ÷üí ôå÷íéêÝò áëëáãÝò ðïõ èÝôïõí óå êßíäõíï ôéò åí ëüãù áðáéôÞóåéò áóöáëåßáò íá ãßíïíôáé åìöáíþò áíôéëçðôÝò
áðü ôïí ÷åéñéóôÞ.
ÐÁÑÁÑÔÇÌÁ ÉÉÉ
ÄéáóöÜëéóç áîéïðéóôßáò ôçò äçìéïõñãßáò õðïãñáöÞò
1.Ïé áóöáëåßò äéáôÜîåéò äçìéïõñãßáò õðïãñáöÞò ðñÝðåé,
ìÝóù åíäåäåéãìÝíùí ôå÷íéêþí êáé äéáäéêáóôéêþí ìÝóùí, íá
äéáóöáëßæïõí ôïõëÜ÷éóôïí üôé:
á) ôá äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò ðïõ ÷ñçóéìïðïéïýíôáé ðñïò ðáñáãùãÞ õðïãñáöþí áðáíôïýí êáô' ïõóßá,
ìüíï ìßá öïñÜ êáé üôé ôï áðüññçôï åßíáé äéáóöáëéóìÝíï.
â) ôá äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò ðïõ ÷ñçóéìïðïéïýíôáé ðñïò ðáñáãùãÞ õðïãñáöþí äåí ìðïñïýí, ìå åýëïãç
âåâáéüôçôá, íá áíôëçèïýí áðü áëëïý êáé üôé ç õðïãñáöÞ
ðñïóôáôåýåôáé áðü ðëáóôïãñáößá ìå ôá ìÝóá ôçò óýã÷ñïíçò ôå÷íïëïãßáò,
ã) ôá äåäïìÝíá äçìéïõñãßáò õðïãñáöÞò ðïõ ÷ñçóéìïðïéïýíôáé ðñïò ðáñáãùãÞ õðïãñáöþí ìðïñïýí íá ðñïóôáôåýïíôáé áðïôåëåóìáôéêÜ áðü ôïí íüìéìï õðïãñÜöïíôá êáôÜ
ôçò ÷ñçóéìïðïßçóçò áðü ôñßôïõò.
2. Ïé áóöáëåßò äéáôÜîåéò äçìéïõñãßáò õðïãñáöÞò äåí ìåôáâÜëëïõí ôá ðñïò õðïãñáöÞ äåäïìÝíá ïýôå åìðïäßæïõí
ôçí õðïâïëÞ ôùí äåäïìÝíùí áõôþí óôï õðïãñÜöïíôá ðñéí
áðü ôç äéáäéêáóßá õðïãñáöÞò.
ÐÁÑÁÑÔÇÌÁ IV
ÓõóôÜóåéò ãéá ôçí áóöáëÞ åðáëÞèåõóç ôçò õðïãñáöÞò
ÊáôÜ ôç äéáäéêáóßá åðáëÞèåõóçò ôçò õðïãñáöÞò èá ðñÝðåé íá äéáóöáëßæåôáé ìå åýëïãç âåâáéüôçôá üôé:
á) ôá äåäïìÝíá ðïõ ÷ñçóéìïðïéïýíôáé ðñïò åðáëÞèåõóç
ôçò õðïãñáöÞò áíôéóôïé÷ïýí óôá äåäïìÝíá ðïõ åìöáíßæïíôáé óôïí åðáëçèåýïíôá,
â) ç õðïãñáöÞ åðáëçèåýåôáé ìå áîéïðéóôßá êáé üôé ôï áðïôÝëåóìá ôçò åðáëÞèåõóçò åìöáíßæåôáé ìå ïñèü ôñüðï,
ã) ï åðáëçèåýùí ìðïñåß åíäå÷ïìÝíùò íá ïñßóåé ìå âåâáéüôçôá ôá ðåñéå÷üìåíá ôùí äåäïìÝíùí ðïõ õðïãñÜöïíôáé,
ä) ç ãíçóéüôçôá êáé ç åãêõñüôçôá ôïõ ðéóôïðïéçôéêïý ðïõ
áðáéôåßôáé êáôÜ ôç óôéãìÞ ôçò åðáëÞèåõóçò ôçò õðïãñáöÞò
Ý÷ïõí åëåã÷èåß ìå áîéïðéóôßá,
å) ôï áðïôÝëåóìá ôçò åðáëÞèåõóçò üðùò êáé ç ôáõôüôçôá
ôïõ õðïãñÜöïíôïò åìöáíßæïíôáé ìå ôïí ïñèü ôñüðï,
óô) ç ÷ñçóéìïðïßçóç øåõäùíýìïõ äçëþíåôáé åìöáíþò,
êáé
æ) ìðïñïýí íá åíôïðéóôïýí ôõ÷üí ôñïðïðïéÞóåéò áðôüìåíåò ôçò áóöÜëåéáò.
¢ñèñï 10
¸íáñîç éó÷ýïò
Ç éó÷ýò ôïõ ðáñüíôïò ÄéáôÜãìáôïò áñ÷ßæåé áðü ôç äçìïóßåõóÞ ôïõ óôçí Åöçìåñßäá ôçò ÊõâåñíÞóåùò.
Óôïí Õðïõñãü Ìåôáöïñþí êáé Åðéêïéíùíéþí áíáèÝôïõìå
ôç äçìïóßåõóç êáé åêôÝëåóç ôïõ ðáñüíôïò ÄéáôÜãìáôïò.
ÁèÞíá, 13 Éïõíßïõ 2001
Ï ÐÑÏÅÄÑÏÓ ÔÇÓ ÄÇÌÏÊÑÁÔÉÁÓ
ÊÙÍÓÔÁÍÔÉÍÏÓ ÓÔÅÖÁÍÏÐÏÕËÏÓ
ÏÉ ÕÐÏÕÑÃÏÉ
ÅÓÙÔÅÑÉÊÙÍ, ÄÇÌÏÓÉÁÓ ÄÉÏÉÊÇÓÇÓ
ÊÁÉ ÁÐÏÊÅÍÔÑÙÓÇÓ
ÅÈÍÉÊÇÓ ÏÉÊÏÍÏÌÉÁÓ
Â. ÐÁÐÁÍÄÑÅÏÕ
Ã. ÐÁÐÁÍÔÙÍÉÏÕ
ÄÉÊÁÉÏÓÕÍÇÓ
ÌÅÔÁÖÏÑÙÍ ÊÁÉ ÅÐÉÊÏÉÍÙÍÉÙÍ
Ì. ÓÔÁÈÏÐÏÕËÏÓ
×Ñ. ÂÅÑÅËÇÓ
ÁÐÏ ÔÏ ÅÈÍÉÊÏ ÔÕÐÏÃÑÁÖÅÉÏ

eu-publi.com

Transcript

Documenti analoghi

antenna da tetto uhf 18 elementi cod. 154384

1 COLLARI COLLARS COLLIERS COLLARES COLARES

JOTARAP

Scarica il manuale d`uso

www.gimaitaly.com TERMOMETRO A CONTATTO TH03F

Fonendoscopi GIMA - GIMA Stethoscopes

manuale Sfigmomanometri a Mercurio